drop-off-rescue

流失挽回

推动停滞在转化漏斗中的联系人进入下一步。此技能会找出已注册但未转化的用户，起草符合其所处阶段的再互动邮件，并在连接 ESP MCP 后，于获得明确确认后安排发送。可每周重复运行，不会重复发送——此技能会按阶段追踪已发送的邮件，并跳过仍处于冷却期内的联系人。

支持三种模式：

• cloud — Cogny MCP + ESP MCP：完整自动化、跨 ESP 去重、发现结果
• solo — 仅 ESP MCP：基于标签去重、按 ESP 自动化
• free — 不使用 MCP：粘贴停滞联系人的 CSV，仅生成邮件草稿（由你手动发送）

用法

/drop-off-rescue              # weekly rerun — default
/drop-off-rescue weekly       # same
/drop-off-rescue audit        # read-only: report stalls + what would be sent, write nothing
/drop-off-rescue free         # no MCP — paste CSV of stalled contacts

此技能旨在通过 /loop 或 /schedule 每周定时运行。重复运行时，会跳过已发送提醒的联系人；纳入新近停滞的联系人；并在输出中祝贺已取得进展的联系人。

步骤 1 — 检测模式

探测两个 MCP 命名空间：

1. 如果至少有一个 ESP 提供 mcp__cogny__<svc>__* 工具 → cloud 模式（并记录该 ESP 为已连接）。
2. 否则，如果至少有一个 ESP 提供 mcp__<svc>__* 工具 → solo 模式。
3. 否则 → free 模式。

如果参数为 free，无论当前连接了什么，都强制使用 free 模式。

如果连接了多个 ESP，询问用户要使用哪一个（或者提出全部运行，并在 cloud 模式下跨 ESP 去重）。

步骤 2 — 标准漏斗阶段

此技能使用一套标准阶段分类。用户可以扩展这套分类，但这些 slug 决定了标签名称、营销活动命名和去重状态——请确保在各次运行间保持稳定。

电子商务：

Slug	含义	典型停滞时间
browse-abandoned	浏览过商品，但从未加入购物车	1–3 天
cart-abandoned	已加入购物车，但从未结账	1–2 天
checkout-abandoned	已开始结账，但未提交	数小时–1 天
post-first-order-silent	完成首次下单，此后没有互动	14–30 天

SaaS / 试用漏斗：

Slug	含义	典型停滞时间
signup	已创建账户，但没有任何操作	1–3 天
no-channel	已注册，但未连接数据源 / 集成	3–7 天
no-trial	已连接渠道，但尚未开始免费试用	7 天
no-client	试用已激活，但尚未连接使用该服务的工具 / 客户端	3 天
no-subscription	试用已结束，但未转为付费用户	试用结束后 0–3 天
trial-started-inactive	已开始试用，但没有实质性使用	3–5 天
trial-ended-no-convert	试用已结束，但未订阅	结束后 7 天

Cogny 自身的 Solo 漏斗（注册 → no-channel → no-trial → no-client → no-subscription）是这套分类的良好参考实现。

如果用户描述的漏斗阶段与这些 slug 不匹配，请添加新的 kebab-case slug——只要确保在重复运行时保持稳定即可（slug 是去重键）。

第 3 步 — 确定每位联系人的当前阶段

主要信号：ESP 标签／细分。 使用各 ESP 对应的工具，读取带有 stage:<slug> 标签的联系人：

ESP	读取阶段标签	应用阶段标签	安排／发送
Klaviyo	使用 list_profiles 按细分／属性 stage 筛选	update_profile（属性）	创建并安排营销活动
Mailchimp	使用 tool_list_members 按标签筛选	tool_update_member（标签）	安排营销活动
Rule	使用 tool_list_subscribers 按标签筛选	tool_add_tag_to_subscriber	tool_schedule_campaign
Get a Newsletter	使用 tool_list_contacts 按标签筛选	tool_update_contact（标签）	使用 time_to_send 调用 tool_send_draft

基于 Klaviyo 事件的后备方案（仅当缺少 stage:cart-abandoned 标签时）： 使用 metric="Added to Cart" 查询过去 7 天的 list_events，排除之后有 Placed Order 事件的档案。通过 update_profile 写回 stage:cart-abandoned 标签，确保下次运行时结果一致。

对话式后备方案（任何 ESP，在完全没有阶段标签时）：

1. 询问用户：“我没有看到联系人的任何 stage:* 标签。以下哪些漏斗阶段适用于你的业务？”——列出标准 slug。
2. 针对用户选中的每个阶段，询问：“哪些人属于这个阶段？请描述条件，例如 加入列表 > 3 天 AND 未购买，或 点击了邮件 X，但从未访问 /signup。”
3. 将每个判断条件转换为 ESP 支持的筛选条件（列表成员资格、标签、日期范围、点击的链接），并预览匹配数量。
4. 在第 7 步的确认门槛下，提供立即应用 stage:<slug> 标签的选项，以便今后的运行完全自动化。

第 4 步 — 检测已发送邮件（核心机制）

每周重新运行时，不得向同一联系人重复发送相同阶段的邮件。该技能采用三层混合机制：

第 1 层 — 联系人标签（主要机制，适用于所有已连接 ESP 的模式）

每次成功发送后，向收件人写入三个标签：

• rescue-sent:<slug>:<YYYY>-W<WW> — 仅追加；每周提醒一次
• rescue-last-stage:<slug> — 覆盖写入；始终反映最近提醒的阶段（一次读取即可检测阶段推进）
• rescue-last-sent:<YYYY-MM-DD> — 覆盖写入；用于计算冷却期和执行全局 7 天防疲劳规则

为何以标签作为主要机制：无需上下文树即可在单机模式下工作，支持跨设备使用，四个 ESP 都提供标签写入工具，可由用户在 ESP UI 中调试，出错时也可批量清除。

第 2 层 — ESP 营销活动名称约定（后备方案）

每个挽回营销活动都严格命名为：

drop-off-rescue / <stage-slug> / <YYYY>-W<WW> / <variant A|B>

重新运行时，如果联系人的标签已被移除（手动编辑、同步工具），则会扫描过去 35 天的 list_campaigns / tool_list_campaigns / tool_list_sent，查找名称匹配的营销活动。再通过各 ESP 对应的报告工具（list_events、tool_get_report、tool_get_campaign_statistics、tool_get_report）交叉核对收件人。

有意不在主题或预览文本中添加标记——让用户在收件箱中看到的内容保持简洁。

第 3 层 — Cogny 上下文树日志（仅云端模式）

每次发送时写入：

insights/drop-off-rescue/<slug>/<sha256(email)[:12]>/last-sent
  → { "week": "2026-W17", "variant": "A", "esp": "klaviyo", "ts": "2026-04-24T10:00Z" }

下次运行时读取此日志。此层可捕获跨 ESP 重复发送的情况——同一组织下同时存在于 Klaviyo 和 Mailchimp 的联系人，在同一周内不会收到两次提醒。

去重判定

如果三层中的任意一层在冷却期内报告命中，则该联系人被归类为**“当前阶段冷却期内已提醒”**。默认冷却期（将在输出中显示，用户可覆盖）：

阶段	冷却期
cart-abandoned、checkout-abandoned	7 天
browse-abandoned、signup、no-channel	14 天
no-trial、no-client、no-subscription、trial-started-inactive	21 天
post-first-order-silent、trial-ended-no-convert	30 天

步骤 5 — 对每个联系人进行分类（每周循环）

对于每个阶段，读取完整的 stage:<slug> 群组，然后对每个联系人进行分类：

类别	条件	本次操作
新停滞	当前带有 stage:<slug>，且从未有过 rescue-sent:<slug>:*	符合条件 — 变体 A
冷却期跳过	在该阶段的冷却期内带有 rescue-sent:<slug>:<week>	跳过，计为“因冷却期跳过”
再次停滞	冷却期已过，仍带有 stage:<slug>，且此前在此阶段最多发送过 2 次挽回邮件	符合条件 — 变体 B（调整语气）
已推进	rescue-last-stage 表示的阶段早于当前阶段标签	在输出中表示祝贺；在新阶段进行提醒
阶段倒退	rescue-last-stage 表示的阶段晚于当前阶段标签	标记为异常，不要自动提醒（数据问题）
已耗尽	此前在此阶段发送过 3 次挽回邮件，但仍未推进	添加 rescue-exhausted:<slug>，直到阶段发生变化前将其排除
已退出	没有任何阶段标签，但带有 rescue-last-stage	在清理阶段清除所有 rescue-* 标签

硬性上限（无论各阶段的冷却期如何，均强制执行）：

• 每个联系人在每个阶段最多提醒 3 次，之后将其标记为 rescue-exhausted:<slug>。
• 每位联系人在任意滚动 7 天内，跨所有阶段最多发送 1 封挽回邮件。如果某位联系人在一周内会收到两个阶段的邮件，只发送优先级较高的阶段（优先级顺序：cart-abandoned > checkout-abandoned > browse-abandoned > signup > no-channel > no-trial > no-client > no-subscription > activation-stages > post-first-order-silent > trial-ended-no-convert），另一个阶段的邮件延后发送。

步骤 6 — 为各阶段起草邮件

对于至少有 1 位符合条件的联系人的每个阶段，起草两个变体：

• 变体 A — 直接简短，以结果为导向。适用于首次提醒。
• 变体 B — 以价值为导向，篇幅较长，并回应可能存在的异议。适用于再次停滞（在同一阶段进行第二次或后续提醒）。

每个变体都需包含：

Stage: <slug>
Variant: A | B
Subject:    <≤55 chars, in brand voice>
Preheader:  <85–100 chars, extends subject, never repeats it>
Body:       <markdown>
Primary CTA: <label> → <URL with UTM: utm_source=email&utm_medium=rescue&utm_campaign=<slug>-<YYYY>WWW&utm_content=<A|B>>

各阶段的语气指引：

阶段	变体 A 语气	变体 B 语气
cart-abandoned	简短、有帮助，例如“还在考虑 X 吗？”	营造紧迫感 + 社会认同 + 小额优惠
checkout-abandoned	“遇到技术问题了吗？我们为您保留了购物车。”	提供优惠 + 消除阻碍（访客结账、Apple Pay）
browse-abandoned	激发好奇心，提及浏览过的类别	以内容为主（选购指南、对比）
signup / no-channel	提供帮助，例如“解锁它只需完成这一步”	创始人寄语，营造欢迎直接回复的语气
no-trial / no-client / no-subscription	明确下一步操作 + 简短教程	回应异议（“是什么让您犹豫不决？”）
post-first-order-silent	致谢 + 相关后续内容	交叉销售 + 提醒品牌价值
trial-started-inactive	“这是您 5 分钟内就能获得的最快成果”	使用场景 + 客户案例
trial-ended-no-convert	“是什么原因让您最终没有继续？”	小额折扣 + 方案推荐

使用品牌真实的语气 — 如果用户提供了品牌 URL，请先用 WebFetch 获取页面内容，以了解品牌语气。不要使用“尊贵的客户”之类的填充语。每封邮件只设置一个主要 CTA。

步骤 7 — 确认关卡（任何写入操作之前）

**在用户明确批准之前，不得调用任何 MCP 写入工具。**这同时适用于标签添加（步骤 3 的后备方案）和邮件发送 / 计划发送。

对于至少有符合条件联系人的每个阶段，原样输出以下内容并等待：

About to send via <ESP>. Nothing has been sent yet.

Stage:            <slug>       (<N> eligible)
Cooldown applied: <d>d         (<M> skipped as already-nudged)
Exhausted:        <K>          (hit 3-nudge cap — excluded)
Variant:          A | B        (<label — e.g. "first nudge" or "re-stall, value-led">)
Schedule:         <ISO timestamp, recipient-local>  |  immediate
Campaign name:    drop-off-rescue / <slug> / <YYYY>-WWW / <A|B>

Dry-run preview (first 3 recipients):
  1. <email>    subject: <rendered>
  2. <email>    subject: <rendered>
  3. <email>    subject: <rendered>

State writes on send:
  - tag rescue-sent:<slug>:<YYYY>-WWW  → <N> contacts
  - tag rescue-last-stage:<slug>       → <N> contacts (overwrite)
  - tag rescue-last-sent:<YYYY-MM-DD>  → <N> contacts (overwrite)
  - context-tree log (cloud mode)      → <N> entries

Reply with:
  send           → execute now via ESP MCP
  schedule <ts>  → queue for that recipient-local time
  variant B      → switch variant and reprint this block
  skip           → don't send, but log a "no-send" finding and continue
  cancel         → abort everything, no writes

如果 ESP 不支持原生计划发送（目前四者都不支持，但应防备未来出现此类缺口），请返回草稿，并提供建议的 at/cron 字符串，供用户自行运行。

**计划发送之前，始终检查工作流冲突：**读取 list_flows / tool_list_automations / tool_list_journeys。如果某个原生工作流已面向与当前阶段等效的细分受众群，请发出警告：

⚠️  Heads up — a native <ESP> flow already targets this segment:
    "<flow name>"  (last modified <date>, status: <active|paused>)

    Running rescue alongside it risks double-touching the contact. Options:
      [1] Pause rescue for this stage, let the native flow do the work
      [2] Pause the native flow, run rescue this week only
      [3] Proceed anyway (document the overlap)

    Which?

Get a Newsletter 没有工作流对象，因此可跳过此项检查。

Step 8 — 同意与抑制检查

每次发送前：

• 剔除 consent:marketing = false 的联系人（或 ESP 中等效的状态：已取消订阅、已清理、已退信或位于抑制名单中）。
• 剔除处于有效 rescue-exhausted:<slug> 状态的联系人。
• 无论处于哪个阶段，都剔除带有 do-not-contact / gdpr-suppressed 标签的联系人。
• 在免费模式下，用户粘贴的 CSV 必须包含 consent 列；值为 false/no/0 的行会被剔除，并显示控制台警告。

如果因同意原因被剔除的联系人超过符合条件名单的 10%，请在输出顶部指出这一点——这通常意味着用户需要关注名单卫生，并应先运行 /revenue-audit 或 /winback-engine。

Step 9 — 免费模式（无 MCP）

当 mcp__cogny__* 和任何 mcp__<esp>__* 均无法解析，或用户明确传入 free 时触发。

1. 请用户粘贴包含以下列的 CSV：email,stage,stalled_since,consent（stage 必须是 Step 2 中的 slug；stalled_since 为 ISO 日期；consent 为 true/false）。
2. 询问品牌名称和一句话的品牌语气描述（与 /welcome-series 的轻量信息收集相同）。也可以询问品牌 URL，以便使用 WebFetch。
3. 为每个阶段拟定两个变体。
4. 输出手动发送资料包：
   • 每个阶段一个符合条件联系人的 .csv（已按同意状态筛选）
   • 每个阶段的每个变体对应的邮件文案（markdown + HTML）
   • 可供复制粘贴的主题/预览文本表格
5. 不会持久化任何状态。 用户需自行去重——请在输出中明确指出。
6. 以升级提示结束：

───────────────────────────────
Ready to stop managing this by hand?

Connect your ESP via Cogny MCP and the next run will:
  • Dedupe against what you've already sent
  • Apply rescue-sent:* tags automatically
  • Schedule the send directly in your ESP after your confirmation

→ https://cogny.com
───────────────────────────────

Step 10 — 输出格式

Drop-off rescue — <ESP or "free mode"> — week <YYYY>-W<WW>
Mode: cloud | solo | free

Funnel movement since last run:
  new stalls:        +<N>
  progressions:      +<N>     (<stage_a> → <stage_b>: N; <stage_c> → <stage_d>: N)
  regressions:       <N>
  exited funnel:     <N>
  newly exhausted:   <N>

Consent drops: <N>  (<pct>% of eligible — <OK | run /revenue-audit>)

──────────────────────────────────────────────────────
Stage: cart-abandoned
  Eligible: <N>   Cooldown-skip: <M>   Exhausted: <K>
  Suggested variant: A     Send window: Tue–Thu, 10am recipient-local

  Top 10 eligible contacts:
  | email               | stalled since | prior nudges |
  |---------------------|---------------|--------------|
  | ...                 | 2026-04-21    | 0            |

  Email draft — variant A:
    Subject:    ...
    Preheader:  ...
    Body:       ...
    CTA:        [label] → <URL with UTM>

  Email draft — variant B:
    ...

  [confirmation block from Step 7]

──────────────────────────────────────────────────────
Stage: no-channel
  ...

每个包含符合条件联系人的阶段都使用一个这样的区块。没有符合条件联系人的阶段（所有联系人都因冷却期而跳过或已耗尽）只需提供一行摘要，无需完整区块。

Step 11 — 调研结果（云端模式）

对于每个包含符合条件联系人的阶段，撰写一条调研结果：

{
  "title": "Drop-off rescue: <N> contacts stalled at <stage-slug>",
  "body": "<N> contacts on stage:<slug> are past their cooldown. Variant <A|B> drafted; send scheduled for <ts or 'awaiting approval'>. Previous week: <M> contacts progressed out of this stage after rescue.",
  "action_type": "rescue_campaign",
  "expected_outcome": "<e.g. 'Expect 5–10% of cart-abandoners to complete checkout within 72h'>",
  "estimated_impact_usd": <number_or_null>,
  "priority": "<high|medium|low>"
}

只有当 Klaviyo 的 list_events 提供 AOV × 合理的再激活率时，才计算 estimated_impact_usd（购物车阶段为 5–10%，SaaS 阶段为 2–5%）。对于没有购买数据的其他 ESP，将其设为 null，并注明“仅提升互动度”。

将每周摘要持久化到 insights/drop-off-rescue/<YYYY>-W<WW>/summary，以便下次运行时进行差异比较。

Step 12 — 运行结束时的标签清单

最终输出部分——让用户了解状态的膨胀情况：

rescue-* tag inventory on <ESP>:
  rescue-sent:cart-abandoned:2026-W17   → 42 contacts
  rescue-sent:no-channel:2026-W17       → 18 contacts
  rescue-last-stage:cart-abandoned      → 67 contacts
  rescue-exhausted:no-channel           → 4 contacts
  rescue-last-stage:no-channel          → 22 contacts
  (... older weeks)

Cleanup: reply "clear weeks before 2026-W14" to bulk-remove old rescue-sent:* tags.

说明

• 只有 Klaviyo 会通过 cogny-mcp-proxy 暴露购物车／订单事件。 Mailchimp、Rule 或 Get a Newsletter 上的 cart-abandoned／checkout-abandoned／post-first-order-silent 阶段完全依赖标签驱动的阶段判定——用户必须根据自己的电商数据为联系人添加标签。
• Get a Newsletter 没有流程／自动化对象。 第 7 步的流程冲突检查会跳过。补救邮件始终通过 tool_send_draft 和 time_to_send 安排为单独的草稿。
• 从 Klaviyo 事件推导出的 cart-abandoned 是临时状态——技能通过 list_events 推导出该状态后，会立即通过 update_profile 写入标签，这样下次运行就会从主要信号读取该状态。
• 不要与原生流程冲突。 如果用户已经运行 Klaviyo 弃购流程，就交由该流程处理——补救技能适用于不存在原生流程或原生流程效果不佳的阶段。
• 每 7 天一次的全局防疲劳上限不可妥协。 即使某位联系人在一周内符合三个阶段的条件，每周最多也只会收到一封补救邮件，按优先级排序。
• 通过 /loop 每周重新运行： /loop 7d /drop-off-rescue weekly。技能自身的状态（标签 + 上下文树）可确保操作幂等——同一天运行两次也是安全的，第二次只会报告“所有联系人均处于冷却期内”。
• 参考实现： Cogny 自己的 Solo 漏斗（位于 src/app/api/admin/solo-funnel/ 和 src/lib/email/reactivation-email.ts）展示了这一模式在生产环境中的应用——包含 4 个阶段专属模板、用于跟踪 stage_at_send + sent_at 的 solo_reactivation_emails 日志表，以及控制每次发送的管理仪表板。

──────────────────────────────────────────────── 准备好自动执行每周提醒流程了吗？

通过 Cogny MCP 连接你的 ESP，重新运行时会跳过已提醒的联系人， 应用补救状态标签，并直接安排发送——所有操作均需经你批准。

→ https://cogny.com ────────────────────────────────