客户问题处理完成后，工单能否直接关闭，取决于客户是否认可处理结果。处理结果确认流程应设在“处理动作已完成、工单尚未关闭”之间，作为关闭前的必过关口。本文围绕确认时点、确认对象、确认渠道和记录字段四项要素，说明流程主干、分步操作、角色分工，以及客户未确认或表示不满意时的处置规则，并给出上线前检查清单。
要点总览（TL;DR）
- 处理结果确认环节设在“处理动作已完成、工单尚未关闭”之间，作为关闭前的必过关口：确认通过才允许关闭工单。
- 确认时点由处理人提交解决说明与证据触发，等待时限按问题等级分别配置；确认对象按问题影响面分层，单用户问题确认报障人，多用户或业务系统问题确认客户方负责人。
- 确认渠道优先沿用原受理渠道与客户习惯渠道，跨渠道发送时在工单内记录发送渠道与时间。
- 记录字段至少包含确认结论、确认人、确认时间、确认渠道、证据附件，备注可选，并区分必填与可选。
- 客户未回复时按提醒节奏逐级提醒并升级责任人，满足约定时限与留痕条件才可自动关闭；客户不满意时回退工单、重新分派并二次处理，再次确认通过后才关闭。
确认流程的核心结构与四个设计要素
处理结果确认流程的主干可以概括为：处理人完成处理动作并提交解决说明，流程生成确认请求并送达客户，客户给出确认结论，流程依据结论决定关闭工单或回退重办。确认环节位于处理完成之后、工单关闭之前，只有确认通过才允许关闭，这是整个流程的核心约束。
流程主干可按下图理解：
- 处理中 → 处理人提交解决说明与证据 → 待确认
- 待确认 → 客户确认通过 → 待关闭 → 关闭并归档
- 待确认 → 客户提出异议 → 回退处理中 → 重新分派与二次处理 → 再次进入待确认
- 待确认 → 超过约定时限未回复 → 提醒与升级 → 满足自动关闭条件后关闭并留痕
四项要素决定流程能否稳定运行，设计要点如下表。
| 要素 | 设计要点 | 常见做法 |
|---|---|---|
| 确认时点 | 由处理人提交解决说明与证据触发，工单进入待确认状态；同时设定等待时限 | 紧急问题等待时限短，一般咨询可放宽；时限按问题等级分别配置 |
| 确认对象 | 按问题影响面分层确定 | 单用户报障确认报障人本人；影响多用户或业务系统时，确认客户方负责人或受影响用户代表 |
| 确认渠道 | 优先原受理渠道与客户习惯渠道，保持沟通连续性 | 原渠道可回复时在原渠道发起；跨渠道发送时在工单内记录发送渠道与时间 |
| 记录字段 | 固定字段记录确认过程，区分必填与可选 | 确认结论、确认人、确认时间、确认渠道、证据附件为必填；备注为可选 |
确认时点与等待时限需要一起设计。触发条件明确为“处理人提交解决说明”，避免处理人仅口头告知就进入待确认；等待时限则决定客户多久未回复时启动提醒或升级。确认对象分层的目的，是让确认人具备判断处理结果是否可接受的信息与权限，减少反复转达。
分步操作：从提交解决说明到关闭工单
把流程拆成四个步骤，每步都明确输入、动作、输出与完成标志，便于在工单系统中配置状态与字段。
步骤一：处理人提交解决说明与证据
- 输入：处理记录、排查过程、修复或处置动作、相关截图或日志。
- 动作：在处理完成后填写解决说明，说明问题原因、已采取的措施、客户需要做的操作（如有），并上传证据。
- 输出：结构化的解决说明与证据附件。
- 完成标志：解决说明必填项填写完整，工单状态变为待确认。
步骤二：生成确认请求并发送
- 输入：解决说明、确认对象、确认渠道规则。
- 动作：系统按模板生成确认请求，或由客服按模板整理后发送；请求中说明问题已处理、请确认结果，并给出回复方式与时限。
- 输出：已发送的确认请求及发送记录。
- 完成标志：确认请求送达确认对象，工单内记录发送时间、渠道与接收人。
步骤三：客户确认、提出异议或超时未回复
- 输入：客户回复或等待时限到期。
- 动作：客户确认通过时记录确认结论；客户提出异议时记录异议内容并回退工单；超时未回复时按提醒节奏提醒并升级责任人。
- 输出：确认结论记录，或异议记录，或超时提醒与升级记录。
- 完成标志：工单进入待关闭、回退处理中或进入自动关闭判定三种状态之一。
步骤四：确认通过后关闭工单并归档
- 输入：确认通过的结论记录。
- 动作：关闭工单，归档解决说明、确认记录与证据。
- 输出：已关闭工单及完整处理档案。
- 完成标志：工单状态为已关闭，确认字段齐全可查。
在工单系统中落地时，状态流转与字段记录需要同步配置。ONES Desk 支持灵活调整工作流以适应不同企业的工作方式，并支持自定义工单属性与工单内容配置，可用于设置待确认状态、确认结论字段与确认请求模板；其及时通知与反馈工单处理结果的能力，可承载确认请求的发送环节。具体是否内置独立的确认节点与超时自动关闭规则，需以实际版本配置为准。
角色分工与各环节交付物
确认流程涉及四类角色：发起确认的处理人、给出结论的客户方确认人、负责抽检与兜底的服务主管，以及超时情况下的升级责任人。职责与交付物对照如下。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 一线客服/处理人 | 完成处理动作，提交解决说明与证据，发起确认请求，跟进客户回复 | 解决说明、证据附件、确认请求发送记录 |
| 客户方确认人 | 核验处理结果是否解决实际问题，给出确认或异议结论 | 确认结论、异议说明（如不满意） |
| 服务主管或质检角色 | 抽检确认记录完整性，复核不满意工单的处置，处理争议 | 抽检记录、复核意见、争议处理结论 |
| 升级责任人 | 接收超时未确认提醒，联系客户或协调内部资源推动确认 | 升级处理记录、最终确认或关闭依据 |
角色划分的关键是让“发起确认”和“判定确认”分开：处理人负责把处理结果讲清楚，客户方确认人负责判断结果是否可接受，服务主管负责检查流程是否被正确执行。升级责任人可以由服务主管兼任，也可以按问题等级指定，但需要在流程中写明，避免超时后无人跟进。
客户未确认或表示不满意时的闭环处理
两类异常分支决定流程是否真正闭环。未确认分支的目标是在不误关工单的前提下推动客户回复；不满意分支的目标是把问题重新送回处理环节，直到再次确认通过。
未确认分支：提醒、升级与自动关闭
- 提醒节奏：首次提醒在等待时限过半时发出，第二次提醒在时限到期时发出，提醒渠道与原确认渠道一致。
- 升级路径：时限到期仍未回复，升级至升级责任人，由其通过电话或其他客户习惯方式联系确认。
- 自动关闭条件：仅在约定时限已到、提醒记录完整、且问题等级允许自动关闭时执行；自动关闭需在工单内留痕，注明关闭依据。
- 责任人与时限：提醒由处理人执行，升级由升级责任人执行，各环节时限按问题等级配置。
不满意分支：回退、重派与再次确认
- 回退工单状态：客户表示不满意时，工单从待确认回退至处理中，原确认结论记为不通过。
- 重新分派：根据不满意原因决定由原处理人继续处理或转派其他人员，涉及多团队时由服务主管协调。
- 二次处理与再次确认：完成二次处理后重新提交解决说明，再次发起确认，直至确认通过才允许关闭。
- 原因分类记录：将不满意原因归入固定类别，如处理结果未解决、响应时间过长、沟通不清晰、期望不一致，用于后续分析。
异常分支规则可汇总为下表。
| 分支 | 触发条件 | 处置动作 | 责任人 | 时限 |
|---|---|---|---|---|
| 未确认 | 等待时限过半未回复 | 首次提醒 | 处理人 | 按问题等级配置 |
| 未确认 | 等待时限到期未回复 | 二次提醒并升级 | 升级责任人 | 到期后即时 |
| 未确认 | 满足自动关闭条件 | 关闭并留痕 | 系统或服务主管 | 约定时限之后 |
| 不满意 | 客户提出异议 | 回退状态、重新分派、二次处理 | 处理人与服务主管 | 按问题等级配置 |
| 不满意 | 二次处理完成 | 再次发起确认 | 处理人 | 同首次确认时限 |
对于工单需要关联研发工作项才能解决的问题，确认流程还需覆盖跨系统跟踪。ONES Desk 支持工单一键关联到 ONES Project 的需求/缺陷工作项，持续跟踪直至处理完成，便于在研发侧处理完成后回到工单发起客户确认；管理者视角可汇总工单处理情况、把控处理进度，并通过工单分析报表观察确认通过率与不满意分布。
示例：一次完整的处理结果确认过程
以下为演示情景，用于说明流程运转与字段填写方式。
某企业客户通过服务门户提交工单，反映报表导出功能在特定条件下失败，影响财务部门三名用户。该问题影响多用户，确认对象确定为客户方财务负责人，确认渠道沿用门户原受理渠道。
处理人排查后完成修复，提交解决说明：问题原因为导出任务并发冲突，已调整任务队列并完成验证；证据为修复前后对比截图与测试记录。工单进入待确认，系统生成确认请求发送至财务负责人，等待时限按一般问题设置为两个工作日。
客户在次日回复确认问题已解决，确认记录填写为：确认结论“通过”，确认人“财务负责人”，确认时间“次日上午”，确认渠道“服务门户”，证据“客户回复截图”，备注“建议后续关注高峰期导出”。工单进入待关闭并完成关闭归档。
另一情形中，客户回复表示导出速度仍然偏慢，确认结论记为“不通过”，不满意原因归入“处理结果未解决”。工单回退至处理中，服务主管协调性能方向的处理人重新分派，二次处理完成后再次提交解决说明并发起确认，客户确认通过后才关闭工单。
| 字段 | 确认通过情形 | 不满意回退情形 |
|---|---|---|
| 确认结论 | 通过 | 不通过 |
| 确认人 | 财务负责人 | 财务负责人 |
| 确认时间 | 次日上午 | 首次确认当日 |
| 确认渠道 | 服务门户 | 服务门户 |
| 证据 | 客户回复截图 | 客户异议说明截图 |
| 备注 | 关注高峰期导出 | 原因分类：处理结果未解决；已重新分派 |
流程上线前的完成检查
流程设计完成后，逐项核对以下检查项，全部满足再投入运行。
| 检查项 | 通过标准 |
|---|---|
| 确认时点与关闭条件是否已在工单状态机中固化 | 存在待确认状态，未确认通过的工单无法直接关闭 |
| 确认对象与渠道规则是否覆盖主要问题类型 | 单用户问题、多用户问题、业务系统问题均有对应的确认对象与渠道规则 |
| 记录字段是否必填、可选划分清晰 | 确认结论、确认人、确认时间、确认渠道、证据为必填，备注为可选，字段在工单中可见 |
| 超时与不满意分支是否有时限和责任人 | 提醒节奏、升级路径、自动关闭条件、回退与重派责任人均已写明 |
| 试运行与效果观察 | 选取一类问题试运行，观察确认通过率、平均确认时长、超时比例与不满意原因分布，确认无工单误关后再扩大范围 |
试运行阶段建议同时检查确认请求模板是否清楚说明了回复方式与时限，以及客户方确认人是否具备判断处理结果所需的信息。确认记录完整、异常分支有人跟进、关闭动作有据可查，流程即可稳定支撑客户问题处理完成后的服务闭环。
常见问题
确认请求发出后客户一直不回复，工单可以自动关闭吗？
可以，但需要同时满足三个条件：约定的等待时限已到、提醒记录完整、该问题等级允许自动关闭。自动关闭时应在工单内注明关闭依据，保留提醒发送记录与升级记录，便于后续追溯。对于问题等级较高或影响多用户的工单，建议由升级责任人先通过电话等客户习惯方式联系确认，再决定是否关闭。
客户口头说“可以了”，但没有在门户或邮件里回复，确认记录怎么填？
口头确认同样可以作为确认结论，但需要把确认过程落到记录里：确认渠道填写实际沟通渠道（如电话），确认人填写实际给出结论的客户方人员，确认时间填写沟通时间，证据栏附上通话记录或沟通纪要。若客户同意，可补发一条简短确认消息请其回复，形成书面留痕，减少后续争议。
客户表示不满意，但问题本身已经按方案处理完毕，还需要回退工单吗？
需要。确认流程判断的是客户是否认可处理结果，处理动作完成不等于结果被接受。客户表示不满意时，工单从待确认回退至处理中，确认结论记为不通过，并记录不满意原因分类。随后由服务主管根据原因决定由原处理人补充说明，还是转派其他人员二次处理，完成后再次发起确认。
确认对象应该找报障人还是客户方负责人？
按问题影响面确定。只影响单个用户的问题，确认报障人本人即可；影响多个用户或涉及业务系统时，确认客户方负责人或受影响用户代表，因为这类确认人具备判断结果是否可接受的信息与权限。若报障人与负责人不一致，可在确认记录中同时保留报障人反馈作为参考。
流程上线后，用什么指标判断确认环节是否起了作用？
可观察四类指标：确认通过率、平均确认时长、超时未回复比例、不满意原因分布。试运行阶段先选取一类问题运行，重点看是否存在未经确认就被关闭的工单；确认记录完整、异常分支有人跟进、关闭动作有据可查后，再扩大适用范围。
