工单关闭条件应由一组可核验的判定项组成，处理人凭感觉点“关闭”往往留下未解决的问题。本文围绕正常解决关闭、用户确认关闭、重复或无效关闭、超时自动关闭四类情形，给出判定项与证据要求、状态流转步骤、角色权限分工、一条完整示例和关闭后的质量检查清单，帮助团队把关闭规则写成可执行、可核对的流程。
要点总览（TL;DR）
- 关闭条件要落成可核验的判定项：解决方案记录、用户确认、关联记录更新、遗留事项转出，每项对应工单里能查到的证据。
- 按关闭类型区分必填项：正常解决关闭四项全查，用户确认关闭以明确回复为准，重复或无效关闭需填原工单编号或无效原因，超时关闭需保留等待期与提醒记录。
- 流程按“处理中—待关闭—待确认—已关闭”推进，处理人提交关闭申请、服务台核对、请求人确认，驳回后回到处理中，并设定重开时限。
- 权限上做到提交关闭与确认关闭分离，团队负责人负责抽检，超时关闭和无效关闭全量检查，正常关闭按比例抽查。
- 用重开率、驳回率、回访满意度、关闭后新建关联工单数验证关闭质量，指标异常时回到判定项和流程节点定位原因。
工单关闭条件由哪些判定项组成
关闭条件的设计思路是：每一条判定项都对应一个能在工单里查到的证据，核对人不需要追问处理人“当时是怎么处理的”。通用判定项覆盖解决方案、用户确认、关联记录和遗留事项四个方面，再按关闭类型决定哪些必填、哪些可以放宽。
通用判定项与证据形式
以下四项构成关闭判定的主体。前三项决定“这件事是否处理完”，第四项决定“有没有把没做完的部分留在关闭的工单里”。
| 判定项 | 判定内容 | 证据形式 | 必填/可选 |
|---|---|---|---|
| 解决方案记录 | 处理动作、结果和用户可复现的操作步骤已写入工单 | 工单的解决描述字段、操作步骤说明、截图或日志附件 | 必填 |
| 用户确认 | 请求人确认问题已解决，或确认窗口已过且无异议 | 工单确认记录、沟通记录、确认时间戳 | 正常解决关闭必填；无效关闭可豁免 |
| 关联记录更新 | 涉及的变更、配置项、资产或知识条目已同步更新 | 变更单号、配置项编号、知识页面链接 | 涉及变更或配置时必填 |
| 遗留事项转出 | 未完成的部分已转为新的工单、问题记录或需求 | 新工单编号、问题记录编号、需求条目编号 | 存在遗留事项时必填 |
按关闭类型区分必填项
四类关闭的证据要求不同，混用一套标准会让无效工单被迫走完整确认流程，也会让正常关闭缺少必要记录。
- 正常解决关闭：四项判定全部适用，解决方案记录和用户确认是核心证据。
- 用户确认关闭：以请求人明确回复“已解决”为准，解决方案记录仍需填写，关联记录按实际情况判断。
- 重复或无效关闭：必须填写重复指向的原工单编号，或说明无效原因（如信息不足、非本团队受理范围）；用户确认可豁免，但需记录通知请求人的方式和时间。
- 超时自动关闭：适用于已给出解决方案、请求人在约定等待期内未回应的工单。解决方案记录必填，系统需保留等待期起止时间和提醒发送记录，作为自动关闭的依据。
必填项确定后，建议把它们写进工单模板：关闭动作触发时校验字段是否填写，缺少证据则无法提交关闭申请。这样判定项从“规定”变成流程中的硬性约束。
关闭流程的操作步骤与状态流转
判定项确定后，需要把它们排成一条动作序列：谁在什么状态下做什么、产出什么。典型流程包含“处理中—待关闭—待确认—已关闭”四个状态，以及驳回后回到处理中的分支。
从提交关闭申请到关闭完成
- 提交关闭申请（处理人）：在处理中状态下填写解决描述、关闭类型、关联变更单号或新工单编号，上传必要附件，将工单置为待关闭。输出是一份字段完整的关闭申请。
- 核对判定项（服务台或协调员）：按关闭类型逐项检查证据是否齐全，齐全则转入待确认，缺失则退回处理人补充。输出是核对结论和核对人记录。
- 等待用户确认（请求人）：工单进入待确认状态，系统按约定等待期（例如3个工作日）计时，并在等待期过半和到期前各发送一次提醒。输出是提醒记录和请求人反馈。
- 分支处理：请求人确认解决则关闭；等待期届满无异议则按超时规则关闭，并记录“超时未回应”；请求人驳回则回到处理中，驳回理由写入工单。
- 关闭后重开：设定重开时限（例如关闭后7天内），请求人可在时限内申请重开，由服务台判断是否属于同一问题；超出时限的按新工单受理，并关联原工单编号。
状态、动作与责任人对照
| 状态 | 触发动作 | 责任人 | 输出 |
|---|---|---|---|
| 处理中 | 完成处理并提交关闭申请 | 一线处理人 | 解决描述、关闭类型、证据字段 |
| 待关闭 | 核对判定项，通过或退回 | 服务台/工单协调员 | 核对结论、核对时间 |
| 待确认 | 发送确认提醒，等待请求人反馈 | 系统提醒，请求人回应 | 提醒记录、确认或驳回意见 |
| 已关闭 | 确认通过或等待期届满 | 服务台/工单协调员 | 关闭时间、关闭类型、关闭依据 |
| 处理中（重开） | 请求人驳回或申请重开 | 服务台判定，处理人继续处理 | 驳回理由、重开次数 |
这套流转需要在工单系统里配置状态、流转条件和字段校验。ONES Desk 支持灵活调整工作流，并可自定义工单属性与工单内容，团队可以据此把关闭类型、解决描述、关联单号设为关闭环节的必填字段，让状态流转与判定项保持一致；具体可配置的校验范围和审批节点以实际产品配置为准。
谁有权关闭：角色分工与职责边界
关闭环节最常见的失控点是处理人自己提交、自己关闭。把“处理”和“确认”拆给不同角色，再让负责人对关闭质量负责，才能避免关闭动作变成走形式。
四类角色的关闭职责
| 角色 | 关闭相关职责 | 权限边界 |
|---|---|---|
| 一线处理人 | 填写解决方案与证据字段，提交关闭申请，响应驳回后继续处理 | 可提交关闭申请，不能自行确认关闭 |
| 服务台/工单协调员 | 核对判定项是否齐全，判断关闭类型是否准确，处理重开申请 | 可确认关闭或退回补充，不能替代请求人做解决确认 |
| 团队负责人 | 制定和修订关闭规则，组织质量抽检，处理争议工单 | 可审批例外关闭，可调整规则版本 |
| 请求人 | 确认问题是否解决，驳回不认可的关闭，申请重开 | 只对自己的工单做确认，不参与他人工单判定 |
权限分配与抽检安排
权限分配遵循两条原则：提交关闭与确认关闭分离；例外关闭（如无效关闭、紧急情况下的强制关闭）需要负责人审批并留下理由。跨团队工单由受理方的服务台负责核对判定项，解决确认仍由请求人完成；若请求人属于其他团队，可在工单中指定其对接人代为确认，并在记录中注明委托关系。
质量抽检由团队负责人或指定的质量角色执行，建议按关闭工单的固定比例抽取（例如每周抽取10%–20%，无效关闭和超时关闭全部纳入）。抽检不合格的工单退回处理人补充证据或重新打开，抽检结果记入个人与团队的关闭质量记录。
示例：一条服务请求工单的关闭全过程
以下为演示情景，用于说明判定项与角色如何协同，不代表真实客户案例。
背景：某部门员工提交工单，反映办公账号无法登录业务系统，工单类型为服务请求，优先级为普通。
- 处理过程：一线处理人排查后确认是账号权限未同步，完成权限配置并请用户重新登录验证。处理人在工单中填写解决描述“已同步账号权限，用户重新登录成功”，关闭类型选择“正常解决关闭”。
- 关闭申请字段：解决描述、操作步骤、验证截图作为附件；关联记录填写配置项编号“ACCT-1042”；无遗留事项，遗留事项转出字段留空并注明“无”。
- 核对与等待：服务台核对四项判定项齐全，工单转入待确认，等待期设为3个工作日。第2个工作日系统发送提醒，请求人回复“已能正常登录”。
- 关闭与归档：服务台确认关闭，关闭时间、关闭类型、核对人写入工单；解决方案同步到知识页面，供同类问题参考。
- 驳回情形：若请求人回复“仍无法登录”，工单回到处理中，驳回理由记录在案，处理人重新排查；若查明是另一系统的问题，则将遗留事项转为新工单并关联原工单编号，原工单按“已转出”关闭。
这个例子说明：关闭不是处理结束后的一个点击动作，而是由字段、证据、确认记录共同支撑的一次交接。遗留事项转出尤其重要，它让关闭的工单保持“已处理完”的准确性。ONES Desk 支持工单一键关联到 ONES Project 的需求或缺陷工作项，也支持关联 ONES Wiki 页面沉淀服务经验，便于把转出事项和解决方案记录在可追踪的位置。
关闭质量的完成检查与持续验证
规则写得再细，也需要用检查清单和指标验证执行情况。单条工单看关闭前是否过关，整体流程看一段时间内的关闭质量趋势。
关闭前检查清单
| 检查项 | 通过标准 |
|---|---|
| 关闭类型 | 与实际情形一致，无效关闭和超时关闭有明确依据 |
| 解决方案记录 | 描述具体、可复现，包含验证方式 |
| 用户确认 | 有确认记录，或等待期与提醒记录完整 |
| 关联记录 | 涉及的变更单、配置项已更新并可查 |
| 遗留事项 | 已转为新工单或问题记录，编号填写完整 |
| 字段完整性 | 必填字段无空缺，附件可打开 |
周期性验证指标
| 指标 | 观察内容 | 异常时的调整方向 |
|---|---|---|
| 重开率 | 关闭后短期内被重新打开的工单占比 | 检查解决方案记录是否充分、确认环节是否流于形式 |
| 驳回率 | 待确认阶段被请求人驳回的比例 | 排查处理质量与关闭类型判断是否准确 |
| 回访满意度 | 关闭后回访中请求人的评价分布 | 结合低分工单复盘判定项与处理过程 |
| 关闭后新建关联工单数 | 同一问题在关闭后再次建单的数量 | 检查遗留事项是否被遗漏转出 |
抽检样本建议覆盖各类关闭类型，超时关闭和无效关闭全量检查，正常关闭按比例抽查；判定口径在规则文档中写清楚，避免不同抽检人标准不一。指标异常时，先回到判定项和流程节点定位原因，再决定是补充字段、调整等待期还是加强核对。
规则文档本身也需要维护：指定负责人，记录版本号和修订内容，流程或字段调整时同步更新关闭判定项，并在团队内公告变更。ONES Desk 可汇总工单处理情况并提供工单分析报表，管理者可以据此观察处理进度和团队表现，把抽检记录与指标复盘放在同一套工作项体系里跟踪；报表包含的具体指标项以实际产品为准。
常见问题
用户一直不回复确认，工单能不能直接关闭？
可以，但要满足两个前提：解决方案记录已完整填写，且等待期与提醒记录可查。建议在规则中写明等待期长度（例如3个工作日）、提醒次数与发送时间，等待期届满无异议后按“超时自动关闭”处理，并在工单中记录关闭依据。请求人在重开时限内提出异议的，仍应重新打开处理。
重复工单和无效工单关闭时，还需要用户确认吗？
通常可以豁免用户确认，但要用其他证据替代。重复关闭必须填写原工单编号，让后续查看的人能直接找到已处理的那条记录；无效关闭需写明无效原因（如信息不足、非本团队受理范围），并记录通知请求人的方式和时间。豁免确认不等于不告知，通知记录本身就是关闭依据的一部分。
跨团队工单由谁负责关闭确认？
由受理方的服务台或工单协调员核对判定项，解决确认仍由请求人完成。请求人属于其他团队时，可在工单中指定其对接人代为确认，并在记录中注明委托关系。这样既保证核对标准统一，也避免受理方替请求人判断“问题已解决”。
关闭后重新打开有没有时限，超时怎么办？
建议设定重开时限（例如关闭后7天内），由服务台判断是否属于同一问题。时限内属于同一问题的直接重开，工单回到处理中并累计重开次数；超出时限的按新工单受理，同时关联原工单编号，保留问题脉络。重开时限与判定口径应写入规则文档，避免不同协调员处理不一致。
关闭规则定好后，怎么判断它真的在执行？
从两个层面看：单条工单用关闭前检查清单核对字段与证据是否齐全；整体流程用重开率、驳回率、回访满意度和关闭后新建关联工单数观察趋势。抽检样本覆盖各类关闭类型，超时关闭和无效关闭全量检查。指标异常时先定位是判定项缺失、等待期设置不合理还是核对环节流于形式，再调整规则并更新版本记录。
