企业微信自动营销方案

先拆清楚：自动营销是四个环节，不是一个功能

搜「企业微信自动营销方案」的人，想要的通常是一整套能自己跑起来的东西。但落到工程上它不是一个功能，而是四个职责分明的环节各自跑通、再接成一个环：分层决定「发给谁」，触发决定「什么时候发」，触达决定「发什么、还发不发」，回流决定「下一轮怎么改」。

这四步最容易被理解成一条流水线 —— 分完层、配好触发、发出去、看个报表，结束。它真正的形状是环，闭合点在第四步写回第一步。站内讲自动化营销四步循环的那篇专门拆过这个闭合点：开环的系统跑上一年，第二轮和第一轮发的是同一批人、同一套话术，而每次复盘的结论都会是「话术要优化」。

另一处容易含混的地方是接口。承担这四步的不是同一类接口：触达是秒级的，发出去不可撤回；标签写入是最终一致的，读到旧值属于正常现象；效果回流是天级的，可以重算。站内讲营销 API 的那篇按这三种时间尺度分开讲了各自的写法 —— 把它们塞进同一段同步逻辑里，是这类系统最常见的架构错误。

前置条件：动手之前先确认这五件事

这五件事任缺一件，后面的步骤都会在某个位置卡住，而且卡住的样子往往不像是缺了前置条件。

• 客户主档里已经有一个稳定的内部 ID，能把企业微信侧的联系人和你自己的订单、表单线索对上。对不上，回流那一步就没有落点。
• 标签由程序写、也由程序改。把层维护成运营在后台手工勾选的名单，第四步的数据无处可写，环在这里就断了。站内讲标签体系的那篇把「谁写谁读」列为分类之前必须先回答的问题，是同一个道理。
• 事件回调已经能收到并落库。感知触发点靠它；没有它就只剩定时轮询，所有时机会整体滞后。
• 有一张「谁、在什么时候、被发过什么」的触达流水表。频次控制、排障、效果归因三件事都从这张表出。
• 退订与转人工的入口先于自动化上线，而不是之后再补。

分步实施：六步，每步都有可判断的完成标志

1. 1先建三层最粗的分层：没有过任何回应的、回应过但没转化的、已经转化的。完成标志是每一层都能说出一个明确不同的下一步动作；说不出来，这一层就不该存在。
2. 2接上事件回调，把好友通过、入群、客户回复这几类事件落到一张事件表。完成标志是把自己的服务停掉几分钟再恢复，事件表里没有空洞。
3. 3写决策层：一条事件进来，查这个客户当前在哪一层、查触达流水表里他今天的频次余额、查是否落在静默时段，输出「发 / 不发 / 延后到几点发」三选一。完成标志是这一层能单独跑测试，不需要真的调发送接口。
4. 4接触达。只有决策层说发才调消息接口；响应回来，把响应头里的 x-request-id 和发送时间写回触达流水表。完成标志是任取一条已发消息，都能从流水表反查到它的 x-request-id。
5. 5接回流。把客户回复、进一步动作、成交这三类信号写回客户主档，并据此更新分层。完成标志是同一个客户在两周内因为行为变化换过层 —— 一个从不变化的分层字段，说明这个环还没合上。
6. 6灰度放量。先只对一层客户、一条流程打开，跑满一个完整周期再扩。第一轮跑得小，是为了让第一批错误便宜。

架构与数据流：谁调谁、状态存哪、失败了谁重试

三个角色要解耦：事件回调负责感知，你的决策层负责判断，消息与客户接口负责执行。回调不要直接同步驱动决策层，中间隔一个队列 —— 回调只做落库和入队，尽快返回。

状态分三处存，不要混：客户当前分层存在客户主档，是可覆盖的最新值；触达流水按条追加、永不修改，频次和归因都从它算；事件原始报文单独留档，用于回放与对账。

重试的责任边界要写死。入站方向，在你确认收下之前由平台侧负责重投，你要做的是幂等 —— 同一个事件重复到达，不能重复触达同一个人。出站方向，重试由你的队列负责，并且只重试「结果未知」的那一类，已经明确失败的请求一次都不该重发。

// 决策层已经判过「要不要发」，这一段只负责发出去和记账
const res = await fetch("https://manager.wecomapi.com/message/sendText", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    guid:    "7db8...",   // 发送账号
    toId:    "78813...",  // 收件人
    content: "订单 #8891 已发货，请注意查收。",
  }),
});

// 排障靠响应头里的 x-request-id，节奏靠 x-ratelimit-remaining
const requestId = res.headers.get("x-request-id");
const remaining = res.headers.get("x-ratelimit-remaining");

const body = await res.json();   // { "code": 0, "msg": "success" }
if (body.code === 0) {
  await touchLog.append({ toId: "78813...", requestId, at: Date.now() });
}

错误处理与排障

拿到一个失败响应，本能反应是去查这个码是什么意思。这个顺序是反的 —— 决定处置的不是码值，而是「现在该做什么」。站内讲接口报错分类的那篇把它归成四类，放到营销链路里，这四类的代价差得很远：

• 确定性失败：参数不对、权限不足这类。重试多少次结果都一样，该做的是停下来告警，而不是排队重试。
• 状态失败：账号掉线、对方已经不是好友这类。重试同样无用，但值得把状态写回客户主档，免得后面几轮继续往这个人身上发。
• 容量失败：节奏太快。要退的不只是这一条请求，而是整条队列降速；只把这一条丢回队尾，下一条照样撞墙。
• 结果未知：超时、连接中断。这一类最贵 —— 它不等于失败，消息可能已经发出去了，必须先查后补，不能直接重发。

线上被问得最多的三个问题，对应三条固定查法：

1. 1「这条到底发出去没有」：拿触达流水表里的 x-request-id 去对。流水表里根本没有这条记录，说明问题出在决策层之前，不在发送这一步。
2. 2「为什么这个客户没收到」：先看他现在在哪一层、当天频次余额还剩多少、是不是落在静默时段。多数「没收到」其实是「被自己的规则拦下了」；但如果拦截不打日志，它看起来和接口失败一模一样。所以决策层每一次「不发」都要留一条带原因的记录。
3. 3「为什么突然整批都发不出去」：先看 x-ratelimit-remaining 的走势。如果事故之前它就已经长期贴近 0，问题出在节奏，不在接口。

频次这一层的建模细节 —— 预算挂在人身上而不是挂在活动上、静默时段按收件人算而不是按服务器算、两条流程同时想找同一个人时谁让路 —— 站内讲自动触达的那篇讲得更细，这里不展开。

怎么判断自己做对了

「跑起来了」不是判据。下面几条是可观察的，放量前后各测一次：

• 触达流水表里的每一条，既能反查到 x-request-id，也能反查到当时是哪条规则决定要发的。
• 决策层「不发」的记录条数和「发」在同一个量级。不发的记录接近于零，说明频控根本没生效。
• 随机抽十个客户，两周内至少有几个的分层发生过变化。全都没变，说明回流没有真的写回分层。
• 放量之后退订与静默率不上升。上升了先降频次，而不是先改话术。
• 把某一条流程停掉一周，对应分层的转化指标应该有可观察的变化。没有变化，说明这条流程本来就没起作用，可以下线。