管理

如何梳理、整合一个团队

2021-06-13  本文已影响0人  沐佳

自4月接到开始整合客服团队的任务以来,花了差不多将近2个多月的时间,而到目前为止,客服团队架构开始慢慢清晰起来,在此做一些反思,希望对未来的自己有所帮助。
当然,我也与其他朋友聊天过这个案例,朋友说这些东西,在成熟的大公司其实都是习以为常的东西,但是对于创业公司又特别是创业公司发展到中型的时候,可能是制度建设中很重要的。

在期间走了很多弯路,现在想来大致可以分为如下几个阶段:

在最开始,我得到的目标是:希望通过整合客服团队,提升售前、售后用户的咨询转化率,以提升公司整体营收。我接手这项任务的主要目标是,获得用户反馈,以改进产品。当然,最终目标也是提升公司整体营收,当然,私底下,我个人还有一个目标:找机会,尝试私域流量运营群的建立,实践年初朋友告诉我的社区运营的增长方法。

于是带着这个目标,我从市场团队慢慢接手了客服团队,并与客服组长进行了第一次的讨论,希望能通过这次讨论摸底团队现有情况,在本次讨论前,我梳理了希望搞清楚问题:

但是,在讨论的过程中,我发现客服组长的态度明显有问题,其心理防御很重,很多事情一旦涉及到细节,对方就含糊其词起来,又特别是涉及到团队的一些目标、指标时,他总会顾左右而言其他,而且在谈话的过程中,一直脸色沉重、眼睛并不太敢直视我。这是十分明显地心存芥蒂,再聊下去,感觉不会再有任何借口,于是我不得不提前终止了这次谈话,作为结束语,我这样一段话:“兄弟,我们现在在一条船上,我来这个团队,并不长呆,我希望能通过客服团队的服务找到一些可能的增长点,当然,这建立在客服团队能完成基础的客服工作之上,但是,从现在我了解的情况来看,在这一点上,我们并没有做得太好,当然,这并不是你的问题,也不是某一个人的问题,而是我们整个公司并未将客服的工作放到一个重要的战略的位置。我知道,客服工作很琐碎,大家都很努力、很辛苦,而且在一个互联网公司中尤其如此,因为其他部门都是朝九晚五,而唯独我们客服部门会有三班倒;可能还会充满负能量,因为你们可能会直面那些吐槽产品的用户。但是,根据我的工作经验告诉我,如果我们能将一些管理工作做好,团队架构搭好,我们可以做到更高效。因此,我们需要一起来搭团队架构,一起将基础的一些管理工作梳理出来,这样可能会减轻大的工作量,而且可能会达到更好的效果,当然,这些都建立一个基础:这个团队必须要一个Leader,当我把团队架构完成,你们上正轨之后,我会退出,而这个Leader需要将这个机器一直运行下去。这个Leader现在看起来很可能是你,但,这需要看我们整理现在完成这个任务的效率,如果我们在本季度不能将这个架构梳理出来,届时我会面临COO方面的压力,到此时我们可能会更细粒度地介入到你们的实际工作。当然,这并不是我希望看到的。”然后,我约了第二天的时间,继续讨论。

走了会议室的那一刻,其实心里是很难受的,甚至有想骂人的冲动,但是,我还是尝试冷静下来。反思自己:其实,这很正常,虽然在一个公司,大家在电梯里见面,偶尔也会点点头互相问问好,但是,并没有接触过,一开始就审问别人的工作,这当然会引起别人的反感,又特别是,对方刚刚从市场团队换到运营部门。一个人在一个完全陌生的环境,肯定会激发自己的自我保护心理,这很正常,于是我大概也想到了接下来的谈话目的:赢得信任。

第二次会话,我开门见山:在我的理解中,客服的工作应该是公司所有团队的界面,也就是说,客服应该能调动公司的所有团队,以更高效地解决用户的问题。但是,据我观察现在好像还不是这样,我们的客服团队好像很少主动调动其他团队,而且好像也很难调动其他团队。我不知道现在是否有这样的问题,或者更直接一点:你觉得,在你们的工作中,有什么时候觉得支持不足或者资源不足的情况没?这一下,好似打开了客服组长的话匣子,说了特别常见的几个问题。但是,归结起来大致其实与很多大公司遇到的问题一致:某些流程复杂,会牵涉到好几个部门,而这些流程又没有一个明确的负责人,导致上游推下游,下游再推上游,而客服又迫于客户的压力在各个团队之间互相协调,一个很简单的问题,可能要来来回回与好几个人沟通,才能最终解决用户问题。于是,我让其选择一个或者两个现在最常见又最复杂的流程,我来想办法。然后,我大概也说了一下处理方案:“我会先将该流程梳理完成,形成成文的流程图,之后,会协调相应的部门负责人,让其指定专门的流程负责人,并最终将流程及流程负责人与COO同步。之后,我们遇到什么问题,直接对着流程来处理就好了,那如果这么处理了,你觉得会解决当前的问题吗?”客服组长思考了一会:“这样肯定会呀,但是,能做到这样吗?”我笑着回复“应该会的,毕竟,我不要脸在公司可是出了名的。”他也笑笑。于是,我结束了这次谈话。并约了一周之后的会议。

第二周很快就来了,期间我完成了上次流程的梳理,明确了流程负责人。其实,期间也没有遇到特别大的阻力,只是大家都只知道自己知道的那一块儿,并不知道他的上下游是怎么样的,这样就导致了他也只能处理自己的那一块,而有了这个流程之后,流程参与者既见树木,又见树林,自然也就知道该如何自主协同上下游,一起搞定这件事了,但是他们也反馈了一个问题:客服在问问题的时候,时常提供的信息不全,这也导致他们在核查问题的时候需要找客服再次确认信息,而客服又需要再与用户沟通,而客户可能会存在并不太方便,或者联系不上的情况,这些也会导致一些问题处理的时间周期拉长(当然,其实这也让我很好奇,为什么大家都愿意日复一日地去处理自己并不知道具体情况的工作,为什么这些显而易见的效率问题,都不愿意跨出沟通的那一步呢?)。于是,带着这些信息,我和客服组长开始了第二次的会话。在这一次会话中,我首先给他展示了这一个周的工作成果。这时,我观察到,客服组长的态度明显好了很多,我感觉能继续回到之前最开始想问的那些问题:”客服团队的现有目标到底是什么?”客服组长经历了2-30分钟的描述,其间大多都是琐碎的日常工作,但是,透过这些锁碎,你能明显感觉到其实就一句话:“稳定压倒一切,千万不要出事儿!”所谓进取、所谓创新、所谓真正意义上解决用户问题,这些都是不存在的。团队人员结构是按平台来划分的,自有平台包括APP、微信端两个人,其中一个包括组长本人,电商平台三个人,负责京东、淘宝等电商平台的客户对接。暂时没有感觉什么问题。团队中除了回复问题之外,还有一部分内部流程的工作,储如帮助市场团队录入线上销售订单(由于友商的开发能力,他并没有提供可同步的数据应用接口,又特别是一些CPS小渠道)。在讨论的过程中,我隐约感觉到这里边有问题,但是,这个感觉又抓不住。不过,这想要的探究的问题已经有了答案,于是我中止了此次讨论,并约好第三天,我们再进行讨论。中间隔了一天,是因为这个信息量其实对我来说还有点儿大,需要更多的时间进行整理与补充。
接下来,我开始整理相应的文档,在整理的时候,有一个问题慢慢浮现出一个问题:如何梳理一个团队,才算完整呢?当然,这个其实与我们做产品时的那个经典问题一样:“比起what to think,how to think更加重要。”于是,我开始去查找相关的资料,并结合当前遇到的问题提出了自己梳理团队的方法框架。


梳理团队的框架

根据我收集到信息,加上我对客服的了解,对框架总结如下图所示,当然,实际的情况比这个复杂很多,又特别是流程与职能,当我把我们公司的客服工作真正梳理完成,我大约整了22个流程,把公司除了行政和人力之外的其他所有团队都包含在我们的流程中了。


客服框架实施

在梳理的过程中,还发现了许多可改进的流程,这让我有一个感悟:公司存在的最终奥义就是为了解决用户的问题,客服在遇到问题的时候,理应、也应该有权利调动公司所有部门、所有资源去解决用户的问题。
当完成这个梳理之后,我开始了与客服组长的第四次讨论,在讨论会上,首先跟进了一次上一个流程的执行情况,在获知明显效率提升之后,我开始了本次的主要议题:

  1. 重新定义客服的使命:解决用户的问题,为用户提供良好的用户体验。将不为这个使命服务的工作全部移到单独的部门。我们暂且称其为后台流程部门,主要负责走用户可等待的售后流程。
  2. 重构客服团队,不再按平台拆分,而是按业务的类别将客服团队拆分为两个大的团队:售前团队,负责接待用户,如果遇到售后问题,记录并转交给售后团队,其主要指向的指标是转化率;售后团队,负责处理用户更加专业的售后问题,其主要负责的指标是用户满意度评分。
  3. 重新梳理团队的KPI。尽量以80%的定量指标如:转化率、用户满意度、首响时长、平均响应时长等等来衡量客服团队每一个人的工作。
  4. 对客服组长的KPI进行拆分。他将仍有20%的时间在一线客服,但需要花更多的时间在团队管理之上。因此,他的KPI中有20%仍为一线客服得分,80%的在团队管理得分,而管理得分主要看每一个成员的KPI考核结果。

至此,基本上客服的整个架构工作基本告一段落,从客服的会话核查来看,一切都在向着好的方向发展。然而,正当准备庆祝的时候,竟然出现了一起突发情况,而这个情况差点导致前功尽弃。欲知后事如何,且听下回分解。

上一篇下一篇

猜你喜欢

热点阅读