巡检结果需要能直接交给一个人处理
“店铺有异常”不足以安排工作。一条可用记录应包括店铺、商品或订单标识、异常类型、实际值、规则阈值、来源位置和负责人。巡检范围从商品可售、待履约订单、售后待办与平台通知中选择，不必一开始收集所有页面。只有拥有相应访问权限的数据才纳入检查。
同一张表区分业务异常和读取失败
示例团队为重点 SKU 设定“可售量低于 5 件提醒”，为内部待处理队列设定 12 小时提醒。阈值是本团队的工作规则，不代表平台的统一时限。
| 对象 | 观察结果 | 交付给谁 / 下一步 |
|---|---|---|
| 店铺 A / SKU-17 | 可售 2，低于内部阈值 5 | 库存负责人：核对可调拨量 |
| 店铺 A / 订单 O-31 | 内部待处理已 13 小时 | 履约负责人：确认卡点 |
| 店铺 B / 售后队列 | 本次读取失败，上次成功为 09:00 | 系统维护人：恢复采集 |
第三行不能写成“售后待办为 0”。报表需要同时保存业务事件时间、源数据更新时间和本次采集时间。只有采集时间很新而源数据很旧，仍可能得到过期结论。
同一个问题不要每十分钟重新开单
可以用“店铺 + 对象标识 + 规则编号”识别同一问题。第一次发现时新建待办，后续仍不满足条件时更新最新值与持续时长。数值明显恶化、处理超时或负责人变更，才按已设规则升级提醒。合并的是同一对象的同类异常，不能把不同订单合成一条而失去处理线索。
示例 SKU-17 从 2 件变成 1 件，继续更新原待办；补货后变成 12 件，经再次取数确认，可关闭缺货提醒。第二天又低于阈值时，新开一次事件并关联历史，便于区分反复发生与一直未处理。
平台通知要保留原文与时间
通知摘要可以帮助分流，但关键要求、截止时间、时区和操作入口应保留原始依据。文字中存在多个日期时，先标明各日期含义，不能任选一个当截止时间。无法确认通知适用范围时交由运营阅读原文；系统不自行承诺已完成申诉、资质补交或其他外部操作。
每日摘要适合列出新增、持续、升级和已关闭的数量；具体处理页再显示证据。没有发生变化的长列表无需反复发送，避免重要提醒淹没在重复通知中。
验收时故意制造“读不到”和“已恢复”
用四组样本验证：源数据正常但低于阈值，应产生业务待办；登录或读取失败，只产生采集待办；同一异常重复读取，应更新同一条；问题恢复后再复发，应留下两个可区分的事件。每条关闭记录都保存依据与时间，防止人工点了完成而源数据仍显示异常。