F旗舰T2+T3优先级 12.5到手价推演羊毛党上限叠加核算上线前拦截

CP-01 · 优惠券到手价沙盘推演

满减券叠完平台券再叠支付立减 · 没人知道到手价到底是多少,直到零点羊毛党告诉答案

一这件事现在是什么样

活动与优惠风控 · 真实业务触发

818 大促报名截止前夜。方案是:店铺券满 99 减 20 + 平台跨店满 200 减 30 + 88VIP 95 折 + 淘金币抵 2%。四层优惠怎么叠加、到手价多少、毛利还剩多少、羊毛党单账号能薅走多少 —— 报名表要提交了,这些数没人算得清。

二痛点 · 每条都有来源

不是流程描述,是调研出来的真痛点 —— 每条可点开核对出处

1
年营业额 30 多万的小商家,打算设满 1000 减 1000,运营重复设置成满 2000 减 2000 —— 零点生效无人值守,羊毛党社交平台集体抢购,成交 1,200 万、货值约 2 亿,被迫关店依据 · 2024-08 天猫厨电商店(年营业额仅 30 多万):打算设满 1000 减 1000,运营重复设置成满 2000 减 2000;零点生效无人值守,羊毛党社交平台集体抢购,成交额约 1200 万、货物价值约 2 亿,保证金被扣、资金冻结、被迫关店
2
事故三要素高度一致:叠加规则复杂、零点生效无人值守、羊毛党社交平台瞬时放大 —— 官方工具覆盖不全且被动,出事前没人拦依据 · 商家共识:平台优惠机制设置太复杂、多种促销叠加稍不注意同时生效,导致产品以极低价售出 —— 事故三要素:叠加规则复杂、零点生效无人值守、羊毛党社交平台瞬时放大

三换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 年营业额 30 多万的小商家,打算设满 1000 减 1000,运营重复设置成满 2000 减 2000 —— 零点生效无人值守,羊毛党社交平台集体抢购,成交 1,200 万、货值约 2 亿,被迫关店
  • 事故三要素高度一致:叠加规则复杂、零点生效无人值守、羊毛党社交平台瞬时放大 —— 官方工具覆盖不全且被动,出事前没人拦
  • 「报活动更要算细账」是运营铁律,但多数小商家报名前只看了一眼报名页 —— 到手价、扣点、运费、退货成本五项没人逐项算过

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四场景闭环

5 步 · 每一步的产出都是下一步的输入

第 1 步
叠加规则建模 · 每层券的触发与互斥店铺券/平台券/支付立减/会员折扣/淘金币 —— 哪些可叠、哪些互斥、触发顺序,规则来源逐条标注
第 2 步
到手价推演 · 分价格带算到个位数按商品价格带逐一推演:99 元档、199 元档、299 元档叠完所有券后的真实到手价
第 3 步
毛利核算 · 到手价以下还能赚多少到手价 − 成本 − 运费 − 推广分摊 − 退货成本 = 单件净利 —— 亏钱的组合当场现形
第 4 步
羊毛党推演 · 单账号损失上限限购 N 件 × 到手价 × 历史羊毛党抢购单量参照 = 最大损失敞口 —— 2 亿货值那个商家缺的就是这一行
第 5 步
上线检查单 · 提交前的最后一道关叠加层数提示、零点值守安排、限购与库存上限核对 —— 检查单签字后才提交

要准备什么

活动报名草稿(券配置/满减门槛/限时立减)
各平台后台的报名界面或草稿截图
商品成本表(含运费与包材)
沙盘的毛利底线
历史大促成交与退款数据
预估单量与退款率的基准
竞品同品类到手价(手动看来的,有几个算几个)
定价竞争力的参照

为什么这个场景值得做

痛感 5 × AI 适配 5 ÷ 落地难度 2 = 12.5

最大差异点 · 不要求客户懂平台叠加规则。报名草稿 + 商品成本 + 历史成交扔进来 —— 每一层叠加的规则来源写明,推演结果与实际结算口径对齐。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」; AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」; 落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

正式件本体
优惠券到手价沙盘报告.xlsx
正式件本体 · 分价格带推演 + 毛利核算 + 羊毛上限
可派发清单
亏损组合与修正方案.xlsx
亏钱的组合 · 两个改法各带重推后的毛利
可派发清单
上线前检查单.xlsx
叠加层数/零点值守/限购库存 · 签字后提交

这套东西不承诺什么

不做「自动改活动」—— 沙盘算的是后果,改配置、按提交键的是人。也不做薅羊毛反制 —— 风控是平台的能力,我们做的是上线前让损失上限被看见。

想看具体怎么跑?

Live Demo 里有一个完整案例的每一步,包括 Agent 在哪一步拦住了