提交 IT 工单前的申请质量清单

本文由国际版原文本地化，文末提供原文链接。涉及的能力以易企办中国版租户和权限为准。

「我的访问有问题，急。」申请人遇到工作阻塞，支持团队则需要判断是现有账号失效、申请更多权限，还是更大范围的中断。分配工单号后，仍需要足够的上下文来处理、追问或升级。服务门户、邮件和其他入口都可以采用同一套接收规则。

按接手人要做的决定设计问题

收单时通常要识别服务、判断业务影响、找到责任人，并确定是否需要审批或紧急升级。表单的每个问题都应支持其中一个决定。申请人可能知道应用名称和自己试图完成的操作，但不了解故障组件。可以给「不确定」选项指定分诊人，避免随意归类。

区分事件、服务申请和变更

• 事件。现有系统、设备或服务未按预期运行。
• 服务申请。申请组织提供的权限、设备或其他服务。
• 变更申请。提出修改，可能需要评估及授权后才能实施。

分类是为引导提问。选错类型时，应允许支持团队转派原记录。严重中断或疑似安全事件应直接走组织批准的紧急渠道，先收集下一位响应人员所需的最少信息，常规附件可随后补充。

收集能改变下一步的信息

「三位同事登录后无法打开调度应用」是可核对的观察结果。缺乏依据时，保留这样的事实描述有助于后续排查。在上传处说明不要提交密码、验证码、密钥或含无关个人信息的截图。确需敏感诊断资料时，使用已批准的渠道。

按申请类型补问

• 权限申请。询问资源、业务用途、权限范围和是否有到期日。申请人选择的角色是申请内容，授权人按组织规则审批。
• 设备申请。收集使用地点、用途和需要日期。
• 变更申请。收集受影响服务、目标、业务负责人和变更评审所需资料。

与实际提交和处理人员用样本走一遍，找出不清楚的标签、无法回答的必填项及没有责任人的分类。

分开判断可办理、需补充和需升级

1. 可以办理。当前责任人能理解申请并采取预定动作时，分派给他并显示下一步。
2. 需要补充。具体缺少哪项信息、由谁补充要写清。交接被接受之前，原团队继续负责。
3. 需要紧急升级。满足组织升级条件或需要立即分诊时，走相应渠道，同时可安排后补资料。

一张填得很完整的常规申请仍按常规优先级处理。紧急事件即使信息不全，也能按规则升级。保留申请人描述的影响，再记录团队分诊后的优先级和原因。

把澄清和交接落到人

明确谁负责初次分诊、专家何时算接手、去向不清楚时谁联系申请人。用具体问题替代笼统催补，例如「您打开的是哪个应用？点击登录后出现什么提示？」约定无人回复、审批人不在、误派及多团队重复处理时的做法。

定义关闭依据，例如服务已交付，或报告的故障已按约定检查并解决。关单时应能回看这一依据。

衡量第一次交接是否可办理

• 一次完整率。无需补充即可进入下一步的申请数，除以同期按同一标准评估的申请数。
• 澄清轮次。正常办理开始前经历多少次补充和复核。
• 有效响应时间。从接收到责任人给出可执行反馈所用的时间，自动回执可单独统计。

比较之前统一口径，区分紧急事件和常规申请，也区分等待补充与主动处理。反复漏填同一字段时，先看提示和位置。资料齐全仍久等时，检查分派责任与人员容量。

先配置一种申请并试点

IT 服务台模板提供申请接收、分派、状态跟踪及处理流程的起点。类别、决策权限、证据要求和升级规则仍由团队定义。邮件接收、AI 提取和外部系统连接需单独配置及验证。推断出的字段应有复核路径，缺失事实保留为待确认。

让提交、审批和办理人员用一类请求试点，测试资料完整、缺资料、误派和紧急升级四类情形。可以带一张现有表单与易企办团队讨论试点。

查看原始文章