从重复工单和高频咨询整理自助服务FAQ，核心是把“问题”变成用户能独立执行的“条目”：先统一采集工单与咨询记录、按同一现象和同一处理动作归并，再按频次、影响范围、自助可解程度和变更风险排序，写成“现象—自助步骤—失败原因—转人工入口”的标准结构，小范围上线后用工单量变化和自助命中情况验证。这套做法适合已有一定工单积累、希望分流重复咨询的服务台团队；如果工单量很少或问题高度个案化，应先积累记录再启动。
要点总览（TL;DR）
- 先统一入选口径：同一现象、同一处理动作反复出现的问题才计入候选，涉及权限变更、敏感信息或需个案判断的问题排除在首批FAQ之外。
- 采集最近一个完整周期的工单与咨询记录，按“现象关键词＋处理动作”归并同义表述，输出带频次、样本量和典型工单编号的候选清单。
- 用出现频次、影响范围、自助可解程度、内容变更风险四个维度加权打分，划分高优先、次优先、暂缓三档，首批容量控制在15–20条并人工复核。
- 条目按“问题标题—适用场景—自助步骤—常见失败原因—转人工入口”成稿，步骤可操作、可验证并标注前置条件；上线后观察一个完整周期，用相关工单量、自助点击与转人工比例判断有效性。
先定口径：哪些问题值得做成FAQ条目
整理FAQ的第一步是统一“什么算重复、什么值得写”的判断标准。缺少口径时，不同人按各自理解筛选，候选清单会混入偶发问题和必须人工判断的事项，后续排序和成稿都会失准。
判定重复工单与高频咨询，建议同时看两个条件：用户描述的是同一现象，服务台采取的是同一处理动作。只满足其一的不宜直接计入。例如“登录失败”每周出现多次，但原因分别是密码过期、账号锁定、浏览器缓存，处理动作不同，就应拆成三条候选问题分别计数，而不是合并成一条笼统的“登录问题”。
归并同类问题时，至少保留三个字段：问题现象（用户看到的报错、界面或结果）、所属系统或服务（便于分配给对应审核人）、提问角色（新员工、财务、外部客户等，决定适用场景的写法）。这三个字段一致，才视为同一候选问题。
以下类型建议排除在首批FAQ之外：需要查看具体账号或单据才能判断的个案问题；涉及权限变更、账号开通、敏感数据查询的问题；处理动作依赖口头协商或跨部门临时决策的问题。这类问题可以保留在知识库作为内部处理参考，但不适合直接面向用户自助。
FAQ条目与知识库文章的分工也需要提前说清：FAQ条目面向用户自助，一条解决一个具体问题，篇幅短、步骤明确；知识库文章面向服务台内部或深度使用者，可以包含背景、原理和多场景说明。同一条目在两者间可以互相引用，但不要用一篇长文承担FAQ的职责。
| 判断项 | 入选条件 | 排除或暂缓条件 |
|---|---|---|
| 重复性 | 同一现象、同一处理动作反复出现 | 现象相同但处理动作不同，需拆分后再判断 |
| 可自助性 | 用户按步骤可自行完成并验证结果 | 需查看个案数据、需人工授权 |
| 敏感性 | 不涉及权限变更与敏感信息 | 涉及账号权限、个人数据、财务信息 |
| 稳定性 | 处理方式近期无重大变更 | 系统即将改版或流程正在调整 |
采集与归并：从工单和咨询记录提取候选问题
候选问题清单的质量取决于采集范围是否完整。建议取最近一个完整周期（如一个季度）的工单与咨询记录，覆盖工单标题与描述、处理记录中的解决动作、在线咨询与会话记录，避免只看工单标题造成漏判。
提取时按统一字段整理，便于后续统计和归并：
- 问题描述：保留用户原话中的关键表述，作为后续标题写法的素材；
- 发生时间：用于判断是否为阶段性集中出现；
- 提问人角色：用于确定适用场景和入口位置；
- 处理动作：服务台实际执行的操作，是归并的核心依据；
- 解决耗时：辅助判断该问题对服务台工作量的占用。
归并采用“现象关键词＋处理动作”双条件聚类。先把同义表述归一，例如“打不开”“进不去”“页面空白”在确认指向同一现象后可合并；再核对处理动作是否一致，动作不同的拆开。归并后每条候选问题记录频次、样本量和若干典型工单编号，便于复核时回溯原始记录。
输出物是一份候选问题清单，字段包括：候选问题编号、归一后的问题描述、所属系统或服务、主要提问角色、出现频次、样本量、典型工单编号、初步判断（可自助／需人工）。清单完成后由服务台一线复核一遍，剔除归并错误和明显个案。
如果工单记录分散在多个入口，采集前先确认各入口的数据能否导出到同一张表。ONES Desk 支持通过门户收集工单并一键分享填写链接，也支持自定义工单属性，团队可以按问题类型、提问角色等字段统一记录，减少后续手工归并的工作量。
打分排序：确定FAQ上线优先级
候选清单通常有几十条，不可能一次全部上线。用可计算的评分规则排序，能让“先写哪些”有据可依，也便于向业务方解释取舍。
建议从四个维度打分，每项1–5分，按团队服务量结构设定权重。以下权重仅为示例，需按实际情况调整：
| 维度 | 含义 | 评分参考 | 示例权重 |
|---|---|---|---|
| 出现频次 | 统计周期内的工单与咨询次数 | 5分：最高频区间；1分：偶发 | 35% |
| 影响范围 | 受影响用户群体大小与业务阻断程度 | 5分：全员或核心业务阻断；1分：个别用户 | 25% |
| 自助可解程度 | 用户按步骤独立完成的可能性 | 5分：纯操作步骤；1分：几乎必须人工 | 25% |
| 内容变更风险 | 处理方式近期变化的可能性，风险越低分越高 | 5分：长期稳定；1分：即将改版 | 15% |
加权总分算出后划分三档：高优先（建议首批上线，通常是高频、影响面大且步骤明确的问题）、次优先（第二批，或需要补充截图、示例后再上线）、暂缓（变更风险高、自助可解程度低，或样本量不足）。分档边界可按首批容量确定，例如首批控制在15–20条。
评分结果需要人工复核后再定稿。复核重点看两类情况：评分高但涉及敏感操作的问题，应降档或改写为“引导提交工单”；评分中等但属于新员工入职高频问题，可适当提前。复核意见记录在评分表备注列，形成首批上线清单。
写成条目：FAQ的标准结构与写法
条目写法决定用户能否真正自助解决。统一结构能让不同编写人产出一致质量的内容，也方便后续维护和复用。
建议每条FAQ包含五个部分：
- 问题标题：用用户提问的原话，例如“提交报销单时提示‘审批人不存在’怎么办”，避免“审批流配置异常处理”这类内部术语；
- 适用场景：说明什么角色、在哪个系统或入口会遇到，帮助用户确认是否对号入座；
- 自助步骤：按操作顺序编号，每步写清点击哪里、输入什么、看到什么结果算成功，前置条件（如需要先登录、需要已开通某权限）写在步骤之前；
- 常见失败原因：列出步骤执行后仍不成功的典型情况，并给出对应处理；
- 转人工入口：明确告知仍无法解决时从哪里提交工单，并提示需要附带的截图或信息。
步骤写法有两个要求：可操作、可验证。每一步都应是一个具体动作，并说明完成标志。例如“在报销单页面点击‘重新选择审批人’，选择直属上级后点击保存，页面提示‘提交成功’即完成”，比“重新配置审批人”更便于用户执行。
以下为三条填写示例（演示情景，非真实案例）：
| 问题标题 | 适用场景 | 自助步骤（节选） | 转人工入口 |
|---|---|---|---|
| 登录时提示“密码已过期”怎么办 | 全体员工，登录办公系统时出现 | 1. 在登录页点击“忘记密码”；2. 输入工号与手机号获取验证码；3. 设置新密码并重新登录，看到首页即成功 | 收不到验证码时，从服务门户提交“账号问题”工单 |
| 打印报销单时格式错乱怎么办 | 提交报销的员工，使用浏览器打印时出现 | 1. 确认使用推荐浏览器；2. 在打印预览中选择“适应页面”；3. 预览显示完整表格后再打印 | 仍错乱时提交工单并附打印预览截图 |
| 新员工无法查看部门共享文档怎么办 | 入职一周内的新员工 | 1. 确认已加入对应部门群组；2. 在文档空间申请访问权限；3. 收到通过通知后刷新页面查看 | 超过一个工作日未通过，提交“权限申请”工单 |
条目与工单提交入口要形成衔接：每条FAQ末尾的转人工入口应指向对应的问题类型表单，用户提交时自动带上已查看的条目信息，服务台处理时能判断是条目未覆盖还是用户操作有误。ONES Desk 支持将工单一键关联到 ONES Wiki 页面，团队可以把FAQ条目沉淀在 Wiki 中，并在工单处理时关联对应条目，便于记录问题与复用经验。
角色分工与交付物
FAQ整理涉及采集、编写、审核、发布维护四类工作，需要明确到人，否则条目容易停留在草稿状态或上线后长期不更新。
| 角色 | 主要动作 | 交付物 | 完成标志 |
|---|---|---|---|
| 服务台一线 | 采集工单与咨询记录，初筛候选问题 | 候选问题清单 | 清单经复核，频次与样本量可回溯 |
| 内容编写人 | 按模板将候选问题写成FAQ条目 | FAQ条目初稿 | 五部分结构齐全，步骤可执行 |
| 业务或系统负责人 | 审核条目准确性，确认前置条件与失败原因 | 审核意见 | 条目状态变为“已审核” |
| 发布与维护责任人 | 上线条目，按复评节奏更新或下线 | 上线清单与更新记录 | 条目在自助入口可见，复评时间已登记 |
角色可以由同一人兼任，但职责要分开记录。建议为每条FAQ登记编写人、审核人和下次复评时间，条目状态按“候选—编写中—已审核—已上线—待更新”流转。ONES Desk 的工单分析报表可帮助团队掌握工单量分布，为候选问题的频次统计和上线后的效果对比提供数据基础；具体报表维度需结合团队配置确认。
上线验证与迭代：用数据判断条目是否有效
条目上线不等于完成。建议先小范围上线首批条目，观察一个完整周期（如四周），再决定扩充或调整。
验证指标建议包括三类：
| 指标 | 观察方式 | 判断参考 |
|---|---|---|
| 相关工单量变化 | 对比上线前后同口径周期内该问题类型的工单数 | 明显下降说明条目被使用且有效 |
| 自助入口点击与命中 | 统计条目被查看次数，以及查看后未提交工单的比例 | 查看多但转人工比例高，说明条目未解决问题 |
| 转人工比例 | 该问题类型工单中，用户已查看FAQ仍提交的比例 | 比例偏高时检查步骤或失败原因是否覆盖不足 |
对照口径要一致：上线前后取相同时长、相同问题类型、相同统计范围，避免因季节性波动或系统变更误判。若团队同期有其他流程调整，需在结论中注明影响因素。
无效条目的处置分三种：步骤表述不清或缺少前置条件的，改写；一条覆盖多个场景导致用户找不到对应步骤的，拆分；问题本身已不再出现或处理方式已变更的，下线并保留记录。每次处置都在条目上登记原因和日期。
新增高频问题的回流机制同样重要：服务台在处理工单时，遇到符合入选口径但尚无对应条目的问题，标记为“候选FAQ”，按固定节奏（如每两周）汇入候选清单，进入下一轮评分。ONES Desk 支持评估和定义工单优先级，团队可据此把待沉淀的高频问题排在处理队列前列，减少遗漏。
完成检查：FAQ整理是否可交付
首批条目上线前，用以下清单逐项核对，全部通过再视为本轮整理可交付：
- 口径齐备：已形成书面的FAQ入选与排除口径，服务台成员理解一致；
- 清单可回溯：候选问题清单包含频次、样本量和典型工单编号，归并规则有记录；
- 评分有依据：优先级评分表填写完整，首批上线清单经人工复核；
- 条目可执行：每条FAQ包含标题、适用场景、自助步骤、常见失败原因和转人工入口，步骤标注前置条件并说明完成标志；
- 责任到人：每条条目登记编写人、审核人和复评时间，状态流转规则明确；
- 兜底可用：转人工入口指向正确的问题类型表单，用户提交时能带上已查看条目信息；
- 验证已安排：验证指标、观察周期和对照口径已确定，复评时间点已登记。
清单核对完成后，把本轮的口径表、候选清单、评分表、条目模板和验证指标表归档到同一位置，作为下一轮扩充的起点。FAQ整理是一个持续循环：采集、归并、排序、成稿、验证，每一轮都把新出现的高频问题纳入，把失效条目清理出去。
常见问题
工单量不大、记录也不完整，还能开始整理FAQ吗？
可以先做小范围试点，但采集口径要相应调整。工单量少时，把在线咨询、会话记录和一线口头反馈一并纳入，取最近一个完整周期作为样本；候选问题清单里保留样本量字段，样本量明显不足的条目放入“暂缓”档，等积累到一定次数再评估。记录字段不统一时，先统一问题描述、处理动作和提问角色三项，其余字段可以后续补齐。
同一个问题在不同系统里表现不同，应该合并成一条FAQ还是拆开写？
以用户能否按同一条步骤解决为准。现象不同但处理动作完全一致、且用户按同一路径操作即可解决的，可以合并为一条，并在适用场景中说明涉及哪些系统；处理动作不同、需要分别操作的，即使根因相同也应拆开，否则用户会在步骤中找不到与自己界面对应的部分。拆分后各自计数，排序时按合计频次评估优先级。
首批FAQ上线后，多久评估一次比较合适？
建议首批上线后观察一个完整周期（如四周）再做正式评估，周期太短容易受偶发波动影响。评估时取上线前后相同时长、相同问题类型、相同统计范围的工单量对比，同时看条目查看次数和查看后仍提交工单的比例。此后可按固定节奏复评，例如每季度一次；系统改版、流程调整或某类工单明显回升时，提前触发复评。
用户看了FAQ仍然提交工单，怎么判断是条目问题还是用户操作问题？
先看工单里用户描述卡在哪一步。如果集中在同一步骤，通常是步骤表述不清、缺少前置条件或界面已变化，属于条目问题，应改写或补充截图；如果用户描述与条目场景不一致，说明适用场景写得不够明确，需要补充角色或入口说明；如果分散在各步骤且操作本身正确，可能是用户未按步骤执行，可在条目中增加完成标志提示。转人工入口收集的信息越具体，判断越容易。
FAQ条目和知识库文章内容重叠，维护时怎么避免两边不一致？
明确两者分工：FAQ条目面向用户自助，一条解决一个具体问题，步骤为主；知识库文章面向内部处理或深度使用，可以包含背景和多场景说明。重叠部分采用单向引用，FAQ条目引用知识库文章的背景说明，知识库文章指向对应FAQ条目，避免同一操作步骤在两处各写一份。指定发布与维护责任人统一管理更新，条目或文章任一方变更时同步检查引用关系。
