服务产品化与产品服务友好化

发布时间：2023-06-29 12:02:08 丨 浏览次数：

　　在ToB企业软件行业里，企业所服务的每个客户的业务流程，经营诉求，要解决的问题差异都很大，因此「」就成为很多ToB企业是否能顺利规模化的很重要的中欧体育一个评判标准。神策数据CEO@桑文锋有一个观点：

　　产品：由乙方产品经理客户在产品使用时会遇到的问题，从产品层面的设计来提前规避或者给予友好的使用帮助说明。当客户遇到问题时中欧体育候，能够最大可能地自助解决，不需要占用乙方的人力资源。

　　咨询：需要乙方安排咨询顾问，与甲方进行线上或者线下的正式沟通后，并给出解决方案。占用几天或者一周时间，或者更长。

　　服务：与咨询类似，有乙方人员介入，但是可以在短时间内完成，比如服务人员可以直接发送帮助说明，或者截图示例即可，或者简短的线上会议来解决客户的问题。

　　产品经理如何应对这些问题？笔者认为是下面两大方向，即服务产品化与产品服务友好化。

　　同时，基于“闭环”理念，对所有用户的帮助按钮点击行为进行埋点监控，看看哪些功能的使用说明经常被点击，那么反推回来这个页面或者对话框是不是需要做进一步优化设计。再进一步，也引导用户对这些帮助文档是否真正解决了他们的问题进行主观反馈，简单一点，就需要“是”与“否”两个按钮；再复杂一些，还可以让用户勾选不满意的地方，收集更多用户的声音，从而为文档的迭代提供数中欧体育据支撑。这自然也是服务产品化的一个实践。

　　2.当出现错误时，显示明确的，可以指导用户下一步动作的提示。尽量避免返回一个纯技术的错误信息，因为这类信息可能只有小部分用户可以读懂。 当客户遇到一个问题，已经有点恼火，还看到一个看不懂的说明，可能会恼火。

　　3.产品团队与服务团队定期沟通，review数据，分析用户关心的问题，经常碰到的问题，流程中的卡点主要是哪些，从而在产品上进行迭代优化或者上线 产品服务友好化

　　比如给每个主要核心的功能都配置一个独立的URL。当客户反馈问题，服务人员捕捉到解决方案时，可以快速把URL给到用户，用户就可以继续完成他的工作。 如果没有独立的URL，那么势必需要服务人员做一个截图，然后用个箭头或者红框告诉用户，点哪里来解决问题。客户再去理解这个说明，再去操作，所耗费的时间可能就比较久了。如果再碰到前端页面改版，或者客户在使用的版本与默认的主版本不一致，那这可能就是一次无效的服务，还会增加客户的反感。案例小讨论

　　有两个用户A与B，分别是两个客户的用户，产品上给这两个客户开设了对应的项目，分别是项目X（ID是 007）与项目Y（ID是 106）。那么当这两个用户在访问某个具体功能（比如项目管理）时，他们访问的URL要不要设置差异呢？

　　用户通过访问即可使用对应的功能。 前端与后端，从当前用户的session与cookie里判断，他们具体要访问的是哪个项目。

　　具体的，A跟B通过顶部导航或者某个按钮进入这两个页面之后，访问的URL分别是 ：