作者： Cekat AI

客户发送了一条消息。团队进行了回复。两小时后，同一位客户又发来一条后续消息。再过两小时，第三条消息。等到问题关闭时，一个本应一次就能解决的问题已经来回发送了四条消息。

这种模式在大多数客服仪表盘上是看不见的。响应时间看起来很正常——每次回复都很快送达。没有被衡量的是，同一个问题反复出现。首次解决率（FCR）正是能够揭示这种模式的指标。

主要优势

• 揭示隐藏的低效： 快速的响应时间可能掩盖糟糕的解决质量。FCR 能将两者区分开来。
• 与 CSAT 直接相关： 在首次联系中解决问题的客户，其满意度始终高于需要后续跟进的客户。
• 降低单张工单成本： 每一次重复联系，都是客服坐席在同一个问题上又花费一分钟。提升 FCR 会带来复利式的节省。
• 聚焦辅导方向： FCR 偏低通常指向某一具体缺口——知识、工具或权限。

计算公式

首次解决率 ＝（首次联系中解决的问题数 ÷ 总问题数）× 100%

有两个定义上的选择比算术本身更重要。

什么算作“首次联系”？ 大多数团队将其定义为客户在同一问题上于规定时间窗口内（通常为 24 至 48 小时）再次回复。如果同一位客户在三周后再次发来消息，那是一个新问题，而不是后续跟进。

什么算作“已解决”？ 更稳妥的定义是客户确认——客户表示问题已解决，或者案例在时间窗口内没有后续跟进即被关闭。在没有客户确认的情况下由客服坐席标记为“已解决”，会虚高该指标。

图片建议 1：一张可视化时间线，展示两张工单——一张在首次联系中顺利关闭，另一张在 48 小时内出现三次重复联系——让读者看到 FCR 实际衡量的内容。

计算示例

一个客服团队一周处理 500 个问题。其中：

• 320 个在首次联系中完全解决。
• 130 个需要在 48 小时内进行一次或多次后续跟进。
• 50 个升级至专家团队。

FCR ＝（320 ÷ 500）× 100% ＝ 64%

与响应时间结合起来看，就能说明一个具体的情况。如果 p90 首次响应时间低于五分钟，但 FCR 停留在 64%，说明团队回复很快，但解决不快。改进的杠杆不是人员配置——而是回复之后发生了什么。

真正推动 FCR 的因素

当客服坐席能够在第一条消息中做到以下三件事时，FCR 就会上升：

理解完整背景。 如果客服坐席在提供帮助之前需要问三个澄清性问题，那么从定义上讲，这次互动就无法在首次联系中解决。在消息到达的那一刻掌握完整的客户背景是前提条件。

获取答案。 如果答案存在于客服坐席必须单独搜索的知识库中、存在于他们看不到的订单系统中，或者存在于只有主管才有的政策文件里，工单就会变成一连串的内部转交。每一次转交都会延长解决时间并降低 FCR。

拥有关闭问题的权限。 如果退款需要主管批准，客服坐席就无法在首次联系中解决。有些审批不可避免——但许多团队把超出必要范围的决策都设置成了审批关卡。

辅导客服坐席打字更快并不会提升 FCR。消除上述三个障碍才会。

衡量时的常见错误

忽视渠道差异

在线聊天的 FCR 与电子邮件的 FCR 表现不同。电子邮件的 FCR 包含在线聊天所没有的固有延迟。要按渠道比较，而不仅仅是看整体。

将 FCR 与首次响应时间混淆

它们衡量的是不同的东西。首次响应高而 FCR 低，意味着团队很快但无效。FCR 高而首次响应慢，意味着团队很彻底但不够专注。

将解决时间窗口设置得过窄

对复杂问题设置一小时的重复联系窗口，数字看起来会不错，但会漏掉第二天早上到来的真实重复联系。

这与工具的契合之处

FCR 是一个下游指标。能够提升它的工具，是那些把背景、答案和权限放在与回复相同位置的工具。

像 Cekat 这样的平台将全渠道收件箱与 CRM 记录和知识库结合在一起，因此客服坐席可以在一个屏幕上看到客户历史、订单数据和参考资料——无需切换到另一个系统去寻找答案。这消除了 FCR 偏低的最大结构性原因。

从哪里开始

在设定目标之前，先衡量当前的基线。提取 30 天的已解决工单，计算整体和各渠道的 FCR。如果这个数字让你感到意外，那么在调整指标本身之前，可能更需要先审视追踪定义。

接下来，看看那 36%（或你的数字）未能在首次联系中解决的问题。寻找共同的障碍。修复一个障碍，一个月后再次衡量，然后再处理下一个。FCR 是一个会对聚焦式修复而非广泛举措作出反应的指标。

关于响应速度与关闭率如何关联的相关视角，请参阅如何缩短客服响应时间。

首次解决率并不是最耀眼的客服指标。但它往往是最诚实的指标——它不会以牺牲实用性为代价来奖励速度，也不会让重复联系隐藏在业务量之中。

一个常见的客户支持问题听起来很简单：谁来处理这张工单？在较小的团队里，答案是”谁有空谁处理”。在较大的团队里，这个答案就行不通了：重置密码和数据库迁移不可能由同一个人高效处理。

支持层级就是结构性的答案。它们按复杂程度把涌入的问题分成三层，让合适的技能水平处理合适的问题。本指南介绍每个层级实际做什么、工单如何在层级之间升级，以及团队在划分时容易出错的地方。

主要优势

• 技能与问题匹配： 简单问题由 Tier 1 直接解决，无需等待专家；复杂问题能得到妥善处理，而不必由通才去猜测。
• 平均解决速度更快： 由于 60-80% 的工单在 Tier 1 关闭，Tier 2 和 Tier 3 的专家不会成为瓶颈。
• 职业发展路径更清晰： 客服坐席从 Tier 1 成长为 Tier 2、Tier 3，每次晋升都有明确的技能标准。
• 人员配置可预测： 每个层级的业务量可以独立预测，使容量规划变得可行。

每个层级实际处理什么

具体的划分因行业而异，但原则是一致的。

Tier 1 一线客服坐席

Tier 1 是第一接触点。所有涌入的工单都从这里开始（除非路由规则明确将高优先级账户发送到其他地方）。

Tier 1 处理的内容： 账户问题、密码重置、订单状态、标准产品信息、初次投诉受理、基础故障排查，以及知识库中已有解决方案的所有问题。

所需技能： 沟通能力、用户层面的产品熟悉度、对常见问题按标准话术回复的执行力，以及判断何时应升级的判断力。

典型解决率： 在设计良好的结构中，全部涌入工单的 60-80% 应在 Tier 1 关闭。如果 Tier 1 的关闭率低于这一水平，要么是知识库不够完善，要么是升级触发条件过于宽松。

Tier 2 产品专家

Tier 2 承接 Tier 1 无法解决的问题：需要更深入的产品知识、对工作流的理解，或有权批准政策例外的问题。

Tier 2 处理的内容： 复杂的配置问题、特定工作流的问题、退款例外、已升级的投诉、需要产品深度的技术问题，以及涉及多个系统的案例。

所需技能： 深入的产品知识、复现客户所报问题的能力、熟悉后端工具和管理界面，以及在规定范围内对政策例外作出判断的能力。

典型解决率： Tier 2 应关闭升级到它这里的 70-85%。其余部分要么升级到 Tier 3，要么需要产品或工程方面的变更。

Tier 3 工程或产品团队

Tier 3 是需要代码变更、基础设施工作或尚未解决的缺陷的问题最终落到的层级。在大多数公司里，Tier 3 并不由专职支持坐席组成，而是由工程或产品团队轮流承担支持职责。

Tier 3 处理的内容： 已确认的缺陷、需要代码修复的集成故障、数据损坏、安全事件、触发产品根本性限制的边缘情况，以及任何需要改动底层系统的问题。

所需技能： 工程知识、直接访问系统的权限、编写补丁或热修复的能力，以及事件响应经验。

典型业务量： 应低于全部涌入工单的 5%。如果 Tier 3 被大量工单淹没，说明 Tier 2 的升级标准有误，或者产品存在系统性问题。

升级实际如何运作

升级是大多数层级结构出问题的地方。有两种模式会导致失败。

升级过于积极。 如果 Tier 1 把任何超过三分钟的工单都升级，Tier 2 就会成为瓶颈，Tier 1 也会失去意义。正确的升级触发条件很具体：无法复现、需要政策例外、客户明确要求主管介入，或问题属于已知的高难度类别。

升级过于迟缓。 如果 Tier 1 在超出自身能力的问题上坚持处理，解决时间就会膨胀，CSAT 也会崩塌。基于时间的升级：在 N 分钟内未解决就自动提升到 Tier 2，可以防止这种情况。

健康的模式是：明确的升级标准加上硬性的时间上限。两者必须同时具备，而不是只取其一。

团队在划分上容易出错的地方

在早期团队中合并 Tier 1 和 Tier 2。 小团队常常完全跳过划分，这在业务量增长之前是可行的。引入 Tier 2 的正确时机，是当同一位专家不断被从其他工作中拉走时；这就是需要设立专职层级的市场信号。

让 Tier 3 做 Tier 2 的工作。 把数小时花在本应在 Tier 2 解决的问题上的工程师，就是没有在开发产品的工程师。这通常是因为 Tier 2 缺少工具访问权限，而不是因为 Tier 2 缺少知识。

没有交接协议。 一张没有背景信息、没有复现步骤、没有客户历史的升级工单，会让 Tier 2 从零开始。交接协议（尝试过什么、客户说了什么、Tier 1 得出了什么结论）不是额外负担，而是升级正在正常运作的体现。

工具在其中扮演的角色

分层结构需要支持升级流程的工具。将新工单默认路由到 Tier 1 的路由规则、能传递完整上下文的升级按钮，以及让 Tier 2 和 Tier 3 查看 Tier 1 对话历史的可见性。

像 Cekat 这样的平台在单一工作区内处理路由和交接机制，因此升级时客户记录、对话历史以及所有尝试过的解决方案都会随工单一起传递。这消除了工单向上层移动时的”从零开始”问题。

从哪里开始

如果你的团队规模较小（少于五人），正式的分层结构可能为时过早。相反，找出两三种持续超出平均处理时间的工单类型：这些就是正在形成的 Tier 2 类别，它们标志着何时应当正式化。

如果你的团队规模较大且业务量在上升，请衡量当前的划分情况：如今每个层级各自解决了多少工单。如果超过 40% 的工单越过了第一位客服坐席，Tier 1 就需要更好的工具或更好的培训。如果升级比例低于 10%，Tier 1 很可能在吸收本应由专家处理的工作。

关于客户服务、客户关怀和客户支持如何在统一团队中划分职责的相关观点，请参阅客户服务 vs 客户关怀 vs 客户支持。

支持层级不是官僚化的层级。它是对增长问题的结构性答案：如何在不论复杂程度、对每个问题都投入同样多注意力的情况下，处理更大的业务量。

某个周二，一个客户服务团队收到了 300 条 WhatsApp 消息。其中 12 条是真正需要跟进数天的问题。其余 288 条是快速的信息咨询，一次回复即可解决。

如果没有工单系统，这 300 条消息都会堆在同一个收件箱里。那 12 个真正的问题被淹没在日常聊天中；第二天有人忘记跟进，到了第五天，客户因为无人回复而愤怒。问题不在于工作量。问题在于，没有办法把需要跟踪的工作与不需要跟踪的工作区分开来。

工单系统是结构性的解决方案。它把需要多步骤处理的消息转化为结构化、可跟踪的工作项，带有 ID、状态、负责人，以及可跨班次留存的历史记录。本指南介绍聊天转工单工作流的实际运作方式、每张工单承载哪些数据，以及审计轨迹如何发挥其作用。

主要优势

• 需要跟踪的工作得到跟踪： 多步骤问题以工单形式存在，责任归属清晰；只需一次回复的消息仍保留为聊天。
• 跨班次的连续性： 当早班客服坐席把工作交接给午班客服坐席时，工单承载完整历史，无需重新解释。
• 默认具备问责机制： 每一次状态变更、每一次重新分配、每一条备注都带有时间戳并归属到人。争议变得可以有据可查。
• 规模化的模式识别： 工单经过分类后，反复出现的同一问题会在汇总层面显现，而不是逐条消息地隐形。

工单系统实际做什么

工单系统把客户消息转化为团队可以跨时间处理的结构化记录。消息仍留在它原来的位置——WhatsApp、IG 私信、电子邮件、在线聊天——但会创建一张工单，把该问题未来所有的操作都绑定到同一个 ID 上。

这一区别很重要。消息是短暂的事件。工单是持久对象，带有字段、状态和历史。一旦创建，工单的生命周期就长于单条消息线程，并成为团队围绕该问题所做一切工作的锚点。

聊天转工单工作流

一个设计良好的系统遵循五个阶段。

阶段 1：受理
消息从任意渠道到达。系统对其进行解析，可以自动完成（基于关键词或 AI 分类），也可以手动完成（客服坐席判断“这需要工单”）。并非每条消息都会变成工单；常规的信息咨询仍保留为聊天。

阶段 2：创建工单
生成一张工单，包含唯一 ID、原始消息、请求者标识、来源渠道、初始分类和默认优先级。此时工单已作为一等对象存在。

阶段 3：路由
根据分类、技能和工作量，工单被路由给某位客服坐席或某个队列。路由规则可以考虑客户优先级、SLA 约束，或哪位客服坐席此前处理过该客户。

阶段 4：解决工作
被指派的客服坐席处理该工单。每一次回复、内部备注、状态变更或升级都会记录在工单 ID 下。如果工单需要在客服坐席或层级之间流转，完整历史会一并转移。

阶段 5：关闭
当客户确认问题已解决（或在规定的静默期后工单自动关闭）时，工单转为已关闭状态。记录可无限期查询——关闭并不意味着删除。

工单承载哪些数据

工单的价值在于它存储的内容。一张最简工单包含：

• 工单 ID： 唯一、便于人阅读，并在每次沟通中被引用。
• 请求者： 客户，关联到 CRM 记录。
• 来源渠道： WhatsApp、电子邮件、在线聊天、电话。
• 分类与子分类： 这是什么类型的问题。
• 优先级： 紧急程度层级，通常由客户细分与问题类型推导而来。
• 状态： 待处理、处理中、等待客户、等待内部、已解决、已关闭。
• 负责人： 当前承担责任的客服坐席或团队。
• SLA 计时： 距离响应或解决 SLA 被违反还剩多少时间。
• 完整消息线程： 按顺序排列的每条客户消息和每次回复。
• 内部备注： 仅客服坐席可见的备注，用于记录不应发送给客户的背景信息。

这些字段是最低要求。不同团队会添加符合自身场景的特定字段：电商的订单号、医疗的患者 ID、B2B 的合同号。规则是一样的：如果某个字段会改变下一位处理者对工单的处理方式，它就应该出现在工单上。

审计轨迹：历史为何重要

每张工单都携带其完整的历史记录。每一次状态变更、每一次重新分配、每一条新增备注、每一次发送的回复，都带有时间戳并归属到具体用户。这条审计轨迹常被视为合规功能，但它的实际价值远不止于此。

争议解决。 当客户说“三天都没人回复我”时，工单历史会准确显示发生了什么，包括是否发送了客户遗漏的回复。没有这条轨迹，争论就会变成各执一词。

交接的清晰度。 当工单从一级转到二级时，审计轨迹显示一级已经尝试过什么。二级客服坐席不会重复已经失败的工作。

辅导信号。 复盘耗时过长或收到投诉的工单，往往能发现流程断裂的具体环节。审计轨迹让这些环节变得可见。

模式识别。 当十位不同的客服坐席各自用不同方式解决同一问题的一个实例时，这些工单上的审计轨迹会显示哪种解决方式真正有效。这将成为知识库条目的输入，从而避免第十一次发生。

审计轨迹不是额外负担。它是在多人处理相互重叠问题的团队中，让结构化工作成为可能的记录。

常见失败模式

工单实施会以几种常见方式失败。

没有回链到原始聊天
客户在 WhatsApp 上发消息，工单被创建，客服坐席在工单工具内回复，但回复从未到达 WhatsApp。客户看不到响应，于是再次发消息。工单与渠道之间的桥梁必须是双向的。

把日常咨询过度工单化
如果每个问题都变成工单，工单队列就会被首次回复即可关闭的条目淹没。真正的工作项在噪音中丢失。创建工单应当是有意的升级，而不是默认行为。

状态陈旧
工作已经停止，工单却仍数周保持“处理中”，会侵蚀对系统的信任。通过自动停滞检测并提示关闭或升级，可以让状态保持准确。

沉默的审计轨迹
历史被记录下来了，但没人使用。让审计轨迹在工单视图中可见，而不是塞进单独的标签页，可以促进辅导和争议解决的使用场景。

它在工具栈中的位置

工单系统在连接它所处两侧时最为有用：客户渠道（消息来源）和 CRM（客户背景所在）。

像 Cekat 这样的平台把全渠道收件箱、CRM 和工单层整合到一个工作区中。这意味着 WhatsApp 消息无需离开对话就能变成工单，客服坐席可以在工单旁看到完整的客户背景，审计轨迹与回复框出现在同一视图中。这消除了切换成本——正是这种成本让许多工单部署显得比它们所取代的非正式系统更慢。

从哪里开始

如果你的团队目前在没有工单系统的情况下管理客户问题，第一步不是购买软件。而是定义哪些类型的消息应该变成工单。

回顾过去一个月。客户消息中有多大比例需要多步骤处理、跨班次跟进，或在多位客服坐席之间协调？这就是值得工单化的量。如果低于总入站的 5%，目前工单系统可能有些过度。如果达到 20% 或以上，缺少工单系统已经在让你付出代价。

如需深入了解工单系统所支持的 SLA 架构，请参阅工单系统 SLA 架构与瓶颈。

工单系统并不解决客户服务问题。它建立一种结构，让团队能够跨班次、跨分类、跨渠道一致地解决问题，并拥有可留存下来为下一次决策提供依据的历史记录。

一位顾客在上午10点通过WhatsApp发送了投诉。到了下午4点，仍然没有人回复。顾客截图后发布到Instagram Stories，并标记了这家企业。到了晚上，这条帖子仅凭顾客自己的社交圈就获得了200次浏览。问题不在于投诉本身，而在于沉默。

这种模式并不罕见。当企业以大多数企业惯用的方式处理投诉时，也就是临时应付、在共享收件箱中处理、没有工作流，这就是默认结果。投诉管理是一种结构性应对：通过明确的流程进行受理、分类、解决和跟进，防止一个糟糕的时刻演变成公开事件。

本指南涵盖手动投诉处理中会出现哪些问题、为什么声誉风险高于单个投诉本身、投诉之后真正让顾客感到问题已解决的是什么，以及如何构建将这三点联系在一起的工作流。

主要优势

• 控制声誉损害: 快速得到回复的投诉很少会变成公开帖子；而未获回复、被搁置的投诉往往如此。
• 挽回即将流失的顾客: 处理得当的投诉所带来的忠诚度往往高于从未投诉过的顾客。
• 揭示系统性问题: 已分类投诉中的模式能暴露出其他任何反馈渠道都无法捕捉到的产品或流程问题。
• 让团队免受模糊不清之苦: 有了明确的阶段和清晰的交接，客服人员就能明白每个环节中“已处理”意味着什么。

手动投诉处理为何会失效

“谁看到投诉就由谁处理”这种默认做法在规模很小时还行得通。一旦企业拥有不止一名客服、不止一个渠道，或每周投诉超过十几件，它就会失效。

失效的方式是一致不变的。

投诉在班次交接之间丢失。 早班客服开启了一段对话，午班客服在没有上下文的情况下接手，于是对话陷入停滞。

没有人负责跟进。 即时回复发生了，但三天后承诺的解决方案没有兑现，因为在首次回复之后没有人被指定为负责人。

数据无法追溯。 下个月出现类似投诉时，没有人能搜索“上次发生这种情况时我们是怎么做的”。每个案例都从头开始。

升级是非正式的。 本应上达主管的严重投诉却停留在初级客服手中，因为没有明确的升级触发条件。

什么都学不到。 在单个案例层面看不见的模式（本月针对同一产品缺陷的五起投诉）因为没有人汇总而始终不可见。

共同的线索是：手动处理以牺牲下游的一切，即连续性、学习和模式识别，为代价，只优化单个案例。

为什么声誉风险高于投诉本身

每一起投诉都有两类受众：提出投诉的顾客，以及他们可能告知的更广泛的人际网络。

对于大多数投诉，更广泛的人际网络永远不会听说，因为顾客得到了回复、感到被倾听，然后继续向前。但当回复迟缓或不能令人满意时，那起私下的投诉就会变成公开的帖子。而公开帖子的传播范围并非线性。

一张无人回复的WhatsApp投诉截图，发布到Instagram Stories或在WhatsApp群组中转发后，会触达一群信任发布者的高互动受众。与营销信息不同，这类内容因来自有具体不满的真实顾客而具有很高的可信度。这样一条帖子就能抹掉数周正向营销投入的成果。

结构化投诉管理的经济理由往往可以归结为：阻止一条病毒式传播的投诉帖子发生，其价值远远超过一套完善的投诉工作流的成本。

投诉之后，什么能让顾客感到问题已解决

挽回一位投诉的顾客，主要不在于结果，而在于流程给人的感受。各支持团队的研究和实践经验一致指向四个因素。

先认可，后解决
感到未被倾听的顾客会升级投诉。一句简短的“我听到了您的声音，这不应该是您所经历的，我来查一下”，往往比不作认可就直接给出解决方案更能平息局面。

时间透明
只要知道自己要等多久，顾客很少介意等待。“我需要等到明天结束前才能给您一个完整的答复”，比同样30个小时的沉默要好得多。

进度可见
随着案例走向解决，顾客想知道状态已经发生了变化。“您的退款已获批准，处理需要3天”这样的更新往往比退款本身更有价值。

负责人保持连贯
被在三名客服之间转来转去，每个人都先问一遍发生了什么，会耗尽顾客的好感。即使其他人在幕后工作，保持一个固定的对接人就能守住这份好感。

这四个因素是流程因素，而非结果因素。结构化的投诉管理工作流能够保证它们，临时应付则做不到。

投诉管理工作流

将受理、解决和声誉保护联系在一起的工作流包含六个阶段。

阶段1 受理
投诉从任意渠道抵达，并立即被识别为投诉（通过AI分类、关键词检测或客服打标签）。随后创建带有唯一ID的投诉工单。

阶段2 认可
在规定的SLA内，聊天渠道通常为15分钟以内，顾客会收到一条认可消息，其中包含：问题正在被查看的确认、供参考的工单ID，以及下次更新的预计时间范围。

阶段3：分类与严重程度
投诉会被打上类别标签（产品缺陷、服务失误、账单、配送等）和严重程度级别。严重程度决定路由：高严重程度的投诉会立即升级给主管。

阶段4：调查与解决。
被指派的客服进行调查，必要时与其他团队协调，并给出解决方案。所有进展都记录在工单ID之下。

阶段5：顾客确认
解决方案被提供给顾客，只有当顾客明确确认满意后才会结案。未经确认就由客服标记为“已解决”，会低估实际的投诉量。

阶段6：跟进与学习
对于严重程度较高的投诉，会在一周内跟进，检查解决方案是否持续有效。汇总后的投诉数据纳入月度复盘，以识别值得升级到产品或运营部门的模式。

常见的失效模式

即使有了工作流，也有三种模式会破坏投诉处理。

优化结案速度而非顾客满意度。 奖励快速结案的指标会促使客服在顾客实际确认之前就把工单标记为已解决。这在仪表盘上看起来不错，在下一次NPS调查中却很糟糕。

升级标准过高。 如果只有“极端”案例才会升级，那么中度不满的顾客，也就是最有可能公开发帖的那群人，就永远得不到主管的关注。放宽升级标准，并预期主管会在队列中投入更多时间。

没有通向产品或运营的反馈闭环。 如果投诉数据留在CS团队内部，同样的缺陷就会不断出现。与产品和运营共享的每周摘要能把投诉数据转化为预防性输入。

这与工具栈的关系

投诉管理不是一款独立的工具，而是由工单系统、全渠道收件箱、CRM和升级规则共同强制执行的流程。

像Cekat这样的平台把这些层次整合到一个工作区中，因此来自WhatsApp的投诉会在同一视图中变成已分类、已排定优先级的工单，同时顾客历史可见、升级触发条件内建、审计记录随时可查，以便日后需要重新审视该案例时使用。这就消除了让大多数投诉工作流“执行起来比忽略更难”的切换成本。

从哪里开始

如果你的团队今天还没有结构化的投诉管理，不要从定义理想工作流开始。先从衡量现状开始。

拉出过去三个月的记录。找出所有收到的投诉。对每一起记录：首次回复用了多久、是否进行了跟进、案例是否解决到顾客所述的满意程度，以及这起投诉事后是否出现在任何社交渠道的公开场合。

这些数据几乎总能揭示出问题最常崩溃的某个特定阶段。修复那一个阶段，能带来声誉保护方面最大的跃升。然后从那里开始，逐个扩展到其他阶段。一次性构建完整工作流通常会失败；针对已衡量的痛点逐步构建则通常能够持续。

关于常见投诉类型及处理方式的具体示例，请参阅客户投诉示例及处理方式。

投诉管理不是要避免投诉，而是要确保你确实收到的投诉得到控制、以顾客尊重的方式得到解决，并产生能够减少下个月投诉量的学习成果。把投诉管理当作工作流而非孤立事件来对待的企业，最终会拥有比那些收到更少投诉却处理糟糕的企业更好的声誉。