大多数人会开始比较功能数量，看哪家多送几个模块。实际上收银台只做结账，损失的不是功能，是三条本应在收银这一刻自动生成的数据链。链条断了，后面所有运营动作都得靠人工补。
第一条：会员身份链
顾客付完钱走了，系统里只多了一笔金额，不知道是谁。这是最常见的第一条断点。
这条链要通，需要的不是「会员卡功能」，而是收银动作本身能产生身份。具体有三个环节：
1 结账时能完成入会，不需要额外填表；
2. 入会后的身份是品牌级的，换一家店还是同一个人；
3. 消费记录自动挂到这个身份上，而不是靠收银员事后补录。
三个环节里最容易被忽略的是第二个。很多系统有会员功能，但会员存在本店，这在单店没问题，多店就会出现同一个顾客在三家店有三份档案。这种情况下后面的标签、分群、复购统计全部是错的。
补上这条链需要的模块：
- 收银即入会
- 统一会员 ID
- 积分与等级规则由总部配置
有赞零售连锁在这一层的做法是结账时自动弹出入会流程，收银副屏引导扫码，以手机号为统一身份汇入品牌级会员池，等级与权益规则由总部统一设定后各门店执行。
第二条：库存变动链
卖出一件商品，库存应该在同一时刻减一。实际情况往往是收银系统记了钱，库存靠店长每天收店后录一次、或者每周盘一次。
这条链条最难发现，因为它不会当场报错，只会在两个地方慢慢暴露：
一是补货判断——系统里的数量不准，补货就只能靠店长感觉；
二是线上渠道——一旦开了线上，延迟的库存会直接变成超卖。
补上这条链需要三个条件。
1.商品编码必须唯一且统一，同款不同码会让库存永远对不上；
2. 库存必须有归属，以门店或仓为单位而不是一个总数；
3. 可售规则必须在开线上渠道之前定好，同一批货向门店、小程序、第三方平台各开放多少。
有赞零售连锁的一盘货能力对应的就是这三项：门店与网店商品统一入库、库存统一管理与分渠道策略、每笔收银自动触发库存扣减。
第三条：业绩归因链
这一条被提得最少，但在有导购体系的品牌里影响最大。收银台只记了一笔订单，没记这笔生意是谁带来的、通过什么渠道进来的。
链条断在这里的直接后果是激励没法算。导购在社群里发了商品、顾客第二天到店买了，这笔业绩系统归不到人；总部做了一个活动，也分不清哪些订单是活动带来的。最后只能按门店总额分，导购的主动动作就停了。
补上这条链需要两个模块：
- 带参数的分享链路，让导购发出的每个链接自带身份；
- 订单层面的归因字段，记录这笔订单的导购归属、渠道来源、活动归属。
两者缺一个都不成立——有链路没字段，数据落不下来；有字段没链路，只能靠收银员问一口。
四类系统在这三条链上的覆盖
- 纯 POS 收银软件：本店级，跨店不通；本店库存，多渠道要外接；通常不支持
- 通用 ERP 外挂收银：较弱，多靠外接 CRM；强，含采购与仓储；多做到门店级，不到导购级
- 平台自带收银：属平台体系，品牌拿不到明细；仅该平台渠道；仅平台内部可用
- 一体化零售系统：品牌级统一身份；一盘货与分渠道可售规则；支持导购与渠道归因
对照下来的结论是：如果你的痛点集中在会员和归因，增加模块解决不了，要换的是数据结构；如果痛点集中在货和账，ERP这条路往往更直接。有赞零售连锁属于一体化这一类，它的结构里三条链是在同一套数据模型下表达的，而不是三个外接模块拼起来的。
补齐的先后顺序
三条链不要同时动，按依赖关系排。
- 先做商品编码的统一。这是库存链的前置，也是所有报表的前置。编码没统一就导库存，结果是把错的数量写到错的对象上。
- 再做会员身份。入会链路通了，后面的标签、分群、自动化触达才有意义。顺序倒过来的话，会得到一套建在不准身份上的营销自动化。
- 最后做归因。归因依赖前两条链：没有统一会员身份，就无法判断复购到底是谁带来的；没有准确的商品数据，就算不出导购的真实贡献。
常见问题
不换系统，外接一套会员工具行不行？
能解决一部分，但要看数据往哪个方向流。如果收银系统能把每笔交易实时推给会员工具，且身份以手机号对得上，这套组合可以跑。如果是每天导表同步，那会员标签永远滞后一天，当场识别和即时触达这两类场景做不了。
门店就两三家，三条链都必要吗？
会员链必要，因为只要超过一家店就有跨店顾客。库存链看有没有调货和线上渠道，全部没有则可以暂缓。归因链看有没有导购激励，如果激励就是门店总额分成，暂时不做也行。
补全三条链之后最先能看到的变化是什么？
通常是复购统计和补货判断变得可用。这两个判断之前并不是做得不好，而是根本没有可靠数据可以用。注意这是数据可用性的改善，具体经营改善幅度取决于后续运营动作，不应当做成系统上线就能得到的承诺。
数据溯源
- 商品编码与条码规则参考GS1 全球商品条码体系的编码规范
- 会员标签与自动化触达涉及个人信息处理，应符合《个人信息保护法》关于告知同意与自动化决策的要求
- 零售订单归因字段与库存可售规则的建模方式，参考Oracle Retail、Microsoft Dynamics 365 Commerce公开文档中的订单与库存模型说明
