这个工作流的目标不是替代 Shopify 或订单管理系统，而是让团队更早看到异常订单。
适合自动化的是提醒和记录，不是未经人工确认就取消、退款或处理争议。
适合谁
- Shopify 店铺有稳定订单量。
- 团队已经知道哪些订单状态需要关注。
- 运营需要 Slack、邮件或表格记录提醒。
- 异常处理仍然由人确认。
不适合谁
- 订单量很低，后台人工查看已经足够。
- 异常字段不稳定，规则还没定义清楚。
- 想自动取消订单、自动退款或自动处理争议。
- 高风险订单没有人工判断流程。
先定义什么算异常
异常不是一个通用标签，必须由店铺自己定义。
常见示例：
- 付款失败或付款状态异常。
- 履约超过约定时间。
- 地址字段缺失或格式异常。
- 库存不足导致无法发货。
- 高金额订单需要人工复核。
- 退款、拒付或争议风险。
第一版不要把所有异常都自动处理，先从提醒开始。
输入和输出
输入：
- 新订单或订单更新事件。
- 定期查询到的订单状态。
- 店铺定义的异常规则。
输出：
- Slack 或邮件提醒。
- 可选的 Google Sheets 异常记录。
- 负责人后续处理标记。
模块结构
可以按两种方式设计：
- 如果上游能主动触发：Shopify 事件或 webhook -> Filter/Router -> 通知。
- 如果只需要定期检查：Schedule -> 查询订单 -> Filter/Router -> 通知。
具体模块名称和可用字段应以当前 Make 与 Shopify 集成为准。
Webhook 还是定时检查
如果你需要订单状态变化后尽快提醒，并且上游能提供事件，优先考虑事件触发。
如果你只需要每天或每小时检查一批订单，定时检查通常更简单。
如果你用高频定时检查模拟实时提醒，要注意运行次数、模块动作和告警噪音。
错误处理
建议至少设计：
- 查询失败时通知负责人。
- 没有匹配订单时正常结束，不发无意义提醒。
- 异常字段缺失时单独标记。
- 通知失败时保留可追踪记录。
操作数提醒
订单量越高，定时检查越频繁，操作数压力越明显。先估算：
- 每天检查几次。
- 每次检查多少订单。
- 每条订单会经过几个模块。
- 通知和记录是否会对每条订单都运行。
常见错误
- 没定义异常就开始搭流程。
- 把提醒流程做成自动处理流程。
- 过滤条件太宽，导致团队收到太多无效提醒。
- 没有记录已提醒订单，重复提醒同一个问题。
相关 Make 文档
第一版先从 帮助文档 入口继续查阅相关主题：
- 定时运行场景
- Webhook
- Router 和 Filter
- Error Handling
- Operations 和 Credits
下一步
先选一个低风险异常，例如地址缺失或履约延迟，只做提醒和记录。等团队确认规则稳定后，再扩展到更多异常类型。
部分链接可能包含联盟推广链接。这个工作流适合发现问题，不适合无人工确认地处理高风险订单。