客服流程图首先要回答：谁负责、在等谁、首次处理无效后怎么办。从受理和分流开始，把调查、等待、升级、解决与关闭分开。只画一个“解决了吗”不能描述完整客服工作。
下面建立虚构团队流程，跟三张工单走一遍。替换为自己的团队、制度与平台状态后，应让新同事在每个停顿都能说出下一步，而不是猜谁接手。
画图前先划边界
本例从客户联系支持开始，到按政策关闭并保留继续联系办法为止。账单审批与事故修复是关联流程，不应藏在一个“升级”框里。
列真实渠道：邮件、聊天、电话、表单。同一问题可能多渠道联系，增加重复检查，别把每条消息都当新问题。保留下一位处理者所需历史，不把无关个人信息复制到公开图。
客户工单、内部工程任务与共享事故是不同记录。关联事故不代表客户沟通责任消失，仍需有人更新客户。
动作框表示工作，判断菱形写明确问题，终点写结果。符号可看流程图基础，主图聚焦责任与路由。
建立八阶段主干
这是一套虚构示例骨架，不是要求紧急帮助必须等日常录入完成。
- 接收并记录。 保存问题、渠道、必要上下文和稳定编号，需要立即行动时同步补记录。
- 核对已有工作。 关联重复请求或已知事故，保留客户诉求，防止两人发冲突指令。
- 分类并分配。 按类别、影响与可执行团队分流，落实负责人，不只写队列。
- 权限内调查。 使用已批准方法，确认操作权限；最快回答不一定正确或获授权。
- 选择下一状态。 解决、等客户、内部协助或专家升级，每条路有明确动作。
- 持续沟通。 按适用政策说明下一步与下次更新时间，不承诺未经确认的修复时刻。
- 验证结果。 记录有效证据，适当时向客户确认并说明余留限制。
- 关闭或继续。 按关闭制度执行，问题仍在则携带上下文继续，不当作完全无关新问题。
框内保持短，排障细步骤链接到操作手册，否则读者很难找到真正的路由决定。
区分等待与升级
“还没解决”可能有多种原因，等待必须写下一位行动者与持续负责的人。
| 情况 | 下一行动者 | 支持侧负责人 | 恢复条件 |
|---|---|---|---|
| 缺订单参考 | 客户 | 已分配客服 | 所需资料收到 |
| 等已批准内部更正 | 内部专家 | 客服或协调人 | 内部结果返回 |
| 当前人无权限 | 授权审核者 | 指定案件负责人 | 决定已记录 |
| 疑似共同故障 | 事故团队 | 客户沟通人 | 有状态更新或恢复证据 |
这些是过程状态，不是所有平台统一名称。Zendesk 区分 Pending、On-hold、Solved、Closed，不能直接套成别的软件规则。
等待应回到正确调查或验证节点。客户补的信息仍不完整，不能直跳解决；专家说“做完”也应对照原问题验证。
升级带工单 ID、问题、影响、已试方法、证据和希望专家执行的动作。明确专家是接管案件还是内部协助，否则两边都可能以为对方会联系客户。
完整示例：同一流程的三张工单
以下均为虚构，说明同一骨架怎样分支，而不是让客服临时制定政策。
| 工单 | 初始发现 | 路由 | 解决前证据 |
|---|---|---|---|
| A：索要收据 | 参考信息足够 | 客服按已批流程操作 | 正确收据通过允许渠道交付 |
| B：疑似重复扣款 | 证据不足 | 先取允许资料，必要时账单审核 | 审核结果及客户说明留档 |
| C：多人无法登录 | 可能共同事故 | 关联事故，保留沟通人 | 恢复核验且通知受影响客户 |
A 可能首次接触就解决，因为信息、权限均足够，不为让图显复杂强加升级。
B 不能因为箭头写退款就承诺退款，先取组织允许的信息，再由授权审核人判断。“等客户”和“等账单”有不同下一行动者。
C 继续泛泛排障可能浪费时间，先关联共同处理并沟通状态。事故结束也不证明每位客户均恢复访问。具体协调另看事故管理流程图。
用泳道说明谁执行
可设客户、一线、专家以及确有必要的案件负责人。泳道是人或角色，不是状态，“待处理”不是执行人。
受理与常规调查放支持道，补资料放客户道，专业操作放专家道。既画请求也画返回，让同事知道如何恢复。
涉及多团队时设一个客户沟通人，可写“一线保留沟通、账单负责更正”，不让客户自己寻找部门。
可以从下面的通用流程图模板起稿。先把输入改成“收到工单”，判断改成“资料是否齐全？”，再补上走查中的等待与升级步骤，在交接处标注沟通负责人。需要你自己调整这张基础图；模板没有预设客服泳道，也不会运行客服工作流。
写清时限、无回复与关闭
区分首次响应、下次更新、解决目标。确认收到不是修复，承诺更新也不必等于解决期限。每阶段哪种计时、等待如何处理，按真实政策写。
客户不回复要有提醒、执行人或自动化、窗口后的动作。本篇不指定通用天数，按无回复关闭应保留原因与后续联系办法。
Zendesk 中已解决可以因回复重开，已关闭采用后续请求路线。其他系统不同，要测试实际平台，别画软件无法实现的通用回环。
客户反馈修复无效时带上已做动作与证据，检查原诊断是否仍成立。不看新信息只重复旧指令，即使箭头回到起点也仍是流程缺陷。
用五种情景验证
走收据、缺信息、专家交接、共同事故、修复失败五种。让不熟图的人在每个停顿说负责人和下一动作。
每个判断出口有标签，类别判断可有多个命名出口。等待有恢复条件，升级有沟通归属。
再对照真实系统：队列存在吗、角色有权限吗、计时是否发对提醒而不重复、恢复工单是否带历史？这些要在运营系统验，不在画布里验。
差异分配负责人，决定改流程还是改配置。箭头写“通知”不代表自动化完成，真实工单能照着走才算有用。
维护客服流程图
写维护人、修订日和依赖制度。渠道、权限、平台行为变化时更新，培训用可读导出，下一次修改用源文件，不从截图重画。
从重开和漏交接中寻找重复缺口，不为每次偶发情况加分支；例外稳定出现且团队达成处理方法后再纳入，专项细则放链接。
