企业微信私域运营怎么起步

第一个月的真正约束：别丢数据

第一个月的产出不该是成交额，也不该是加了多少人 —— 那些数字在样本量到位之前没有解释力。该产出的是一套能回答三个问题的数据：这个客户从哪来、现在归谁、他走到哪一步了。这三个问题在第三个月会同时被问到，而那时候补数据已经来不及。

补不回来的东西有明确清单：加好友通过的时刻与来源、客户与承接成员的对应关系、进群退群的时间点、会话原文。它们的共同特征是只在事情发生的那一秒存在，事后从任何地方都还原不出来。相比之下，标签体系、分层规则、话术模板都可以随时重建，推倒重来也不心疼。

• 先采后用：这个月只要求写进库里，不要求现在就用得上。
• 宁可字段冗余，不要字段缺失。多存一列的成本是磁盘，少存一列的成本是三个月后重来。
• 凡是以后还能算出来的指标都不急，凡是以后算不出来的字段都今天就得有。

第 1 周：把口径和账号结构定死

第一周不写业务代码，先定三个口径 —— 它们改一次，历史数据就废一次。

1. 1什么算一个客户。你在会话侧拿到的是某个成员视角下的联系人，同一个真人被两个销售加上就是两条身份。主档必须是人，身份表多对一挂上去；这个结构第一周不定，第二个月就得停下来重构。
2. 2什么算有效线索。加上好友算，还是回过一句话才算，或者留过联系方式才算？这个口径决定了后面所有渠道对比是不是在同一把尺子上。
3. 3什么算活跃。用最近一次双向会话的时间，别用最近一次你发消息的时间 —— 后者只能证明你还在发。

账号结构同期定下来：用几个账号承接、谁负责哪一类客户、多账号之间要不要隔离。在 wecomapi 里一个企业微信账号对应一个独立实例、有各自的 guid，调用时用它指定要操作哪个账号。起步阶段不必上复杂方案，但账号维度必须从第一天就进数据模型，事后补这一维要动所有表。按业务线切还是按环境切，站内另有一篇专讲，这里只需要做出选择并写下来。

口径写在哪也有讲究：写进一份带日期的文档，每次改动追加一行，不覆盖旧的。半年后看数据打架，第一件事就是查这条口径当时是怎么定义的 —— 没有变更记录，你只能重新讨论一遍，然后得到第三个版本。

第 2 周：先接上那三件不可回溯的事

第二周只有一个目标：让发生了什么自动落进你的库，而不是靠人记。三件事按这个顺序接。

1. 1来源写入。加好友通过的那一刻，把来源与承接成员一起写进主档 —— 码怎么设计、写失败怎么兜底、未知来源怎么记，站内讲来源归因那篇有完整口径，这个月只要保证这一步和通过事件在同一段逻辑里完成。
2. 2关系与消息事件订阅。用 wecomapi 的事件回调拿到通过、进群、退群与消息事件，收到之后先快速返回 2xx 再入队异步处理，用事件 ID 做幂等 —— 重复投递一定会发生。
3. 3首次触达。通过之后发一条欢迎语，同时把这条消息的发出时刻记下来，它是后面算首次回复率的分母起点。

// 示意逻辑，evt 是归一化后的内部事件对象
// 精确的事件类型、字段与端点以线上文档为准
async function onCustomerAdded(evt) {
  await ack();                                 // 先快速 ACK，再异步处理
  if (!(await dedupe.first(evt.id))) return;   // 事件 ID 幂等

  await store.bindSource(evt.customerId, {     // 建档与来源写入放在同一次消费里
    channel:  lookupChannel(sourceKeyOf(evt)),
    owner:    evt.staffId,
    joinedAt: evt.ts,
  });

  await post("https://manager.wecomapi.com/message/sendText", {
    guid:    evt.accountId,
    toId:    evt.customerId,
    content: welcome(evt),
  });
}

这段的重点不在发消息，在它前面那几行：ACK、幂等、写库的先后顺序决定了这个月采到的数据能不能用，欢迎语晚发一天反而问题不大。

承接归属要单独记一张表，而不是只在主档上放一个当前归属人。人会离职、客户会转接，主档上那个字段被覆盖之后，「这个客户当初是谁加进来的」就没了 —— 而算渠道效果、算人效、复盘转接影响，用的全是历史归属，不是当前归属。

第 3 周：只跑通一条最窄的闭环

第三周开始做自动化，但只做一条，而且挑最窄的那条：新客户通过 → 自动打来源标签 → 发欢迎语 → 记录首次回复。它的价值不是省人力，是产出第一个能指导决策的数 —— 首次回复率。

为什么是这个数：加人数只反映投放力度，成交数样本太小，首次回复率在几百人的量级上就有统计意义，而且它同时暴露渠道质量和欢迎语质量两件事。分渠道拆开看，差距通常大得吓人。

• 这一周不要碰规则引擎。三条 if 能表达的逻辑，上引擎只会让下周改一句文案变成一次发版。
• 自动发出的每条消息都带来源标记，出问题时能一秒定位是哪条规则干的。
• 留一个全局开关，能在不发版的情况下把自动发送整个关掉。

欢迎语本身也是这周唯一值得反复改的东西。第一句别发长文、别甩链接、别一上来自我介绍三段 —— 发一个对方能一句话回答的问题，回复率的差距在第一周就能看出来。这条消息是你在这个客户身上唯一一次几乎必然被读到的机会，浪费在自我介绍上很可惜。

后面加第二条、第三条自动化时仍然走同一个出口。把限速、去重和留痕做在调用 wecomapi 发送接口的那一层，业务代码只能通过这个出口发消息，加多少条链路都不用把这些检查重做一遍。

第 4 周：出一张只回答三个问题的表

月底出一张表，只回答三个问题：这个月新增了多少客户、分别来自哪、多少人回过话。三列，不要更多。

分母比分子重要。渠道 A 加了 300 人没有信息量，渠道 A 投出去 1000 次曝光、加上 300 人、其中 90 人回过话才有。缺分母的表格看起来很饱满，但据它做不了任何取舍。

1. 1定复盘节奏：每周一次，每次只改一件事。同时改文案、改时段、改渠道，下周就不知道是哪一项起了作用。
2. 2把未知来源当成一个正式的值列出来，它的占比就是归因覆盖率 —— 口径同样见站内讲来源归因那篇。第一个月这个数通常在三成以上，看着难受，但把它藏起来更糟。
3. 3留一份原始明细。汇总表以后随时能重算，明细丢了就再也算不回来。

同样重要的是这个月不该看的数：成交额、人均产出、和同行的对比。样本量在这个阶段撑不起这几个数，看了只会得出错误结论，然后据此调整方向 —— 第一个月最大的浪费不是没做事，是根据噪声做了一次转向。

这个月坚决不做的四件事

1. 1不建标签树。第一个月你还不知道哪些标签会被消费，建出来的多半是垃圾。站内讲标签体系那篇的第一条规矩是新增标签必须先声明消费方，而这个月你声明不出来。
2. 2不做批量群发。手上这几百人是最贵的种子客户，用一次无差别群发试水，换回来的是一份删好友率数据和一批回不来的人。
3. 3不自研整套 SCRM。这个月要写的代码总共不超过几百行：接事件、写库、发欢迎语、出报表。超出这个规模，说明在做还没被验证过的需求。
4. 4不急着扩账号扩人。承接能力没验证之前加账号，只是把同一个问题复制一遍。先看单个承接人的首次回复率能不能做到及格。

第二个月往哪走，由第一个月那张表决定，而不是由计划决定。如果首次回复率在各渠道之间差得很远，下个月的重点是砍渠道和改第一句；如果各渠道都差不多但整体偏低，问题在承接节奏，该做的是把响应时延压下去；如果两项都还行、人却留不住，才轮到客户分层和跟进节奏。这三条路径需要的系统完全不同，先花一个月拿到判据，比按模板铺一遍便宜得多。