工单关闭条件要能被执行和复核，通常由三部分共同确定：可验证的解决标准、可留痕的确认依据、明确的关闭权限。本文聚焦服务请求流程，给出判定项设计方法、角色分工、完整示例与检查清单，帮助你把“处理完毕”这类笼统表述换成可勾选、可追溯的关闭规则。
要点总览（TL;DR）
- 工单关闭条件由三部分共同确定：可验证的解决标准、可留痕的确认依据、明确的关闭权限，三者齐备才允许关闭。
- 解决标准按工单类型分别定义，服务请求、咨询、故障报修、权限类申请的判定项各不相同，每项应能用“是/否”回答。
- 关闭环节要分清提交人、处理人、确认人或审批人、工单管理员的职责与交付物，例外关闭由工单管理员审批并留痕。
- 关闭后保留重开入口，约定触发条件、时限与责任人，重开记录保留原关闭信息，形成可回溯的状态链。
- 用完成检查清单逐项核对判定项是否可验证、权限是否明确、重开与例外是否有规则，补齐后再投入执行。
工单关闭条件由哪三部分构成
关闭条件写成一句“问题已解决”，执行时就会变成处理人的主观判断：有人凭印象关单，有人等提交人回复，有人越权操作。把关闭条件拆成三个要素，每个要素落到具体字段，判定才有共同口径。
第一是解决标准，回答“做到什么程度算完成”。它必须是可验证的，能通过查看交付物、核对记录或取得对方确认来判断真假。第二是确认依据，回答“凭什么说已经完成”，需要留下可查的记录，如提交人的确认回复、交付物链接、处理过程说明。第三是关闭权限，回答“谁有权把状态改成已关闭”，要指定角色，并规定越权和例外情形的处理路径。三者缺一，关闭就会退回到口头判断。
三个要素对应的字段可以这样设计：
| 要素 | 要回答的问题 | 建议承载字段 | 填写要求 |
|---|---|---|---|
| 解决标准 | 做到什么程度算完成 | 完成标准（按工单类型预设）、判定项勾选 | 逐项勾选，不允许整体跳过 |
| 确认依据 | 凭什么确认完成 | 确认人、确认时间、确认方式、交付物链接或处理说明 | 至少一项可查记录，不能只写“已处理” |
| 关闭权限 | 谁可以执行关闭 | 关闭人、关闭角色、关闭时间、关闭原因 | 与授权角色一致，例外关闭需附审批记录 |
字段设计完成后，还要约定一条总规则：三个要素全部满足才允许关闭，任一缺失则工单停留在待确认或处理中状态。这条规则让关闭从“处理人的个人决定”变成“流程上的状态迁移”。
按工单类型制定关闭判定项
不同类型的工单，完成的样子不一样。服务请求的完成是“东西交付并被接收”，咨询的完成是“答复给出并被确认”，故障报修的完成是“服务恢复并经提交人验证”。用同一套判定项覆盖所有类型，要么标准过松，要么把简单工单拖入不必要的审批。合理做法是先按类型拆分，再为每类写出输入、判定动作和输出。
拆分时先列出本组织实际发生的工单类型，通常包括服务请求、咨询、故障报修，必要时增加权限申请、账号变更等子类。每类工单在提交环节就带上类型字段，系统据此加载对应的判定项清单。判定项控制在三到五项，每项都能用“是/否”回答，避免出现“基本完成”“大致可用”这类无法核对的表述。
| 工单类型 | 输入 | 判定动作 | 输出 |
|---|---|---|---|
| 服务请求 | 请求内容、交付物、提交人信息 | 核对交付物与请求是否一致；确认提交人已接收并认可 | 交付物链接、提交人确认记录、判定项勾选结果 |
| 咨询 | 问题描述、答复内容 | 核对答复是否覆盖所问问题；确认提问人表示已获得所需信息 | 答复记录、提问人确认回复 |
| 故障报修 | 故障现象、处理过程、恢复情况 | 核对服务是否恢复；由提交人验证并确认可正常使用 | 处理过程说明、恢复验证记录、提交人确认 |
| 权限或账号类申请 | 申请范围、审批结果、开通记录 | 核对开通范围与审批一致；确认申请人可正常使用 | 审批记录、开通凭证、申请人确认 |
判定过程中会遇到无法按原类型关闭的情况。例如服务请求在交付前发现需求本身有误，或故障报修实际指向一个需要长期处理的问题。这时不应强行勾选判定项，而应转入其他流程：需求有误的退回提交人补充或转为变更请求；故障涉及根因治理的，转为问题管理流程跟踪，原工单注明转出原因和关联记录后再关闭或合并。转出动作本身也要留痕，保证后续能查到这条工单去了哪里。
关闭流程中的角色与交付物
关闭环节常见的失序有两种：处理人自行关单，提交人还没确认；或者所有人都等对方确认，工单长期悬置。解决办法是把关闭环节的角色、职责和交付物写清楚，让每个动作都有归属。
| 角色 | 职责边界 | 交付物或确认记录 |
|---|---|---|
| 提交人 | 确认解决结果是否符合请求；在约定时限内反馈 | 确认回复或验收意见；超时未反馈的记录 |
| 处理人 | 完成处理并提交判定项；发起确认；不得在未取得确认依据时自行关闭 | 处理说明、交付物链接、判定项勾选结果 |
| 确认人或审批人 | 对高风险或例外关闭进行复核，判断依据是否充分 | 复核意见、审批记录 |
| 工单管理员 | 维护判定项与关闭规则；处理越权关闭、超时悬置和例外关闭 | 规则变更记录、例外关闭审批单、状态调整日志 |
关闭权限的授予遵循“谁处理、谁发起，谁确认、谁认可”的分工：处理人负责提交关闭申请并附上依据，提交人负责确认结果，工单管理员保留对例外情形的处置权。对于低风险的标准服务请求，可以约定提交人超时未反馈即视为默认确认，但这一规则要事先告知并在工单中显示倒计时，避免变成单方面关单。例外关闭指依据不完整但仍需结单的情形，例如提交人已离职、请求重复提交，这类关闭必须由工单管理员审批，并在工单中写明原因和审批人。
这些判定项、确认记录和状态流转需要有承载的地方。ONES Desk 支持自定义工单属性与工单内容，可用来放置完成标准、确认方式等字段；工作流可灵活调整，便于把“待确认—已关闭”的迁移与角色权限对应起来；团队可以在同一处集中管理工单状态、处理进度和责任分工。当工单背后涉及产品需求或缺陷时，ONES Desk 支持将工单一键关联到 ONES Project 的需求或缺陷工作项持续跟踪，也可关联 ONES Wiki 页面沉淀处理经验，让关闭依据不只停留在工单本身。
示例：一条服务请求工单的关闭判定
以下为演示情景，用于说明判定过程，不代表真实案例。
背景：某部门员工提交一条服务请求，申请为新入职同事开通内部知识库的编辑权限，工单类型为“权限或账号类申请”，提交人注明使用人为新同事，期望在入职当天可用。
处理人核对申请后完成权限开通，随后按判定项逐项处理：
- 申请范围与审批结果是否一致：审批记录显示批准的是知识库编辑权限，开通记录为同一权限，判定通过，附审批单号与开通截图链接。
- 开通对象是否正确：核对账号为提交人指定的新同事账号，判定通过。
- 申请人是否可正常使用：处理人在工单中发起确认，提交人回复“已登录验证，可以编辑”，判定通过，确认时间与回复内容一并留存。
三项判定全部通过后，处理人提交关闭申请，工单状态由“待确认”变为“已关闭”。关闭记录中包含：关闭人、关闭时间、三项判定结果、审批单号、开通凭证链接、提交人确认回复。整条工单从提交到关闭的过程可被追溯，后续如出现权限异常，也能据此定位当时的开通范围和确认情况。
关闭后的重开与例外处理
关闭不等于终结。问题复现、确认不充分、关闭依据后来被证明有误，都需要有回到处理中的路径，否则团队只能新建一条工单，历史记录被割裂。
重开的触发条件应事先约定，常见的有三类：提交人在关闭后一定期限内反馈问题复现；复核发现确认依据不完整，例如只有处理人说明而无提交人确认；关联工作项出现新的处理结果，影响原判定。时限可以按工单类型分别设定，例如服务请求关闭后若干工作日内可申请重开，超过时限则按新工单处理并关联原工单。时限的具体天数由组织根据服务节奏确定，关键是写进规则并让提交人可见。
重开后工单回到处理中状态，责任人默认为原处理人；原处理人已不在岗时，由工单管理员重新指派。重开记录要保留原关闭信息和重开原因，形成完整的状态流转链。例外关闭则走另一条路径：由工单管理员审批，工单中注明例外原因、审批人和后续补偿动作，例如另行安排回访或转为问题跟踪。例外关闭的数量建议定期回顾，数量持续偏高往往说明判定项设计与实际业务不匹配，需要调整标准而非放宽审批。
完成检查：关闭条件是否可执行
规则写完后，用下面这份清单逐项核对，判断关闭条件能否真正落地。
- 每类工单都有独立的判定项清单，且每项都能用“是/否”回答，没有“基本完成”这类模糊表述。
- 判定项与工单字段对应，勾选结果、确认人、确认时间、交付物链接都能在工单中查到。
- 关闭动作有明确的授权角色，越权关闭能被识别，例外关闭有审批记录。
- 提交人确认的方式和时限已告知，超时默认确认的规则有明确提示。
- 无法按原类型关闭时，有转出流程和转出记录，原工单能关联到后续处理对象。
- 重开触发条件、时限和责任人有书面约定，重开后状态流转可追溯。
- 例外关闭有定期回顾机制，回顾结果能反馈到判定项的修订。
- 判定项和关闭规则有维护责任人，规则变更留有记录。
清单中任何一项无法确认，都说明关闭条件还停留在原则层面。逐项补齐后，关闭判定就从个人经验变成了团队可共用、可审计的流程规则。
常见问题
提交人长期不回复确认，工单能否直接关闭？
可以约定超时默认确认，但需要满足两个前提：规则事先告知提交人，并在工单中显示确认倒计时；超时记录本身作为确认依据留存。对于低风险的标准服务请求，这种方式能避免工单长期悬置；对于高风险或涉及权限、费用的工单，建议仍由确认人或工单管理员复核后再关闭，避免默认确认掩盖实际问题。
一条工单同时涉及服务请求和故障处理，关闭条件按哪类执行？
建议按工单的主诉求确定类型，并在处理过程中拆分。若故障部分需要根因治理，可将其转为问题管理流程跟踪，原工单注明转出原因和关联记录；服务请求部分按对应判定项完成确认后关闭。关键是转出动作留痕，让后续能查到这条工单去了哪里，避免两类标准混在一起导致判定项无法勾选。
关闭权限应该给处理人还是工单管理员？
常见分工是处理人发起关闭申请并附上判定项与确认依据，提交人确认结果，工单管理员保留例外情形的处置权。这样既不让处理人单方面关单，也避免所有关闭都堆到管理员处形成瓶颈。权限授予方式可以按角色或工单类型区分，具体粒度需结合所用工具的权限配置能力确定。
重开时限设多长比较合适？
时限没有统一标准，可按工单类型和服务节奏分别设定。例如权限类申请可设较短窗口，故障报修可适当延长。超过时限的反馈按新工单处理并关联原工单，保证历史记录不断裂。时限一旦确定就写进规则并对提交人可见，避免同一类工单出现不同处理口径。
判定项和关闭规则由谁维护、多久回顾一次？
建议指定工单管理员作为维护责任人，规则变更留有记录。回顾频率可结合例外关闭的数量判断：例外关闭持续偏多，往往说明判定项与实际业务不匹配，需要调整标准。回顾结果应反馈到判定项修订，而不是单纯放宽审批，否则关闭条件会逐渐失去约束力。
