门店需求与补货
优先试点这一场景的目标是把销量、库存、天气、活动和交期整理成补货建议、缺货和滞销风险。
- 输入
- 销量、库存、天气、活动和交期
- 输出
- 补货建议、缺货和滞销风险
- 验收
- 检查日报耗时、缺货与滞销预警命中率、店长采纳率
- 边界
- 店长可调整并记录原因

零售门店应用要贴近店长每天的补货、排班、巡店与经营复盘。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 门店需求与补货 | 销量、库存、天气、活动和交期 | 补货建议、缺货和滞销风险 | 店长可调整并记录原因 |
| 选品与陈列 | 商圈、客群、销量、空间和商品 | 选品、陈列和验证建议 | 实际动线和品牌策略需现场确认 |
| 动态定价与出清 | 库存、保质期、需求、毛利和规则 | 折扣/出清建议和影响 | 价格政策和消费者公平性需审批 |
| 排班 | 客流、技能、工时、法规和偏好 | 班表、缺口和备选方案 | 遵守劳动规则并允许员工反馈 |
| 导购知识与话术 | 商品、促销、客户需求和禁用表述 | 推荐理由、对比和话术草稿 | 不能虚假宣传或诱导消费 |
| 巡店与问题闭环 | 检查表、照片说明、整改和标准 | 问题清单、责任人和复查计划 | 高风险问题由现场人员确认 |
| 会员运营 | 会员、购买、权益和互动 | 分层、活动和服务建议 | 个人信息最小化并允许退出 |
| 损耗与防损 | 盘点、报损、退货和异常交易 | 损耗趋势、异常和核查清单 | 不得仅凭模型怀疑员工或顾客 |
| 门店经营日报 | 销售、毛利、客流、库存和人员 | 一页日报、异常和行动项 | 口径统一,不能用单日波动定责 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把销量、库存、天气、活动和交期整理成补货建议、缺货和滞销风险。

这一场景的目标是把商圈、客群、销量、空间和商品整理成选品、陈列和验证建议。

这一场景的目标是把库存、保质期、需求、毛利和规则整理成折扣/出清建议和影响。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“门店经营日报”。它所需输入是销售、毛利、客流、库存和人员,目标交付是一页日报、异常和行动项。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:日报耗时、缺货与滞销预警命中率、店长采纳率。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。