01 / 从真实资源开始
原模板与适用场景
原模板包含客户、销售、合同／采购、法务和履行／发货泳道，用“订单金额巨大”和“订单标准吗”表达升级审核分支。金额判断没有提供具体阈值，使用时应改为公司已确定的授权条件；这里讲流程表达，不判断某份合同是否有效或应当获批。
在这份模板里，你能找到
- 客户提交采购订单
- 合同/采购部审查订单
- 订单标准吗？
- 订单已发货
上述节点来自原模板。下面的改图步骤包含新增建议；预览图不会自动同步这些修改。
02 / 具体案例
用一个具体案例理解这张图
案例：客户提交一张含特殊交付安排的设备订单。销售确认信息后交给合同／采购审查；条件超出标准范围时进入有权限的审核角色。审核退回则修改交付条件，并再次向客户确认。取得有效批准后才通知履行团队准备发货，不能用销售口头确认替代最终状态。
本例用于说明改图思路，不是客户业绩或实测结果。
03 / 动手改图
按照这四步整理你的版本
为每条泳道指定实际职责
保留客户提交、销售确认、订单审查和履行的分工。审核泳道名称按实际组织设置；若一个人承担多个职责，也要区分动作而不是将整张图挤进一条线。
将升级条件写成可核对规则
把模糊的巨大金额改为“是否超出已授权范围”，并在注释中引用团队现有规则。非标准付款、交付或其他条件进入对应审核，不自行生成金额阈值。
补齐拒绝和修改回路
审核未通过时记录原因，返回负责修改的角色；修改改变客户约定时重新确认。退回、客户取消与批准是不同状态，不能合并成“处理结束”。
让发货读取明确批准状态
履行团队核对订单版本和批准结果再执行。发货后记录完成或异常状态；若审批后发生变更，重新进入适当审查，避免新版订单沿用旧版批准。
04 / 对照检查
节点与分支应该怎样表达
| 项目 | 表达方式 | 核对重点 |
|---|---|---|
| 待确认 | 销售补全订单信息 | 记录版本与客户反馈 |
| 待审核 | 超范围或非标准条件升级 | 使用真实授权规则 |
| 退回修改 | 说明原因并再次确认 | 不要误计为最终取消 |
| 批准／已发货 | 审查结束后交给履行 | 批准与发货分别记录 |
05 / 让 AI 帮你起稿
可以直接复制的 AI 绘图提示词
先复制下方文字，再打开 AI 绘图入口粘贴；把角色、条件和节点替换为你的实际情况。这段示例不会自动导入模板。
画设备销售订单审批泳道图，角色为客户、销售、合同采购、有权限审核人、履行发货。客户提交订单→销售补全信息→审查是否标准及是否在授权范围内。需升级则审核，未通过记录原因并返回修改，涉及客户约定的修改再次确认；批准后核对订单版本并发货。客户取消独立结束，批准后的订单变更返回审查。阈值与授权规则留待填写，不给出合同有效性结论。
生成后逐条核对文字、层级与连线；需要保留原模板版式时，可直接使用模板编辑入口。
06 / 交付前复核
这些问题容易被忽略
- 自行填写金额阈值，令示例被误读为公司的授权制度。
- 审核拒绝后没有责任人和返回节点，订单长期停留在等待状态。
- 把批准和发货画成同一节点，无法区分等待履行与履行完成。
用一个正常案例和一个异常案例从起点走到终点，再保存你的版本。不要只检查配色和对齐。
07 / 常见问题
使用前还想确认
每个订单都必须进入法务泳道吗？
按团队已确定的审查规则表达。模板只是示意，不能据此推断所有订单或所有组织都采用相同审批角色。
订单已获批但客户修改数量怎么办？
先记录新版本，并按真实规则决定是否重新审查。图中应保留变更入口，避免新旧版本与批准依据混在一起。
从这张模板开始，做成你的工作图
先确认节点，再调整分支，最后统一排版。
使用这个模板在线编辑 ↗
