企业微信客户运营怎么做分层

一层成不成立，只看动作是否不同

检验方法只有一个：把层的名字遮住，只看每层对应的动作清单。两张清单能对调而不出错，说明这两层在系统里没有区别，该合并。这条规矩通常能砍掉一半的层。

反过来，一个看起来很粗的分层，如果每层动作差得很远，它就是好分层。只有两层、一层走人工一对一跟进、一层只进内容池，比六层全都发同一套群发有用得多。层数不是精细度的证明，动作差异才是。

• 分类回答「这个客户是什么样的」，分层回答「对这个客户我们做什么」
• 分类可以有很多套并存，分层在同一个动作维度上只能有一套
• 分类错了是标注不准，分层错了是资源投错地方

所以设计顺序应该反过来：先列出实际能做的运营动作有几种（人工跟进、定向内容、活动邀约、进内容池、暂停触达），再倒推需要几层。动作只有四种就不要设计六层，多出来的两层从第一天起就是空转的。

三个轴：阶段、活跃、价值，别压成一个字段

能驱动动作的维度实际上只有三类。它们的更新机制完全不同 —— 这是必须分开存的根本原因，不是数据模型洁癖。

• 阶段：由业务事件推进，以单调向前为主，回退需要显式理由。变化频率低，一个客户一个月推进一两次。
• 活跃：滑动时间窗上的聚合值，会自动降级，每天都在变。它不描述客户是谁，只描述客户最近的状态。
• 价值：来自订单、合同这类外部系统，权威不在客户运营侧。更新慢，但一变就是大变。

把三个轴压成一个「客户等级」字段是最常见的错。压完之后任何一个轴变了都得重算这个字段，而三个轴的变化频率差着两个数量级；更麻烦的是它无法解释 —— 一个客户从 A 级掉到 B 级，没人说得清是因为不活跃了还是因为合同到期了，而这两种情况该做的事恰好相反。

层与动作的对照，重点在退出条件

每一层要写清三件事：进入条件、对应动作、退出条件。团队通常只写前两件，于是客户进得去出不来，三个月后每层都在膨胀，「高意向客户」里躺着一半半年没说过话的人。

• 阶段轴：已建立联系未互动 → 首触与破冰；有过有效互动 → 需求确认；需求明确 → 人工跟进与方案；已成交 → 交付与复购序列
• 活跃轴：高活跃 → 允许更高频次与主动邀约；一般 → 内容为主；沉默 → 只保留低频价值内容；长期沉默 → 暂停触达，进唤醒实验池
• 价值轴：不单独驱动动作，只用来调整前两个轴上的资源投入优先级

退出条件必须能被自动判定。「销售觉得这个客户凉了」不是退出条件，「90 天内无双向互动」是。凡是需要人来判断才能退出的层，最后都不会有人去退 —— 没有谁的 KPI 是清理自己的高意向名单。

还有一条容易漏：退出之后去哪一层必须写死。只写「退出高意向」不写「退到哪」，客户会掉进一个没有任何动作覆盖的空档，在报表上他还在，在实际运营里他消失了。

动作侧则要保持统一：不管哪一层，触达都收敛到同一个发送入口，层只决定内容、频次和是否需要人工介入。用 wecomapi 这类网关接入时这一点是天然的，一套接口同时覆盖单聊与群，改分层不需要动发送代码。

三个轴对应三种算法

阶段轴由事件推进。用 wecomapi 的事件回调拿到互动事件后，只做状态机的一次尝试推进 —— 判断当前状态允不允许这次转移，允许就写，不允许就丢。状态机本身怎么建，站内讲客户生命周期建模那篇专门写过，这里只留一条：不要在这里塞业务分支，状态机里长出 if 之后，半年内就没人敢改它了。

活跃轴用定时重算，不要用事件实时更新。活跃度是窗口聚合值，每来一条消息就重算一遍窗口，代价大而且结果在两次触达之间根本没人看。每天一次批量重算足够，重算时间挑在批量任务生成之前，顺序错了等于用昨天的分层发今天的消息。

价值轴走外部同步，客户运营侧只读不写。这条经常被破坏 —— 运营为了做一次活动，手动把某批客户的价值层调高，之后再没调回来。要么彻底只读，要么给覆盖操作强制加有效期。

// 示意逻辑，字段名为自有数据模型，平台侧字段以文档为准
async function runTouchTask(task) {
  const now = await tiers.read(task.customerId);  // 读当前分层，不用任务快照
  if (now.stage !== task.expectStage) return skip(task, "stage_changed");
  if (now.activity < task.minActivity) return skip(task, "downgraded");
  if (now.paused) return skip(task, "paused");

  // 通过校验才发送
  // POST https://manager.wecomapi.com/message/sendText
  await send(task);
}

这段二次校验最常被省。批量任务从生成到实际执行之间可能隔几个小时，中间客户可能已经降级、已经成交、甚至已经明确说过不想再收消息。拿任务里的分层快照去发，等于用几小时前的判断做现在的动作，而这类错误客户是能直接看出来的。

震荡、膨胀，以及人机冲突

震荡出现在活跃轴上：客户在阈值附近来回穿越，一天进一次高活跃层、出一次，两次都触发动作。解法是加滞后 —— 进入阈值和退出阈值不设成同一个值，中间留一条缓冲带，比如 7 日内 3 次互动才进、21 日内 0 次才出。缓冲带的宽度比阈值本身更值得反复调。

膨胀的信号是层数超过五个。每个轴不超过四层是个不错的硬约束；超过说明你在用分层表达本该用标签表达的东西 —— 标签可以有几十个，层不行，因为每多一层就要多写一套动作和一套退出条件，而这两样的维护成本是持续的。

第三个坑是分层结论和一线判断冲突。做法是分层给建议不给指令：允许人工覆盖，但覆盖必须填原因、必须带有效期，到期自动回到系统判定。覆盖记录只落在你自己的库里，同步到 wecomapi 侧的只有最终生效的那一层，避免两边各存一套判定逻辑、对不上时谁也说不清该信哪个。

从两层开始

别一次上三个轴。先做阶段轴的两层：已建立联系但没有过有效互动 / 已有有效互动。这两层的动作差异最大、判定最不容易错，而且能立刻暴露一个更基础的问题 —— 你的事件数据够不够支撑「有效互动」这个定义。多数团队在这一步就会发现数据缺口，这比设计出六层再发现要便宜得多。

跑一个月，看两件事：两层的人数比例是否稳定，以及有多少客户在两层之间来回跳。前者不稳定说明进入条件写得太松，后者频繁说明缺滞后。这两件事都稳了，再加第二个轴。