B端系统审批流与原型验证实战 - 第1节
1.1 业务场景识别：从哪里发现审批流价值
要设计一套高可用审批流系统，第一步不是画流程图，而是用“业务场景”还原真实协作现场。B 端审批流通常发生在跨角色、跨部门的流程驱动环节，常见场景集中在以下三类：
- 费用报销类 — 员工垫资 → 主管审核 → 财务核销 → 出纳付款；
- 采购合同类 — 需求发起 → 商务比价 → 法务审批 → 总经理签章；
- 请假考勤类 — 员工申请 → 部门批准 → HR 备案 → 考勤同步。
产品洞察： 三类场景背后都存在“规则异常多、跳转路径复杂、人工催促频繁”的共性痛点，这是审批流产品设计的核心切入点。
1.2 用户角色与权限矩阵：谁在“卡”流程？
一个典型审批流涉及 5 类角色，每类角色的权限粒度直接影响流程设计策略。以下是对比清单：
| 角色名称 | 典型职责 | 权限边界 | 业务痛点关键词 |
|---|---|---|---|
| 发起人 | 填写申请、上传附件、选择审批人 | 仅查看自己发起流程的状态 | 不知道审批到谁手上；重复退回修改 |
| 直属主管 | 第一级审批：核实业务真实性 | 可驳回或转交下一级 | 手机端操作不便；多任务堆叠无优先级 |
| 部门总监 | 第二级审批：预算额度检查 | 可驳回、退回至发起人、追加会签 | 缺乏预算约束关联；无法批量处理 |
| 财务/法务 | 合规与金额核验 | 驳回、退回并发起补充材料流程 | 附件规范不一；经常来回补件效率极低 |
| 总经理 | 超权限金额终审 | 最终批准或驳回，终结流程 | 信息过载，只看摘要，实际决策依赖系统预判 |
权限设计原则： 审批流中的“权限”不等于 CURD，而是“谁能看见哪些字段”、“谁能中断/转发/会签”。在原型阶段，要用角色-字段矩阵代替传统的权限树。
1.3 业务痛点：每一个“卡顿”都是需求信号
通过对上述场景与角色的访谈预判，可以归纳出审批流的 4 类经典业务痛点：
- 流程可视化缺失 — 发起人看不到审批链中的当前位置，靠微信私聊催促，造成低效跟踪；
- 审批规则硬编码 — 金额、部门、类型变化时系统无法动态适配，后端改代码周期长；
- 驳回与撤回无收敛 — 驳回到任意节点、撤回后数据版本混乱，导致流程重跑或财务对账不平；
- 批量处理能力弱 — 主管端同类型单据无法批量通过或驳回，每天需逐条点开查看。
避坑提醒： 不要在产品早期直接用“提高效率”作为需求主题。应先还原“卡点时刻”，例如：“周五下午财务总监无法同时审批 30 张报销单，导致付款延期 3 天”——这才是真实需求颗粒度。
1.4 典型审批路径与角色触点图解
下面用一张内联流程图画出一个通用企业审批流的“主线 + 分支”结构，标出不同角色的决策节点与跳转可能性：
1.5 用户访谈核心问题模板（可直接复用）
在需求调研阶段，用下面这套结构化问题访谈对应角色，能快速收拢审批流需求边界：
【针对发起人】
1. 你最近一次填报销单被退回的原因是什么？
2. 审批过程中你通常通过哪种方式知道“现在卡在谁手上”？
3. 如果系统能自动告诉你预计审批完成时间，你会如何使用这个信息？
【针对财务/法务审批员】
4. 你每天审批的单据中，有多少比例需要发起人补材料？
5. 重复退回最多的业务类型是哪一类？
6. 审批通过后，你希望系统自动触发什么下游动作？
【针对总经理】
7. 你审批前最需要看到的 3 条摘要字段是什么？
8. 你希望什么类型的审批自动跳过你？
9. 如果系统给出“AI 预审建议”，你通常会采纳还是推翻？