注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

熊猫外交官 的博客

 
 
 

日志

 
 
 
 

客服的哲学  

2016-05-31 14:15:08|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
来公司两个月了,虽然我最开始招聘简历里写的是产品经理和项目经理,结果来的时候给我的定位是售前技术支持,但实际在干工作的时候却是让我搞类似售后客服这么一个活。可你要说任何一个公司,售后客服要是能拿到我这个工资,那也是够奇葩的了。所以虽然在工作定位上实在是大材小用,不过看在钱的份上我也就暂且忍了。虽然某些人一直感觉故意淡着我我会闹心,不过从我的角度来讲,我目前所遭遇的情景并非是我个人主观意志的选择,而是人为安排得结果。从投入产出比上来讲是严重失衡的。虽然我并不是很期待我能对这种人为的情况进行怎样的主动说服与改善,因为我无论是主动还是被动,都是被人家看起来玩弄于鼓掌之中。但这也确实给我最近一段时间充分的闲暇来思考与写一些东西。毕竟去年我之所以写的文章总量很少是因为我每天要写将近8000-10000字的公司稿件,实在是累的没心思再抽空写太多的心得。而且我发现,其实客服这个活还是有很重要的功能以及系统工程作用在里面的。所以也就有了这篇闲着蛋疼的客服的哲学。
    客服这个活得主要特点在于被动的处理客户提出的最明显的问题,所以才叫客户服务。因此客服接到的问题和需求往往也带着很强的片面性。客户往往是在使用的时候受到了障碍才想起来找你,只不过这个障碍是如何出现的,这是个需要商讨的问题。在我最初的面对的问题当中,绝大多数客户的提问往往是由于对于产品的整体概念以及具体操作理解不清,导致的无法使用。在这个阶段所有的应答基本上都可以用一个基本套路来解决,那就是做一套的产品使用说明书,然后提供N个资源建设标准模板,再把产品本身不具备的功能工具准备好,一次性的交给客户,这样基本上能够解决80%以上客户在基本问题上打转的提问发生。
    从这个角度来讲,我们会发现在很多创新性产品的早期,在很多产品服务当中都提供相关的产品说明书和备用工具包。这需要整个产品设计的时候对于自身产品的弱点非常清楚,架构设计逻辑较为清晰,才能够提供较为完备的工具包和说明方案。而当产品到了研发中期的时候,技术部门会对现有提供的工具与产品功能进行分析,进而把那些较为普遍,但前期公司为没有研发能力的自身实践的功能整合到产品当中去,用以节省客服与售后支持成本,提高产品竞争力。比如说我们现在平台对于不同课件的文件格式的转码与课件制作功能,就被列入接下来需要开发研究的一个产品项。当然,当一个产品趋于完善,在出现必要的大迭代升级以前,还有一个研发后期的概念。这个时候由于这一个产品所研究的很多技术功能,在下一代产品,以及其他产品的研制当中也能够起到相类似的作用,也就是通用技术的流通,专利技术的再转化与积累。我们通常所说的一个企业的专利技术积累也就是这个概念了,专利技术积累的技术,一定是和产品相结合,并具备一定通用价值的技术。
    而这些技术需求的发现,从某种程度上来讲往往需要客服来收集与确认。这是因为从产品架构开始对功能进行的设计往往是产品经理思路当中对客户需求的单向满足。但是不同的客户可能会存在不同的使用习惯甚至是使用目标。在这个时候,对于产品的实际掌控者就在于客户所提出的反馈,而不是靠产品经理从大框架上排兵布阵就能够应对所有现象发生的了。
   而我在第二个阶段遇到的客户提问,就是需求实现层面的问题。这个时候客户的操作目标往往千奇百怪,你要分析的不是说他表面上跟你说哪里有BUG,而是从你对产品的理解层面,如何能够实现他的这个需求。甚至很多时候客户跟你说的问题是一个过程性的伪需求,其最终目标并不是你表面上看到的那个,这个时候也需要那你为其指明一个可行的解决方案才能解决问题。这个时候客服所担任的工作其实不是应答,而是项目经理这个层面的操作指导和计划制定。假如在需求方面你确实认定这是一个真需求,是产品本身存在的缺陷和BUG的时候。那么你需要做的就不是跟客户继续扯皮了,而是要找产品设计的负责人员分析BUG出现的原因,来解决问题。
   从这个层面来讲,我认为客服虽然没法搞得跟技术那样可以写代码或者搞化学实验什么的,但客服可以帮助技术诊断问题出现的原因,以及相关的解决方案。这是因为我在做客服的时候遇到过这样一个案例。比如说我们自己的产品,有的客户提出已经在1.0的平台当中做好的课件,能不能迁移到3.0的版本当中去直接使用。我一开始问技术,技术说这是不行的,理由巴拉巴拉说了一堆,从人员有限,1.0的版本太渣设计不合理啥的说了一堆。后来因为项目推进遇到客户的抵触情绪,质疑平台的技术实力,我不得不又对这个问题进行一次诊断。只是我不是再去问技术能不能做版本迁移,而是提前研究了一下系统构架的概念,以及新版本数据录入的操作流程。然后我问了技术两个问题,第一是教师在1.0版本录入的数据源文件能不能从服务器的路径下直接导出来,第二个是与原文件对应的属性能不能用表格导出来。得到的答案是都可以。那么其实无法迁移这个事情只是无法做到自动化迁移,但事实上通过对1.0版本的文件属性进行二次修改符合3.0版本的属性规范,还是可以做到迁移的。只是没有那么智能罢了。
    虽然从理论上来讲,找个技术写个小代码解决这个问题其实也不难,但是当你没有把问题拆解到这个层面的时候,非常有可能技术就是在思路里面认为这是不存在解决方案与结果的事情。也就是说很多需求和缺陷之所以在客服和技术端没有办法得到解决,往往并不是从技术层面没有人能写出牛逼的代码,而是缺乏一个将需求从构架层面制定解决路径的视野去解决问题。虽然从客服的工资角度来讲,很难说每个公司都能花大价钱找我这种开挂的客服,不过我认为这种事情其实还是有一个解决方案的。那就是在公司内部应答机制上做一个设计。比如说公司在内部沟通的时候除了在客服与技术之间要有一个团队协作的公开平台以外,还应该将产品的技术框架予以分解和展示。当客服提出一个问题的时候,技术不能简单的说不行,而是最起码的在构架和流程图当中给出相关问题的发生点以及分析意见。这样即便是某一个人不具备相关的宏观视野,但是通过将问题的细化和分解,还是有助于别人参与到解决问题中来的。
    协同工作的实质,就是通过一个公开的平台充分暴露与贡献每个人的智慧对一个产品各个维度的系统看法,进而帮助人们锁定具体问题,具体解决工具。单纯的靠个人能力和智慧的应答是没法对复杂问题提供有效帮助的。
    在我看来,客服虽然表面上是一个针对客户应答的响应接口,但是其发挥作用的大小,完全与整个公司架构与组织机制的关系相衔接。牛逼的客服是半个产品经理,半个项目经理,还是半个销售,能够从需求直接指导后台给出产品小周期的开发迭代需求。最菜逼的客服,基本上就是拿着公司给的一套应答模板在电话边当应答机,记录相关问题,就是卖个声音而已。
  评论这张
 
阅读(10)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017