闽豪商贸 · 会员中台

统一会员打通方案

把企业微信、微盟、三套 ERP 里四份互不相认的客户数据，合成一个人、一张卡、一套等级——覆盖山东 18 家专柜与线上商城。

版本
v3 · 2026-09-21（在 v2.0 方案与执行手册基础上重构，含技术评审修正）
数据基线
微盟侧 API 实测 2026-09-17
状态
待拍板 D1 / D4 / D5 / D6，之后 P0 可立即启动
Layer 1

全局

给老板的五分钟：问题是什么、打算怎么办、需要你定什么。

一页纸

四句话说完整个项目。

一件事

同一个顾客，在企微里是导购的好友、在微盟里是一张会员卡、在 BOY LONDON 的系统里是一条消费记录——三处互不相认。这个项目就是把这三条记录认成一个人，并给这个人一个通用等级。

一个名字

对外统一为「山海集」——山（山东大本营）× 海（闽，福建根源）。商城叫山海集潮选，积分叫海贝，等级从山麓卡到山海尊享卡，导购叫山海顾问。D1 待定

一条路

以手机号为唯一主键做去重，企微好友经领卡授权入池、自有 ERP 走接口、品牌方 ERP 走月度导出；合并后统一算成长值、发等级、驱动复购。

一句实话

35,776 个「客户」里，消费满 100 元的只有 3,529 人。这个项目真正要做的不是把池子做大，是把这 3,529 变成 10,000。池子大小是口径，不是生意。

现状：四个池子，互不相认

这不是「数据没打通」的技术问题，是同一个顾客在公司内部有四个身份、谁也回答不了「他到底消费了多少、该是什么等级」。

Pool 01 企业微信 50,000 外部联系人，握在 18 家店的导购手里。与微盟完全不通。口径待验
Pool 02 微盟 CRM 35,776 客户总数；其中已领卡成为会员 19,324。积分、储值、券在这里，是全公司唯一一套已经通用的资产。
Pool 03 自有伯俊 ERP 可控 雷克狮途等自有品牌。闽豪自己掌控，可做接口级对接。
Pool 04 品牌方 ERP 不可控 BOY LONDON 走品牌方伯俊，sprayground 走品牌方未知系统。闽豪无系统权限，只能谈导出。
用户提出的根本约束：系统自带的 CRM 与账号体系不对外通用

微盟的会员主档、积分账户、等级引擎都锁在微盟生态里，对外没有企业级 SSO，也不承诺把身份图谱交还给商户；伯俊与品牌方系统同理。这意味着任何一个平台都不能当作闽豪的唯一身份中心——把所有鸡蛋放进微盟，换供应商那天，打通出来的会员图谱归零。方案因此改为「双中心」：微盟负责权益执行，闽豪自控的映射主表负责身份归属。详见 目标架构 与 R1。

目标架构

五层，从四池分立到一个人。与 v2.0 的关键差别是第四层多了一个盒子——闽豪自己那张表。

A · 数据源 — 四池分立，互不相认 企业微信 50,000 外部联系人 · 导购持有 微盟 CRM 35,776 客户 / 19,324 会员 自有伯俊 ERP 雷克狮途等 · 可控 品牌方 ERP BOY 伯俊 / SG 未知 · 无权限 B · 接入 — 三路流水线 第一路 · 企微绑定（持续运营） 渠道活码 → 欢迎语领卡 → 授权手机号 → 绑 wid 第二路 · 接口对接 WING3/R3 标准连接器 第三路 · 月度批量 导出 → 清洗 → 导入 / 手工补录 C · 身份解析 — 去重合并 手机号 = 主键　·　unionid = 辅助　·　wid = 会员主档 ID 消费额跨来源求和　·　积分以微盟账户为准　·　等级合并后重算　·　标签取并集并打来源标 D · 双中心 — 权益执行与身份归属分开放 微盟会员中台 — 权益执行 wid 主档 · 积分「海贝」· 储值 · 券 · 等级引擎 四级卡面 · 小程序会员中心 · 营销自动化 跑得起来，但拿不走 闽豪 ID 映射主表 — 身份归属 手机号哈希 ↔ wid ↔ external_userid ↔ ERP 会员号 来源 · 首末次消费 · 归属门店/导购 · 变更留痕 新增 · 落在已定的闽豪集成层（Go + PostgreSQL） E · 应用 — 一个会员走遍全品牌 企微 1v1 与分层召回 山海集潮选小程序商城 门店开单 — 受限，见 R5 会员分层看板与月报

架构 v3。相对 v2.0 的两处改动：① D 层由「微盟为唯一中心」改为双中心，新增闽豪自控的 ID 映射主表；② E 层标出门店开单是受限环节而非已通环节。

需要老板拍的四件事

其余八项决策可以边做边定，这四项不定，P0 就启动不了。

#要定什么建议不定的后果
D1品牌新名是否用「山海集」用，过渡期落款「山海集 · 闽豪商贸」小程序、卡面、门店物料全部停摆
D4会员口径以哪个数为准（25k / 19,324 / 35,776）先对账，大概率落 35,776去重基数是错的，后面所有指标都不可信
D5BOY / SG 的会员数据能否拿到按「联营数据共享」谈按月导出，不成降为只要汇总占门店大头的两个品牌成为数据黑洞
D6自有伯俊 ↔ 微盟对接是否立项采购走微盟服务市场买授权，但先要接口清单（见 R7）自有品牌的消费数据继续靠手工导
这四项之外，还有一件不需要拍板但必须立刻做的事

「山海集潮选」小程序名立即查重占名（D2）。小程序名全网唯一、先到先得，被抢注就得重做整套命名。这件事成本为零，拖延的代价不可逆。

Layer 2

打法

给运营与 IT 的：分几路做、做成什么样、按什么节奏、谁来定。

三路打通

四个池子的可控程度完全不同，所以不能用一种办法。三路并行，共用同一个主键与同一套合并规则。

Route 01 · 持续运营
企微 50k 绑定
工作量最大、决定项目成败的一路。本质是运营动作，不是技术动作。
  1. 渠道活码矩阵铺到 18 店 × 每个导购，配柜台立牌与收银话术
  2. 好友通过后欢迎语自动推领卡卡片
  3. 顾客授权手机号 → 命中微盟已有 wid 即绑定去重
  4. 未命中 → 自动注册新 wid，纯增量
  5. 存量 5 万好友按活跃 / 沉默 / 流失分层，导购 1v1 召回
产出：绑定率按门店与导购的周报，纳入导购 KPI。
Route 02 · 一次性 + 持续
自有伯俊 ERP
唯一一路能做到接口级自动同步的，因为系统在自己手里。
  1. 伯俊导出会员档案：手机号、累计消费、积分
  2. 按手机号匹配微盟 wid，命中即并入主档
  3. 未命中批量建档，来源标记＝伯俊
  4. 采购 WING3 / R3 ↔ 微盟标准连接器，打通订单与库存
  5. 联调验收后转为常态同步
前置：D6 采购决策；采购前先确认会员档案在不在对接范围（R7）。
Route 03 · 周期性手工
品牌方 ERP 回灌
没有技术捷径。这一路的瓶颈是谈判与法务，不是接口。
  1. 与 BOY LONDON / sprayground 谈数据共享条款（D5）
  2. 品牌方按月导出消费流水
  3. 清洗为微盟导入模板，批量补录
  4. 手机号匹配 wid，合并成长值
  5. 拿不到导出的门店：导购按 SOP 手动补录
合规前置：跨法人主体提供个人信息，须走 PIPL 第 23 条（R6）。

会员体系

一套名字从品牌一直贯到积分，四级等级全品牌通算。核心承诺是一句话：等级通用，礼遇分品牌。

V1山麓卡 成长值 0
  • 消费积分 1:1
  • 生日券
V2山岳卡 成长值 1,000
  • 积分 1:1.2
  • 免费改衣
  • 新品优先购
  • 升级礼 50 元券
V3海纳卡 成长值 5,000
  • 积分 1:1.5
  • 专属导购
  • 免费顺丰
  • 升级礼 150 元券
V4山海尊享卡 成长值 20,000
  • 积分 1:2
  • 私享会
  • 跨品牌免费干洗
  • 升级礼 500 元券

成长值怎么算

成长值 ＝ 累计消费金额（元）× 1 ＋ 行为加分。消费不分品牌、不分渠道，全部通算——这是「一个会员走遍全品牌」唯一的落点。

消费 1 元（任意品牌 / 渠道）+1
注册 / 领卡+50
添加企微好友+50
完善资料（生日等）+30
每日签到+2
评价 / 晒单+10

保级：等级有效期 12 个月滚动评定。存量会员初始化时就高保护 12 个月（D8），避免老客户一夜降级引发投诉。

命名体系

山 ＝ 山东大本营，海 ＝ 闽（福建）根源。一套意象贯穿品牌、商城、等级、积分、导购称谓。

品牌主名山海集 SHANHAI COLLECT
商户展示名山海集 · 闽豪商贸（过渡期）
商城小程序山海集潮选 待查重
会员中心山海集会员中心
门店命名山海集 · {城市}{商场} {品牌}专柜
会员统称山海会员
积分名海贝
储值名山海余额
导购身份山海顾问
会员日每月 8 日「山海日」
上线前必须定版：两份文档的等级名称不一致

《打通方案 v2.0》写的是 V1 山海卡 / V4 巅峰卡，《执行手册》写的是 V1 山麓卡 / V4 山海尊享卡。本页采用执行手册版本（时间更晚，且与整套命名自洽）。卡面设计、小程序文案、导购话术全部挂在这个名字上，改一次全套返工——请在 P4 启动前书面定版。

路线图

五个阶段，约 12 周到等级体系上线。P1 是主战场，P3 从第 8 周起常态化运转。

阶段 W1W2W3W4W5W6 W7W8W9W10W11W12
P0 口径对齐基础
对账 · 清洗 · 定模板 · 拍 D1/D4对账 · 清洗
P1 企微绑定放量主战场
活码矩阵 · 欢迎语领卡 · 5 万好友分层召回 · 导购 KPI活码矩阵 · 领卡链路 · 5 万好友召回
P2 自有伯俊对接接口
首导会员档案 · 采购授权 · 订单通与库存通联调
P3 品牌方回灌持续
谈条款 · 月度导出清洗导入 SOP · 手工补录兜底 →
P4 等级体系上线收口
P2 后 2–4 周P2 后
各阶段关键动作： P0 对账 25k / 19,324 / 35,776 三个口径、手机号去重清洗、制定 ERP 导入模板、拍板 D1/D4/D5/D11、小程序名查重占名。 P1 配置 18 店 × 导购的渠道活码矩阵、欢迎语领卡与手机号授权链路、5 万好友分层召回、导购 SOP 与 KPI、绑定率周报。 P2 自有伯俊首导会员档案、采购 WING3/R3 ↔ 微盟对接授权、订单通与商品库存通联调验收。 P3 与 BOY / SG 谈数据共享条款、月度导出—清洗—导入 SOP、无法导出门店的手工补录流程。 P4 成长值初始化与就高保护、四级卡面与权益页上线、海贝与山海日活动、会员分层看板。

P4 落在 P2 完成之后 2–4 周，因为成长值初始化依赖合并后的累计消费额；在数据没并完之前发等级，等于按错误基数给客户定身份。

决策清单 · 12 项

前四项标红，决定项目节奏；其余八项可在对应阶段前定。

#决策点建议决策人需在
D1品牌与店铺新名是否采用「山海集」采用，含过渡期双名并示老板P0 启动前
D2小程序名注册（山海集潮选）立即查重占名，避免抢注运营立即
D3商城结构：一套通店 vs 每品牌独立网店单商城多品牌分区，品牌专区做视觉区分运营 + ITP2 前
D425k / 19,324 / 35,776 以哪个为准先对账，对完大概率用 35,776数据 + 运营P0 第 1 周
D5品牌方（BOY / SG）会员数据能否导出按「联营数据共享」谈按月导出，不成降为只要汇总老板 + 品牌 BDP0–P1
D6自有伯俊与微盟对接是否立项采购服务市场买授权，先索取接口清单IT + 财务P2 前
D7是否引入 iPaaS 中间件系统 ≤ 3 用点对点，扩展再上ITP3
D8存量会员等级初始化策略就高保护 12 个月，避免投诉运营P4 前
D9V3 / V4 高成本权益预算先用低成本权益上线，跑数据再加码财务 + 运营P4 前
D10企微召回方式与合规导购 1v1 ＋ 公众号为主；短信外呼需法务确认运营 + 法务P1 前
D11会员协议补充「多品牌数据互通」条款补充并全量告知；跨主体部分另见 R6法务P0 前
D1218 家门店是否统一改名线上全统一，门店门头受商场约束不强求运营 + 门店P2
Layer 3

细节

合并规则、对 v2.0 方案的八条评审修正、指标口径、合规红线。这一层是给执行和法务看的。

合并规则

同一手机号出现多条记录时，逐字段怎么并。这张表要在 P0 就定死，否则每批导入的结果都不一样。

字段规则为什么
累计消费额取各来源之和跨品牌消费都要算，这是「一个会员走遍全品牌」的定义本身
积分以微盟积分账户为准；ERP 侧积分按 1:1 折算一次性并入积分是能当钱花的负债，必须单一账本，不能两边各记一份
等级合并后按新体系重算，不就高重算是为了口径统一；老客户的保护由「初始化就高保护 12 个月」单独兜（D8），两件事分开
会员标签取并集，并打来源标（微盟 / 企微 / BOY / SG / 雷克狮途）来源标是事后追溯和分品牌运营的唯一抓手，丢了就补不回来
一人多号以最近消费的号为主号，其余挂附属最近消费号最可能是当前在用的手机号

技术评审 · 八条修正

对 v2.0 方案与执行手册的逐条复核。R2 和 R5 是其中最该先看的两条——一条可能大幅省掉 P1 的工作量，一条是方案目前最大的落地漏洞。

R1
微盟不能是唯一中心
架构 · 用户提出 · 已并入 v3 架构图

v2.0 把微盟 CRM 定为「唯一会员数据中心」。但微盟自带的 CRM 与账号体系对外不通用：没有企业级 SSO，会员主档与身份映射关系锁在平台内。一旦更换供应商，打通出来的身份图谱不跟着走，等于重做。

对策：在已经定下的闽豪集成层（Go + PostgreSQL + Docker Compose）里建一张 ID 映射主表——手机号哈希、wid、external_userid、各 ERP 会员号、来源、首末次消费、归属门店与导购。每日从微盟与企微增量拉取写入。成本是一张表加一个定时任务，但这是唯一一份闽豪自己拿得走的会员资产。微盟负责权益跑起来，这张表负责身份是我们的。
R2
打通可能不必全靠「授权手机号」——P0 第一周就去验
技术路径 · 若成立可大幅压缩 P1 工作量 · 含两个待实测前提

v2.0 的结论是「不能导出撞库，只能靠欢迎语领卡授权手机号逐个绑」。这个结论来自 external_userid → unionid 的批量转换被限制——但那是反方向。

反过来的 unionid → external_userid 接口仍然开放：按企微官方文档，企业主体额度为 10 万次/小时、48 万次/天、750 万次/月，单次最多查 100 个；已经是好友的返回 external_userid，尚未加好友的返回 pending_id（90 天有效）。也就是说，只要能拿到微盟侧会员的 unionid，一次跑批就能得到「微盟 35,776 人里哪些已经是我们企微好友」的完整重叠图——召回名单从「盲发 5 万」变成「精准打没重叠的那部分」，同时立刻知道真实重叠率。

两个前提必须实测，我没有验证：① 微盟开放接口是否返回会员 unionid；② 微商城小程序 / 公众号主体与企业微信主体是否在同一微信开放平台主体下（官方要求主体名称一致）。两条任一不成立，这条路就走不通，退回原方案。验证成本约一天，收益是 P1 的工作量级，值得放在 P0 第一周。
R5
最大的落地漏洞：结账那一刻
运营 · 方案未覆盖 · 不解决则等级体系上线即空转

v2.0 的应用层写了「门店 POS 开单」，但 BOY LONDON 走品牌方伯俊、sprayground 走品牌方未知系统——占门店大头的两个品牌，收银系统不在闽豪手里。这意味着「积分 1:1.5」「免费改衣」这类等级权益，在专柜开单的那一刻没有任何技术手段自动生效。

现实只有两条路：(a) 权益兑现全部收口到微盟侧——券、积分、小程序核销，POS 只认价格不认等级；(b) 收银时导购在企微侧边栏手工记一笔，事后回灌补积分。

结论：两条路都重度依赖导购的现场执行。所以导购 SOP、话术与 KPI 是这个项目的主实施项，不是配套项；技术只能把工具递到导购手上，递不到顾客手上。建议把「结账动作」单独立为 P1 的一条验收标准：单店试点跑通「报手机号 → 导购操作 → 顾客当场看到积分到账」的完整闭环，再铺 18 家。
R3
「统一池 ≥ 40,000」是虚荣指标
指标 · 建议替换北极星

35,776 个客户里，消费满 100 元的只有 3,529 人，占比 9.9%。换句话说约九成「会员」从未产生有意义的消费。把「六个月统一池 ≥ 40,000」当北极星，衡量的是数据库行数，不是生意。

建议：北极星换成「可触达且近 12 个月有消费的会员数」（基线 3,529）与「跨品牌消费人数」（基线待建）。40,000 保留为口径指标，用于验证打通进度，不进 KPI。
R4
50,000 这个数也要进对账表
口径 · P0 一次全量拉取即可定论

25k / 19,324 / 35,776 三个口径已经在对账，但 50,000 被直接当成了事实。企微后台的「客户数」在不同口径下可能是客户—导购关系条数而非去重人数：同一顾客被三个导购添加，是一个 external_userid、三条关系。按 external_userid 去重后的真实人数可能明显低于 5 万。

对策：P0 做一次 externalcontact/list 全量拉取，按 external_userid 去重计数，把结果和另外三个口径放进同一张对账表。目标基数错了，P1 的召回计划和绑定率分母全错。
R6
品牌方数据回灌是法律问题，不是导出问题
合规 · 需法务前置 · 含一处定性更正

方案把 BOY / SG 的数据获取当成「谈判 + 导出模板」。但两者是独立法人主体，把它们系统里的会员个人信息交给闽豪，属于《个人信息保护法》第 23 条「向其他个人信息处理者提供个人信息」，需要向个人单独告知并取得单独同意——不是在自家会员协议里补一条就能覆盖的。

另有一处定性需要更正：方案称「手机号属于敏感个人信息」。PIPL 第 28 条列举的敏感个人信息并不包含手机号（GB/T 35273 的个人敏感信息示例表里有，但那是推荐性国标，不是 PIPL 的定性）。这个差别直接决定要不要走「单独同意」流程，建议让法务按 PIPL 口径重述，不要按错误定性去设计流程。

更干净的做法是从源头改：专柜现场收集时就让闽豪成为收集方，一次授权覆盖「山海集全品牌」，新客从此合规入池；存量部分做多少、以什么形式做，交法务判断。这条不解决，P3 整条路线在合规上是悬空的。
R7
D6 采购前，先确认「会员」在不在对接范围
采购 · 一个询价动作即可澄清

已核实的伯俊 WING3 / R3 ↔ 微盟对接，公开口径是订单通、商品库存通。方案据此推出「自有伯俊可会员 API 双向同步」——这跨了一步。订单与库存连接器不必然携带会员档案。

对策：D6 落单前，向微盟服务市场与伯俊各要一份接口清单，明确三件事：会员档案是否双向同步、积分与成长值是否在同步范围、冲突时以哪边为准。否则可能买到一个「订单通了、会员还是手工导」的方案，而会员才是这个项目的标的。
R8
三个身份平面别混，离职回收是交叉点
身份 · 与已在推进的统一身份轨道对接

会员身份（手机号 / unionid / wid）、员工身份（企微 ＋ 已定的托管 Entra）、系统账号（微盟商户后台、伯俊账号）是三套东西，互不通用，不要在同一张图里混谈。

与 CRM 直接相关的风险是离职回收：导购离职时，企微侧有「客户继承」可以把客户迁走，但微盟商户后台没有企业 SSO，账号必须手工停用。漏掉一个，就是一名离职导购长期保留着全量会员明细的查询权限。

对策：把「微盟后台账号 / 企微导购身份 / 渠道活码归属」三项，直接并进已有的离职回收清单，和办公 IT 的离职流程同一张表走。

指标

保留原方案的五项北极星，按 R3 的意见调整了权重：前三项是过程指标，后两项才是生意指标。

指标现状基线3 个月6 个月性质
企微绑定会员数近似 0≥ 8,000≥ 20,000过程
企微添加率（新会员）~0%≥ 30%≥ 50%过程
统一会员池规模（去重后）未打通完成 P0 清洗≥ 40,000口径，不进 KPI（R3）
近 12 个月有消费的会员数3,529建立监测翻倍为目标建议新增北极星
跨品牌消费会员占比未统计建立基线≥ 8%生意
会员复购率未统计建立基线+15%生意

「近 12 个月有消费的会员数」的 6 个月目标建议在 P0 对账完成、确认真实基数之后再定具体数字，现在给一个翻倍的方向即可。

合规红线

四条，任何一条踩了都不是罚款问题，是接口被封或项目推倒重来。

  • 严禁批量调用 external_userid → unionid 转换接口撞库。这是 2022 年 6 月明确的限制，违规封禁接口权限——封的是整个企业的能力，不是某个应用的。R2 里说的是反方向的接口，两者不要混。
  • 跨法人主体提供个人信息须走单独同意。PIPL 第 23 条。品牌方回灌（P3）整条路线以此为前提，见 R6。
  • 多品牌数据互通须在会员协议中明示并公示。D11，P0 前完成，且建议全量告知而非只告知新会员。
  • 短信外呼召回需法务确认后再用。D10。导购 1v1 与公众号引导是安全路径，外呼是风险路径，不要为了赶 P1 的绑定率指标把它先开起来。

口径与来源

数据基线

微盟商户后台接口实测，2026-09-17。商户：闽豪商贸Fashion。

35,776客户总数
19,324已成为会员
3,529消费 ≥100 元
104本月新增客户

抽样观察：最近 20 位新会员 100% 未添加企微好友，且多数为普卡、无消费——企微导流环节目前完全未运转，这也是 P1 被列为主战场的原因。

本页内容的出处

  • 业务事实、命名体系、等级设计、12 项决策、21 项 TODO、北极星指标 —— 来自《闽豪统一会员打通方案 v2.0》（2026-09-18）与《闽豪会员项目执行手册 v1.0》（2026-09-18）。
  • 数据基线 —— 微盟接口实测（2026-09-17）。
  • 企微接口额度与 pending_id 机制 —— 企业微信开发者文档「unionid 与 external_userid 的关联」，文档标注最后更新 2025-11-17。
  • 八条评审修正（R1–R8）为本次复核新增，其中 R1 源自用户提出的「系统自带 CRM 与 IAM 无法跨平台通用」约束。
  • 未经验证、标注为待实测的两项：微盟接口是否返回会员 unionid；小程序与企微是否同主体。见 R2。

闽豪商贸 · 统一会员打通方案 v3 · 2026-09-21 ｜ 三层结构：全局给决策、打法给执行、细节给技术与法务。
本页为方案载体，不含任何 API 凭证。「山海集」全套命名以 D1 拍板为准，等级名称以 P4 启动前的书面定版为准。