企业微信社群运营怎么系统化

撑不住的临界点不是群数量

真正的临界点是群的种类数乘以状态漂移速度。种类多意味着每个群的处理逻辑不同，漂移快意味着这些逻辑的输入天天在变。两者相乘超过人脑的工作记忆，运营就开始靠印象干活，而靠印象干活的下一步一定是漏。

• 运营开始靠记忆而不是靠清单：问「今天哪些群要发活动预告」，答案来自某个人的脑子
• 同一件事在不同群做法不同，而且说不清为什么不同 —— 通常是历史遗留，不是刻意设计
• 没人说得清某个群现在归谁、当初为什么建、还需不需要留着

出现这三个信号时，第一件该做的事是减种类，不是上系统。把三十种群规则收敛成四五种模板，比把三十种原样搬进系统便宜得多 —— 搬进去的是三十套要长期维护的配置，而配置一旦进了系统，就再没人敢删了。

群要有生命周期，尤其要有退役

绝大多数群池的真实问题不是新群建得不够快，是老群从来不下线。四个状态就够用：

• 筹备：群已建但还没开始运营，这个阶段要完成模板绑定、值班归属、群公告
• 活跃：进值班表、进群发名单、计入健康度分母
• 沉默：连续若干天无客户发言，降频、只保留低成本动作、进唤醒候选
• 退役：不再消耗任何运营预算，从名单和分母里移出

退役不等于解散。多数客户群解散的成本比留着高 —— 客户会问、会觉得被抛弃。退役的意思只是这个群不再进入任何自动化名单，也不再拉低你的健康度平均值。这个区分能让运营愿意执行退役判定，否则没人敢按那个按钮。

状态流转要自动判定、人工可覆盖。判定输入是 wecomapi 事件回调推来的群消息事件与成员变更事件，这两类事件持续落成明细表之后，状态流转就是这张表上的一组定时查询，不需要额外埋点，也不需要运营手工维护一张群清单。

把人肉动作翻译成规则，先分三档

不是所有动作都该规则化，全都硬上的结果是客户群里出现明显的机器味，而机器味在客户群里是负分。按「错了代价多大」和「是否代表企业做出承诺」两条线，切成三档：

1. 1可完全规则化：入群欢迎、群公告与群名的模板化同步、活动前的定时播报、值班交接提醒、关键词命中后给运营的内部提示。共同点是错了成本低，而且不构成对客户的承诺。
2. 2规则辅助、人来确认：客户问题的答复草稿、投诉的升级路由、涉及报价和排期的对话。规则负责识别、组装上下文、推到人面前并开始计时，人负责看一眼再发。
3. 3永远不该规则化：道歉、承诺、以及任何关于「这个客户关系现在到哪一步了」的判断。这三样交给规则，省下的时间远远抵不过一次翻车。

第二档价值最高，也最容易被跳过。团队往往要么全人肉、要么想一步跨到全自动，而社群运营的时间损耗大头恰恰在中间这档 —— 不在于处理一个问题要多久，在于发现有个问题需要处理要多久。

落地上，第二档需要的是把事件转成任务，而不是转成消息。用 wecomapi 的事件回调把命中规则的群消息投成一条待办，带上群、发言人和前后几条上下文，运营在自己的工作台里处理完再回群里发；反过来把提醒也发成群消息，只会让群更吵，运营照样得回去翻。

三个健康度指标，别用消息条数

消息条数是最容易采集也最没用的指标 —— 一个群里两个运营互相接话，条数很好看。换成这三个：

• 客户侧发言人数占比：窗口内去重后有多少不同客户说过话，除以群内客户数。这个指标造不了假。
• 运营侧首响时延的分位数：看 P90，不看平均。平均值会被大量秒回的「收到」拉平。
• 连续无客户发言天数：直接作为沉默与退役状态的判定输入，不需要额外定义。

三个都能从消息事件里算出来。用 wecomapi 的群消息事件把发言人身份与时间落成一张明细表，健康度就是这张表上的三个聚合查询，业务侧不需要额外埋点，也不依赖任何一方按时填表。

一个必须处理的细节：首响时延要按「客户提问」计算，不是按「任意客户消息」。客户在群里说一句「收到」也算进分母的话，这个指标会一路变好看，同时和真实体验彻底脱钩。识别提问不需要模型 —— 带问号、命中疑问词、@ 了运营，这一组规则就能覆盖大部分，剩下的漏掉不影响趋势判断。

规则上线不出事的三件事

1. 1影子运行：新规则先只记录不执行，跑一到两周，把规则的判断和运营实际做的事对一遍。差太多的规则不要上，先改规则或者先改预期。
2. 2按群灰度：先在内部群和低风险群开，再按群标签逐步放量。不要按百分比随机放量 —— 群和群之间差异太大，随机抽到的样本没有代表性。
3. 3每条规则一个独立开关，而且开关要能被非工程的人关掉。出事那天，会写 SQL 的人不一定在。

// 示意逻辑，事件类型与字段名以文档为准
// 回调里已快速 ACK，这里是队列消费者
async function consume(evt) {
  for (const rule of rules.match(evt)) {   // 群标签 + 事件类型双重匹配
    if (!rule.enabled) continue;           // 每条规则一个独立开关

    const action = await rule.decide(evt);
    if (!action) continue;

    if (rule.shadow) {                     // 影子模式：只记录，不执行
      audit.log(rule.id, evt, action);
      continue;
    }
    // POST https://manager.wecomapi.com/message/sendText
    await execute(action);
  }
}

回调侧照站内一贯的口径处理：先快速 ACK，再把事件投进队列，规则匹配和动作执行都放在消费者里。规则数量涨上来之后匹配本身也会变慢，占着回调请求跑匹配，迟早被判超时然后触发重试，而重试会把同一批规则再跑一遍。

系统化之后，人做什么

规则化的目的不是减人，是把人的时间从「检查有没有漏」挪到「处理确实需要判断的事」。前者是机器的强项，后者机器现在还做不了，而且客户能分辨出来。

一个稳定的形态大概是这样：机器负责所有定时的、重复的、有明确触发条件的动作，以及把需要人处理的事按优先级排成一个队列；人负责这个队列，加上每周看一次健康度，决定哪些群该退役、哪些规则该改、哪些新出现的重复动作该收进规则。

最后一条是这套东西能不能长期跑的关键 —— 规则集需要有人定期做减法。只加不减的规则集三年后会变成没人敢动的黑箱，那时候的维护成本比当初人肉还高，而且没有回头路。