工单关闭条件要同时满足三件事：用户请求的事项已有明确结论或交付物，结论已通过约定渠道告知并得到确认或已过确认期，工单记录里留有可复核的处理说明与关联证据。本文给出一份可直接套用的填写示例，把这三件事拆成可勾选的判定项，并区分“关闭”“待确认后自动关闭”“转问题管理”三种走向，帮助你在服务请求类工单的关闭环节做出稳定判断。
要点总览（TL;DR）
- 工单关闭条件可拆成四个判定项：请求事项已有明确结果、结果已通过约定渠道告知、已获得确认或已过确认期、处理说明完整可复核。
- 示例工单四项中三项满足、确认项未满足，结论走向为“待确认后自动关闭”，确认期届满无异议再关闭。
- 结果、确认、记录三类条件在账号权限、设备报修、咨询答复等请求类型中保持稳定，变化的是证据形式与确认方式。
- 服务事件恢复与根因处理、优先级与 SLA 时限判定、重复提交合并、用户撤回等情形应转出或单独处理，不套用本示例。
示例要解决什么：关闭判定为什么容易出错
这份示例面向服务请求类工单的关闭环节，典型场景包括账号开通、权限调整、设备报修、使用咨询等由用户提出、由服务台或支持团队响应的请求。这类工单数量多、处理过程短，关闭动作往往由处理人顺手完成，判定依据容易停留在“我觉得处理完了”的层面，因此需要一份结构化的判定范例来统一口径。
关闭条件缺失时，常见两类偏差。第一类是关闭过早：处理人完成了操作但未告知用户，或告知后用户尚未确认，工单就被标记为已关闭。用户随后发现结果不符合预期，只能重新提交，重复工单增加，处理记录也出现断点。第二类是关闭过晚：事项实际已交付，但因为没有明确的确认规则，工单长期挂在“处理中”，统计口径失真，处理人也不清楚何时可以收尾。
示例要产出的判定结构由三部分组成：
- 条件项：把关闭判定拆成若干条可勾选的具体条件，每条对应一个可回答“是/否”的问题。
- 证据：每条条件项对应的支撑材料，例如处理记录、交付截图、用户回复、关联单据编号。
- 结论走向：根据条件项的满足情况，得出“关闭”“待确认后自动关闭”或“转出”的结论，而不是只有“关”与“不关”两个选项。
把判定写成条件项加证据加走向的结构，好处是关闭动作可以被复核：任何人拿到这张记录，都能看出当时依据什么做出判断，也能看出哪一条尚未满足。
完整示例：一张服务请求工单的关闭判定全过程
以下为假设情景，用于演示填写方式，非真实客户案例，涉及的人名、编号与时间均为示例数据。
工单背景信息
| 字段 | 示例填写内容 |
|---|---|
| 工单编号 | REQ-2024-0317（示例编号） |
| 请求类型 | 账号权限申请 |
| 请求内容 | 申请人需要开通项目资料库的只读访问权限，用于查阅历史项目文档 |
| 处理人 | 服务台支持工程师（示例角色） |
| 处理过程 | 核对申请人所属部门与项目归属，确认权限范围符合审批要求；在权限系统中完成只读权限配置；通过邮件将开通结果与访问入口告知申请人 |
| 约定确认期 | 告知后 2 个工作日内未提出异议，视为确认 |
逐条核对关闭条件
| 条件项 | 核对过程 | 判定 | 证据 |
|---|---|---|---|
| 请求事项已有明确结果 | 权限已配置完成，申请人可访问指定资料库，结果与请求内容一致 | 满足 | 权限系统配置记录、访问入口说明 |
| 结果已通过约定渠道告知 | 已通过工单登记的邮箱发送开通通知，内容包含权限范围与访问方式 | 满足 | 通知邮件记录 |
| 已获得确认或已过确认期 | 告知时间为示例日期，确认期为 2 个工作日，核对时仍在确认期内且申请人未回复 | 未满足 | 邮件发送时间、工单回复记录为空 |
| 处理说明完整可复核 | 处理记录写明了核对依据、配置动作与告知方式，附有配置记录 | 满足 | 处理记录、附件 |
结论走向
四项条件中三项满足、一项未满足，且未满足项属于确认环节，因此结论为“待确认后自动关闭”：工单进入待确认状态，确认期届满且申请人未提出异议时自动关闭；若申请人在确认期内回复问题，则退回处理中继续跟进。这一走向避免了两种极端：既没有在用户尚未确认时直接关闭，也没有让工单无限期停留在处理人手中。
如果核对时发现权限配置范围与申请内容不一致，则结论应为“退回处理中”，补齐配置后重新核对；如果申请人在确认期内反馈权限不足并暴露出权限模型本身的缺陷，则结论为“转问题管理”，由问题管理流程跟进根因，原工单在关联问题单后关闭。
逐项解释：每个关闭条件项为什么这样写
示例中的四个条件项分别对应结果、告知、确认、记录四个维度，每一项都承担独立的判定任务，缺一项就会出现判定漏洞。
| 条件项 | 含义与判断依据 | 填写要求 | 常见错误写法及后果 |
|---|---|---|---|
| 请求事项已有明确结果 | 请求中提出的具体事项已经产生可描述的结果，且结果与请求内容一致 | 写明做了什么、结果是什么，与请求原文逐条对应 | 只写“已处理”“已完成”，无法判断结果是否覆盖请求；后果是关闭后用户发现需求未被满足，产生重复工单 |
| 结果已通过约定渠道告知 | 结果通过工单登记的联系方式或双方约定的渠道传达给申请人 | 记录渠道、时间与告知内容要点 | 仅在内部群口头说明或默认用户“应该知道”；后果是用户不知情，确认环节形同虚设 |
| 已获得确认或已过确认期 | 申请人明确回复认可，或在约定确认期内未提出异议 | 写明确认方式、确认时间或确认期起止 | 把“用户没回复”直接等同于“用户同意”而不设确认期；后果是关闭依据不可复核，争议时无法说明 |
| 处理说明完整可复核 | 工单记录中有处理过程、判断依据与关联证据，第三方可据此还原处理经过 | 附配置记录、截图、单据编号等可查证的证据 | 记录只有一句结论、附件缺失或关联单据未填；后果是复核时无法验证，审计与复盘都失去依据 |
四个条件项之间是并列关系，全部满足才可直接关闭。确认项是唯一允许“以时间到期替代明确回复”的条件，因此必须同时写明确认期长度与起算时间，否则“已过确认期”无法判定。记录项则贯穿始终，它不产生新的结论，但决定结论能否被复核，填写时应把它当作关闭动作的组成部分，而不是事后补写的备注。
可迁移规律：换一类工单怎么改这份示例
四类条件中，结果、确认、记录三类是稳定结构，换任何请求类型都保留；变化的是每一类下面的具体证据形式与确认方式。调整时先确定“什么算完成”，再确定“怎么让用户知道并确认”，最后确定“留下什么能复核”。
| 请求类型 | 结果条件的写法 | 证据形式 | 确认方式 |
|---|---|---|---|
| 账号权限申请 | 权限已按申请范围配置并可访问 | 权限系统配置记录、访问入口说明 | 邮件告知加确认期，或用户回复确认 |
| 设备报修 | 设备恢复正常使用或已更换替代设备 | 维修记录、更换单据、设备状态确认 | 使用人现场试用确认或签收 |
| 咨询答复 | 问题已给出明确答复且答复覆盖所问内容 | 答复记录、引用的制度或文档条目 | 用户回复“已解决”，或确认期内无追问 |
调整时的取舍原则有三条。第一，结果条件必须可观察：写成“用户满意”“问题解决”这类无法直接验证的表述，判定就会退回到主观判断。第二，确认方式应与请求的影响程度匹配：影响范围小、可逆的操作可以用确认期自动关闭；影响范围大或不可逆的操作，例如数据删除、权限回收，应要求明确回复确认后再关闭。第三，证据形式应选择系统里本来就留痕的材料，避免为了关闭工单额外制造记录，否则条件项会被处理人视为负担而绕过。
当请求类型混合时，例如一张工单里既有权限申请又有咨询，建议按主要请求确定结果条件，其余事项在记录中逐条说明处理情况，避免用一张工单承载多个互不相关的结论。
在工具层面，这套判定结构可以落到工作项的状态与字段上：把条件项设为关闭前需核对的检查项，把告知时间、确认期、关联单据作为字段记录，工单从处理中进入待确认、再进入已关闭的状态流转由这些字段驱动。ONES 工作项支持自定义状态与字段，可以把上述条件项配置为关闭前的必填核对内容，使判定记录随工单一起留存，便于后续查询与复盘。
适用边界：这些情况不按本示例关闭
本示例针对服务请求类工单的关闭环节，以下情形应转入其他流程，不宜直接套用本示例的条件项。
- 服务事件与问题管理：当工单实质是服务中断、性能下降等事件，或需要追查根因时，恢复服务与根因处理分别归服务事件管理和问题管理。此类记录应按事件与问题的流程关闭，本示例的结果条件无法覆盖“根因是否消除”的判断。
- 优先级与 SLA 管理：时限承诺、超时判定、优先级升降属于工单优先级与 SLA 管理的范围。关闭条件回答“是否可以收尾”，不回答“是否按时完成”，两者应分开记录，避免用关闭时间替代时限考核。
- 用户长期无响应：确认期届满仍无回复可按待确认后自动关闭处理，但若工单涉及未交付的承诺事项，应先补充告知再进入确认期，不能以用户沉默为由关闭未完成的事项。
- 重复提交：同一请求被重复提交时，应合并到原工单并在记录中注明关联关系，重复工单按合并处理，不单独走关闭判定，以免同一事项出现多条互相矛盾的结论。
- 请求被撤回或不再需要：用户主动撤回时，结论走向为“撤回关闭”，需记录撤回时间与撤回人，与正常完成的关闭区分开，便于统计时分别口径。
把这些情形识别出来并转出，是关闭条件能够稳定执行的前提。判定项写得再细，如果适用范围被扩大，条件本身也会失去约束力。
常见问题
确认期应该设多长，起算时间从哪天算？
确认期长度没有统一标准，可按请求的影响程度和用户响应习惯确定。示例中账号权限开通设为 2 个工作日，起算时间从告知送达之日算起，并在工单中写明告知时间与确认期截止时间。影响范围大或不可逆的操作，例如权限回收、数据删除，建议要求用户明确回复后再关闭，不用确认期到期替代确认。确认期一旦写入工单，核对时就要按记录的时间判断，避免事后凭印象认定“应该已经过了”。
用户在确认期内回复“还有问题”，工单应该怎么走？
先判断问题的性质。如果只是原请求范围内的补充或遗漏，例如权限范围少配了一项，工单退回处理中，补齐后重新走一遍告知与确认；如果反馈暴露出权限模型、流程规则等共性缺陷，需要追查根因，则转问题管理，原工单在关联问题单后关闭。两种走向都要在处理记录中写明原因和关联单据，便于后续查询时区分“处理不完整”和“根因待解决”。
同一请求被用户重复提交，是逐张关闭还是合并？
建议合并到原工单处理，并在两张工单的记录中互相注明关联关系。重复工单按合并处理，不单独走关闭判定，避免同一事项出现多条结论不一致的记录。合并后只需在原工单上完成结果、告知、确认、记录四项核对，重复工单的状态变化以关联说明为准。若重复提交的原因是原工单长期未响应，应同时检查响应环节，而不是只做合并。
用户主动撤回请求，关闭记录要写什么？
撤回属于独立于正常完成的结论走向，记录中应写明撤回时间、撤回人、撤回方式（例如工单回复、邮件、电话确认）以及撤回时事项的处理进度。若已产生部分交付物，例如权限已开通一部分，需说明是否回收及回收结果。撤回关闭与正常完成关闭在统计时应分开口径，否则完成率与处理时长都会被拉偏。
关闭条件与 SLA 时限考核是什么关系？
两者回答不同问题：关闭条件判断“这件事是否可以收尾”，SLA 管理判断“是否在承诺时限内完成”。关闭时间可以作为时限统计的参考点，但不宜直接替代时限考核口径，尤其是待确认后自动关闭的情形，关闭时间晚于实际交付时间。建议在工单中分别记录交付完成时间与关闭时间，时限判定以约定的考核节点为准，具体口径归工单优先级与 SLA 管理主题处理。
