企业微信客户维护怎么自动化

先按「通知谁」分类，不按场景分类

这三类场景在需求文档里长得几乎一样，都是「到了某个条件就发一条消息」。但它们的收件人不同，错误代价因此差着两个数量级。按场景排期，你会先做最显眼的那个；按收件人排期，你会先做最划算的那个。

• 对内提醒（跟进到期、待办、客户有新动静）：收件人是员工。判错了最多让人多看一眼，可以激进地自动化，不需要任何风险评审。
• 对外关怀（生日、节日、纪念日）：收件人是客户。判错了直接暴露在客户面前，内容必须模板化、可审、可随时停。
• 对上预警（流失风险、异常客户）：收件人是主管。判错了造成误判与无谓施压，重点不在及时，在证据。

落地顺序就按这个分类走：先把对内那一档做透。它的投入产出比高一个数量级，而且做的过程中会顺带把客户状态模型建起来 —— 后面两类都依赖这个模型，先做它等于把地基一起打了。

跟进提醒：难点是「什么算跟进过」

这个功能的所有麻烦都来自一个没定义清楚的词。发过一条消息算跟进过吗？对方没回呢？一次群发扫到他算吗？定义松一点，提醒就永远不响；定义紧一点，销售会被提醒淹没然后全部静音。

可用的定义是把跟进算成双向的：最近一次由客户发起、或者客户对你的消息作出回应的时间，才是有效接触时间。单向发出去的消息不更新这个水位。这条一改，群发就再也不能把所有人的跟进计时器清零 —— 而这恰恰是「明明一个月没联系，系统显示都跟进过」的根因。

实现上，用 wecomapi 的事件回调按消息方向更新这个水位，定时任务只读它，不再回头去翻消息记录。回调侧只管写、扫描侧只管读，两边解耦之后，提醒规则怎么改都不影响这份数据的准确性。

// 示意逻辑，事件结构与字段以线上文档为准
app.post("/wecom/callback", (req, res) => {
  res.sendStatus(200);                  // 先快速 ACK，再异步处理
  queue.push(req.body);
});

async function onEvent(evt) {
  if (!isInboundMessage(evt)) return;   // 只有客户侧来的消息才算有效接触
  await contact.touch(customerIdOf(evt), timestampOf(evt));
}

// 定时扫描超期客户，提醒发给归属员工，不是发给客户本人
// POST https://manager.wecomapi.com/message/sendText
// { "guid": "...", "toId": "<员工会话>", "content": "3 位客户跟进已超期" }

生日关怀：数据质量不够就该关掉这个功能

这是少数「做不好不如不做」的功能。生日字段的常见状态是：一半为空、一部分只有月日没有年、还有一部分是客户随手填的。在这种数据上开自动祝福，等于随机给一批人发日期错误的问候。

• 只对有明确来源的生日启用：客户自己在表单里填过的、实名订单带出来的。来源不明的一律不发。
• 固定在当天的一个工作时段发，不要卡零点。零点发是机器行为的最强信号，客户感受到的是被系统记住，不是被人记住。
• 做年度幂等键，一个客户一年只发一次。数据修正、任务重跑、多账号重复归属，这三种情况都会造成重复祝福。
• 农历生日要么完整支持，要么明确不支持。半支持的结果是一部分人收到的日期是错的，而你不知道是哪部分。

还有一条内容上的判断：关怀消息里带优惠券，短期转化会好看，长期会把这条通道烧掉。客户学会「生日祝福 = 又要卖东西」之后，以后所有的关怀他都会直接划过。要放促销就别叫关怀，让它走营销流程，占营销的频次预算。

流失预警：预警的是关系变化，不是绝对沉默

「多少天没说话就算流失」这个阈值，几乎没有一个数字是对的。不同客户的自然节奏差异，比流失信号本身大得多 —— 一个每周都来问的客户沉默两周，和一个季度采购一次的客户沉默两周，完全不是一回事。用同一个数字判断，你会同时收获大量误报和大量漏报。

可用的做法是拿客户自己的历史节奏做基线：算出他过去若干次有效接触的平均间隔，当前沉默时长超过基线的若干倍才报警。这比全局阈值准得多，而且不需要任何模型，一条 SQL 就能跑出来。新客户没有基线，单独走一套固定规则，攒够几次接触后再切回基线判断。

• 主动询问频率下降：从每周主动问变成偶尔应一句，这个信号比彻底不说话出现得更早
• 只读不回：能拿到已读类事件时，这是个不错的中间态信号，值得单独建一档
• 退群、删除好友：这不是预警，是确认。报出来的时候已经晚了，它的价值在于回头校准前面两个阈值

预警必须附带「为什么」和「建议动作」。只给一份客户名单的预警，主管收到之后唯一能做的就是转发给员工，等于在链路里多插了一层噪声。把触发原因（沉默时长、历史基线、最近一次接触的内容摘要）一起给出去，这条提醒才有人真的会处理。

三类任务共用一套调度骨架

三类场景的业务含义差别很大，工程结构却是同一个：定时扫描、状态判定、分发，发送统一走 wecomapi 的消息通道。把这个骨架抽出来，后面加第四类、第五类场景就只是加一个判定函数。

1. 1判定和发送分离。判定可以随便重跑，发送必须幂等。两者混在一个任务里，任何一次重跑都会重复打扰。
2. 2扫描按账号分片。发送限速是账号维度的，分片键就得跟着账号走，否则一个大客户经理的名单会把整批任务卡住。
3. 3所有自动动作写进客户时间线。销售打开会话时要能看见「系统昨天发过生日祝福」，否则他会再问候一次。这条最容易被跳过，也最影响客户感受。
4. 4每类场景独立开关，且能按账号、按客户维度停。出问题时你需要的是关掉一类，不是关掉整个调度器。