壳牌中国“晒中超，约球星”营销活动

一句话结论：外资品牌入华做全国促销，难点不在创意，而在 700 家门店的奖品、库存、批次和核销能不能对得上账。这篇文章拆一套 2017 年真实跑过一个中超赛季的系统，也讲清楚今天用 Odoo 重做时，哪些该用标准能力，哪些必须定制。

Odoo 全国促销抽奖管理架构：五层横向架构，触点、抽奖服务、Odoo 业务中台、履约、分析

一、先看结果：一场全国促销的三组硬数字

2017 赛季，壳牌中国围绕中超做了「晒中超，约球星」活动。消费者扫码、上传中超相关照片、玩九宫格抽奖，100% 中奖；奖品从签名球衣、中超球票，到京东卡、微信红包、壳牌合成油优惠券，全部在线上派发、线下核销。

后台奖品页截图里的一组真实数字，比任何形容词都直接：微信红包中奖 10,972 份；50 元京东卡 5,206 张，按面值累计 260,300 元；中超球票 1,145 张；球迷衫 601 件；球星专属 VCR 12 份。活动结束时，这些数字要能对上库存、对上财务、对上门店。

二、玩法不复杂，复杂的是每一步都要“有据可查”

但把这七步拆开，每一步都连着后台：

100% 中奖不是一句营销口号，而是一份库存承诺。只要有一个奖品池算错，前台就会变成“抽得到、领不到”。

三、四个真问题：做过全国促销的都懂

1. 奖品不是“配置”，是库存

很多活动后台把奖品当成一张配置表：名称、图片、概率。真到全国 700 家门店，奖品就是库存：总仓有多少、城市仓有多少、这家店还剩几件、哪些店根本不派。贵阳当时不派球衣，系统里对应的门店库存就是禁用状态，需要按门店编码或城市码批量启停。

系统里因此有三层库存：奖品总库存、城市或门店库存、批次库存。任何一层没扣减，第二天就会出现超发；任何一层没回滚，活动结束就会剩一堆“账上有、库里没有”的奖品。

2. 有库存不等于能中奖：概率、库存、批次三重约束

这是这套系统最容易被低估的地方。京东卡和中超球票除了受中奖概率和库存限制，还受批次限制：批次库里这一批票或卡发完了，即使总库存显示还有，系统也会自动跳过，换下一个奖品，直到所有奖品抽完，用户端无感。

如果只做“概率 + 总库存”，活动第三天就会卡死：用户一直抽到“谢谢参与”，客服电话被打爆。批次约束是把票务、卡商的实际供货节奏翻译成系统规则。

3. 派奖是四套外部系统，不是一次数据库写入

同样是“中奖”，履约方式完全不同：

每一类都要有独立的状态机：待发放、已发放、已核销、失败、已补发。后台如果只有一个“已中奖”状态，财务和客服都没法用。

4. 700 家门店的主数据，在没Ai的年代，全部人工清洗

门店名称、门店编码、所属城市、归属经销商、营业状态、兑奖密码、二维码，这些字段看着普通，但它们是所有库存和核销的索引。文档里反复强调“不要改编码”，原因很实际：编码一改，历史中奖单、库存、二维码全部对不上。

后台还把门店库存的启停做成了批量操作：输入门店编码或城市码，比如 gy 代表贵阳，筛选奖品，批量启用或禁用。这个功能在活动执行中比任何花哨的报表都重要，因为奖品派发范围经常在活动开始后临时调整。

四、这套系统的业务骨架

把前台功能翻译成业务对象，其实只有七类：

这套模型不依赖某一种技术。2017 年我们把它落在一套自有后台加微信 H5 上；今天做同类项目，我会把主数据和账实放进 Odoo，把高并发抽奖独立出去。

后台的价值不是“能抽奖”，而是活动结束后，每一份奖品都能说清楚去了哪里。

五、Odoo定制此平台的参考架构

外资品牌入华、在华合资企业做这类项目，常见诉求是：中国团队要快、总部要看得懂、财务要能对账、IT 要能审计。Odoo 的优势不在“抽奖”，而在它本来就有库存、批次、权限、多语言、多币种和报表。

参考架构分五层：

C 端流量不要直接打到 ERP。抽奖是毫秒级、强并发的动作，Odoo 负责账实和主数据；中间用队列异步回写，既保住体验，也保住数据一致性。

六、外资品牌入华、合资企业落地时的 6 个提醒

1. 微信生态是渠道，不是插件。 公众号、微信卡包、红包、小程序、企业微信各有资质和接口限制；域名备案、JS 安全域名、订阅消息模板都要提前排期。海外团队常以为“接个 API 就行”，实际它是中国本地运营体系的一部分。
2. 个人信息保护要按中国规则重做一遍。 手机号、地址、照片属于个人信息；收集要最小化，用途要告知，中奖公示要脱敏。外资企业还要处理总部访问中国数据的问题，PIPL 与 GDPR 双轨合规不是法务一句话，得落到字段、权限和日志上。
3. 奖品的税务和发票，提前和财务对齐。 实物礼品、微信红包、卡券的税务处理不同，涉及个人所得税代扣代缴、视同销售、进项转出等口径。系统要能导出“谁、什么时候、中了什么、价值多少”，否则财务只能手工翻台账。
4. 先治理门店主数据，再谈活动配置。 门店编码、城市、经销商、开关店状态、兑奖密码，必须有一个唯一来源。历史项目里最常见的返工，不是抽奖算法，而是“这家店到底归哪个城市”。
5. 总部报表要一开始就设计。 外资总部通常要英文界面、多币种，按国家、区域、城市、门店多维查看；中国团队要的是当天能导出、能核对。Odoo 的多语言、多公司、透视表能省掉大量二次开发，但指标口径要提前定。
6. 把活动做成模板，而不是一次性项目。 奖品池、概率、批次、门店范围、核销规则都能配置后，第二场活动可能一两周就能上线；如果每次都要改代码，第一场省下的钱，第二场就还回去了。

外资入华不是把海外系统翻译成中文。渠道、合规、税务、门店组织，这四件事都得按中国的运行方式重新设计。

门店库存与中奖报表：按城市、门店、奖品的库存与中奖分布

七、传统外包与 Odoo 定制：差在哪

这不是说 Odoo 什么都能开箱即用。抽奖引擎、微信红包、门店寄售库存、卡券核销，仍然需要定制开发；差别在于，定制的是业务插件，不是从零造一套 ERP。

八、我们做这类项目的方式

欧度智能长期做 Odoo 定制开发与实施，客户里既有走出去的中国企业，也有进入中国的外资品牌和合资公司。壳牌中国这套「晒中超，约球星」系统由我们团队在 2017 年交付，从门店二维码、奖品池、批次约束，到红包、卡券、球票的派发与核销，完整跑过一个中超赛季。

今天再做同类项目，我们通常按四步走：

1. 业务建模：先把活动、门店、奖品、库存、中奖单、卡券、流水七类对象定清楚，再谈页面。
2. 最小闭环：先跑通“扫码、抽奖、派奖、核销、报表”一条链路，两周内给业务方可用版本。
3. 本地集成：微信生态、短信、支付、电子发票、400 工单，按实际服务商接入。
4. 交付与复用：源码、部署、权限、操作手册一起交付，把活动沉淀成模板。

如果你正在评估入华后的第一套营销或渠道系统，可以先自查四个问题：

• 门店、经销商、城市三层主数据，有没有唯一编码和唯一来源？
• 奖品是“配置”还是“库存”？批次、门店范围、回滚规则想清楚了吗？
• 红包、卡券、实物、票务的履约和失败处理，是否各有状态机？
• 总部要的报表，中国团队当天能不能导出来并对上账？

这四个问题答清楚，系统选型基本就不会跑偏。

如果您需要聊具体的 Odoo 定制方案，可以访问 odooai.cn 或 odooapp.cn，也可以直接在公众号留言。