企业微信自动触达怎么做才不打扰

打扰预算挂在人身上，不是挂在活动上

几乎所有超频事故都是同一个结构：每条自动化流程单独看都很克制 —— 新客欢迎序列一周三条、活动通知一周一条、复购提醒两周一条、生日祝福一年一条。它们同时命中同一个人的那天，这个人一天收到四条。

根因是配额挂错了地方。挂在活动上，每条流程只看得见自己；挂在人身上，所有流程共用一个池子，谁先来谁先花。改动不大，但它把「克制」从每个业务方的自觉变成了系统的硬约束，只有后者能长期成立。

预算的数值不用一开始就算准。取一个明显偏保守的初值 —— 营销类每人每周一到两条是个能用的起点 —— 先让约束跑起来，再拿后面讲的负向指标反推该松还是该紧。一上来就纠结数字，通常的结果是这套机制永远上不了线。

频次预算的四个建模决定

1. 1主体是人，不是账号，也不是客户所在的群。同一个人被三个销售加了好友，他感受到的是三条消息，系统里也该是同一个主体在被扣额度。
2. 2周期用滚动窗口，不用自然周。自然周的结果是所有流程都在周一把额度花光，周二到周日一片安静。最近 7 天的滚动窗口没有这个边界效应。
3. 3光有周额度不够，还要有最小间隔。三条额度挤在同一个上午发完，完全符合预算，体验却是连环轰炸。加一个以小时计的冷却时间，它防住的是「集中打扰」，而周额度防的是「总量过多」，两件事。
4. 4不同类型扣不同的额度。服务型通知（订单状态、会议提醒、客户自己触发的回执）扣得少甚至接近不扣，营销型扣得多。但不能不扣 —— 一旦某个类型可以无限发，它迟早变成绕过预算的后门。

// 示意逻辑，字段名与发送接口约定以线上文档为准
async function trySend(person, msg) {
  if (isQuiet(person, msg.type)) return defer(person, msg);   // 时段：硬门，延后不丢
  if (!(await cooldown.ok(person, msg.type))) return drop(msg, "cooldown");
  if (!(await budget.take(person, cost(msg.type)))) return drop(msg, "quota");
  if (!(await dedupe.check(person, msg.hash))) return drop(msg, "dup");

  // 走到这里才真正发
  // POST https://manager.wecomapi.com/message/sendText
  return channel.sendText(person, msg.text);
}

关键在这层闸门的位置：它必须在发送侧，不能在编排侧。放在编排侧，每接一条新流程都要重新实现一遍检查，漏掉一条整个约束就失效。放在发送层，所有流程无论从哪来都绕不过去。调用 wecomapi 的发送接口时，把闸门包在调用它的那一层里，业务代码只能通过闸门发消息，不给第二条路。

预算还要允许人工突破：一个连紧急通道都没有的系统，最后一定会被人从旁边绕过去，而绕出来的那条路没人管得住。这条通道怎么设 —— 谁批、多久失效、留什么痕 —— 站内讲群发规范那篇写得更细，触达侧只需要守住一点：它走的仍然是同一道闸门，只是带一个能被审计的豁免标记，而不是另开一个不过闸的入口。

静默时段按收件人算，不按服务器算

静默窗口最常见的实现是拿服务器时间判断，然后在跨时区、跨行业的客户身上翻车。判断依据应该是收件人那边的时间和作息：能拿到时区就用收件人本地时间，拿不到就用其所在区域的默认值，再拿不到用最保守的那一档。

• 夜间静默是硬门，不是优先级。再紧急的营销内容也不该在凌晨发出去；真正紧急的服务型通知走另一条链路，并且要能被单独审计。
• 节假日单独一张表。促销节点前后客户的容忍度和平时不一样，收紧和放松两个方向都要能配。
• 首次触达和跟进触达的时段策略要分开。第一条消息发在什么时间影响的是通过率和第一印象，跟进消息更该跟着对方上次回复的时间走。

撞上静默窗口的消息，默认行为是延后而不是丢弃，但延后必须带过期时间。没有过期时间的延后队列，会在第二天早上八点把攒了一夜的消息一次性倒出去 —— 那比夜里发还糟。恢复发送时也要限速，让积压按正常节奏流出，而不是瞬间清空队列。

还有一个容易被忽略的时段问题：批量任务的执行时间不等于客户的接收时间。凌晨跑批生成待发列表完全没问题，但生成之后必须进延后队列，等到允许的时段再发。把跑批时间和发送时间绑死，是最常见的夜间打扰来源，而且这种代码看起来完全正常，评审时不会有人拦。

分层决定谁配得上更高的频次

给所有人同一个频次上限，是最省事也最差的做法：高意向客户会觉得你反应慢，沉默客户会被同样的节奏一路推到删好友。预算应该按分层分配，而且要能自动升降档。

• 按生命周期阶段分池：新客、活跃、沉默、流失预警，各自一套频次上限和可发的内容类型。
• 自动降档：连续几次触达没有任何回应，自动降到低频池。这条反直觉但重要 —— 不回复通常不是「还没看见，多发几次就好了」，而是一个明确的负反馈。
• 升档要有依据：主动咨询、点开链接、进群这类正向行为才算升档信号；运营手动拉高只能是临时的，并且必须带到期时间。

分层还有一个常被忽略的用法：给内容类型也分层。同一个人在同一档频次里，能收到的内容类型也该有区别 —— 高意向的人可以收到具体方案和报价，沉默池的人只该收到打扰感最低的那类。频次和内容一起收紧，比只压频次有效得多。

新流程一律先灰度。挑一个分层、放很小一部分人进去跑两周，看的不是转化率而是这批人的负向指标有没有抬头。对照组要真实：同一分层里随机切分，一组走新流程、一组维持原状，两组都从同一套 wecomapi 发送通道出去，免得把通道差异算成流程效果。这一步只花两周，省掉它的代价是拿全量客户做实验。

分层数据从哪来是另一个话题，站内讲标签体系那篇更细。这里只强调一点：分层字段必须是发送闸门能直接读到的，读不到就等于没分层。

两条流程抢同一个人，谁让路

预算见底的时候，系统必须能决定谁发、谁不发、谁等一等。没有仲裁规则，实际生效的规则就是「谁的定时任务先跑」，那是一种随机策略。

1. 1定优先级：服务型通知 > 客户自己触发的响应 > 高意向跟进 > 通用营销。这个顺序在绝大多数业务里都成立。
2. 2允许抢占，但只抢占还没发出去的。已经排队待发的低优先级消息可以被顶掉，已经发出去的当然不行。
3. 3同窗口合并：一小时内要发给同一个人的三条内容，能合成一条就合成一条，合不了就只留优先级最高的那条。
4. 4被挤掉的要记账。哪条流程长期抢不到额度，是运营需要知道的信息，不该悄无声息地消失。

顺序上有个细节：仲裁要发生在扣减额度之前，不是之后。先决定这一轮谁有资格发，再去扣；反过来做就变成先到先得，优先级形同虚设。合并也有前提 —— 内容本身得能合并，别把两条毫不相干的信息硬拼成一段，客户读到的是一坨没有重点的长文，比收到两条更烦。

客户的退出信号，比你的指标更早

预算和时段解决的是「我发多少」，出口解决的是「他不想要的时候怎么停」。缺了这一块，前面所有的克制都只是你单方面的估计。

• 显式退订必须能被识别。客户在会话里说「别发了」「不用了」，这是最强的信号，比任何模型打分都准。命中之后立刻写回预算，把这个人的营销类额度归零，并且要能持久生效，不被下一次分层刷新覆盖掉。
• 用静默期，不要永久拉黑。给一个可配置的冷静期，到期后允许低频恢复，但恢复后的第一条内容必须是服务型或者确实高价值的。
• 出口要能被审计。谁在什么时候被停了、因为哪个信号、什么时候恢复的 —— 处理投诉时，这套记录是唯一能自证的东西。

怎么识别退订意图 —— 词表、特征取舍、宁可误判也不漏判 —— 站内讲群发规范那篇已经写全，这里不重复。触达侧要额外注意的是它挂在哪：识别要挂在入站消息链路上，收到就判、判中立刻改预算，不要等下一次发送前才去查一遍。晚一步的代价是这个人在空档里又收到一条，而那一条正好是他刚说过不想要的。

比显式退订更早出现的是行为信号。打开率、回复率这类正向指标不会告诉你有没有打扰到人 —— 一条让人烦躁的消息和一条有用的消息，都可能被点开。真正反映打扰的是负向指标：删好友率、退群率、不再回复的比例、投诉量。

把这些接成自动熔断，而不是放进月度复盘。按分层和流程分组统计，任一组的负向指标超过基线就自动降频甚至暂停这条流程，同时告警。用 wecomapi 的事件回调可以拿到客户关系与群成员的变更事件，把它们回流到分层和预算模块，熔断才有实时输入，而不是等月底看报表。基线怎么按分层分别定，和群发规范那篇是同一套口径，不重复。触达侧要额外定的是熔断之后怎么恢复：自动降频很容易，自动恢复很危险 —— 恢复应当是一次显式动作，由人看过这一组的负向指标再打开。