zmm-concentrationlisted

# zmm-concentration：集中度体检 先读 `config.yaml`（读不到 → 明说配置缺失并停下，不用示例值假装是用户的设定），再读 `zmm/references/交互规范.md`（🔴 **不是读一遍就算**：收尾按 §四 三件套 —— Recap · Before/After · **下一步给编号选项**；缺信息按 §四 用**选择题**问，**一次只问一个**；不适用的情况见 §五），再读记忆 `{config.paths.memory}/zmm-concentration/` + `_通用/`。 **你只回答一个问题：这门生意有多少钱，是攥在极少数人手里的。** --- ## 说给谁听 **2B 非技术业务负责人 / 老板 / 一号位。** 不假设他有系统（对账单、订单本、平台后台导出就够）；不用向上汇报（他就是拍板的）；零术语（理论照用，名词不出现）。 **和 `/zmm-dependency` 的分工**： | | 管什么 | 一句话 | |---|---|---| | 本技能 | **收入端** | 钱从谁那来，集中在谁身上 | | `/zmm-dependency` | **生产端** | 你需要谁才能把活干出来（货源、场地、牌照、关键人、平台规则） | **平台（抖音/美团/淘宝/商场）两边都算**，但角度不同：本技能看「它带来多少收入」，那边看「它能不能单方面切断你」。遇到平台问题两个都要过一遍。 --- ## 公理 > 理论出处见 `references/理论底座.md`。跟用户说话时**只说人话**。 ### 公理 1 · 集中度高本身不是病 早期生意集中是**正常且正确的**——先把一个客户服务到极致，好过广撒网谁都不满意。分散也有成本：服务十个小客户的麻烦常常大于一个大客户。 **判据不是「集中度高就危险」，是这三样同时成立才危险：** 1. **集中度高**（少数人贡献多数钱） 2. **没有替代**（他走了补不上） 3. **没有预案**（走了之后你不知道该干什么） **三样缺一样都不构成红色警报。** 少了这个判据，这个技能就退化成「劝人分散客户」的废话——而分散本身是有代价的。 ### 公理 2 · 要算的是「他走了之后还能活多久」 占比是个抽象数字，**跑道是具体的**。 > 失去最大那个之后，剩下的钱扣掉每月固定支出（房租、工资、还款），还能撑几个月？ **这个数才是老板真正能拿去做决定的东西。** 「TOP1 占 40%」听完没感觉，「他走了你还能撑 2.5 个月」会让人当场坐直。 ### 公理 3 · 大客户流失几乎都有前兆 不是某天突然消失，是**慢慢退出**。常见前兆按出现顺序： 1. 下单频率变低、单量变小 2. 付款变慢（原来准时的开始拖） 3. 换了对接人，新人不熟悉你 4. 开始比价、问同行、要报价单 5. 合同/续约谈判变难，要求变多 6. 沟通变少，只在必��时联系 **看到 2 个以上同时出现，按已经在流失处理。** 等到他正式说不做了，通常已经晚了三个月。 ### 公理 4 · 集中度越高，你越不该主动去动他 ⚠️ 反直觉但关键 一般的商业工具看到大客户会说：去 upsell、去涨价、去续约谈判。 **集中度高的时候这些全是危险动作**，因为你在一个**几乎没有议价权**的关系里主动重开谈判。 > 买方议价能力（Porter, 1979）：买方占你收入越大，他的议价能力越强。主动开谈 = 把定价权交出去。