序言

　　互联网产品有着鲜明的特点：功能更新速度快、线上活动多、上线时间紧迫等，作为一个互联网公司的客服中心，我们如何利用完善的上线支持流程给予产品部门更多的支持？如何提供更准确的数据保障？如何将更多的用户建议及意见收集起来？

　　我本人目前任职于新浪网客户服务中心，在本篇文章中，将会结合日常积累的一些经验，针对客户中心在新产品（功能）上线支持流程，做一些探讨。

第一部分 支持流程描述

一、产品立项阶段

　　客服中心从产品立项开始，就介入到产品项目组中，加入PDT（Product Development Team）核心成员小组，参加每次项目组的例会，了解项目进展。这样做的好处在于：

　　A 客服中心是和用户接触的一线部门，更了解用户的日常使用习惯，可以给予产品部门更多来自用户的声音；更多来自用户的看法。在某种程度上，客服中心是最能代表用户的。

　　B 我们可以更加深入的了解这个产品的理念，更好的去理解产品的侧重点、受众群体等，更有利于日后制定客服的工作重点（如倾向性收集用户意见；线上问题归类汇总等）。

　　C 可以和产品组人员尽快的熟悉，相互了解，为以后的接口、沟通等工作搭好平台。

二、需求评审阶段

　　这个阶段，是产品经理最繁忙的，对于客服中心来讲，也是一个关键阶段，在这期间，要求客服中心做到：

　　A 要参加每次需求评审会，了解产品重点功能。

　　B 对那些可能会影响到用户感受、使用习惯的需求，一定要多站在用户角度思考问题并及时说出自己的建议，请整个产品项目组进行讨论。

　　C 某些特殊敏感工作流程（查找密码、付费用户使用权益等问题），一定要及时和产品经理沟通，及早确认法务问题、服务流程等工作。

三、开发/联调阶段

　　这个阶段，“团队明星”的聚焦点在开发和运维工程师团队中。

四、产品测试阶段

1、测试工作：

　　需要成立客服中心测试小组（3-4人），由接口二线带领，开始对新产品进行内部测试。测试的重点在于：产品BUG、使用简易度建议、文字描述查错等

　　应挑选细心、总结能力强的人员参与测试，测试前，统一规定测试流程及测试文档结构，测试时间不应超过2天。

　　测试团队的内部工作分配可分为两种：

　　A 分块测试（适用于大产品）：将产品功能划分为几个大块，分配给测试成员进行分块测试。

　　B 整体测试（适用于小产品）：测试产品所有功能。

　　测试完成后，由接口二线总结测试文档，反馈给产品部门。

样例：测试文档结构要求

一、信息概述：

　　产品线名称：

　　参与测试人员：

　　测试环境描述（操作系统、网络环境、软件环境）：

　　测试时间（精确到小时）：

二、内容描述：

　　产品bug类（罗列测试过程中遇到的页面报错、产品BUG等）：

　　文字描述类（页面文字描述、系统文字提示错误）：

　　建议类（使用建议、功能性建议）：

三、疑难问题确认

需要确认的FAQ问题

一些经验：

　　一定要让一线人员参与测试，锻炼他们对产品的理解能力，增加他们的参与感。

　　测试过程中，对于出错的信息；不明确的文件描述，一定要附加截图辅助说明，这样更便于其他人的阅读。

　　对于测试报告，一定要及时评定，让参与测试的一线知晓自己报告的优缺点，有助于他们的提高，这样做还可以给予他们成功感。

2、FAQ&知识库：

　　参与完产品测试工作后，就需要制定FAQ了。

　　首先，需要请测试小组的成员，模拟用户提出使用问题。这个工作，需要尽可能多的模拟用户在使用过程中可能遇到的问题、疑问，结合产品重要功能做出总结。

　　其次，将重要问题和测试过程中遇到的疑难问题，和产品经理进行逐一确认。

　　最后，制定统一的问题处理流程&回复口径。这个工作的最后时间戳，应该是以成功更新到知识库为准。

3、数据统计准备：

　　我们的客户对于这个产品是否？

　　我们的客户对于这个产品有什么改进建议？

　　哪个功能是最能另我们的客户满意的？哪个是最不满意的？哪个是投诉最多的？

　　和其它竞争产品相比，我们的哪些功能是最吸引用户的，哪些是被咨询最多的？

　　上线后，产品部门最想了解的问题肯定包含以上这些，产品功能、服务的再改进，对于产品未来发的展有着十分重要的意义。

　　因此，客服中心的数据就显得极为重要了，目前我们的用户问题统计数据，主要来源于业务树。

　　业务树的建立，一定要由三个方面的成员一起最终确认：

1. 领导测试小组的接口二线：确保业务树的结构符合客服中心整体要求
   
2. 产品经理：业务树结构符合产品运营侧重点
   
3. 参与测试的一线：提供使用建议，让所有一线可以更加方便的使用和记录业务树。

一些经验：

　　业务树要随着产品运营而修改，这样可以让一线的工作更高效。

4、培训&知识考核：

　　组织一线培训，将产品完全的展现在一线面前。

　　此工作的时间戳，应该是以考核完成为准，考核可以让我们来评估培训的效果及一线掌握知识点的情况。

一些经验：

　　在培训中，一线还会提出许多未确认的疑难问题及流程建议，及时的更新&确认可以让工作更加有效。

　　培训的过程中，不要一味的填鸭，一定要让一线参与进来，模仿用户提问、一线谈感想等等，都是很好的互动环节。

　　考核的试卷一定要点评，让一线加深印象。

5、接口流程：

　　产品上线后，客服中心肯定会有一些问题是需要产品工程师来协助调整的，问题如何反馈？如何监督时效性？敏感问题如何沟通？接口人是谁？这些环节都应在产品上线前尽快确认，确认需要请产品经理辅助进行。

　　一些经验：

　　目前，我们是利用第三方的软件系统来实现问题的追踪、汇总、统计工作。这个系统的名字叫做“JIRA”，目前我们已经使用了超过3年的时间，使用效果可以说超乎我们的预想。

五、产品上线阶段

1、产品上线第一周：

　　重要的时刻来了，在产品上线后的前三天，我们奉行时段报表制度，每隔3-4个小时，就让接口二线发送一次报表，给产品部门通报客服中心的用户来电情况，写明焦点问题&用户建议等。

一些经验：

　　上线后的及时沟通很重要，对于重点问题，应做到和产品经理的面对面沟通。

　　上线前的几天，每天下班后，应由产品经理召集，所有产品组的成员召开一次碰面会，我们也可以在会上及时了解产品bug、服务策略调整等重要信息的调整动态。

　　询问你的一线人员，比如这个产品和其它网站同类产品的一个比较，你觉得这个产品的有点在哪里？不足在哪里？你觉得产品未来的发展重点应在哪里？问完之后，你就能感觉到这样做的好处了。^_^

2、产品上线一周后：

　　步入到正常的客服中心产品支持流程。对某些业务树选项、问题处理流程等进行微调。

一些经验：

　　定期和一线员工沟通产品报表结构的问题，听听一线员工对问题的分析，他们认为哪些业务树的归属位置是错的，应该改进的，这对于产品报表数据的准确性是十分有帮助的。

　　有什么好的建议嘛？在遇到投诉类问题时，一定要随时问一下一线员工，听听他们对于处理流程和产品功能的看法，也会给你许多帮助的。

第二部分 阶段性重点工作简述图

　　以上，就是对于目前客服中心在新产品上线流程中扮演的角色及重点工作的一个综述，也是对日常工作的一个总结，希望有机会可以和诸位探讨，也感谢诸位的耐心阅读。

　　作者为新浪网客服中心经理。