01建议起点
3-5 店 · 1 个区域先统一一份晨报和一组核心指标。
Pilot Brief
先把试点边界讲清楚
门店每天忙着拼表，真正需要处理的缺货、滞销和数据异常反而被淹没。
02人工关口
店长 / 运营确认补货、调拨和会员触达不直接执行。
03首批输出
晨报 + 异常队列每项建议带数据来源、责任人和状态。
04扩展条件
编码与口径一致门店对账稳定后再增加区域和动作。
以上为模拟试点范围，不代表已披露客户业绩、已交付项目或固定收益；具体范围以诊断和书面约定为准。
Workflow
从经营数据到门店行动
先让数据口径一致、异常有优先级、建议有人确认，再连接采购或触达流程。
01口径对齐
统一门店、SKU、库存、活动和时间口径，并记录字段来源。
02异常排队
按缺货风险、滞销程度、活动波动和数据缺失生成优先级。
03建议编排
结合在途库存、仓储限制和门店等级生成补货或调拨建议。
04负责人确认
店长或运营人员确认动作，系统记录负责人、状态和结果。
Acceptance
晨报能否真正指导行动
用源表抽查、早会使用记录和任务闭环验收，不只看报表是否生成。
晨报准点
在约定早会时间前生成核心指标、异常摘要和待办列表。
源表可对账
抽查门店与 SKU 时，可定位到 POS、库存或活动源字段。
建议可执行
建议包含原因、优先级、建议数量、负责人和确认状态。
权限不越界
试点只读取数据并创建建议，不自动下采购单或批量触达会员。
Implementation Conditions
启动前需要确认什么
先统一编码、指标和负责人，复杂预测可以放到后续阶段。
业务问题与适用条件3 项问题 · 4 类适配条件
问题拆解
- 门店、区域与总部使用不同表格和统计口径，早会前仍要反复核对数字。
- 缺货、滞销和活动波动混在报表里，运营人员难以快速判断先处理什么。
- 建议发到群里后缺少负责人、截止时间和处理结果，后续无法复盘。
适合客户
多店共用同一商品体系可导出销售与库存明细晨报仍依赖人工拼表有明确的区域运营负责人
启动准备与责任边界样本 / 权限 / 人工复核
数据样本
准备连续营业日的销售、库存、在途、活动和历史晨报。
业务口径
确认缺货、滞销、周转、活动波动和异常数据的定义。
处理规则
明确谁确认补货与调拨、使用什么渠道、如何标记完成。
边界与前提
- 补货建议必须结合采购周期、起订量、在途库存和仓储限制，试点阶段不自动下单。
- 门店或 SKU 编码不一致时，应先治理主数据，避免把编码问题误判为经营异常。
- 涉及会员标签和触达建议时，仅处理已授权的必要字段，并保留人工确认。
系统、节奏与交付物6 类系统 · 3 段周期
接入系统
POS 系统库存表/ERP商品与门店主数据活动排期表企业微信/钉钉经营日报
交付周期
第 1 周
计划对齐门店、SKU、库存和活动字段，并锁定晨报模板。
第 2 周
计划完成源表对账、异常规则和建议队列原型。
第 3-4 周
计划在早会中试用，复盘误报、责任分派和任务闭环。
交付材料
- 主数据与指标口径表
- 经营晨报模板
- 异常优先级规则
- 补货调拨建议队列
- 任务闭环复盘表