制定工单系统使用规范，先划定适用范围和工单类型，再固定提交入口与必填字段，随后定义分派、升级、SLA计时与关闭规则，最后明确各角色职责、例外处理和定期复核机制。规范应写成可执行的条款加配套字段表，并在小范围试运行后修订发布。规范落地需要工单流转与状态管理承载，ONES Desk 可作为统一受理与流转的平台，本文围绕规范本身的编写方法展开。
要点总览（TL;DR）
- 规范按“定边界—定字段—定流转与SLA—定角色—写条款—试运行发布”的顺序编写，先确定适用范围和工单类型，再设计字段与流转规则。
- 必填字段以能否据此分派、判断优先级和计算SLA为取舍标准，紧急程度各档要给出可判定的定义。
- SLA条款必须同时写明起算点、暂停条件和终止点，响应时限与解决时限分开设定，升级条件写成可核验的规则。
- 条款采用主体、动作、时限、判定标准四要素句式，避免“尽快”“及时”等无法核验的表述。
- 发布前先小范围试运行一个完整业务周期，用积压、超时率、退回率等指标检验条款，修订后再发布并做版本管理。
规范先写清什么：适用范围、工单类型与边界
规范的第一章要回答“谁在什么情况下必须使用工单系统”。这一层写不清，后面的字段和流转规则就失去约束对象，容易出现同一类请求一半走工单、一半走群聊的情况。动笔前先确定三件事：适用对象、工单类型、以及不走工单的请求如何分流。
适用范围要写到可判断
适用范围应写明团队名称、使用的系统、覆盖的业务范围，以及生效时间。写法上避免“全公司相关事项”这类笼统表述，改为可判断的句子，例如“本规范适用于IT服务组受理的总部及分公司办公设备、账号权限、办公软件三类请求”。范围之外如有试点团队，单独注明试点期限和观察范围。
工单类型按受理动作划分
类型划分的依据是“受理后由谁、按什么流程处理”，而不是按提交人的部门划分。常见划分方式如下，团队可按实际业务裁剪：
| 工单类型 | 典型场景 | 主要处理方 |
|---|---|---|
| 故障报修 | 设备无法开机、系统登录失败、网络中断 | IT运维组 |
| 服务请求 | 账号开通、权限申请、软件安装 | IT运维组或对应系统管理员 |
| 咨询 | 使用方法询问、政策口径确认 | 一线受理人直接答复 |
| 投诉与建议 | 服务态度、处理结果不满 | 服务负责人 |
每类工单应配一句典型场景说明，帮助提交人自行判断。类型数量控制在团队能维护的范围内，类型过多会导致提交人选择困难、分派错误率上升。
明确不走工单的请求与相邻流程边界
规范需要列出例外渠道，例如紧急安全事故走电话值班、采购需求走采购系统、研发缺陷走缺陷管理流程。同时写清与相邻流程的交接点：工单处理中发现是产品缺陷时，由处理人转为缺陷单并在工单中记录关联编号，工单本身继续跟踪到对用户有答复为止。资产领用、报废等涉及资产台账的动作，说明在哪个系统登记、工单只承担申请与审批环节。
本节交付物是一份《适用范围与工单类型清单》，包含适用对象、类型表、例外渠道表和相邻流程交接说明，作为规范正文的第一章。
提交入口与必填字段怎么定
提交环节的规范目标只有一个：让受理人拿到工单后能直接判断“派给谁、多急、影响多大”。字段设计围绕这个目标取舍，与分派、优先级、SLA计时无关的信息一律设为选填。
统一入口与渠道
规范应指定一个主入口，例如服务门户或工单系统内的提交页面，并说明可用的辅助渠道，如邮件转工单、企业IM机器人提单。辅助渠道要写明转换规则：由谁在什么时限内把消息转为工单，未转成工单的请求是否计入SLA。原则上以系统内工单记录为准，口头和聊天记录不作为受理凭证。
必填与选填的划分依据
判断标准可以归纳为三条：影响分派的信息必填，影响优先级判断的信息必填，影响SLA计时的信息必填，其余选填。按此标准形成的字段表如下：
| 字段 | 必填/选填 | 填写说明 |
|---|---|---|
| 标题 | 必填 | 一句话说明现象或诉求，含对象和故障表现，不超过30字 |
| 工单类型 | 必填 | 从类型清单中选择，选错由受理人改派并记录 |
| 详细描述 | 必填 | 发生时间、操作步骤、报错信息、已尝试的处理 |
| 影响范围 | 必填 | 仅本人/本部门/多部门，用于判断优先级 |
| 紧急程度 | 必填 | 按规范给定的三档定义选择，不自行描述 |
| 期望完成时间 | 选填 | 有明确业务节点时填写，作为排期参考 |
| 附件 | 选填 | 截图、日志、报错文本，单个文件大小按系统限制 |
| 联系方式 | 必填 | 便于处理人回访确认 |
紧急程度要给可判定的定义
“紧急”是最容易被滥用的字段。规范应为每一档给出判定条件，例如：紧急指核心业务系统不可用且影响多个部门；较高指单人无法工作且无替代方案；一般指不影响当前工作。提交人按定义选择，受理人有权依据实际影响调整并注明理由。
附件与敏感信息
规范应约定：涉及账号密码、身份证号、客户名单等敏感信息时，不在工单描述和附件中明文粘贴，改为说明信息所在位置或通过约定渠道单独提供；截图前遮蔽无关的个人信息。附件保留期限与工单归档期限一致，由规范管理员在系统中设定。
本节交付物是《工单提交字段表》，逐字段写明必填属性、填写说明和校验规则，可直接配置到表单中。
分派、流转与SLA计时规则
流转规则是规范的核心操作部分，写法上要落到“谁在什么时点做什么、状态如何变化、时限从何时算起”。规则含糊会直接导致超时统计失真和责任人推诿。
接单与分派责任
规范应指定一线受理岗负责首次响应：在工作时间内提交的工单，受理人在约定时限内完成查看、分类确认和分派；非工作时间提交的工单，从下一个工作日开始计时。分派对象按工单类型对应到处理组，处理组负责人再指定具体处理人。分派错误时，接收方在约定时限内退回并说明理由，退回不计入处理人时限，但计入受理环节的时长统计。
状态节点与准入条件
状态设置以能反映责任转移为准，常见节点如下：
| 状态 | 进入条件 | 责任方 |
|---|---|---|
| 待受理 | 工单提交成功 | 一线受理岗 |
| 处理中 | 已分派到处理人并开始处理 | 处理人 |
| 待补充 | 信息不足，已向提交人发出补充请求 | 提交人 |
| 待验证 | 处理人完成操作，等待提交人确认 | 提交人 |
| 已关闭 | 提交人确认解决，或超期自动关闭 | 受理人或系统 |
每个状态写明谁能操作、操作时需要填写什么，例如转入“待补充”必须写明缺什么信息、期望回复时间。
SLA计时口径
规范必须写明三个时点：起算点、暂停条件、终止点。起算点通常为提交成功时间或受理确认时间，二者选一并全文统一；暂停条件一般包括等待提交人补充信息、等待第三方供应商处理，暂停期间不计入处理时长，恢复后继续累计；终止点为状态转为“已关闭”的时间。响应时限与解决时限分开设定，响应时限约束首次回复，解决时限约束关闭。不同优先级对应不同时限，时限值由团队根据服务能力确定并在规范中列表固定。
升级触发与路径
升级条件写成可核验的规则：响应时限剩余一定比例仍未接单、解决时限过半仍无进展、同一问题影响范围扩大到多部门、提交人对处理结果二次投诉。升级路径按层级写明：处理人升级至处理组负责人，组负责人升级至服务负责人，服务负责人协调跨部门资源。每次升级在工单中记录升级原因和新的承诺时间。
在系统中落地时，状态流转和时限提醒需要平台支持自定义工作流与工单属性。ONES Desk 支持灵活调整工作流、自定义工单属性，团队可以按上述状态表和时限口径配置响应流程，并通过工单分析报表查看处理进度与团队表现，用于核对规范执行情况。
本节交付物是《状态流转表》和《SLA计时规则说明》，前者逐状态写明准入条件与操作人，后者写明起止时点、暂停条件和各优先级时限。
角色分工与交付物
条款要有人执行，规范应为每类角色写明职责、关键动作和产出，避免出现“大家都负责、实际无人负责”的条款。
| 角色 | 关键动作 | 产出 |
|---|---|---|
| 提交人 | 按字段要求提交、及时补充信息、验证处理结果 | 信息完整的工单、确认或驳回意见 |
| 受理人 | 首次响应、分类确认、分派、跟踪超时 | 分派记录、退回理由、超时提醒 |
| 处理人 | 处理操作、记录处理过程、发起升级 | 处理记录、解决方案说明、升级申请 |
| 审批人 | 审批涉及权限、费用或特殊资源的工单 | 审批意见与审批时间 |
| 规范管理员 | 维护类型清单与字段表、统计执行情况、组织修订 | 规范版本、月度执行报告、修订记录 |
交接与代班需要单独约定：处理人请假或离岗时，由处理组负责人在系统中改派，并在工单中注明交接人和交接时间，SLA不因交接重置。违规与超时的处理责任也要写明：提交人信息长期不补充导致工单挂起的，由受理人按约定规则关闭并记录原因；处理人无正当理由超时的，纳入月度执行报告，由服务负责人跟进。规范管理员每月汇总一次执行数据，作为修订依据。
本节交付物是《角色职责矩阵》，按角色—动作—产出三列填写，附交接规则和超时处理条款。
示例：一份可直接改写的规范条款
条款写法直接影响执行效果。可执行的条款通常包含主体、动作、时限和判定标准四个要素，下面给出三条示例，团队可替换其中的对象和时限后直接使用。
提交条款示例
“提交人应在发现问题的当日通过服务门户提交工单，标题写明对象与现象，详细描述包含发生时间、操作步骤和报错信息；影响多个部门的问题须在影响范围字段选择‘多部门’。未按字段要求填写导致无法分派的，受理人可退回并要求补充，退回期间不计入响应时限。”
改写说明：原稿若写成“请尽量详细描述问题”，无法判定是否达标；改为列出必须包含的信息项，并说明未达标的后果，条款才具备可执行性。
分派与SLA条款示例
“一线受理岗应在工作时间内每2小时查看一次待受理队列，对信息完整的工单在4小时内完成分派；紧急工单在30分钟内响应。解决时限自工单提交成功时起算，等待提交人补充信息期间暂停计时，补充完成后恢复累计。解决时限过半仍无进展的，处理人应升级至处理组负责人并记录升级原因。”
改写说明：时限值需由团队按服务能力填写，示例中的数字仅作格式示范；起算点、暂停条件和升级触发条件三项必须同时写明，缺一项就会出现统计口径分歧。
关闭与回访条款示例
“处理人完成操作后将工单转为待验证，并说明处理结果和验证方法；提交人应在3个工作日内确认，确认后工单关闭。提交人逾期未确认且无异议的，系统自动关闭并记录。受理人对紧急工单和投诉类工单在关闭后2个工作日内回访，回访结果记入工单备注。”
改写说明：关闭条件要区分“确认关闭”和“超期关闭”两种情形，回访范围限定到具体类型，避免写成“定期回访”这类无法核验的要求。
发布前试运行与完成检查
规范写完后直接全员发布，风险在于条款与实际操作脱节。更稳妥的做法是先小范围试运行，用数据检验条款是否可执行，再修订发布。
试运行范围与观察指标
选择一到两个业务量适中、配合度较高的团队试运行，周期建议覆盖一个完整的业务周期，例如四周，以便观察到月末集中提交的情况。观察指标包括：工单积压数量、首次响应超时率、解决超时率、退回率、升级次数、提交人补充信息的平均等待时长。指标口径与规范中的SLA定义保持一致，试运行期间的数据只用于修订，不用于考核。
反馈收集与修订
试运行结束前组织一次反馈会，参与人包括提交人代表、受理人、处理人和规范管理员，逐条核对规范条款：哪些字段实际没人填、哪些状态很少使用、哪些时限明显过紧或过松。修订记录写明修改条款、修改理由和生效时间，形成版本号。
发布、培训与版本管理
正式发布时同步开展一次培训，重点讲字段填写、状态含义和升级路径，培训材料与规范正文同版本。规范管理员负责版本管理：每次修订保留旧版本，注明生效日期，系统内的表单和状态配置与规范版本同步调整。规范落地后，工单的统一受理、分派与跟踪可由 ONES Desk 承载，其门户收集工单和自定义表单能力可用于固化提交入口与字段要求；涉及研发缺陷的工单可关联到 ONES Project 的工作项持续跟踪，处理经验可沉淀到 ONES Wiki 页面。
完成检查清单
发布前逐项核对，全部通过方可发布：
- 适用范围写明团队、系统、业务范围和生效时间，无笼统表述。
- 工单类型清单完整，每类有典型场景和对应处理方。
- 例外渠道和相邻流程交接点已写明。
- 提交字段表标注必填/选填，每个必填字段有填写说明。
- 紧急程度各档有可判定定义。
- 状态流转表写明每个状态的准入条件和操作人。
- SLA起算点、暂停条件、终止点全文统一，各优先级时限已列表。
- 升级触发条件和升级路径可核验。
- 角色职责矩阵覆盖全部角色，交接和超时处理有责任方。
- 试运行指标已收集，修订记录和版本号已建立。
- 培训已完成，系统配置与规范版本一致。
本节交付物是《试运行计划》和《规范完成检查清单》，前者写明范围、周期和指标，后者作为发布前的核对依据。
常见问题
团队规模很小，工单量不大，还需要写完整的规范吗？
需要，但可以按规模裁剪内容，不必照搬全部章节。小团队可以保留四项核心内容：适用范围与工单类型、提交必填字段、状态流转与响应时限、角色职责。角色可以由同一人兼任，例如受理人和处理人为同一人，但规范中仍要写明兼任关系和交接规则，避免人员变动后责任断档。试运行周期也可以缩短，覆盖一周到两周的典型工单即可。
规范里的SLA时限值应该怎么定，定多长合适？
时限值没有通用标准，应依据团队实际服务能力和历史处理数据确定。可以先统计过去一到两个月的工单首次响应时长和解决时长分布，取中位数附近作为初值，再按优先级分档拉开差距。试运行期间重点观察超时率：超时率过高说明时限过紧，过低则说明约束不足。时限值写入规范后保持稳定，调整时走修订流程并注明生效日期。
提交人长期不补充信息，工单一直挂在“待补充”状态怎么办？
规范中应预先约定挂起处理规则：受理人发出补充请求时写明缺什么信息和期望回复时间，超过约定时间未回复的，受理人可按规则关闭工单并记录原因，提交人后续可重新提交。同时要明确暂停计时的边界，等待补充期间SLA暂停，但暂停时长应纳入执行统计，用于发现字段设计或沟通方式的问题。
规范发布后，系统里的表单和状态配置需要同步调整吗？
需要，规范与系统配置不一致会让条款失去约束力。发布时应同步核对三处：提交表单的必填项与字段说明、状态节点及每个状态的操作权限、时限提醒与升级通知的触发条件。规范管理员负责在每次修订后检查配置是否与新版规范一致，并在修订记录中注明配置调整时间。使用 ONES Desk 时，可通过自定义表单和自定义工作流承载字段与状态要求，使系统配置与规范版本保持对应。
规范多久复核一次比较合适？
建议每季度做一次常规复核，出现以下情况时提前复核：工单类型清单与实际提交内容明显不符、超时率连续上升、组织架构或处理组调整、系统配置发生较大变更。复核由规范管理员组织，依据月度执行报告逐条核对条款是否仍可执行，修订后更新版本号并通知相关角色。
