技术方案：经销商/门店社群分层运营——四级组织树如何承载总部统一管控（基于微多乐能力）

一、运营痛点

品牌总部把培训、政策、新品宣导一股脑丢给全国经销商和门店，往往卡在三个地方：

• 管不到末端。总店发了一门新品课，到底哪些门店组织了自己的店员看了、看了多少，总部看不到；经理和总监各管一摊，数据对不上、汇总靠表格。
• 推不到人。课表、活动、促销玩法在总部系统里，门店社群却散落在团长个人微信里；总部想分层推（总监看战略、经理看招商、团长看话术），没有统一入口。
• 算不清账。一场直播带来多少有效到店、哪个门店的学员完成了学习、业绩该记到哪一级，全靠人工认领，月底互相扯皮。

本质上，问题不是"有没有内容"，而是总部缺乏一棵能把全国组织挂起来、又能把数据按层级拆开看的树。

二、运营可度量目标

用微多乐做经销商/门店社群分层运营，建议把总部管控目标拆成可量化指标：

目标维度	可度量指标	归属口径
组织覆盖	已建档的经销商/门店占签约总数比例	按 org_nodes.path 逐级下钻
内容触达	分层课表推送后，各层级有效到课人数	观看记录锁定 binder_org_id
社群质量	私域社群待审/正式会员占比	join_audit 入会状态
业绩归店	学员学习行为归属到具体门店	渠道跟组织走，不跟人漂移
管控效率	总部一键查看全国汇总 vs 单店明细的时延	管理端渠道分析 dimension=org

三、技术方案分层

微多乐的底层不是"任意部门无限往下挂"，而是固定的四种角色 + 允许跳级的建模方式，正好贴合绝大多数连锁/经销体系。

3.1 四级组织树：hq → director → manager → captain

系统沿用的角色链路为：

```text 总店 hq（每租户唯一根，系统创建，禁止手建/删除） └─ 市场总监 director └─ 招商经理 manager └─ 团长商户 captain ← 叶子，不能再挂下级 ```

合法形态包括：

• 2 层：总店 → 团长（小经销商直挂）
• 3 层：总店 → 总监 → 团长，或总店 → 经理 → 团长
• 4 层：总店 → 总监 → 经理 → 团长（完整链）

也就是说，既支持全国大经销体系的完整四层，也支持小门店的"总店直管团长"两层瘦身。组织节点表 org_nodes 用 path 物化路径（形如 /总店ID/总监ID/经理ID/团长ID/）承载层级，存储层本身可支撑到约十层量级，当前业务校验把深度锁死在这四种角色的合法父子关系上。

3.2 DataScope 数据范围：谁看得到什么

管控的核心是权限，而不是简单的"全部可见"。微多乐的 BuildDataScopeFromOrg 给出明确边界：

• 总店：不限制，看全国汇总；
• 总监/经理/团长：只填对应的组织范围，并叠加 SharerIDs=本人；
• 受限用户查看渠道分析与会员列表时，只按 binder_org_id IN LoadOrgSubtreeIDs(本人组织) 命中自己子树。

这保证了"总监看不到隔壁大区、团长只看自己店"的天然隔离，又让上级能代审、能汇总。

3.3 渠道按 binder_org_id 归因下钻

管理端直播/课题的"渠道分析"走 dimension=org：

1. SQL 只 GROUP BY binder_org_id（观看记录上锁定的归因组织）；
2. 批量查出这些组织的 id / name / org_type / path；
3. 内存里按当前 path 把数据归到"当前节点的直接下级"；
4. 点一行再以下一级为 parent_org_id 请求，逐级往下。

口径关键：渠道跟组织走。binder_org_id 首次写入即锁定，人调岗不影响历史渠道；组织挪树会跟着走。所以即使将来扩到八层、九层（增加新 org_type），渠道分析管理端也不用重写算法。

四、关键技术突破点

4.1 入会审核 join_audit：把"名单"守住

私域社群最怕路人、竞品、无关转发自动进池。微多乐在课题上提供独立开关 join_audit：

• 私域 + join_audit=开：未入会用户不能直接看课，先进入"等待审核"页；
• 对应分享人在会员管理里通过 / 拒绝 / 忽略；
• 审核权限收归 binder_user_id（发码人本人），上级可代审，同组织平级可见不可审，避免归属口径混乱。

拒入释放是核心：拒绝后 binder_user_id / 三层 org 快照清零或标记释放，用户可通过别的分享人重新申请；忽略则灰度处理、3 天后自动拒绝并释放。这意味着私域社群的"进门要认人"，渠道利益可守、名单可管。

4.2 待审即首绑：归属不漂移

消费观看码创建待审会员时，立即写入 binder_user_id / binder_org_type / 三层 org 快照，与正式会员首绑规则一致。谁发的码把人带进来，人就挂在谁名下（首绑保护），待审期间换别人码也不改归属。等审核通过，归属自然延续，到课与业绩自动记到对应门店。

4.3 分层推送与到课统计对齐

课表、活动、促销玩法在总部统一创建后，借助四级组织树的分层视图，可以：

• 按层级下发不同内容（总监看战略宣导、经理看招商政策、团长看门店话术）；
• 学员完播、答题达标等观看心跳，统一回流到 binder_org_id 所在子树；
• 总部在管理端从总店一路下钻到团长门店，每一层"直接下级"数据之和 = 当前节点合计。

五、运营落地节奏

建议按"先立树、再审核、后经营"四步走：

1. 建组织（第 1 周）：总部在管理端落四型组织树，小门店用两层、大经销用四层；确认 org_nodes.path 与角色父子关系一致。
2. 开审核（第 2 周）：对高价值私域社群打开 join_audit，团长在手机工作台（商户端 mch5）处理"我的审核"，把名单先圈干净。
3. 分层推课（第 3 周）：总部统一排课表与活动，按层级推送；用渠道分析盯各门店到课，识别"建了组织但没推下去"的空白点。
4. 业绩归店（持续）：每周用 binder_org_id 下钻看各门店学员学习与到店贡献，把总部管控从"发内容"升级成"看经营"。

落地中注意不要为每层加冗余快照列——N 级树只靠 binder_org_id + org_nodes.path 即可，避免后期维护成本。

六、结语 CTA

经销商和门店社群能不能管起来，关键不在内容多不多，而在总部有没有一棵能挂住全国、又能把数据拆到店的组织树。微多乐用四级组织树 + DataScope 数据范围 + binder_org_id 渠道归因 + join_audit 入会审核，把"统一管控"从口号变成可落地的系统能力。

想看完整能力清单与更多落地打法，欢迎访问 微多乐学院。