工单关闭按“先判定可关闭、再确认结果、后归档留痕”三步执行：处理人完成处置并写清解决说明，向提交人确认问题已解决或按规则免确认，满足条件后由有权限的角色变更状态，系统记录关闭时间、关闭人、关闭原因与关联记录。关闭前要核对请求是否已交付、是否还有待回访或待审批事项；关闭后保留可追溯记录，需要重开时按约定条件恢复。
要点总览（TL;DR）
- 关闭前先做判定：请求已交付、结果已确认或符合免确认规则、没有未完成的关联事项，三项都满足才进入关闭操作。
- 关闭按四步执行：写解决说明、发起结果确认、由有权限角色变更状态并填写关闭原因、系统记录关闭时间与关闭人。
- 提交人负责确认结果，处理人负责解决说明与处置证据，服务台或工单管理员执行关闭与原因归类，团队负责人抽检与审批例外。
- 关闭后约定重开期限，误关闭通过重开并备注纠正原因处理，原关闭记录保留，形成完整轨迹。
- 用检查清单核对判定、说明、确认、权限、原因与留痕，未确认即关闭、无解决说明、原因缺失属于阻断项。
关闭前先判定：哪些工单可以进入关闭
关闭动作本身只需几秒，真正决定关闭质量的是动手前的核对。处理人准备关闭一条工单时，先对照以下条件逐项确认，全部满足才进入关闭操作。
- 请求已交付：用户申请的服务、权限、账号、设备或信息已经实际提供，或处理结果已经产生。
- 结果已确认或按规则免确认：提交人明确回复问题已解决；或者该工单属于团队约定可免确认的类型，例如纯通知类、重复提交已合并的工单。
- 无未完成关联事项：没有挂起的子任务、待审批的变更、待回访的满意度调查，也没有关联到其他团队尚未回复的协作请求。
出现以下情形时，工单应保持打开状态，继续推进而不是提前关闭：等待用户补充信息或反馈确认结果；等待第三方供应商、外部系统或兄弟团队回复；存在未完成的子任务或待审批事项；处理结果尚未验证，例如补丁已提交但用户环境还未生效。这些情况下可以先更新处理记录、说明当前卡点，让工单状态如实反映进展。
关闭原因分类建议在流程设计阶段就固定下来，避免关闭时随手填写。常见分类如下表，团队可按服务类型增删，但应保持选项数量精简、含义互斥。
| 关闭原因 | 适用情形 | 填写要求 |
|---|---|---|
| 已解决 | 请求已交付且提交人确认或按规则免确认 | 必须关联解决说明 |
| 重复 | 与已有工单描述同一问题 | 填写被合并或指向的工单编号 |
| 取消 | 提交人主动撤回，或需求不再需要 | 记录撤回来源与时间 |
| 无法复现 | 按提交信息多次尝试未能重现问题 | 写明尝试步骤与沟通记录 |
| 非本团队受理 | 转交其他团队或不属于服务范围 | 填写转交对象或范围说明 |
判定环节的产出是一份核对结论：要么“满足关闭条件”，要么“暂不关闭并注明卡点”。这份结论不需要单独文档，体现在解决说明和状态选择中即可。
关闭操作步骤：从解决说明到状态变更
判定通过后，关闭按四步执行。每一步都有明确的输入、动作、输出和完成标志，便于处理人和服务台按同一口径操作。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 第一步：写解决说明 | 处置过程记录、交付凭证、相关截图或日志 | 处理人填写解决说明，写清做了什么、结果是什么、用户如何使用或验证 | 结构完整的解决说明与处置证据 | 说明能让未参与处理的同事看懂问题与结果 |
| 第二步：发起结果确认 | 解决说明、提交人联系方式 | 向提交人发送确认请求，说明处理结果并请其回复是否解决；同时设定确认时限 | 确认请求记录与提交人回复 | 收到明确确认，或确认时限到期且符合免确认规则 |
| 第三步：变更状态 | 确认结果、关闭原因分类 | 由有权限的角色将工单状态改为已关闭，选择关闭原因并补充必要备注 | 状态变更记录与关闭原因 | 工单状态显示为已关闭，关闭原因已填写 |
| 第四步：系统留痕 | 状态变更动作 | 系统自动记录关闭时间、关闭人、关闭原因及关联记录 | 可查询的关闭记录 | 在工单详情中能查到上述字段，且与操作一致 |
确认时限需要结合服务类型设定。高频、低风险的服务请求可以设置较短的确认窗口，例如一个工作日内未回复视为默认确认；涉及权限变更或数据操作的工单，建议要求明确回复后再关闭。时限规则应写入团队的服务说明，并在工单中可见，避免提交人不知情。
解决说明的写法直接影响后续查询和知识沉淀。建议包含三部分：问题或请求的描述、采取的处理动作、最终结果与验证方式。例如“已为该用户开通项目文档库只读权限，权限于当日 14:00 生效，用户可在项目空间直接访问”，比“已处理”更有追溯价值。
在工具层面，关闭动作依赖状态流转和字段记录。ONES Desk 支持自定义工作流与工单属性，团队可以按自身方式配置关闭状态、关闭原因等字段；处理过程中可直接与客户对话并反馈处理结果。具体状态名称、关闭原因字段和操作入口以实际产品界面为准，配置前建议先在测试流程中走通一遍。
角色与交付物分工：谁确认、谁关闭、谁复核
关闭环节涉及四类角色，职责边界清晰才能避免“谁都以为别人会关”或多人重复操作。下表给出各角色的职责与交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提交人 | 确认处理结果是否满足需求；在约定时限内回复；超时未回复时按团队规则处理 | 确认回复或超时记录 |
| 处理人 | 完成处置，填写解决说明，提供处置证据，发起结果确认 | 解决说明、处置凭证、确认请求记录 |
| 服务台或工单管理员 | 执行或核对状态变更，选择关闭原因，处理免确认类工单的关闭 | 状态变更记录、关闭原因归类 |
| 团队负责人 | 抽检关闭质量，审批例外关闭，处理争议与误关闭纠正 | 抽检记录、例外审批意见、纠正记录 |
权限设计上，建议将“变更状态为已关闭”的权限收敛到服务台或工单管理员，处理人负责准备关闭所需的信息。这样做的原因是关闭原因归类需要一致性，集中执行更容易保持口径统一。对于处理人同时兼任服务台的小团队，可以由同一人完成，但仍需在流程上区分“准备关闭”和“执行关闭”两个动作，保留核对环节。
团队负责人不必逐单复核，按抽检比例检查即可。抽检重点看解决说明是否可读、关闭原因是否准确、确认记录是否完整。例外审批适用于不符合标准条件但确需关闭的工单，例如提交人长期失联且服务已无法继续推进，此时由负责人审批并记录理由。
示例：一条服务请求工单的完整关闭过程
以下为演示情景，用于说明字段如何填写，不代表真实客户案例。
情景设定：某员工提交工单，申请为其新入职同事开通项目协作空间的访问权限。工单从受理、处理到关闭的连续过程如下。
- 受理：服务台确认申请人、目标空间与权限范围，将工单指派给系统管理员，状态为处理中。
- 处理：系统管理员在协作空间中添加该成员并分配只读角色，截图保存成员列表作为处置证据。
- 解决说明填写：“已为张三开通项目 A 协作空间只读权限，角色为访客，可查看文档与任务列表，不可编辑。权限已于 6 月 3 日 10:20 生效，请让本人登录确认能否访问。”
- 确认环节：处理人通过工单对话向提交人发送上述说明，请其确认。提交人当日回复“已能正常访问，谢谢”。沟通记录随工单保存。
- 超时处理：若提交人未在约定时限内回复，服务台按团队规则将该类低风险权限工单视为默认确认，并在关闭备注中注明“确认时限到期，按规则关闭”。
- 状态变更：服务台将状态改为已关闭，关闭原因选择“已解决”，关联处置截图。
- 关闭后保留字段：工单编号、提交人、处理人、关闭人、关闭时间、关闭原因、解决说明、对话记录、处置截图、关联的空间与成员信息。
这个例子中，解决说明写清了对象、动作、生效时间和验证方式，关闭原因与实际情况一致，关闭后任何人查看工单都能还原处理过程。若该权限申请涉及敏感数据，团队可将此类工单设为必须明确回复后才能关闭，取消超时默认规则。
关闭后的重开与留痕管理
关闭是流程的一个节点，不是记录的终点。用户在使用中发现问题复现，或确认时误判，都需要有恢复通道。
重开条件与时限：建议约定在关闭后一定期限内，例如七个自然日内，提交人可凭原工单申请重开；超出期限的问题作为新工单提交，并在新工单中引用原工单编号。重开时状态恢复为处理中，保留原有解决说明和对话记录，新增重开原因。时限长短按服务类型调整，权限类工单可短一些，咨询类可长一些。
留痕字段与查询：关闭记录至少保留工单编号、提交人、处理人、关闭人、关闭时间、关闭原因、解决说明、确认记录、关联工作项或文档。查询方式应支持按关闭原因、关闭时间、处理人筛选，便于复盘。若工单关联了研发侧的需求或缺陷，关闭时应在关联记录中同步状态，避免两边信息不一致。ONES Desk 支持将工单一键关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀服务经验，关联关系会随工单保留。
误关闭与重复关闭的纠正：发现误关闭时，由服务台重开工单并在备注中写明纠正原因，原关闭记录保留不删除，形成完整轨迹。重复关闭指同一问题被多次关闭又重开，应检查解决说明是否真正回应了问题，必要时升级给团队负责人协调。纠正动作本身也应留痕，便于抽检时区分正常关闭与事后修正。
关闭数据的简单用法：按月统计关闭原因分布，可以看岀重复提交、无法复现的比例是否偏高；统计重开率，可以判断确认环节是否流于形式；统计从受理到关闭的时长分布，可以识别处理瓶颈。这些统计不需要复杂报表，按关闭原因和重开标记做基础汇总即可。ONES Desk 可汇总工单处理情况，帮助管理者了解处理进度，具体统计口径以实际配置为准。
完成检查：关闭流程是否做到位
以下清单可用于处理人自查、服务台日常核对或团队负责人抽检。每项给出通过标准与所需证据，任一阻断项不通过即视为关闭不合格。
| 检查项 | 通过标准 | 所需证据 | 是否阻断 |
|---|---|---|---|
| 关闭判定 | 请求已交付，无未完成关联事项 | 解决说明中的交付描述、关联事项状态 | 是 |
| 解决说明 | 写清问题、动作、结果与验证方式，他人可读懂 | 工单中的解决说明字段 | 是 |
| 结果确认 | 有提交人明确回复，或符合免确认规则并有记录 | 对话记录、超时记录或免确认依据 | 是 |
| 关闭权限 | 由有权限角色执行状态变更 | 操作日志中的关闭人 | 是 |
| 关闭原因 | 已选择分类且与实际情况一致 | 关闭原因字段 | 是 |
| 留痕完整 | 关闭时间、关闭人、关联记录可查 | 工单详情页字段 | 是 |
| 关联同步 | 关联的研发工作项或文档状态一致 | 关联记录状态 | 否，但需限期补齐 |
阻断项包括未确认即关闭、无解决说明、关闭原因缺失，出现任一项应退回处理人补充。抽检频率建议按团队工单量设定：日均关闭量较大的团队每周抽检一次，每次抽取一定比例；量小的团队可每月抽检。抽检由团队负责人或指定的质量角色执行，结果记录在固定的检查表中，连续出现同类问题的，回到流程设计上调整确认规则或字段设置。
检查的目的在于让关闭动作形成稳定习惯：判定有依据、说明可追溯、确认有记录、权限不越位、数据能复盘。做到这几点，工单关闭就不再是点一下按钮，而是服务交付的可靠收尾。
常见问题
提交人一直不回复确认，工单能不能直接关闭？
取决于团队是否事先约定了免确认规则。低风险、高频的服务请求可以设置确认时限，例如一个工作日内未回复视为默认确认，关闭时在备注中注明“确认时限到期，按规则关闭”。涉及权限变更、数据操作或敏感资源的工单，建议要求提交人明确回复后再关闭。规则要写进服务说明并在工单中可见，让提交人知道不回复的后果，避免事后争议。
工单关闭后发现处理结果不对，应该重开还是新建工单？
在约定的重开期限内，例如关闭后七个自然日内，凭原工单申请重开更合适，原有解决说明和对话记录会保留，新增重开原因即可。超出期限的问题作为新工单提交，并在新工单中引用原工单编号，便于对照。重开时限按服务类型调整，权限类工单可短一些，咨询类可长一些。
处理人自己关闭工单，和由服务台统一关闭，哪种做法更好？
两种做法都能运行，区别在于关闭原因的口径是否容易统一。由服务台或工单管理员集中执行关闭，关闭原因归类更一致，也便于统计；处理人负责准备解决说明和处置证据。小团队中处理人兼任服务台时可由同一人完成，但流程上仍保留“准备关闭”和“执行关闭”两个动作，中间有核对环节，避免漏填说明或原因。
关闭原因分类设多少个合适？
建议保持精简且含义互斥，常见的有已解决、重复、取消、无法复现、非本团队受理几类，团队可按服务类型增删。选项过多会导致填写随意、统计失真；选项过少则无法区分问题来源。分类应在流程设计阶段固定，关闭时按实际情况选择，并配合填写要求，例如重复类要写被指向的工单编号，取消类要记录撤回来源与时间。
关闭数据怎么用来改进服务流程？
按月统计关闭原因分布，可以看重复提交、无法复现的比例是否偏高；统计重开率，可以判断确认环节是否流于形式；统计从受理到关闭的时长分布，可以识别处理瓶颈。这些汇总按关闭原因和重开标记做基础统计即可，不需要复杂报表。发现某类问题集中出现时，回到流程设计上调整确认规则、字段设置或服务说明，而不是只要求处理人加快关闭。
