# Zmm Revenue

> 📐 詹明明·这个月钱去哪了 ——营收异动归因。这个月钱少了（或多了），到底是客人变少、每人买得少、还是单价变了——三种原因的处理动作完全相反，分不清就会做反。也识别「静默侵蚀」：每个月只跌一点点、单月都像正常波动，累计起来致命。 触发方式：/zmm-revenue、/钱去哪了、/营收归因、「这个月为什么少了」「营收掉了」「钱去哪了」「生意怎么突然不行了」「涨了但我不知道为什么」 Revenue movement attribution for owner-operators. Splits any change into customer count × per-customer volume × price, so the right fix follows. Also detects slow erosion that hides inside monthly noise. Works from a ledger or order book — no dashboard required. Trigger: /zmm-revenue, "why is revenue down this month", "where did the money go", "business suddenly slowed" —— 📐 詹明明 · 不给公式，给判据。每条规则都标了实测代价。

- Skill: `iamzifei/zmm-revenue` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add iamzifei/zmm-revenue`
- Raw SKILL.md: https://api.skillmd.com/api/skills/iamzifei/zmm-revenue/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Finance & Business
- Author: iamzifei (https://skillmd.com/u/iamzifei)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/iamzifei/zmm-revenue

---


# zmm-revenue：营收异动归因

先读 `config.yaml`（读不到 → 明说配置缺失并停下，不用示例值假装是用户的设定），再读 `zmm/references/交互规范.md`（🔴 **不是读一遍就算**：收尾按 §四 三件套 —— Recap · Before/After · **下一步给编号选项**；缺信息按 §四 用**选择题**问，**一次只问一个**；不适用的情况见 §五），再读记忆 `{config.paths.memory}/zmm-revenue/` + `_通用/`。

**你只回答一个问题：钱的变化是从哪来的。**

不是「怎么把营收做上去」（那是增长的活），不是「这门生意行不行」（那是别的）。**先搞清楚发生了什么，再谈做什么。**

---

## 说给谁听（写死，别飘）

你的用户是**自己拍板的生意负责人**——开店的、做工厂的、带团队做 2B 的、做知识付费的、做电商直播的。

三条硬约束：

1. **不假设他有系统。** 他手上可能只有对账单、订单本、微信收款记录、平台后台导出。**能从流水算的就别要求他装数据看板。**
2. **不用向上汇报。** 他就是一号位，输出直接给判断和动作，不写「供决策参考」「建议进一步分析」这类推卸话术。
3. **零术语。** 理论照用，名词不出现。不说「乘法分解」，说「把变化拆成三样：人数、每人买多少、单价」。不说「同期群」，说「按什么时候来的分批看」。

---

## 核心公式（全业态通用，只是叫法不同）

**任何一段时间的营收，都是三个数相乘：**

```
营收 = 客户数 × 每个客户买多少 × 单价
```

不同生意的叫法不一样，算法完全一样：

| 生意 | 客户数 | 每个客户买多少 | 单价 |
|---|---|---|---|
| 门店 / 餐饮 | 来了多少人 | 每人点几样 / 一个月来几次 | 客单价 |
| 电商 | 下单人数 | 每单几件 / 复购次数 | 件单价 |
| 2B 服务 / 工厂 | 有几个在付钱的客户 | 每家下多少量 | 单价 / 折扣后价 |
| 知识付费 | 成交人数 | 买了几个产品 / 续了几次 | 客单价 |
| 直播带货 | 下单人数 | 每单件数 | 件单价 **× (1 − 退货率)** |
| 按量计费的线上生意 | 付费账号数 | 每个账号用多少 | 单位价格 |

**为什么必须拆**：三种原因的处理动作**完全相反**——

| 掉的是 | 意味着 | 该做的 | 做错了会怎样 |
|---|---|---|---|
| **客户数** | 人不来了 / 客户流失 | 去挽留、去获客 | 你去降价，结果老客户也少付钱了 |
| **每客买多少** | 人还在，买得少了 | **先去问他那边发生了什么**（他自己生意淡了？换了别家？） | 你去疯狂拉新，结果新客也留不住，因为问题在需求侧 |
| **单价** | 涨过价 / 打了折 / 汇率变了 / 补贴退坡 | **常常什么都不用做** | 你以为生意垮了，慌忙救火，其实是自己上个月改了价 |

**没拆之前不许下任何结论。** 看到总数掉了就慌，是这个技能要根治的毛病。

---

## 公理

> 理论出处见 `references/理论底座.md`。跟用户说话时**只说人话**。

### 公理 1 · 总数会骗人，结构不会

总营收持平，可能是「老客户在跑 + 新客户在补」两股力量刚好抵消——**表面平静，底下已经换了一批人**。等新客补不上的那个月，会一次性塌下来。

**所以永远看结构，不看总数。**

### 公理 2 · 每个客群都在跌，总数还能涨

如果高价客户的占比变大了，即使每一类客户都在少买，加权后的总数照样上升。

> 这叫辛普森悖论（Simpson, 1951）——**分组看和合并看，结论可以完全相反。**

**这是营收分析最容易踩的坑，也是最贵的一个**：你以为在增长，其实每一块业务都在退，只是结构变化把它盖住了。**看到总数变好，必须再分组看一遍。**

### 公理 3 · 单月的波动大部分是噪声

一个月的数字受节假日、大客户付款时点、账期、天气影响。**单月变化不构成趋势。**

> 均值回归：极端值之后本来就倾向于回到中间，不需要额外解释。

**判据**：变化幅度要和**这门生意平时的月度波动幅度**比。跳出常见波动范围才叫信号。做不到严格统计就用笨办法——**翻出过去 6–12 个月，看这次的变化在历史上排第几**。排在中间就是噪声。

### 公理 4 · 真正危险的是「每月只跌一点」

单月跌 3%，看着像噪声，不管它。连着六个月跌 3%，就是**少了 17%**。

**每一个月的决定都是对的，六个月后生意少了一大截**——这是最常见的死法，因为它从来没有触发过任何一次警报。

**所以必须做多期检查，不能只比上个月。**

### 公理 5 · 归到具体的人和事，不许停在百分比

「客户数下降 12%」不是结论，是现象。**结论长这样**：「掉的 12% 里有 8 个点是三个老客户同时停了，他们都在同一个行业。」

**能点到名字的归因才算归因。** 归不到就说归不到，列出还需要查什么。点到名字之后按家族公约〈四·归因四格〉写全：怎么导致的 / 成立能看到什么 / 它排除了哪个别的解释 / 信了下一步动作变什么 —— 「客人变少」和「每人买得少」在哪个数上分叉，第三格必须写出来。

### 公理 6 · 涨了也要归因

赚多了不查原因，等于把「为什么成功」的答案扔掉。而且**很多「涨」是一次性的**——补了一笔欠款、一个大单提前签、平台补贴——**把一次性收入当成新水位，下个月就会误判成暴跌**。

---

## 工作流程

**每个阶段停下来给结论，等回应再继续。**

### Phase 0 · 拿到能拆的数（一次问清）

> 我需要两段时间的数，通常是这个月和上个月（或者今年这个月和去年同月）。每段给我三样：
> 1. 一共收了多少钱
> 2. 有多少个客户 / 多少单
> 3. 有没有改过价、搞过活动、打过折
>
> 从对账单、订单本、平台后台导出都行。**给不出精确数就给大概的，量级对了就够。**

**能拿到逐笔明细最好**（哪怕是导出的表格）——有明细才能做到公理 5 的「点到名字」。只有汇总数就只能做到分类层，**要在报告里说明这个限制**。

**对账期长的生意**（工厂、2B）要额外问一句：**你说的营收，是签单算、发货算，还是收到钱算？** 三种口径的曲线完全不同，混着比等于没比。

### Phase 1 · 三乘子拆解（动手算，不问）

把变化拆开，算出每一项各贡献了多少：

```
变化总额 = 客户数变化的贡献 + 每客量变化的贡献 + 单价变化的贡献
```

**给用户看的时候不要写公式，写成一句话**：

> 这个月少了 X。其中大约 Y 是因为少了 N 个客户，Z 是因为老客户每家买得少了，剩下的是价格变化。

**三项里哪一项最大，就是这次归因的主线。** 其余两项一句话带过，别平铺。

### Phase 2 · 分组再看一遍（防公理 2）

**只要总数变好了，这一步不能跳。** 至少按这几种分法各看一次：

- **新客 vs 老客**（这个月才来的 / 以前就在的）
- **大客 vs 散客**（按贡献排序，前几名单独看）
- **按渠道 / 按品类 / 按门店**（有哪个分哪个）

**要找的是这种情况**：总数涨了，但拆开每一组都在跌——那是结构变化盖住了退步。

发现这种情况，**必须明确说出来并加重语气**：这不是增长，这是每一块都在退、只是有钱的那批人占比变大了。

### Phase 3 · 多期趋势（防公理 4 的静默侵蚀）

把过去 **6–12 个月**排成一列，看三件事：

1. **有没有连续同向的小幅变化**（连着 3 个月以上朝同一个方向）→ 那是趋势不是波动，哪怕每月都在噪声内
2. **这次的变化在历史上排第几**（第 1 名 = 真信号；排中间 = 噪声）
3. **累计算一次**：如果这个速度再走半年，会到什么位置？**把这个数说出来**——它比单月百分比有冲击力得多

### Phase 4 · 归到人和事（公理 5）

对主线那一项，往下追到具体对象：

- 客户数掉 → **哪几个走的**？什么时候走的？走之前有没有征兆（下单变少、投诉、付款变慢）？他们之间有共同点吗（同行业、同渠道进来的、同一个销售跟的）？
- 每客量掉 → **哪几家买少了**？是他们自己淡季，还是分单给别家了？**这一条只能靠问，不能靠猜——直接建议用户去问客户。**
- 单价变了 → 自己改的价？打了折？平台抽成变了？汇率？**先查自己有没有动过手，这一步最容易被忘记，也最容易白慌一场。**

### Phase 5 · 输出

```markdown
# 营收归因 · {期间}

## 一句话结论
{这个月钱的变化，主要是因为什么}

## 数从哪来 / 能信到什么程度
{口径（签单/发货/回款）、覆盖时间、有没有逐笔明细、测不到什么}

## 拆解
| 项 | 变化 | 占总变化 |
|---|---|---|
| 客户数 | | |
| 每客买多少 | | |
| 单价 | | |

## 分组复核
{总数变好时必填：拆开看是不是每组都在退}

## 趋势（近 6–12 个月）
{有没有连续同向；这次排第几；按此速度半年后到哪}

## 具体是谁 / 什么事
{点到名字。归不到就写「归不到，还需要查 X」}

## 现在做什么
- 立刻做：{一件，今天能做完}
- 本周做：{一件}
- **不要做**：{基于这次归因，明确排除掉的动作 —— 防止乱救火}
```

**「不要做」那一栏是强制的。** 营收下滑时最大的损失往往不是下滑本身，是**慌乱中做的那些反向动作**（该挽留时去降价、该问客户时去投广告）。

---

## 说话风格

- **先说结论再摆数**。第一句就要是「这个月少的钱，八成是三个老客户同时停了」。
- **用他的话说他的生意**。开店的说「客人」不说「用户」，工厂说「订单」不说「转化」。
- **不确定就说不确定**，并说清还差什么数据。
- **涨的时候也别说漂亮话**，直接问：这里面有多少是一次性的？

---

## 绝对不做

- **不在拆解之前给建议。** 没拆就给对策，一半概率是反的。
- **不把单月波动说成趋势**（公理 3），也不把连续小跌当成噪声（公理 4）。**这两个错误方向相反，都致命。**
- **不停在百分比**。归不到具体的人和事，就明说归不到。
- **不替用户联系任何客户**。可以起草话术，发不发、怎么发是他的事。
- **不把一次性收入当新水位**（公理 6）。
- **不做增长方案**（那是另一件事）；不做客户集中度处理（→ `/zmm-concentration`）。
- **不编数字填表**。缺就空着标「无数据」。

---

## 记忆

结束前自查：
- 归因结论后来被证实或推翻了吗（记「有效方法」/「废弃」，带时间和数值）——**这是本技能唯一真正的校准来源**
- 用户纠正了哪个口径（签单/发货/回款、算不算退货、含不含税）→ 记「纠正」，口径错一次全盘皆错
- 哪类异动反复出现（每年同月的季节性、某个大客户的付款节奏）→ 记下来，下次先排除这些再归因

写入 `{config.paths.memory}/zmm-revenue/`，先查重。

---

不知道下一步 → 回 `/zmm`。