WhatsApp 活动跟进规则设置：按回复、点击或未回复状态触发后续动作与最佳发送时间

概览

活动跟进把自动化挂接到一条 WhatsApp 营销活动上：活动发出后，每位收件人会按互动情况与一组规则匹配 — 已回复、已点击、已读、已送达未读、X 小时内未回复、失败等 — 匹配后为该收件人触发一个动作。动作包括启动一条流程、发送一条模板（可复用消息内容）、把联系人加入滴灌式活动、添加或移除标签、指派人工坐席，或让联系人退订。

配套的最佳发送时间工具会分析你的受众在过去活动中真正活跃的时段，并建议下一个发送日与小时。它纯粹基于统计 — 没有 AI，也不训练模型。

持久化设计。与滴灌式活动一样，延迟跟进是持久化的：每个待执行动作都是数据库中的一条记录，带有到期时间戳，因此重启只会推迟它，绝不会丢失。

你将获得

• 每个活动各自的跟进规则，在活动构建器的跟进（Follow-ups）步骤中定义；创建与编辑时都采用整组替换语义。
• 同时支持立即与延迟两类触发事件：
  • 立即（辅助服务上报的那一刻触发）：已回复、点击按钮、点击链接、已读、失败。
  • 延迟（等待一段时间后评估）：已送达未读、已读未回复、已发送未回复、未送达。
• 动作：启动流程、发送模板、加入滴灌、添加标签、移除标签、指派坐席、退订。
• 每位收件人对每条规则只触发一次的保证（无论立即还是延迟）。
• 最佳发送时间：一张 7×24 的星期×小时互动热力图，并给出建议的下一次发送时段，显示在活动的 Schedule 步骤中。
• 活动详情页上的每条规则结果统计。

前提条件

• 套餐已授予 access_campaign_followups 的工作区。没有该权限时，跟进步骤会被隐藏，任何提交的规则也会被忽略。
• 一条用于挂接规则的 WhatsApp 营销活动。
• 最佳发送时间需要足够的历史互动数据（候选小时必须达到最低样本量），来自最近 120 天内的活动。

权限按套餐授予。没有专门的管理后台页面 — 在工作区套餐上授予 access_campaign_followups，即可显示跟进步骤并启用规则执行。触发延迟规则的后台扫描器注册在系统的后台心跳上（与活动排期、定时消息和广播扫描器并列），无需配置 cron。

定义跟进规则

1. 在活动构建器中创建或编辑活动（WhatsApp Campaigns → Create / Edit）。
2. 打开跟进（Follow-ups）步骤。（仅当套餐包含活动跟进时可见。）
3. 添加一条或多条规则。每条规则设置：
   • 当（触发事件） — 例如已回复、点按快捷回复按钮、点击链接、已读、已送达未读、已读未回复、已发送未回复、未送达、失败。
   • 延迟 — 对未回复 / 仅送达 / 未送达事件，设置数值加单位（分钟、小时或天），从收件人发送时刻起算；延迟结束后重新检查条件，仍然成立才会触发。立即事件没有延迟。
   • 则（动作）及其目标 — 启动流程、发送模板、加入滴灌、添加 / 移除标签、指派坐席或退订。选择器会列出工作区的流程、模板、滴灌、标签与坐席。
4. 保存活动。规则按顺序保存；编辑会替换整组规则。

规则如何运行

• 立即规则在辅助服务上报互动结果（回复、点击、已读、失败）时直接触发。每条规则对每位收件人最多触发一次，并通过原子占位保护，防止并发上报重复触发。
• 延迟规则在发送时创建一条持久化的待执行记录（到期时间 = 发送时间 + 延迟）。后台扫描器查找已到期的记录并触发 — 但仅在否定条件仍然成立时（例如收件人仍未回复）。若期间收件人已经回复，该记录会被跳过。

最佳发送时间

1. 在活动构建器的 Schedule 步骤中打开最佳时间建议。
2. 工具会按你的工作区时区显示星期几 × 小时的互动热力图，在过去 120 天的数据中，回复与点击的权重高于被动的已读。
3. 数据足够时，它会高亮最佳时段并给出标签（例如 “Tuesday 10:00–11:00”），以及该时段的下一个未来日期和时间，供你安排发送。

纯统计。最佳发送时间把过去的已读 / 回复 / 点击时间戳聚合为网格，并对达到最低样本阈值的峰值小时进行排序。它不训练模型，也不保证效果；历史数据太少时不会返回建议。

监控

打开活动的详情页。每条跟进规则都会显示其触发事件、延迟、动作、目标与执行计数：

说明与限制

• 时序。延迟规则由后台心跳按有限批次触发，因此会在到期时间当时或稍后触发，而非精确到秒。待执行动作是持久化的数据库记录，重启只会推迟，不会丢失。
• 幂等。每条规则对每位收件人最多触发一次。对已有收件人重新应用规则（回填）可以安全地重复运行。
• 条件复查。对延迟的未回复 / 仅送达规则，触发时会根据收件人当前状态重新评估条件；已退订的收件人始终跳过。
• 最佳发送时间只是统计 — 它不训练模型，也不保证效果，历史数据太少时不会返回建议。
• 失败的动作会连错误原因一起记录在执行记录上，绝不影响活动本身。