软件功能交付流程
使用场景: 工程团队，文档化开发工作流
开始 → 产品规格书完成
→ 技术设计评审 [通过？]
否 → 修改设计
是 → 开发迭代
→ QA 测试 [全部通过？]
否 → 修复缺陷 → 返回QA
是 → 部署到 Staging → 上线生产 → 结束
这样组织的原因: 明确"修复缺陷回到QA"（而不是回到开发）这个循环，消除了谁来负责修复和重测的歧义。
真实案例
客户上线流程
使用场景: 客户成功团队，梳理入职前30天
开始 → 账户创建
→ 发送欢迎邮件 → 安排启动会 [会议完成？]
否 → 发送跟进（3次）→ 标记为高风险
是 → 产品演示 → 集成配置 [配置完成？]
否 → 技术支持介入
是 → 达成第一个价值里程碑 → 结束
这样组织的原因: 画流程图时发现"没有完成启动会"的客户处理方式各不相同。流程图把三次跟进后再升级标准化了下来。
员工招聘流程
使用场景: HR 团队，标准化招聘工作流
开始 → 招聘需求审批
→ 发布职位 → 简历筛选 [有合格候选人？]
否 → 延长截止日期或重新发布
是 → 电话初面 → 综合面试 [录用决定？]
否 → 附反馈拒绝
是 → 背景调查 → 发放 Offer [接受？]
否 → 关闭该需求或找下一位候选人
是 → 启动入职流程 → 结束
这样组织的原因: 招聘团队发现"Offer 被拒绝"后没有文档化的下一步。流程图暴露了这个空白，他们补上了转到次优候选人的路径。
客服工单分流
使用场景: 客服团队，制作首次响应操作手册
开始 → 收到工单
→ [账号有效？]
否 → 发重新激活链接 → 关闭
是 → [已知问题？]
是 → 发临时方案 → [严重级别？] → 严重则升级给工程
否 → 尝试复现 → [复现成功？]
是 → 提 Bug 报告 → 关闭
否 → 要求补充信息 → 结束
这样组织的原因: 分流手册用决策路径替代了主观判断，明显缩短了首次响应时间。严重已知问题的升级路径是在一次大故障后补入的。
发票审批流程
使用场景: 财务团队，记录应付账款流程
开始 → 收到发票
→ 有采购单号？否 → 退回供应商
→ 金额 < 5万？是 → 经理审批 → 付款处理
→ 金额 5-50万 → 总监审批 → CFO签字 → 付款处理
→ 金额 > 50万 → 需要董事会审批 → 付款处理
→ 结束
这样组织的原因: 把三级审批路径画成判断图后，减少了发票发错审批人的情况——这个问题之前导致了长达两周的付款延迟。
内容发布工作流
使用场景: 市场团队，标准化文章审核和发布流程
开始 → 分配写作任务
→ 提交初稿 → 编辑审核 [通过？]
否 → 附评论退回 → 返回写作
是 → SEO 审查 [优化达标？]
否 → 更新关键词和结构
是 → 需要法务审核？是 → 法务通过 → 排期发布 → 结束
否 → 排期发布 → 结束
这样组织的原因: 可选的法务审核步骤（针对金融、健康、法律建议类内容）是在一次事故后加入的。设为条件性而非强制性，让法务团队的审核量减少了70%。
使用技巧
- 画的是实际发生的事，而不是应该发生的事。和真正做这项工作的人一起过流程——凭记忆画的初稿总会漏掉步骤。
- 每个判断菱形应该恰好有两个出口（或每个明确选项一个出口）。如果有三个出口，把它拆成两个独立判断。
- 把正常路径画成垂直或水平的直线，备选路径向两侧分出。这让图一眼就能扫清结构。
- 当流程跨越多个角色或团队时，用泳道风格的列背景——让权责边界一目了然。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=process-map
使用这个流程图模板