背景

有赞作为一家 SaaS 服务公司，核心价值是为商家提供产品解决方案以及服务。 B 端产品的场景通常比较复杂，通过处理客户反馈需求，一方面满足客户诉求，提升商家的活跃度；另一方面可以从客户反馈中提炼真实使用场景和想法，反哺产品设计进行产品迭代。商家反馈的需求往往是一些经营视角的诉求，无法直接用作研发，在到研发之前，需要经过服务经理初步筛选，根据内部分工分发给对应的产品经理，产品经理对需求进行理解、合并、拆分和规划排期，这一系列的流转横跨了公司的多个职能部门。

根据精益管理的理念，一切客户不会为之买单的成本，都称之为“浪费”。站在客户的视角来看，他们并不会关心需求在有赞内部如何流转，而更关注有赞响应和解决问题的时效，要提升客户的满意度，就要减少需求流转过程中的不必要的“浪费”。

有赞为商家提供了 BBS 论坛、产品端反馈需求入口、客满热线、服务经理对接等多处反馈渠道，让商家能够更方便、快捷的反馈需求，但多个渠道反馈的商家需求如果没有进行统一的管理，就会造成一些问题：

商家反馈需求没有统一的待办列表，无法集中跟进、规划、处理。
需求处理进度无法及时更新、透明，增加了很多重复沟通和跟进成本。
上下游团队配合缺少明确的流程与问题上升机制，导致需求处理效率缓慢，积压严重。
需求处理结果没有及时闭环反馈给商家，导致商家再次咨询或投诉，满意度降低。
无法针对商家集中反馈的功能模块进行分析，驱动产品提炼更贴近商家使用场景。

效能改进与产品、服务运营等多个部门参与针对以上问题进行了分析和改进，梳理出适合跨部门多角色有效协同的方法，本篇文章大致介绍此次改进的思路以及实践经验可供参考。

一、建立端到端闭环的工作流

工作流是为了把必要的人串联起来完成某个目标，把含有多个环节或者步骤的工作，清晰地定义出每一个步骤所需要完成的事情和参与人的职责，形成共同约定和可流动的价值。一个新人加入组织，可以快速的根据工作流完成一项工作，减轻了培训和学习成本。

制定过程中有三个要点：

任务流向闭环：明确任务的传递方向和次序，确保闭环。
任务交接：明确任务交接标准与界限
推动力量：明确内在协调与约束机制如图：

工作流是一个组织优秀实践的沉淀，通过建立和不断优化端到端闭环的工作流，商家需求响应的能力得到改善：

通过明确各环节的职责范围，上下游各团队能够持续关注、协作处理，并约定了初步的处理时效。
从需求分散各处，到统一需求待办列表，建立了固定沟通机制和通道可以确保重要且紧急的需求优先安排研发。
明确各产品模块需求负责人，提升了内部沟通和处理效率。

二、解决瓶颈问题，建立 SLA （Service-Level Agreement）

商家反馈需求做到了【管】后，需要进一步做【理】的改进，目的在于提升价值的流动效率，而非单纯提升资源效率。

【约束理论】中提到过，在一条业务链中，瓶颈节点的节拍决定了整条链的节拍，任何一个多阶段生产系统，如果其中一个阶段的产出取决于前面一个或几个阶段的产出，那么产出率最低的阶段决定着整个系统的生产能力。要提升整个处理回路的效率，需要找出瓶颈环节，针对性的解决问题，疏通整个链路的流动。有赞处理商家需求的回路可分为两大周期：

响应周期：

从商家提出需求到客满或服务经理，服务经理对需求进行登记、收口并指给对应产品经理–产品经理收到需求评估是否是商家经营的本质诉求，并给出答复接受或无法满足–服务经理、客满答复商家处理结果。

解决周期：

产品经理对接受的商家需求进行方案设计–研发排期–研发上线–服务经理或客满通知商家上线

我们将处理链路上每一个环节制定了 SLA 标准，观察各环节的处理时效，并通过超时上报的机制上升反馈来保证需求可以被及时处理。最初的改进重点在推动产品经理及时响应，然而如果大量处理结果做不到及时的反馈给商家，那么前期的推动就产生不了价值。及时的将处理结果反馈给商家的好处在于，商家得到良好的反馈体验的同时，有赞可以收到商家对新功能的体验感受，带来新的反馈。以有赞目前的情况，每月收到商家反馈的需求量达到上千条，仅是产品经理对需求理解、处理，服务经理、客满对逐个需求的处理结果进行答复给商家，都会是很大一部分人力成本。而这部分的成本是商家不会为之买单的“不必要浪费”。

使用商家数不断增加，商家反馈需求数会跟着增多，从而需求整理、反馈的人力成本增加，导致占用了服务经理和产品经理真正投入去挖掘提炼真实需求的精力，整个产品的迭代优化速度会降低，影响商家的活跃度甚至会减少使用商家数。我们通过以下两个方法去减少在需求整理、反馈的成本。

2.1 降低需求梳理成本：明确商家需求优先级

我们通过商家画像、商家反馈数两个维度量化优先级，提升产品经理处理需求的效率，节省人力。

影响力：经营场景和用户角色相对复杂的行业标杆商家反馈的需求更具有行业代表性，更容易抽象高层次的模型，利于产品向下兼容。
影响面：运营将所有商家提交的相同需求关联到一起，呈现同一个需求影响商家数，来解决商家普遍反馈的需求。

2.2 降低进度反馈成本：商家端与有赞商家需求池联动

微商城、零售产品端开放了需求反馈入口，商家可以通过店铺系统后台随时反馈使用问题，同时可以随时查看需求的处理进度，从而减少了一些对需求登记、跟进、反馈的“服务人力成本”。

三、管理工具在线化

起初我们是用文档、表格来记录商家反馈的需求，交给产品经理来评估方案、更新需求的研发进度。而需求进入研发过程是在效能平台进行流转（自研项目管理工具），这样一来会有很多弊端，例如，人工维护多个需求列表的信息，会造成进度更新不及时，从而造成信息不对称，答复商家错误的进度，引起商家不满。管理者想知道商家提的需求集中在哪几个功能模块？某个商家今年总共提了多少需求？我们解决了多少，多少没有满足？这些过程数据都需要手动梳理，耗费人力。基于以上诉求，我们把商家需求前期收集的过程也做进了效能平台，让需求从商家提出一直到研发上线在同一个平台流转，便于管理需求全生命周期（如下图）。

在设计工具时需要考虑这几件事：

明确关键使用者的诉求：使用该用具的人希望通过工具解决什么问题？（业务方希望实时透明商家需求进度、产品经理希望减少处理步骤、管理者希望看到处理时效的数据）
明确想要表达的关键信息：该工具想要传递给使用者的信息是哪些？（需求的报告人和经办人，需求相关的商家信息、需求当前状态、流转的时间节点、优先级、需求对应的产品模块等）
梳理使用场景：使用者会在哪些场景如何使用？（提交需求时要怎么做、产品经理在收到需求时要怎么做、想查看进度时怎么做）

管理工具在线化带来的好处显而易见：

降低培训成本，对于新人来说，不清楚需求的如何流转，可以按照工具的引导来完成。
需求全生命周期在同一平台流转，减少了人工维护进度的人力成本，上下游信息保持实时对齐。
可获取系统数据，可用于度量和分析，为后续优化流程和策略提供依据
从商家反馈需求分析关键字端数据，分析集中功能模块问题、商家行业等辅助产品优化

基于商家需求的流转，可以提取各种数据，如各环节的处理时效，需求集中的功能模块，从不同维度进行数据分析（如下图），对有赞的运营计划和管理动作起到很大的辅助作用。

总结

有赞服务着数量庞大的商家群体，微商城、零售等标准产品能满足商家的大部分经营需求，但相对于商家反馈的需求，有赞的人力是有限的。面对标准产品无法满足的多样化的需求，有赞云应运而生，结合社会化的开发者伙伴生态，助力商家成功，帮助商家低成本高效率的实现个性化、多样化的定制服务。

很多企业的经营理念都是以客户为中心，有赞的愿景是帮助每一位重视产品和服务的商家成功。这并不是一句简单的口号，而是真正的站在商家的角度去思考如何更专业的服务，提供更好的产品。介绍了有赞在管理客户反馈需求上的「工作流」、「改进方法」、「工具」后，有几点心得跟大家分享：

能够长久生存发展的公司的协同工作流一定是强大的，而且必定是与时俱进的。不断的优化工作流就像一个人需要不断的反思自己一样重要。
照搬别人的改进方案基本是行不通的。不同的组织都有不同的历史背景、素质、氛围，方案的制定一定要因地制宜。可以学习精华部分，再适配到自己的组织中。就像人可以学习其他人的优点，但是没有办法过和别人有同样的人生一样。
过程改进可以“敏捷”一些，不用等到一切都无懈可击再去推行，是一个透明-检视-调整的过程，也是组织磨合的过程。

创作场景

客户反馈需求管理实践