做客户运营的朋友应该都有同感：拉新那一下大家都舍得花钱，但拉来之后呢？名单躺在 CRM 里，超过三十天没有互动，从“高意向客户”悄悄变成了“沉默客户”。销售靠手机通讯录一个个手动跟进，一天撑死一百多条，还要被各种“在忙”“再考虑”挡回来。我去年接手客户唤醒这块时，第一件事就是把“定时任务+企微消息API”这套自动化唤醒触达链路搭起来：每天固定时间自动扫描沉默客户列表，生成带有明确理由的唤醒文案，通过企业微信应用消息直接触达客户，再把客户的回应和点击行为回收回来。这篇文章是系列第二篇，重点讲调度方案选型、企微消息接口接入，以及链路跑通之后那些文档里不会写的坑。适合自己搭 CRM 客户池、或者负责客户触达系统的技术和运营同学参考。
1. 先搞清楚唤醒对象：沉默客户不是一个文件夹
1.1 沉默阶段的分层标准
很多团队把“超过 N 天没互动”一刀切成沉默客户，然后统一走同一套话术，这是最大的浪费。不同沉睡深度的客户，心理状态和唤醒成本完全不一样。我把客户池按“距最近一次有效互动”拆成了四层：
| 层级 | 定义 | 唤醒难度 | 建议策略 |
|---|---|---|---|
| 流失预警期 | 7-14天未互动 | 低 | 轻量提醒，以服务/关怀为主 |
| 已沉默期 | 15-30天未互动 | 中 | 权益类或利益点触达 |
| 深度静默期 | 31-90天未互动 | 高 | 强钩子+人工衔接 |
| 流失期 | 超过90天未互动 | 极高 | 不主动推，转召回类活动 |
这套分层是运营团队反复校准的结果。预警期客户往往只是“最近忙忘了”，一条温和的消息就能拉回来；深度静默期堆再多“亲，好久不见”也没用，需要给出足够具体的理由和利益。计算沉默天数时一定要注意：不要拿“最后登录时间”当唯一口径，对 B 端客户来说“有效互动”应该至少包含：登录/访问、工单反馈、销售通话、企微会话回复这几类事件里的任意一种。
1.2 每条唤醒消息都必须有一个“理由”
这是最容易踩的坑：定时任务每天准点给沉默客户发“早安+优惠券”，发了一个月发现触达率越来越高，回复率越来越低，甚至有人直接拉黑。原因很简单，客户不关心你建了多漂亮的唤醒系统，他关心的是“你凭什么在这个时间点打扰我”。
所以我在设计唤醒任务时，给每条策略绑定了触发理由，没有理由的触达一律不建：
- 客户上次咨询过某产品，但 15 天没有后续动作 → 跟进型唤醒
- 客户账户里有一张即将到期的权益券/积分 → 到期提醒型唤醒
- 客户常用的产品有版本更新或新能力 → 内容型唤醒
- 大促/活动与客户历史偏好匹配 → 活动型唤醒
每次生成消息时，任务系统必须能从数据里拼出这个理由，拼不出来就跳过。宁可少发一条，也不能发一条“没头没脑”的消息。客户唤醒的本质不是“提醒他你还在”，而是“重新给出一个让他愿意回应的由头”。
1.3 用一张唤醒计划表管住全部状态
唤醒任务不能做成“每天临时查一次、发完就拉倒”，那样没法统计、没法排重、也没法追踪效果。我习惯在数据库里维护一张唤醒计划主表，字段大致是：
CREATE TABLE `wakeup_plan` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` varchar(64) NOT NULL COMMENT '企微UserID', `customer_id` varchar(64) DEFAULT NULL COMMENT 'CRM客户ID', `wakeup_stage` tinyint(4) NOT NULL COMMENT '沉默阶段：1预警 2沉默 3深度静默', `strategy_code` varchar(32) NOT NULL COMMENT '策略编码，如FOLLOW_UP', `next_send_date` date NOT NULL COMMENT '计划触达日期', `task_id` bigint(20) DEFAULT NULL COMMENT '本次执行的调度任务ID', `msg_id` varchar(64) DEFAULT NULL COMMENT '企微消息ID', `send_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0待发送 1已发送 2发送失败', `reply_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0未回复 1已回复', `open_status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '0未打开企业微信 1已打开', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY `uk_task_user` (`task_id`, `user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;唤醒计划表的核心作用是：让“定时扫描”和“触达执行”解耦。每天定时任务只负责筛选客户、插入待触达记录；发送任务再拉着计划表里的待发记录去批量调企微 API。这两个环节分开，出错时处理起来非常清晰——是筛选逻辑的问题，还是发送环节的问题，一眼就能定位。
2. 定时任务选型：单机调度、XXL-Job 还是 Serverless
2.1 别一上来就上重武器：Spring Boot @Scheduled 够用场景
如果你的团队还在起步阶段，客户量不大，也不存在多实例同时跑任务的问题，那 Spring Boot 自带的@Scheduled是最低成本的起步方案。代码就几行：
@Component public class WakeupScanScheduler { @Scheduled(cron = "0 30 9 * * ?") public void scanSilentCustomers() { // 1. 查询符合条件的沉默客户列表 // 2. 写入 wakeup_plan 表 // 3. 触发发送执行器 } }cron表达式里0 30 9 * * ?表示每天早上 9 点 30 分执行一次。这个时间不是随便定的，我建议把唤醒消息的发送时间放在上午 9 点 30 到 11 点之间，避开刚上班的半小时，也避开午休。这个细节直接拉高触达后的回复率。
但@Scheduled有几个明显的坑：
- 集群部署时，每个实例都会执行一次同样的任务，不做分布式锁就会出现重复触达。
- 任务执行到一半进程重启，没有任务日志，没法追溯“上次跑到哪了”。
- 没有运维界面，任务参数调整要改代码重新发版。
怎么判断自己是否需要升级？看两点：应用实例数是否大于 1，以及每天要处理的任务量是否达到几千条以上。两个条件都不满足，老老实实用@Scheduled加 Redis 锁就能撑住早期阶段。
2.2 Spring Cloud 架构下的实际选择：XXL-Job
如果你的系统是 Spring Cloud 微服务架构，多个服务实例同时部署，这时候再用@Scheduled就是给自己埋雷。我这边最终选的是 XXL-Job，原因很务实：它和 Spring Boot/Spring Cloud 亲和度最好，社区活跃，文档也全。
XXL-Job 的核心用法是：调度中心独立部署，执行器嵌在业务服务里，通过注册中心自动发现。我用到的能力有三个：
- 分片广播：按客户 ID 哈希取模拆分成多个分片，每个执行器处理自己负责的那一片，解决“几万条客户一次性扫不完”的问题。
- 调度日志：每次任务跑完，调度中心能看到每个分片的执行结果、耗时、异常堆栈，排查问题效率高很多。
- 失败重试：可以配置失败重试次数和间隔，对于企微 API 偶发超时有实际意义。
核心代码大致是这个结构：
@XxlJob("silentCustomerWakeup") public ReturnT<String> silentCustomerWakeup(String param) throws Exception { int shardIndex = XxlJobHelper.getShardIndex(); int shardTotal = XxlJobHelper.getShardTotal(); // 按分片拉取客户 List<Long> customerIds = customerMapper.selectSilentCustomersByMod(shardTotal, shardIndex); for (Long customerId : customerIds) { // 生成唤醒计划、发送企微消息 wakeupService.process(customerId); } return ReturnT.SUCCESS; }注意这里用customerId % shardTotal == shardIndex的方式来路由分片，而不是直接用进程内随机分配。原因是保证同一个客户每次任务都由同一台机器处理，后续做状态校验和幂等会轻松很多。
XXL-Job 的“调度中心”本身也是一个服务，得单独部署。我见过不少团队嫌麻烦，后来用了 Oracle 的 Scheduler 或者自研调度表，最后都绕回来自建或者上现成框架，原因一致：分布式任务最缺的不是“到点触发”，而是“失败可查、重试可控、任务不重复”。
2.3 轻量场景的另一种答案：Serverless 定时触发器
如果你的客户唤醒链路没那么重，比如只是每天早上从数据库取一批名单，调企微 API 发一条消息，没有复杂的审批流转，那用 Serverless 定时触发器也很合适。
主流云厂商都提供定时触发器，配置一个 Cron 表达式，到点自动拉起云函数。好处是：
- 不用维护调度中心，没有常驻服务器成本。
- 天然单实例执行，不会出现多机重复跑的问题（前提是别把触发间隔压得太极限）。
- 弹性伸缩，任务量上去也不怕。
我看最近很多人在讨论 Serverless 定时任务，比如拿它做每日签到类的自动化，其实思路完全一致：定时触发 + HTTP 调用外部接口 + 记录执行结果。做唤醒触达也只是把“外部接口”换成了企微 API。需要注意 Serverless 的执行时长限制，一般默认几分钟，如果名单扫描 + 消息发送超过这个时间，就要把任务拆成“扫描一个批次、发完一批再触发下一批”的接力模式。
2.4 我的选型建议总结
拿我们实际遇到的场景举个例：一开始只有一台服务器，每天跑一次 @Scheduled，后来业务扩容到 3 个实例，立刻发现在凌晨任务时间点大家同时开跑，客户收到两条一模一样的消息。后来切到 XXL-Job + 分片广播，问题才真正解决。所以选型不是越高级越好，而是跟着系统规模走。
| 方案 | 适用场景 | 优点 | 注意事项 |
|---|---|---|---|
| Spring Boot @Scheduled | 单实例、小数据量 | 零成本、上手快 | 集群下要加锁，无任务日志 |
| XXL-Job | Spring Cloud 多实例、任务量中等偏上 | 分片、调度日志、失败重试 | 需额外部署调度中心 |
| Serverless 定时触发 | 轻量独立任务、不想维护调度组件 | 免运维、按量付费 | 执行时长受限，无状态化设计 |
| Axum/Rust 生态定时任务 | 技术栈是 Rust 的团队 | 性能好、可嵌业务 | 生态相对小众，团队要熟悉 |
这套对比不仅适用于唤醒触达，其他任何“到点跑批”的业务都能复用判断框架：先看实例数，再看任务量，最后看你在不在意任务日志。
3. 企微消息 API：把唤醒消息送到客户面前的完整链路
3.1 接入前的必要准备：自建应用、可见范围、可信 IP
要在企微侧发主动消息，最常用的是“自建应用消息”通道。它的逻辑是：企业微信内部创建一个应用，这个应用被授权可以主动给成员（也就是你的客户）发消息。
准备步骤依次是：
- 登录企业微信管理后台，进入“应用管理 - 应用 - 自建”，创建一个应用。创建后你会拿到
AgentId和Secret，这两个参数是所有消息接口的前提。 - 配置“应用可见范围”。这一步最容易被忽略，坑也最大：自建应用只能给可见范围内的成员发消息。如果你把可见范围设成了某个部门，那这个部门之外的客户 UserID 即使存在，消息也发不出去。
- 配置“企业可信 IP”。企微 API 对来源 IP 有校验，只允许可信 IP 地址调用。服务端如果是动态公网 IP，需要固定入口或者走代理网关。
- 如果要用回调接收消息状态，还需要配置回调 URL、Token 和 EncodingAESKey。
准备好这三样东西，等于给你的“唤醒触达”开了一条合规、稳定的消息通道。
3.2 access_token 的获取与全局缓存
企微 API 的鉴权方式是先拿 access_token，再拿它去调消息接口。有个关键细节：access_token 的有效期是 7200 秒，而且整个企业同一应用只有一个 access_token，它会被并发获取的请求互相覆盖，处理不当会出现“刚拿到的 token 突然失效”的诡异问题。
正确做法是全局缓存 + 加锁刷新：
@Component public class WeComTokenManager { private static final String TOKEN_KEY = "wecom:access_token"; private final StringRedisTemplate redisTemplate; private final RestTemplate restTemplate; public String getAccessToken() { String cached = redisTemplate.opsForValue().get(TOKEN_KEY); if (StringUtils.hasText(cached)) { return cached; } // 双检锁，防止多个线程同时刷新 token synchronized (weComTokenLock) { cached = redisTemplate.opsForValue().get(TOKEN_KEY); if (StringUtils.hasText(cached)) { return cached; } String token = fetchTokenFromWeCom(); redisTemplate.opsForValue().set(TOKEN_KEY, token, 7000, TimeUnit.SECONDS); return token; } } private String fetchTokenFromWeCom() { String url = "https://qyapi.weixin.qq.com/cgi-bin/gettoken" + "?corpid=" + corpId + "&corpsecret=" + secret; // 返回结果中取 access_token return restTemplate.getForObject(url, JsonNode.class).get("access_token").asText(); } }这里有两个小心思：缓存时间设置成 7000 秒而不是 7200 秒，留出刷新余量；用 Redis 而不是本地内存缓存，保证多实例环境下拿到的是同一个 token，不会你自己刷新一次把别人的 token 顶掉。
企微 API 调用返回码里，40014是“不合法的 access_token”，42001是“access_token 过期”。我建议在发送消息前先检查返回码，如果遇到这两个错误码，立即清掉 Redis 缓存重新拉取再重试一次，能把大部分偶发失败直接救回来。
3.3 发送应用消息：接口链路与参数细节
拿到 token 之后，发送应用消息的接口是POST /cgi-bin/message/send，请求体长这样：
{ "touser": "zhangsan", "msgtype": "text", "agentid": 1000002, "text": { "content": "您好，您上次咨询的报价方案我们已更新，点击查看最新权益 >" } }核心参数说明：
touser：接收成员的 UserID，一次调用可以传多个，用竖线分隔，最多 1000 个。但从控制节奏的角度，我不建议一次塞满，后面会讲原因。msgtype：消息类型。文字场景用text就够，想带点排版和链接样式可以换markdown类型，图文卡片可以用news。agentid：自建应用的 AgentId。text.content：消息正文。text 消息的内容长度限制在 2048 字节以内，包含超链接文本时，链接本身也会占长度，写文案时记得留余量。
注意：这个接口发送的是“应用消息”，客户在企业微信里会收到一条来自对应应用的通知消息，而不是像个人微信那样直接显示在聊天列表里。这是渠道特性，不是 bug。从唤醒场景看，应用消息的优势是带应用标识和跳转链接，配合图文形式比普通聊天消息更有“服务感”。
3.4 通过回调拿到送达结果
只是把 send 接口调用成功还不够，“成功”只代表企微接受了，不代表客户看到了。要判断“客户是否打开了这条消息”，需要配置企微回调。
在自建应用的回调配置里，订阅“接收消息”事件后，企微会把一条消息是否被点击、成员会话状态等事件推送到你的回调服务。实际操作中最有价值的两个事件是：
- 用户点击了应用消息里的链接或按钮
- 用户直接在企微会话里回复了该应用
收到回调后，去更新 wakeup_plan 表的open_status和reply_status。这一步是整个唤醒系统真正能闭环的关键：只有知道“哪些客户看了没回、哪些回了”，后续的二次触达和人工跟进才有依据。
我见过不少团队把唤醒做到“发出去”就结束了，然后说“唤醒没效果”，其实是链路没闭合——你根本不知道哪些消息被打开了，自然没法优化文案和时机。
4. 一条完整唤醒链路：从名单扫描到行为回收
4.1 整体任务编排逻辑
把定时任务和企微消息链路拼起来之后，一天的实际执行流程是这样的：
- 早晨 9 点，XXL-Job 触发“名单扫描任务”，按沉默分层标准查出当天需要触达的客户。
- 将客户写入 wakeup_plan 表，状态为待发送，同时给每个客户匹配策略和文案模板。
- 9 点 30 分，触发“消息发送任务”，从计划表取待发记录，按批次发送企微应用消息。
- 发送成功后更新 send_status = 已发送，记录 msg_id。
- 全天内，企微回调持续监听客户是否打开、是否回复，更新对应字段。
- 当天跑完，运营后台能看到整体触达率、打开率、回复率。
这个流程最关键的设计是“扫描”和“发送”分开，原因很实际：扫描阶段如果 SQL 写错了或者数据源有问题，只影响计划表的生成，不会误发消息；发送阶段如果企微接口抽风，只需要重跑发送任务，不需要重新筛选客户。
4.2 候选筛选：去重、接触上限、黑名单
筛选逻辑不是一句“查最近互动超过 30 天”那么简单。我沉淀下来的三个必要过滤条件：
- 策略周期排重：同一个客户同一策略周期内只能触达一次。比如“超期未回访”策略，15 天之内不能对同一个人重复触发；防止客户连续两周各收到一条差不多的“您在吗”。
- 全局频控上限：每个客户每周最多接收 2 条唤醒类应用消息，超过就走人工跟进渠道。这个上限最初是拍脑袋定的，跑了一个月之后发现回复率下降的拐点正好在 2 条，就保留了下来。
- 排除名单：已回复客户、已退订客户、黑名单客户必须第一时间从候选集剔除。这些名单维护在单独的配置表里，扫描 SQL 里 join 排除。
筛选 SQL 的骨架大概是：
SELECT c.id, c.user_id FROM customer c LEFT JOIN wakeup_plan wp ON wp.user_id = c.user_id AND wp.task_id = ? -- 本次任务ID LEFT JOIN blocklist b ON b.user_id = c.user_id WHERE c.last_active_time < DATE_SUB(NOW(), INTERVAL 30 DAY) AND c.is_black = 0 AND b.id IS NULL AND NOT EXISTS ( SELECT 1 FROM wakeup_plan w WHERE w.user_id = c.user_id AND w.strategy_code = 'FOLLOW_UP' AND w.created_at > DATE_SUB(NOW(), INTERVAL 15 DAY) )这套 SQL 有一个隐含假设：task_id和user_id的组合唯一。所以我在建表时特意加了联合唯一索引，防止发送任务重跑时插入重复计划，这是幂等设计的第一层保险。
4.3 触达节奏与文案结构设计
唤醒触达最容易犯的错是“想一次把话说尽”。文案里又放问候、又放产品介绍、又放优惠券、又放链接，结果客户根本不知道你来找他干嘛。
我通常用三段式结构：
- 第一句：说清楚身份和来由。比如“您好，我是XX客户成功团队的小周”，或者“您账户里有张优惠券快要到期了”。
- 第二句：给出具体理由或利益点。这里一定要落到客户身上，而不是你们的活动名称。
- 第三句：给一个极低门槛的行动指令。“回复 1 查看详情”“点开链接领取”，不要让客户思考下一步做什么。
发送节奏上，我强烈建议做“周轮询”而不是“天天发”。例如周一发跟进型，周三发权益提醒型，周五发内容型。当一个客户连续三周被唤醒都没有任何回应，就别再自动发消息了，转给人工做最后一轮电话/线下触达。自动化的价值在于规模化覆盖，但最后的破冰动作往往是需要温度的。
4.4 发送状态与客户行为回收
发送完成后，wakeup_plan 表的状态更新逻辑要明确：
| 状态字段 | 取值 | 更新时机 |
|---|---|---|
| send_status | 1 已发送 | send 接口返回成功 |
| open_status | 1 已打开 | 企微回调收到打开事件 |
| reply_status | 1 已回复 | 企微回调收到客户回复消息 |
这里有一个细节：客户回复企业微信应用消息时，企微回调推给我们的数据类型是普通消息事件，需要在回调里解析发送者 UserID，再回写 wakeup_plan 表。客户回复的内容不一定要做复杂的 NLP 分析，可以先把“是否回复”当作关键信号，回复内容推给销售人工判断即可。
这一步真正的价值是：运营团队可以看实时看板，比如“今天发了 800 条，打开率 42%，回复率 11%”，第二天做投放策略调整就有了数据依据，而不是凭感觉。
5. 生产环境踩过的坑：频控、token 失效、重复触达
5.1 企微接口的频控不是“总条数”，是“人均条数”
刚开始自测时，我用一个测试号连发几十条消息都没事，以为接口没有限制。上线第一天，客户量一上来，消息发送任务跑了几分钟就开始报45009——接口调用超过频率限制。
仔细看错误码对应的文档才发现，企微应用消息的限频是按“每个成员每分钟最多接收 2 条”这个维度卡控的，不是你企业的总发送量。也就是说，同一个客户如果正好同时出现在两个任务里，一前一后两条消息发过去，第二条很可能直接限频失败。
解决方案有两层：第一，任务调度层面给每个客户设置全局频控，保证同一客户在同一分钟窗口内最多只会进一个发送批次；第二，发送任务里对企微返回的频控错误码做特殊处理，遇到45009就把这条记录标记为“延后处理”，放到下一个批次再发，而不是直接标记失败并丢弃。
5.2 重跑任务造成重复触达
唤醒任务因为是“扫描+发送”两步，任何一步失败都会有人选择“重跑任务”。如果发送环节没有做幂等，重跑一遍全量计划，客户收到的就是两遍完全相同的消息，运营和销售的投诉电话会立刻打爆。
我的处理是两层幂等：
- 数据库层：
task_id + user_id联合唯一索引，插入计划表时重复记录直接失败。 - 发送层：发送前先查 wakeup_plan 表，
send_status = 1的记录直接跳过。
5.3 串行发送慢到“任务超时”
第一版发送执行器图省事，用 for 循环一条条调企微接口。1 万条消息差不多要跑 20 分钟，一旦中间网络抖动，整个任务就卡死。
后来改成“分批 + 线程池 + 队列”的方式：
public void batchSend(List<WakeupPlan> plans) { // 每批 100 条，用固定大小线程池并发调用 ExecutorService executor = Executors.newFixedThreadPool(10); List<List<WakeupPlan>> batches = Lists.partition(plans, 100); for (List<WakeupPlan> batch : batches) { CountDownLatch latch = new CountDownLatch(batch.size()); for (WakeupPlan plan : batch) { executor.submit(() -> { try { weComMessageClient.send(plan); } finally { latch.countDown(); } }); } latch.await(); Thread.sleep(500); // 小幅休眠，避免触底限频 } }核心是：单批次并发、批次间休眠、整体受控。线程数不要贪多，10 个对企微接口已经足够，再多反而容易触发对端限频。实测同等数据量下，这个方案的发送时间从串行的 20 分钟压到 4 分钟左右。
5.4 一条必看的自查清单
给你一份上线前自查清单，每条都是坑换来的：
- 自建应用可见范围是否包含全部目标客户
- 服务端出口 IP 是否已配置为企业可信 IP
- access_token 是否走了全局缓存加锁刷新
- 计划表是否有唯一键防止重复插入
- 发送任务是否做了批次并发和频控休眠
- 回调地址是否配置、是否订阅了消息事件
- 是否对常见错误码（40014、42001、45009）做了重试或延后逻辑
6. 唤醒效果怎么算：指标口径与后续优化
6.1 真正该盯的三个指标
唤醒任务上线后，运营最关心的往往是“今天发了多少条”。但“发出去”不产生价值，我一般只看三个指标：
- 打开率：已发送消息中被打开的比例，反映文案吸引力和触达时机。
- 回复率：已打开消息中客户有实际回复的比例，反映利益点是否打动人。
- 有效唤醒率：回复后 7 天内有实质互动（下单/跟进/建立联系）的比例，这是最终业务价值。
打开率低，先调发送时间和文案开头；回复率低，重点调利益点和行动指令；有效唤醒率低，问题往往出在前端筛选——客户本身已不是有效线索，别在这个池子里烧钱。
6.2 从自动化群发走向人工衔接
自动化任务跑稳之后，下一步一定是“机器找到有意向的人，人工跟进真正重要的事”。我会把 wakeup_plan 表里回复状态为“已回复”的客户记录实时推给对应的销售/客服，由人在企微会话里继续聊。回复但还没成交的客户，比任何沉默客户都有价值，不能让他们在系统里躺着等下一个定时任务。
这里要注意一个边界：自动化适合做第一波唤醒，不代表它能替代销售。客户回复后的人工衔接如果断档，前面所有自动化工作都白费。可以在企微侧配置“客户联系”功能，把会话记录同步给销售，销售看到的是客户从哪条唤醒消息里点进来的，对话开场自然很多。
6.3 这套体系还能迁移到哪些场景
定时任务加企微消息这套组合，本质上是一个“根据业务状态主动触达”的通用骨架。跑通唤醒之后，我把它延伸到了另外几个场景：
- 新客户欢迎：注册后第三天自动发一条使用引导。
- 流失预警：核心客户 7 天未活跃，自动通知客户成功经理。
- 权益到期：优惠券/积分到期前 3 天自动提醒。
- 订单异常：订单长时间卡在中间状态，自动推送催办提醒。
每个场景只是换了筛选条件、文案模板和回调处理逻辑，调度、发消息、状态回收这些底座都没有变。这也是我为什么先把唤醒链路打磨稳的原因——它是所有主动触达业务的基石。
我自己跑下来的体会是：定时任务和企微消息 API 本身都不复杂，真正复杂的是把“运营节奏”翻译成“调度策略”，再把“发送成功”翻译成“客户真的回应了”。宁可少触达，不要瞎触达；宁可先跑 100 条测试名单，也不要一上来就全量。最后再分享一个小习惯：每次上线新的唤醒任务前，我会先用测试成员列表跑一轮 mock 发送，人工检查文案、链接、App 跳转是否正常，再放开全量。这个动作已经帮我避免了好几次“上线两小时收到十几条投诉”的尴尬。
