自助支持验收：拦截率、首次解决率、成本与风险四张表

自助支持最容易犯的错，是用「帮助中心有多少篇」证明它有用。

一、三个月后，数字看起来都很好

孟舟的帮助中心上线三个月，文章从十二篇涨到四十八篇，搜索量每月上涨，页面浏览量也不错。他准备在月度复盘里写「自助支持效果显著」。

写之前他多做了一步：把最近一个月的支持需求按上一篇的漏斗重新算了一遍。总需求从 210 次降到 200 次，降幅不到 5%；90 次看过自助内容的需求里有 10 次仍转入人工，真正自助解决为 80 次，人工处理为 120 次；一线升级到本人的比例比他以为的高；每月内容维护的六小时也一直没记进成本。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他这才意识到，文章数量、搜索量、浏览量都是活动指标，不是结果指标。 真正要回答的是四个问题：拦住了多少、拦住之后一次解决了吗、单位成本是多少、风险有没有兜住。

二、四张表：拦截、解决、成本、风险

验收不需要几十个指标。四张表，每张回答一个问题。

拦截率要写清分母。 本文总需求 200 次包含自助与人工，不只统计已经进入工单系统的 120 次。自助解决率为 80 ÷ 200 = 40%；80 ÷ 120 是自助与人工数量之比，不是另一个拦截率。记录去重需求、观察窗口与后续重开规则，不能以未提工单自动证明已解决。

首次解决与最终解决分别记。 沿用上一篇内部定义，80 次自助解决、81 次一线首次解决，共 161 次，整体首次解决为 80.5%；本人后续解决 35 次后，最终解决为 98%。一线首次解决率为 81 ÷ 90 = 90%，分母也不同。这里将自助或一线首轮解决、窗口内无重开且无升级计为首次解决，是本系列内部口径，不声称适用于所有客服系统。

成本要含内容维护，并避免重复计时。 本期人工处理基线为 120 次 × 12 分钟 = 24 小时 = 1440 美元，内容维护 360 美元、工具 20 美元；另记误自助引起的额外复查 3 小时 = 180 美元，合计 2000 美元。额外复查不包含在前述 12 分钟中；这是本期观测假设，不沿用第 01 篇“每次额外 6 分钟”的初始估算。

风险表不是走过场。 至少覆盖五类：误自助导致错误操作、内容过期、截图或模板泄露隐私、无人值班时的响应、对外承诺过度。每一类写清「有没有预案、有没有演练过」。

三、评分锚点与综合分

四张表要变成一个可比较的分数，前提是每一维都有明确的 0–1 锚点，而不是拍脑袋。

四张表要在同一时点取数。 拦截率取上月工单、成本取上月账单、风险取本季度演练记录；时点不一致，综合分会失真，也无法和上季度比较。

首次解决维度得分 = 0.90 − 3 × (0.95 − 0.805) = 0.465
综合分 = 0.35 × 0.80 + 0.30 × 0.465 + 0.20 × 0.80 + 0.15 × 0.90
       = 0.280 + 0.1395 + 0.160 + 0.135
       = 0.7145 ≈ 0.71 → fix

权重反映阶段，不是永恒标准。 早期产品更该看拦截与成本，成熟产品更该看首次解决与风险。权重可以调，但调完要连续用四个季度，不能这个月一套、下个月一套。

评分规则要写死，避免自我宽容。 「感觉还行」不能变成 0.9。每一维都写清达标线与扣分方式，换一个人算，结果应该一样。

综合分只用于纵向比较。 它适合回答「这个季度比上季度好还是差」，不适合和别的产品比，因为分母、时薪与目标都不同。

四、scale、fix、stop 与季度内容审计

分数出来之后，只允许三种结论，每种对应一组动作。

本例唯一结论是 fix。 综合分 0.7145，首次解决维度 0.465，风险还缺“无人值班时的响应”预案。先补风险出口，再查首轮未解决的需求；不能用最终解决率 98% 替代首次解决率，把分数抬到扩量区间。

fix 聚焦一个业务维度，风险硬项优先完成。 本例业务重点是首轮解决，不同时改搜索、语言与人力配置；安全和响应出口不能因“只修一维”被推迟。每项给出明确的观察窗口和验收条件。

stop 不是失败。 如果自助内容的维护成本长期高于它节省的人工，停掉一部分内容、把用户交回人工，是更诚实的选择。产品问题用文档遮掩，只会让用户多走一步。

停用要有清单。 哪些文章下架、哪些保留但标注过期、哪些重定向到人工入口，逐条写清。直接删页面会让老链接变成死链。

验收的另一半是内容审计。不是重读全部文章，而是按信号抽查。

零点击文章要果断处理。 三个月零点击，通常意味着标题没人搜、内容没人需要，或者入口太深。先改标题，再观察一个月；仍然为零，就下架或合并。

截图审计要查隐私。 抽查时重点看邮箱、订单号、客户名与头像有没有打码；这一项出问题，代价远高于内容过期。

下季度清单只写两件事：先砍什么、先补什么。 每件不超过三项，多了执行不了。先砍低效内容，再补高频缺口，顺序不要反。

审计结果要留档。 哪个季度、抽了哪些、改了什么、下季度验证什么，写成一页纸。没有留档，下一个季度会重复同样的判断。

五、行动清单与复算验收

先定口径，再收数。口径不定，四张表会各算各的。

• 确定总工单、人工工单、自助解决三个口径，并写进文档。
• 补齐四张表的原始数据：拦截、解决、成本、风险。
• 为每一维写清 0–1 评分规则与目标值，换人复算结果一致。
• 按权重算综合分，记录连续四个季度的趋势。
• 根据分数给出 scale、fix 或 stop 三者之一的结论。
• 做一次内容审计，抽样高流量、零点击、模板与截图。
• 写下季度「先砍三项、先补三项」，并指定验证时间。
• 把未闭环的风险列成待办，指定负责人与截止日期。

验收标准：你能用一张纸说清拦截率、首次解决率、单位成本与五类风险的闭环情况，并据此给出 scale、fix 或 stop 中唯一一个结论。

使用边界与实操验收

本文只处理自助支持的季度验收，不涉及通用 DX 指标、外包协作验收与留存分析。

DX 与 API 的验收不归本文。 首次成功时间、调用留存、接口可用性属于开发者体验；本文的四张表针对终端用户的自助支持。

外包与借力的验收不归本文。 回收工时、返工率、单位成本与退出条件，属于协作验收；本文假设内容由你维护。

分数不是考核，是决策工具。 它的作用是让你在下个季度只做一件事，而不是给你一个可以汇报的数字。分数好看但风险未闭环，仍然应该先补风险。

关键参考与核验范围

核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对支持指标与内容审计的通用做法，本文未逐条引用其内容。

• Google SRE 手册：Monitoring Distributed Systems ：用于核对「用少量关键指标判断系统状态」的一般原则。
• Diátaxis 文档类型框架 ：用于核对内容按用途分类与定期维护的思路。

引用口径。 本文只借用两份材料的原则：指标要少而可行动，内容要按用途维护。文中的 200 次需求、2000 美元与 0.7145 全部来自教学假设，评分函数为本文的内部规则，与上述材料无关。

核验范围。 核验的是「四张表 + 评分锚点 + 三种结论」这套验收结构是否仍然可操作，不是比对某个分析工具。工具会变，口径不变。

如何自行复核。 用本文的四维权重与评分规则，把你的真实数据代进去重算一次；如果结论与你的直觉相反，先检查分母与成本口径，而不是先改权重。

系列导航

• 上一篇：人工升级路径：自助失败之后怎么交给人
• 回到目录：一个人的自助支持：帮助中心、排查树与工单减少
• 相关阅读：借力验收：回收工时、返工率、单位成本与退出