一个客服运营者的产品观

    |     2016年12月25日   |   会员信息, 文库   |     评论已关闭   |    1546

产品与客服运营追根溯源是一家,两者的关系应该是包含与被包含的关系。没有产品就无从谈服务,其实这个观点也是前段时间行业内去“中心化”(企业内部由集权向分权)转变的本质所在。今天就和大家聊聊作为一个客服运营者如何看待产品与服务运营的关系以及和产品人的相处之道。

产品管理的价值是为企业盈利,而服务运营的价值是为产品增加附加值。所以我们可以认为客服运营工作其实都是为产品“打工”的。脱离对产品深入理解的运营容易偏离真正的目标,譬如我们做客服运营不仅要考虑人力成本、产能服务指标等,也同时要了解产品的用户体验、转化价值路径、后续用户行为等才能体现客服运营的附加价值。

什么是好产品?本人并不认同业界流行的一句话:“即使是屎一样的产品,运营也要在上面种出花”,这是对产品设计责任的推诿,是对各类运营资源的极度浪费。

有一个经典的命题:在你眼中什么样的产品算好产品?回答可能是“有口碑的产品”、“用户量和DAU都很棒的产品”、“像微信这样牛逼的产品”、“很赚钱的产品”。

这些回答有两层根据,第一是所描述的理由在一定程度上代表了这个产品“活”的很不错;第二是深刻经历过反面的“坑”,越发觉得这才是我想服务的产品。

好产品有一些共同的特性,诸如满足用户需求、体验好等,但在客服人的眼中,这些标准并没有卵用,因为我们没有专业视角也区分不了。每个产品都会做需求分析,设计和体验好是标配,关键差别是需求满足的方式和程度不同,导致产品自带的势能表现不同。

从客服运营的角度来反思,“体验好”的产品才是好产品。怎么算“好体验”:

1、用户教育成本低;
2、所见即所得;
3、营销支持到位。

串联起来的意思是“用户可以清晰便捷地参与产品体验,服务满意,并乐意适当地参与到互动与传播”。“好的客服运营”反应了需求满足方式合理,运营低成本撬动高增长。当然,这不代表运营就投入少,而是根据阶段性目标,投入产出比合理。

一般而言,客服缺少的是产品经理的专业视角,判断产品品质的主要根据来自于用户的反馈、数据的精细分析、增长需求以及积累下来的运营理念。

我们从客服对产品品质判断的三个方面来理解运营如何参与到产品管理中。

•用户教育成本

教育成本实际就是获得新用户的成本,包含了几层含义:

1)用户角度的产品定义

在宣传时,我们应从用户角度来对产品进行定义和描述,而不是从专业角度罗列产品的各项技术性功能,要使文案在第一时间激发用户想象和进一步了解的兴趣。

2)用户对产品预期

要考虑产品的设计理念是否能真观体现核心服务,产品是否符合宣传预期。同时要谨慎制定规则,请勿将规则创新当做产品创新,这会让用户产生不适。

3)引导首次体验

要保证有足够的内容、数据,并及时、高效地向用户传达产品的活跃度。

教育成本问题集中体现在用户管理的前置环节,在客服运营执行层面上很容易得到反馈:

1、建立用户基地包括电话、在线客服渠道及UGC社区等交互渠道,收集最底层的反馈,判断产品问题集中的类型是BUG、体验还是根本理念问题。

2、观察数据,如果教育成本高,那么留存率、核心业务的点击率和使用率都会明显偏低。做客服运营也许不了解产品的具体设计和改良方法,但必须能够判断得出产品问题的方向。

•所见即所得

指的是产品的服务体验足够好,即需求被满足。举个简单的例子,工具类的产品如百度、Google,查询结果便是需求,很直接;社交通讯类的微信是早期体验好,用户量逐步增长,并呈良性循环。从产品角度来讲,显然前者的客服运营比后者要容易一些。这两个例子更多是模式的选择,不算产品把控问题,只是说明“所见即所得”对服务难度的影响。

由此可以总结出:当核心服务的边际成本不再随着用户的增长而增长,那么客服运营的均衡点问题便达到了。譬如UGC社区,当运营机制和环境完善后,用户增长,UGC也会自然增长,不再需要增加人力投入,从而达到平衡。这与增长黑客中的PMF理念异曲同工。

回归服务运营层面,需注重两点:

1)注意覆盖率和体验度

产品不可能满足所有用户的需求,客服服务是有边界的。要做到服务周到就要通过数据去跟踪客户特定行为的比例和路径,在产品上做引导、推荐等,并优化点击率、使用率,降低因为增加覆盖率所导致的用户流失。

体验度表现在对于可能引发用户中断服务(用户体验差)的环节的优化。

举几个客服端的例子,在线客服机器人自助服务功能中,当用户提问后系统会将后台数据通过一定关键字匹配后展现给用户,这样在一定程度上可以降低提问者的等待时间,提升服务满意度。

另外包括web端与H5页面报错、加载页面、概念说明,都是引发用户不满和不爽的地方,需要详尽地添加文案、进行引导或自动跳转。

以上都是通过服务的转化漏斗分析来反向推动产品优化。

2)需求的挖掘

譬如电商平台的商家端,一开始只有上下架、编辑管理、财务结算等功能,而随着用户数增长,就需要挖掘商家的营销需求,可以对买家分层、灵活地给予促销支持等。通过热点分析、互动分析留意用户的集中行为,譬如用户频繁点击“经验”明细,可以在分析后尝试围绕“经验”设计活动。

因此客服需要有敏锐的数据观察能力,并对用户行为的因果有分析思维。

•营销支持

营销支持是业内各类型客服中心提出最多的需求,涉及的类型很多,包括用户互动、积分、分享、邀请、活动等。对于产品经理和技术人员来说,它不一定属于核心业务的优先级,但确实是组织赖以生存的武器。从运营的角度讲做好营销支持有几个要点:

1)场景结合

现在很多标配的营销功能已经没有红利了,不再是放个入口数据就能蹭蹭上涨。拿分享功能来说,如何在合适的路径嵌入,如何进行利益刺激,流量回流时用H5互动还是直接下载,甚至可以考虑与“有奖邀请”结合来发挥作用,这些策略需要做精细化设计。

2)降低技术成本

提需求时要充分了解技术的难度和周期,在维持核心规则的前提下多考虑第三方工具和折中方案,甚至通过第三方引入来增加合作资源。

3)文档和跟进

技术(IT实施者)或者是产品(经理),有时候并不能充分、时时了解营销产品的关键意义,就需要有对应的说明文档,并且永远要坚信“上线无BUG才是真的无BUG”。测试环境下以及技术口中的无BUG仅可作为参考,所以要尽量提前上线或小规模测试。

•客服运营者眼中的产品人

服务运营者也可以看作是产品的“共同家长”,而每个孩子的天赋和适合的成长路径也许家长并不知晓,可能会短视、急于求成或者只管自己的一亩三分地。产品经理像管家,整体协调监管产品的开发运营,并控制每个需求的技术支出。所以最终需要运营人来督促“成长”,产品经理帮助其“塑身整形”。

1)产品人、客服人不可或缺

前面一直强调服务运营需要把控产品,这是对运营提的要求,而实际上,产品经理的同样高度关注数据、转化、用户行为,他们有用户分析的专业知识,对用户行为的因果关系更了解,把控产品的整体设计,并对部分产品数据负责。

产品经理的另外一个能力是帮助服务运营者将抽象的需求化作逻辑清晰的产品需求,并设计出可视化模型,协调设计和开发资源,跟进需求上线。

在一定程度上,产品经理就是客服运营者手中的阿拉丁神灯。

二、产品人、客服人亦友似敌

好的产品经理喜欢研究产品和用户,他们并不会排斥各种需求,甚至也会喜欢客服工作,但他们也烦客服,觉得客服部门:

1、异想天开、盲目提需求,不考虑产品的扩展性和整体规划;

2、像出头鼹鼠一样临时提需求、改需求;

3、不懂产品技术原理,对牛弹琴。

同样,客服人也会“讨厌”产品经理:

1、无视用户需求,自作主张做设计和改需求,常爱以“XX产品也是这样做”为由,并不真正重视客户体验;

2、一味压低客服需求的优先级;

3、产品BUG太多,怀疑没有做过测试。

3)如何配合

多数情况下,客服主要是对用户体验、集中进线问题和留存数据负责,产品经理对产品迭代、需求上线、测试负责,不同公司架构不同,导致关注目标不同,这无可厚非,这里我们列举一下二者日常配合时应注意的要点。

A、双方能力均衡、能换位思考。客服要了解产品的原理和生产流程,有主动研究和体验产品细节的精神,在向产品部门提需求时做到有理有据。产品经理则要熟悉在行业竞争环境下用户行为的变化特征。只有当双方能力平衡的时候,才能换位思考,降低沟通成本。

B、建立产品文档。产品经理写出完整的产品迭代功能、参数说明,客服需知晓并随时查看,一方面清楚产品的优化细节,以便在产品推广宣传时自如应对用户问题;另一方面,不会因向产品部门提无谓的客服需求而导致口角。

C、需求评估。当需求数量过多,优先级无法统一时,召开沟通例会,对需求进行评估,达成一致。

D、将用户声音及改进意见形成文档。产品经理可以直接听取一线客服端用户反馈的声音,针对用户问题主动提出产品的改进意见并形成文档。客服收集到的用户反馈和问题总结,务必以文档形式呈现,双方约定文档的格式。

E、互KPI思维。提倡产品、客服了解彼此的KPI或目标,相互推进。

譬如产品经理可以在无服务页面增加其他服务入口,这样既可以客户降低流失率(产品经理的KPI之一),还可以提升业务数据。

综上,我们强调客服需要有产品观,在策划和执行各种服务手段时充分考虑产品的属性,衡量综合成本,促进产品的改进。另一方面,尊重协作和产品逻辑,有大局观,不要做只能通过吵架来解决需求的运营。喜欢是拥有,深爱是克制。总之,眼中无产品,服务皆枉然。

本文刊载于《客户世界》2016年12月刊;作者韩露,单位为平安壹钱包。

转载请注明来源:一个客服运营者的产品观

相关文章

噢!评论已关闭。