ERP 与发货
- 可以读取
- 订单编号、付款标记、承诺发货日期、快递扫描状态
- 可以准备
- 内部发货任务和客户通知草稿
- 获批后可以写回
- 获批的发货备注或已经确认的物流编号
- 遇到这些情况停下或交回给人
- 订单无法匹配、必要字段为空、或连接暂时不可用
- 企业
- 虚构的奥克兰小型批发商
- 开始时间
- 每个工作日早上 7:30
- 访问边界
- 动作获批前保持只读
- 输出
- 晨间简报和易读的操作记录
01 输入
先读取一夜之间的变化
这次示例运行只读取当前流程需要的记录。下面的每一条记录都是模拟数据。
- ERP 与发货SO-1842
已付款订单延迟发货
承诺发货日期是昨天，但系统里还没有快递扫描记录。
异常 - CRMSO-1848
配送资料不完整
配送规则要求填写门牌单元号，但这个字段是空的。
需要人工处理 - 库存系统SKU-042
库存低于补货规则
现有 8 件，补货点为 12 件，而且没有未完成的采购申请。
符合规则 - 财务系统与 ERPINV-614
付款状态不一致
财务系统显示已经付款，订单记录仍然显示等待付款。
数据冲突 - 共享邮箱LEAD-233
客户跟进已经到期
约定的跟进时间已经过去，系统里还没有收到回复。
可以准备草稿
连接器合同
每套系统都有明确的小任务，不是把大门全部打开
接入真实系统前，我们会为每个连接器写清允许范围。这个模拟示例逐项展示它可以读取什么、准备什么、获批后写回什么，以及什么时候必须安全停下。
CRM
- 可以读取
- 客户编号、必要配送字段、跟进日期、最后一次回复
- 可以准备
- 资料缺失异常或客户跟进草稿
- 获批后可以写回
- 在匹配记录中写入获批备注和下一步日期
- 遇到这些情况停下或交回给人
- 客户无法匹配、两条记录互相冲突、或关键字段需要人判断
库存与采购
- 可以读取
- 现有数量、补货点、未完成申请编号
- 可以准备
- 包含数量、原因和模拟估算金额的采购申请
- 获批后可以写回
- 获批订单编号和下次检查日期
- 遇到这些情况停下或交回给人
- 批准后库存记录发生变化、出现新供应商、或写回失败
财务系统
- 可以读取
- 当前检查需要的发票编号和付款状态
- 可以准备
- 附上两边数据的来源冲突异常
- 获批后可以写回
- 这个示例不写财务记录，财务系统仍是付款状态的主来源
- 遇到这些情况停下或交回给人
- 财务与 ERP 状态不一致，或无法按编号匹配发票
共享邮箱
- 可以读取
- 会话编号、约定收件人、最后回复、跟进日期
- 可以准备
- 按照确认过的话术准备跟进草稿
- 获批后可以写回
- 获批的发送结果和一条 CRM 活动记录
- 遇到这些情况停下或交回给人
- 出现新收件人、会话无法确认、或没有合适的消息规则
02 检查与判断
按照确认过的规则处理，再把常规工作和例外分开
遇到资料缺失或不同系统互相冲突时，数字员工不会自己猜答案。它只准备规则允许的动作，其余事项交给人判断。
发现这种情况数字员工可以准备控制边界
- 1发现这种情况
库存达到或低于补货点，而且没有未完成的采购申请
数字员工可以准备按照事先确认的数量准备采购申请
控制边界任何支出都必须由指定负责人批准
- 2发现这种情况
已付款订单超过发货时间，但没有快递扫描记录
数字员工可以准备内部发货任务和客户通知草稿
控制边界对外消息必须先经人工审核
- 3发现这种情况
必要字段缺失，或者两个来源的数据互相冲突
数字员工可以准备附带冲突数据的异常记录
控制边界不猜测字段，也不修改关键记录
- 4发现这种情况
跟进日期已过，而且没有收到回复
数字员工可以准备按照确认过的话术准备跟进草稿
控制边界发送前由人审核
03 动作轨迹
跟着一条库存异常完整走一遍
同一条模拟记录 SKU-042，从第一次检查到最后写回都保持可见，这样您能看清每次判断和人工批准发生在哪里。
追踪记录 · SKU-042 · 模拟数据
虚构企业 · 模拟业务记录输入
早上 7:31
读取库存记录
现有库存为 8 件，老板确认过的补货点是 12 件。
检查
早上 7:33
确认没有未完成的申请
采购记录中没有 SKU-042 的有效申请。
判断
早上 7:35
匹配已经确认的补货规则
规则允许准备一份 24 件的申请，但不允许未经批准产生支出。
准备动作
早上 7:37
准备采购申请 PR-0092
申请中列出货品、数量、模拟估算金额和触发这次申请的规则。
人工批准
早上 7:47
记录运营负责人的决定
示例中的负责人批准了申请。在此之前，没有下单，也没有写回系统。
写回系统
早上 7:50
创建获批订单并更新来源记录
获批的采购单编号和下次检查日期被写回 ERP 的库存记录。
04 写回与审计
每次读取、判断和获批更新都有通俗的记录
操作记录是工作流程的一部分，不是额外的口头承诺。下面展示模拟记录 SKU-042 的完整轨迹。
| 时间 | 执行者 | 对象 | 动作 | 状态 |
|---|---|---|---|---|
| 7:31 | 数字员工 | 库存 / SKU-042 | 读取现有数量和补货点 | 只读 |
| 7:33 | 数字员工 | 采购记录 | 检查是否已有未完成申请 | 没有找到 |
| 7:37 | 数字员工 | PR-0092 | 准备采购申请并附上原因 | 等待批准 |
| 7:47 | 运营负责人 | PR-0092 | 批准建议支出 | 已批准 |
| 7:50 | 数字员工 | ERP / SKU-042 | 创建获批订单并记录订单编号 | 已写回 |
05 晨间简报
老板看到的是要做的决定，不是又一个后台
早上 8:00，示例运行把所有工作整理成异常、待批准事项和已经完成的动作。
- 3 个异常需要关注
- 2 个动作草稿等待审核
- 1 份采购申请已经批准并写回
- 1 个数据冲突仍然等待人工处理
- 0 个动作在缺少必要批准时执行
本页所有数量、业务编号、金额、决定和时间均为模拟示例数据。
我们如何搭建这套系统
用小型连接程序接上现有系统中事先确认的部分
BestAI 会为工作流程需要接触的每个系统编写一段定制集成程序，也就是 API connector。具体接法取决于您正在使用的工具。接入真实数据前，我们会先确认流程可以读取什么、可以准备什么、哪些动作必须由人批准，以及每个结果要写回哪里。
- 继续使用团队熟悉的 CRM、ERP、财务和邮箱工具
- 访问范围只包含这条流程需要的字段和动作
- 连接真实记录前，先测试规则和例外情况
- 让团队清楚看到人工决定和每一条操作记录