企业微信群发怎么做才不扰民

没有拒绝路径的条款，都是建议

规范落不了地，九成原因是所有条款都写成了同一档：一段建议性的文字，靠人自觉。可执行的规范必须先分档，每一档对应系统里不同的处理方式。

1. 1硬约束：系统直接拒绝，任何人任何理由都绕不过去。数量要少，三到五条，多了必然被绕。
2. 2软约束：默认拒绝，但存在一条带审批的放行路径，放行记录必须带审批人和失效时刻。
3. 3建议：不拦截，只记录并进复盘。它的价值是攒数据，用来判断这条该不该升级成软约束。

分完档还有一个位置问题：硬约束的检查必须做在发送出口那一层，不能做在编排层。放在编排层，每接一个新的群发入口就要重新实现一遍，漏一个整套规范就失效。把这道检查包在调用 wecomapi 发送接口的那一层里，所有群发无论从哪个入口进来都绕不过去。

频率条款管批次，不是拍「一周几条」

每人每周不超过两条是必要的，但那是人维度的预算，站内另有一篇专讲怎么把它做成发送闸门。群发规范该管的是另一层 —— 批次维度。两层是与关系，任一不过就不发。

批次维度有三个量值得写进条款，共同点是提交任务时就能直接算出来，不用等发完再看。

1. 1名单重叠度：本次名单与最近几次群发名单的交集比例。超过阈值说明你在反复打扰同一批人，而这批人恰好最容易先流失。这个数比一周几条更贴近真实打扰。
2. 2同一名单的最小间隔：同一批人两次群发之间至少隔多久。它和重叠度是一对，重叠度管是不是同一批人，间隔管隔得够不够久。
3. 3单次覆盖比例上限：一次群发最多覆盖客户总量的百分之几。全量群发的问题不只是打扰，是它既没有对照组也没有回滚余地 —— 发错了，你连一个没被污染的样本都剩不下。

阈值的初值不用讨论出来。取一个明显偏严的值先让条款跑起来，被拦住的任务会自动暴露哪些是真需求、哪些是习惯性群发，两个月的数据比两小时的会议有用得多。

时段条款：群和单聊分开写

把群消息和单聊套同一份时段规范，是这块最常见的失误。一条不合时宜的单聊消息影响一个人；一条群消息在几百个群里同时展开，打扰量要乘以群成员数，而且它会被截图。

• 群消息的可发窗口要显著窄于单聊，夜间和周末尤其如此。
• 时段条款写成允许发送的窗口，不要写成禁止发送的时段。白名单在系统里只有一种解释方式，黑名单总会留下没人想过的缝。
• 作息按收件人所在行业定，不按你们团队的作息定。To B 客户的周末和 To C 客户的周末不是一回事，混在一张表里，必然有一类被打扰。
• 活动结束后设静默期。促销结束当晚客户对同类内容的容忍度最低，而这恰好是运营最想再追一波的时候。

时段和内容类型是耦合的，条款要写在一起。订单状态、会议提醒这类客户自己在等的服务型通知，本来就不该被营销时段窗口卡住 —— 但放行必须是按类型显式声明的，并且这条通道要能被单独审计。只要存在一个不受时段约束又没人看的类型，营销内容迟早会被包装成它发出去。

还有一条容易漏的：同一批消息不要在同一分钟内推完。这不是频率约束的要求，是观感 —— 同一个群里几个人在同一秒收到一模一样的内容，被截图放在一起比对的概率会明显上升。把一批任务在允许窗口内摊开，成本只是排期，收益是同一批内容不会在同一秒集中砸到客户眼前。

退出机制：存客户主档，两处过滤

退出机制做不住，绝大多数情况下是存错了地方 —— 存进了某次活动名单的排除项里。这次确实没发给他，下次导一份新名单，他又回来了。

退出是客户主档上的一个状态，不是名单上的一个标记。它必须跨账号、跨渠道、跨活动生效：客户对着 A 销售说了别发了，B 销售的群发也不该再触达他 —— 客户感知到的是你们公司，不是某个账号。

三种退出信号的来源和强度不一样，要分开处理。行为类的信号不必等人发现：退群、删好友这类关系变更用 wecomapi 的事件回调订阅之后直接写回主档，比等运营下次导名单时才看出来及时得多。

• 显式退出：客户在会话里明确表达。怎么把这句话识别出来属于触达策略，站内讲自动触达那篇给了可用的判据；规范这一层只规定一件事 —— 识别到之后必须写进客户主档，而不是写进本次活动的排除名单。
• 行为退出：退群、删好友、连续多次无响应。强度比显式退出弱，但足以降到最低频次。
• 分类退出：允许只退营销类，保留订单状态、会议提醒这类服务型通知。一刀切停掉全部消息，反而会引发另一类投诉。

过滤要做两处，目的不同：圈选时查一次，让运营看到的可发人数是真实的，报表口径才对得上；发送前再查一次，兜住圈选之后新产生的退出 —— 一个大批次跑几个小时，中间有人退出是常态。只做前者会真发出去，只做后者报表会虚高。

// 示意逻辑，精确字段与调用约束以线上文档为准
async function buildAudience(query) {
  const raw = await crm.select(query);
  return raw.filter((c) => !c.optOut.marketing);   // 第一处：让口径正确
}

async function deliver(task, person) {
  if (await optOut.check(person, task.category)) { // 第二处：兜住新产生的退出
    return skip(person, "opt_out");
  }
  return post("https://manager.wecomapi.com/message/sendText", {
    guid:    task.accountId,
    toId:    person.id,
    content: render(task, person),
  });
}

退出之后怎么恢复、静默期怎么设，属于触达策略而不是群发规范，站内讲自动触达那篇更细。规范这一层只需要规定一件事：恢复必须是显式动作，不能由名单刷新、分层重算或者一次系统迁移顺手带回来。

例外通道：没有它，规范活不过第一次大促

一份只有禁止、没有例外的规范，第一次大促就会被绕过去。不是被推翻，是被绕过：有人直接拿手机操作，或者临时开一个不走系统的入口。那比放宽条款糟得多，因为绕过去的那部分完全没有记录。

1. 1例外必须有审批人，且审批人不能是发起人。这条看起来官僚，但它是唯一能让例外不泛滥的机制。
2. 2例外必须带失效时刻。本次大促期间放宽要落成一个具体时间点，到点自动收回，不依赖谁记得去关。
3. 3例外必须留痕：谁批的、放宽了哪一条、覆盖多少人、内容快照。事后复盘时这份记录是唯一能自证的东西。
4. 4例外之后必须复盘。放宽的那几天负向指标涨了多少，是下次要不要再批的依据。

还有一个反直觉的做法：例外额度提前设好，而不是每次现批。一年里允许几次超规格群发，写进规范，用完为止。有限额度会逼着业务方自己排优先级，比每次靠人情博弈健康得多。

条款的数值靠数据定，不靠会议定

所有阈值 —— 重叠度多少、间隔几天、窗口几点到几点 —— 都不该在会议室里拍出来。拍出来的数值没有依据，第一次被质疑就守不住。

做法是每次群发后固定记录四个负向数：退订数、删好友数、退群数、投诉数，按渠道、内容类型和客户分层分组。这几个数在时间序列上一抬头，就是条款该收紧的信号；长期贴地，说明还有放宽的空间。前面说的 wecomapi 事件回流已经把关系变更写进了主档，统计直接从那里取，不必等人工汇总。

• 基线按分层分别定，理由和站内讲自动触达那篇给熔断定基线时一样：全站均值放在沉默客户和新客身上都不成立。
• 每季度只改一两条。一次改五条，下个季度你分不清是哪一条起了作用。
• 条款要能被运营自己改，改完立刻生效。需要发版才能调的规范，最后一定会被绕开。

上线顺序也别搞反。新条款先跑影子模式：只判定、只记录、不拦截，两周之后拿着「这条规则本来会拦掉多少任务、分别是哪些」去和业务对齐，再打开拦截。直接上拦截的结果通常是第一天就拦住一个真需求，然后条款被当场推翻，连带后面几条也推不动了。