01 / 从真实资源开始
原模板与适用场景
适合服务台团队对齐受理与支持分工。原模板含用户、IT服务中心、帮助中心工程师、智能客服等角色，也包含外部服务请求。图中的“3个工作日内答复”和岗位缩写属于示例，正式使用应替换为团队已有约定。
在这份模板里，你能找到
- 创建工单
- 分派工单
- 关闭工单
- 记录满意度结果以供跟进
上述节点来自原模板。下面的改图步骤包含新增建议；预览图不会自动同步这些修改。
02 / 具体案例
用一个具体案例理解这张图
案例：员工从网页报告打印机无法使用。服务台先记录设备、现象和影响，再尝试已有方案；不能处理时分派给工程师。工程师修复后转为待确认，用户仍有问题则重新进入处理。这里新增的待确认与重新打开路径，是为避免“修复完即关单”的交接空白。
本例用于说明改图思路，不是客户业绩或实测结果。
03 / 动手改图
按照这四步整理你的版本
合并渠道但保留来源
电话、邮件、网页请求统一进入创建工单，记录问题描述和联系途径。合并相同问题时保留关联关系，不把重复渠道误计为多件独立故障。
设置初步判断和责任人
由服务台判断是否已有可用方案。能直接解决则进入处理和确认；不能解决时分派给相应工程师，交接中写明已尝试的方法，避免重复询问。
为外部依赖补等待状态
如果需要厂商、设备替换或其他部门支持，新增等待外部响应节点，并保留跟进负责人。外部请求发出不代表问题已经解决。
让关闭具有明确依据
处理完成后请用户确认或按团队实际约定复核。仍未解决时返回分析节点；满意度记录可位于结束后，但不能用满意度替代故障是否解决的判断。
04 / 对照检查
节点与分支应该怎样表达
| 项目 | 表达方式 | 核对重点 |
|---|---|---|
| 待受理 | 请求已到达，尚未确认范围 | 记录渠道与初始信息 |
| 处理中 | 服务台或工程师执行动作 | 明确当前主责人 |
| 等待外部 | 依赖其他团队或供应商 | 保留跟进动作和下一次检查 |
| 待确认／已关闭 | 技术处理后复核结果 | 未解决应有返回路径 |
05 / 让 AI 帮你起稿
可以直接复制的 AI 绘图提示词
先复制下方文字，再打开 AI 绘图入口粘贴；把角色、条件和节点替换为你的实际情况。这段示例不会自动导入模板。
绘制IT服务台泳道图，角色为用户、服务台、工程师、外部支持。电话邮件网页请求统一创建工单。服务台判断能否直接解决，能则处理后请用户确认；不能则记录已尝试方法并分派工程师。需外部支持时进入等待状态，由工程师继续跟进。处理后进入待确认，仍未解决则重新分析，确认解决后关闭。响应时限与优先级标准留待团队填写，不编造承诺。
生成后逐条核对文字、层级与连线；需要保留原模板版式时，可直接使用模板编辑入口。
06 / 交付前复核
这些问题容易被忽略
- 将“分派工单”画成处理结束，导致转派后没有责任人。
- 直接沿用原图的响应时限，让示例看起来像公司的服务承诺。
- 把每一轮沟通都建成新工单，无法追踪同一问题的处理历史。
用一个正常案例和一个异常案例从起点走到终点，再保存你的版本。不要只检查配色和对齐。
07 / 常见问题
使用前还想确认
所有问题都需要人工建单吗？
图只表达需要建立可追踪记录，不限定必须人工填写。若系统自动建单，可将创建动作放在系统泳道，人工负责核对和补充。
满意度低是否代表工单不能关闭？
不一定。技术问题是否解决和服务体验是不同维度，应分别记录；关闭条件按照实际约定表达。
从这张模板开始，做成你的工作图
先确认节点，再调整分支，最后统一排版。
使用这个模板在线编辑 ↗
