衡量自助服务门户的自助分流效果，核心是把进入门户的请求按最终去向分层统计：用自助解决率看门户内闭环的比例，用分流率看未转人工的比例，再用转人工率、重复提交率、首次解决时长和满意度交叉验证。计算前需要固定时间窗、去重规则和分母口径，并把“自助解决”与“用户放弃”分开统计，避免把未处理请求算成成功分流。
要点总览（TL;DR）
- 衡量自助分流效果，统一以“门户有效请求数”为分母：自助解决率=自助闭环请求数÷门户有效请求数，分流率=未转人工请求数÷门户有效请求数。
- 分流率包含放弃请求，解读时要与自助解决率、转人工率、放弃率一起看，避免把未处理请求算成成功分流。
- 取数前固定请求ID、用户ID、入口来源、是否转人工、解决状态和时间戳等字段，并写明去重窗口与缺失值处理规则。
- 按入口来源、问题类型、用户群体拆分指标，定位自助解决率偏低的环节，再决定补知识、改入口还是调排班。
- 自助解决率高不等于体验好，需结合满意度与重复提交率交叉验证；样本过小或口径变更时不下结论。
评估目标：先明确自助分流要回答什么问题
自助分流评估要回答三个问题：用户是否愿意通过门户发起请求，请求是否在门户内完成闭环，未闭环的请求最终去了哪里。这三个问题分别对应入口吸引力、门户解决能力和人工兜底规模，缺少任何一个，结论都会偏向单一侧面。
评估结论通常服务于三类决策：入口优化（把用户引导到合适的自助入口）、知识补充（定位自助无法覆盖的问题类型）、人力排班（根据转人工量和时段分布安排坐席）。把评估结果直接用于个人或团队考核时，容易诱导压低转人工数字，因此需要先明确用途再设计指标。
本文聚焦服务入口与自助解决环节，知识内容的具体编写维护、工单流转与状态管理的详细规则属于其他主题，这里只在取数和口径需要时提及。
可以把评估目标整理成一张问题清单，每个问题对应一个决策：
| 评估问题 | 主要指标 | 服务的决策 |
|---|---|---|
| 用户是否愿意用门户 | 门户使用渗透率 | 入口位置、宣传方式、默认入口设置 |
| 请求是否在门户内闭环 | 自助解决率、自助首次解决时长 | 知识补充、搜索优化、自助流程改造 |
| 未闭环请求去了哪里 | 分流率、转人工率、放弃率 | 人工排班、转人工触发规则、兜底入口设计 |
指标与范围：自助分流的核心指标和统计对象
自助分流评估以“门户有效请求”为统一分母，各指标从不同去向切分同一批请求。统计对象是门户会话或请求记录，关联到用户和后续工单；时间窗按周或月固定，单位分别为百分比、次数和时长（分钟或小时）。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 自助解决率 | 自助闭环请求数 ÷ 门户有效请求数 | 在门户内完成解决、未转人工的请求数 | 门户有效请求数 | 周/月 | % |
| 分流率 | 未转人工请求数 ÷ 门户有效请求数 | 未转人工的请求数（含自助闭环与放弃） | 门户有效请求数 | 周/月 | % |
| 转人工率 | 转人工请求数 ÷ 门户有效请求数 | 从门户转入人工渠道的请求数 | 门户有效请求数 | 周/月 | % |
| 重复提交率 | 重复提交请求数 ÷ 门户有效请求数 | 同一用户同一问题在设定窗口内再次提交的请求数 | 门户有效请求数 | 周/月 | % |
| 自助首次解决时长 | 自助闭环请求的解决时间总和 ÷ 自助闭环请求数 | 各请求从发起到标记解决的时间之和 | 自助闭环请求数 | 周/月 | 分钟/小时 |
| 门户使用渗透率 | 通过门户发起的请求数 ÷ 全部服务请求数 | 门户来源请求数 | 全部渠道服务请求数 | 周/月 | % |
有效请求需要排除测试账号、压测与机器人流量、明显重复提交以及无任何操作的空会话。分流率与转人工率之和不一定等于100%，因为放弃和未处理请求也占一部分，这正是需要单独统计放弃率的原因。
数据口径与证据：数据从哪里来、怎么保证可比
指标能否复算，取决于取数来源和字段是否固定。门户访问日志提供会话与点击行为，搜索记录反映用户表达的问题，工单系统提供最终去向和解决状态，满意度评价提供体验侧证据。四类数据通过请求ID和用户ID关联。
需要固定的关键字段包括：请求ID、用户ID、入口来源（首页搜索、分类导航、帮助中心文章、外部链接等）、是否转人工、解决状态、发起时间、解决时间、满意度评分。缺少“是否转人工”字段时，无法区分自助闭环与放弃，指标就失去意义。
去重规则建议按“同一用户+同一问题主题+设定时间窗口”合并，例如24小时内同一用户对同一类问题重复发起，只计一次有效请求，其余计入重复提交。窗口长度需要与业务节奏匹配，并在口径文档中写明。
缺失值处理遵循三条规则：无解决状态的请求归入“未处理”，不计入自助闭环；无满意度评价的请求在满意度指标中剔除，同时记录评价覆盖率；转人工标记缺失的请求单独列出，不默认归入任一去向。口径变更（如入口改版、去重窗口调整）需要记录生效日期，跨期对比时以同一口径重算或标注断点。
计算与评估步骤：从原始数据到分流结论
按以下五步执行，每一步都产出可核对的中间结果，便于他人复算。
- 圈定范围与清洗。确定统计周期和渠道范围，导出请求明细，剔除测试、机器人流量和空会话，得到门户有效请求数。完成标志是有效请求数与原始记录数的差异有书面说明。
- 按最终去向打标签。为每个请求标注四类去向之一：自助闭环、转人工、放弃、未处理。标签依据解决状态、转人工记录和最后操作时间综合判断，避免同一请求多标签。
- 计算指标并看趋势。代入公式计算自助解决率、分流率、转人工率、重复提交率、自助首次解决时长和渗透率，与上一周期对比，观察变化方向和幅度。
- 拆分定位薄弱环节。按入口来源、问题类型、用户群体三个维度拆分自助解决率和转人工率，找出明显偏低的组合，作为知识补充或入口调整的候选对象。
- 交叉验证。把自助解决率与满意度、重复提交率放在一起看。自助解决率上升但满意度下降或重复提交率上升，说明部分“解决”可能只是用户暂时离开。
当请求记录、状态流转和统计口径分散在多个表格中时，评估工作本身也需要一个承载点。ONES 可以通过工作项记录每个请求的来源、去向和解决状态，用状态流转保留转人工与闭环的痕迹，并按周或月汇总统计，使上述标签和指标能够基于同一份记录复算，减少口径对不齐带来的争议。
例子：一个月的自助分流数据怎么算
以下为演示数据，仅用于说明计算过程，不代表任何行业基准。
某月门户原始请求记录12,600条，剔除测试与机器人流量400条、空会话200条，得到门户有效请求12,000条。按最终去向打标签后：自助闭环7,800条，转人工2,400条，放弃1,200条，未处理600条。
| 去向 | 请求数 | 占有效请求比例 |
|---|---|---|
| 自助闭环 | 7,800 | 65.0% |
| 转人工 | 2,400 | 20.0% |
| 放弃 | 1,200 | 10.0% |
| 未处理 | 600 | 5.0% |
| 合计 | 12,000 | 100% |
代入公式：自助解决率 = 7,800 ÷ 12,000 = 65.0%；分流率 = (7,800 + 1,200) ÷ 12,000 = 75.0%；转人工率 = 2,400 ÷ 12,000 = 20.0%。分流率75%中包含10%的放弃请求，因此解读时需要同时说明“未转人工”中有多少是真正解决。
按问题类型拆分后，账号权限类问题的自助解决率为82%，而报销流程类问题仅为41%，转人工率达到45%。这一差异指向报销流程类知识覆盖不足或入口引导不准确，应优先补充该类问题的自助内容，而不是整体压缩转人工量。
解读与限制：指标怎么看、哪些结论不能下
自助解决率高说明门户内闭环比例高，但不能单独证明体验好。需要同时看满意度和重复提交率：解决率高、满意度低、重复提交率高，往往意味着用户是在多次尝试后勉强完成，或问题被暂时搁置。
样本过小时不下结论。某类问题一周只有十几条请求，自助解决率的波动主要来自随机性；分母为零时指标无定义，应标注“无数据”而非记为0%。
跨期对比要检查可比性。入口改版、搜索算法调整、知识批量更新、去重窗口变化都会改变分母或标签分布，此时应重算历史数据或标注断点，避免把口径变化误读为效果变化。
分流率不宜作为唯一绩效指标。单纯追求降低转人工，可能促使一线把本应转人工的复杂请求留在自助渠道，短期数字好看，长期带来重复提交和满意度下降。建议设定观察期（如连续两个完整统计周期），用自助解决率、转人工率、重复提交率、首次解决时长和满意度组合判断，并结合拆分结果确定改进动作。
常见问题
门户有效请求数怎么界定，测试和重复提交要不要算进去？
有效请求是全部指标的统一分母，界定清楚才能跨期比较。一般从门户原始请求记录出发，剔除测试账号、压测与机器人流量、无任何操作的空会话，再按“同一用户+同一问题主题+设定时间窗口”合并重复提交。
被合并掉的重复提交不进入分母，单独计入重复提交率，这样既能反映真实请求规模，又能观察用户反复尝试的情况。去重窗口长度要与业务节奏匹配，并在口径文档中写明生效日期。
自助解决率上升，但用户满意度下降，应该怎么判断？
这种情况通常说明部分“解决”并非用户认可的结果。建议把自助解决率与满意度、重复提交率放在同一时间窗内对照，并抽查自助闭环请求的实际处理记录。
如果满意度下降集中在某类问题或某个入口，优先检查该类问题的知识覆盖和入口引导是否准确，而不是继续追求提高自助解决率。必要时设定观察期，连续两个完整统计周期后再判断趋势。
某类问题一周只有十几条请求，算出来的自助解决率能直接用吗？
样本过小时，自助解决率的波动主要来自随机性，单周数字不宜直接下结论。可以拉长统计周期、合并相近问题类型，或只做定性观察。
分母为零时指标无定义，应标注“无数据”，不要记为0%。对于请求量小但影响大的问题类型，可以结合个案记录和满意度评价做补充判断。
入口改版或知识批量更新后，历史数据还能直接对比吗？
入口改版、搜索算法调整、知识批量更新、去重窗口变化都会改变分母或标签分布，直接对比容易把口径变化误读为效果变化。
处理方式有两种：按新口径重算历史数据，或在趋势图上标注断点并说明变更内容。无论哪种，都要在口径变更记录中写明生效日期，保证后续复算时能还原当时的统计条件。
评估自助分流效果，需要哪些系统里的数据配合？
至少需要四类数据：门户访问日志（会话与点击行为）、搜索与点击记录（用户表达的问题）、工单系统（最终去向与解决状态）、满意度评价（体验侧证据）。四类数据通过请求ID和用户ID关联。
当请求记录、状态流转和统计分散在多个表格中时，评估工作本身也需要一个承载点。ONES 可以通过工作项记录每个请求的来源、去向和解决状态，用状态流转保留转人工与闭环的痕迹，并按周或月汇总统计，使标签和指标能够基于同一份记录复算。
