Shopee 多门店直播优惠券发放自动化闭环

先说口径，避免误读 · 已实测：菲律宾 361degrees.ph 一家店的 10 张直播券全部建成并逐张回列表核验（券码、面额、门槛、总数、商品数、状态逐项对上）。 · 未实测：其余 21 家店、其余 7 类券型（商品券 / 店铺券 / 非公开券 / 短视频券 / 3 类买家券）。 · 本页不含代码，也不承诺提效百分比——原因写在 roiNote 与第 6 章。

1. 为什么商家必须做这套自动化

1.1 券不是”发一张”，是”发一季”

打开这家店的优惠券列表，翻到底部是 563 页（每页 10 条）——历史券约 5,600 张。 同期券效果面板（近 7 天）显示：销售 ₱4,157,249、订单 1,436、使用率 3.35%、买家 1,291。 券已经是日常经营的主抓手，不是促销节才用一次的东西；任何靠手工一张张点、靠翻页找券的做法都会失控。

1.2 8 种券型 × 22 家店 = 组合爆炸

优惠券首屏有 8 个创建入口：整体转化类（商店券、商品券）、分发渠道类（非公开券、直播券、短视频券）、 买家群体类（新买家券、回购买家券、关注礼券）。 而这家主体在 Shopee 有 8 个国家、22 家店（菲律宾 4、泰国 5、越南 4、马来西亚 4、新加坡 2、 印度尼西亚 / 台湾 / 巴西各 1）。

“哪种券 × 哪家店 × 哪个周期”靠人记，结果必然是两个：漏建（某店该发的没发）和错建 （券挂到别的店、面额填错、期间写错）。这两件事都不会报错，只会安静地少赚。

1.3 错建的代价，比”慢”贵得多

• 券一旦生效，删不掉。 平台只提供「结束」，结束后状态变「已过期」但历史仍在列表里。 写错面额或门槛，等于带着错误跑完整个周期。
• 重复建券 = 让价翻倍。 同一批商品挂两张同门槛同面额的券，买家可以叠加使用，直接吃掉利润。 这不是理论风险：本次实施中就真实发生过一次（见 3.1）。
• 漏建不会有人告诉你。 券少发一张，表现只是”这段时间转化率略低”，复盘时很难归因。

所以这件事的自动化目标不是”点得快”，而是每一张都能被核验、每一张都不会重复、换店不用重学。

2. 端到端业务流水线（4 步）

Step 1｜认店与取表：路径就是业务语义

运营把发放表放进对应门店目录：

执行目标\<国家>\<门店域名>\<年份>\<月份>\  （例如 执行目标\菲律宾\361degrees_ph\2026年\10月\）

流程做的第一件事不是打开浏览器，而是读表头：表格前 4 行写着店铺、时间、券类型、每张券可使用数量。 以表头声明的店铺为准去确定”这是哪家店的活”，目录只当提示——因为商品编号只属于表头那家店， 拿错店建券，平台会用一句”数据无效”把你挡回来（真实踩过，见 3.2）。

产出：一份”待建券清单”（券名、门槛、面额、要挂的商品）。

Step 2｜解表成券参数：券名自己就是答案

发放表长这样：第 6 行是表头「优惠券名称 | 优惠商品」，第 7 行起是数据；一张券的多个商品就是多行同券名。

实际这一版是 55 行 → 10 张券 → 54 个唯一商品。 券名直接就是参数：2400-410 意味着”满 ₱2400 减 ₱410”，500-50 就是”满 ₱500 减 ₱50”， 不需要运营再翻译一遍，也不需要和运营对一次口径。

其中有一个商品被甲方指定同时挂两张券（53467133726 同时出现在 2900-310 与 4000-970）， 流程按人的决定执行，不擅自”去重”。

产出：10 组参数（券名 / 面额 / 门槛 / 商品清单 / 张数 2,000）。

Step 3｜建券：填参数、挂商品、提交

每张券在后台要填的其实只有 8 件事：券名、领取期限、奖励类型、折扣类型、折扣金额、最低消费、可使用总数、优惠商品。 直播券不绑直播场次，只有一条固定设置”仅在 Shopee 直播中显示”——这点和很多人的直觉相反，实测确认。

商品通过官方模板上传：单列 Product ID，A1 表头、A2 起填商品编号。 平台限制比折扣活动严：单商品规格 ≤500、累计规格 ≤5,000（折扣活动允许 15,000 行，两个口径不能混用）。 本单最大的券挂 14 个商品，远低于上限。

期限有一处只能顺着平台：开始时间取”进页面那一刻的默认值”（平台给的是当时 +8 分钟）， 因为开始时间不允许回填到过去，也不接受程序改写；结束时间按发放表截止日填 23:59。 所以流程要求”打开页面就干活”，不要在中间挂太久。

产出：后台里一张张真实存在的券。

Step 4｜回读登记与投递巡检：把”建好了”变成”可核验”

提交之后页面不会告诉你结果（原因见 3.1）。流程在这里做的唯一一件事是： 回到优惠券列表，按券名 + 期间找到那一行，抄下券码（形如 LIVE-1540284689833984）， 并核对状态（进行中 / 接下来的活动）、面额、总数、商品数——对上了才算这张完成，然后登记进台账。

另一件配合作业习惯的事：投递前巡检。运营把表放错目录是常态（本次就发生过）， 巡检会一次扫完 22 家店目录，报出”放错店 / 放错月 / 无法判定 / 非投递表”四类，并直接给出该去的目录。

产出：_券码台账.json（每张券的券码与状态）+ 一份巡检报告。

3. 三大企业级可靠性保障（都是踩出来的）

3.1 判据可信：平台那句”操作流程已捕获”，一个字的可信度都没有

真实事故：首张券提交后，页面不跳转，弹出一个框写着”操作流程已捕获…请复制下面的唯一ID发给 Shopee 支持团队”。 任何人看到这个都会判断”提交失败了、里面还有报错”。于是又点了一次「确认」—— 结果是第二张一模一样的券被建出来了。

后来把那个弹窗拆开看：它里面的”唯一 ID”位置是空的，根本没生成任何编号。 进一步实测：提交成功会弹它、结束券会弹它、从编辑页离开也会弹它。 也就是说，它既不是成功信号，也不是失败信号。

所以这套流程现在只认一条判据：回列表按券名 + 期间回读。 这条规矩换来的东西是实的——10 张券里没有任何一张重复，唯一那张重复券是事故当下产生的，之后被及时结束止损。

3.2 数据防损：三道闸，每一道都对应一次真实损失

• 门店闸（表头 vs 目录）：把发放表放错店目录 → 打开的是另一家店的建券页 → 上传商品时平台报 “失败 · 所有数据无效”。看着像表格格式错误，实际是商品编号不属于这家店。 同一份文件、同一套流程，换回表头那家店，5 个商品一次通过。 现在流程以表头为准，两者不一致会明确告警。
• 回读闸（不一致不许提交）：填完表单先逐项回读，名称/面额/门槛/总数/商品数与预期不符就停下， 不提交。实测中止过一次：某张券首次上传后商品数还没渲染完，回读对不上，流程拒绝提交； 重跑一次正常建成——如果当时”先点了再说”，就会多一张错券。
• 防重闸（提交只点一次）：这一条写在流程最前面，不是建议而是硬性纪律。 提交后无论页面什么反应，都只允许去列表核对，不允许再点第二次。

3.3 异常自愈：止损动作也要验证

• 真出了重复券怎么办？平台不允许删除，只能「结束」。流程给的处置路径是：结束 → 等 5~10 秒 → 刷新列表 → 看到状态变「已过期」、且结束时间被改写成点击那一刻（实测原 10-31 23:59 变成 12:38）， 才算处置完成。“点了结束”不等于”已经结束”。
• 批量中途某张失败：跳过并继续下一张，不重试（重试的代价是重复券）；最终以台账里”缺哪张”为准补做。
• 表放错位置、放错月份：巡检工具兜底，只读不改，把该动的目录写清楚，人来挪。

4. 交付物样张：管理层怎么验收

这批跑完，本地桌面/项目目录里留下三样东西，验收不需要懂后台：

验收动作就三步：数券张数（应为 10）→ 抽查任意两张的券码与后台是否一致 → 看有没有”已过期”的异常券。 全部对得上，这批就算交付完成。

说明（不粉饰）：目前建券这条线不发邮件战报，验收靠台账 + 截图；邮件版需要另配（履约线已有两封制战报，可直接复用格式）。

5. 零知识数据安全承诺

• 数据不出本机：发放表、商品编号、券码全部在本地读写；业务数据 0 字节流向 Operun 服务器 （服务器只转发”打开页面、读这一块、点这个按钮”这类指令，不接触表格内容）。
• 本地真实 IP：全程用商家本机的真实浏览器与真实网络出口，不经过任何中转代理池。
• 真实登录态，零凭证留存：不保存账号密码、不导出 Cookie；运行结束即释放，下次靠已有登录态继续。
• 凭证画面脱敏：对外素材去掉账号密码、买家个人信息、金额面板；商品名截断到品牌 + 款号。
• 可审计：每一次建券都留券码与回读状态，出问题能追到”哪一张、什么时候、什么参数”。

6. 复现口径：本页数字去哪复核

未取证的部分同样写在这里：其余 21 家店批量、其余 7 类券型的表单差异、平台是否对重复券有额外考核—— 都没有实测，本页不给结论。