01 / 从真实资源开始
原模板与适用场景
原模板从用户联系客服中心开始，以软件、政策或培训、硬件和优化请求逐项判断，并连接文档推荐、分析师处理、设备审查和关闭工单。模板中的机构名称、联系方式和程序介绍属于示例内容，使用前应替换；它也没有定义适合所有产品的分类标准。
在这份模板里，你能找到
- 用户联系客服中心
- 是软件的问题？
- 是政策或者培训的问题？
- 是硬件的问题吗？
上述节点来自原模板。下面的改图步骤包含新增建议；预览图不会自动同步这些修改。
02 / 具体案例
用一个具体案例理解这张图
案例：用户说“无法上传文件”。客服先补充文件类型、大小、报错文字和是否只有某个设备出现问题。文件格式不符合说明时进入使用指导；支持的文件仍报错时进入软件排查；需要当前未支持的格式则记录为优化需求。新增的补充信息节点，能避免仅凭一句话就把问题转给开发。
本例用于说明改图思路，不是客户业绩或实测结果。
03 / 动手改图
按照这四步整理你的版本
用可观察的信息建立入口
记录用户想完成的任务、实际现象、出现条件与已尝试动作。将账号密码等敏感内容排除在普通工单描述之外；这里需要的是能复现问题的信息，而非全部用户数据。
让判断条件可以被回答
把“软件有问题吗”补充为产品支持范围内是否出现异常。政策或培训类表示需要解释现有规则和操作方式；硬件类涉及设备故障；优化类表示希望增加或改变能力。无法判断则返回补充信息。
在每个分支写出交付物
软件分支交付复现记录与排查结果，培训分支交付适用说明，硬件分支交付检查结果，优化分支交付需求记录。分类不是解决完成，转交后仍需保留跟进负责人。
把关闭和需求采纳分开
用户问题得到处理或解释后再确认关闭；优化需求是否进入开发计划应单独记录。提交建议不代表承诺上线。对无法复现的故障，保留复查条件，而不是静默结束。
04 / 对照检查
节点与分支应该怎样表达
| 项目 | 表达方式 | 核对重点 |
|---|---|---|
| 软件故障 | 预期功能与实际结果不一致 | 提供复现步骤和报错信息 |
| 使用指导 | 已有功能或规则需要解释 | 确认说明是否解决用户问题 |
| 硬件检查 | 现象与设备有关 | 交给有权限的人员核实 |
| 优化诉求 | 期望超出现有能力 | 记录评估状态，避免误承诺 |
05 / 让 AI 帮你起稿
可以直接复制的 AI 绘图提示词
先复制下方文字，再打开 AI 绘图入口粘贴；把角色、条件和节点替换为你的实际情况。这段示例不会自动导入模板。
画客服问题分流流程图。入口为用户提交问题，先收集目标任务、现象、报错和已尝试动作。信息不足则补充信息。区分软件故障、规则或培训、硬件问题、优化请求四类，分别进入复现排查、提供说明、设备审查、记录需求。每条分支写交付物和跟进负责人，处理后确认关闭；仍未解决则返回排查。优化需求进入评估不等于承诺开发，不填写不存在的响应时限。
生成后逐条核对文字、层级与连线；需要保留原模板版式时，可直接使用模板编辑入口。
06 / 交付前复核
这些问题容易被忽略
- 把所有“不会使用”都当成产品故障，排查信息无法支持开发定位。
- 设置多个是／否判断，却没有给信息不足的请求留出口。
- 将“提交优化需求”标为“已解决并已上线”，混淆当前答复与未来计划。
用一个正常案例和一个异常案例从起点走到终点，再保存你的版本。不要只检查配色和对齐。
07 / 常见问题
使用前还想确认
一个请求同时涉及软件和培训怎么办？
可设置主分类和关联任务，保留同一跟进入口。先处理阻止用户完成任务的部分，再记录其他改进，避免把用户在多个部门间来回转派。
分类图与IT工单泳道图有什么区别？
分类图重点是判断依据和分支去向；泳道图重点是角色交接。可以先用分类图确定去向，再用工单泳道图表达谁跟进和怎样关闭。
从这张模板开始，做成你的工作图
先确认节点，再调整分支，最后统一排版。
使用这个模板在线编辑 ↗
