mcpField
C
cold-email-weekly-rhythm

cold-email-weekly-rhythm

github.com/growthenginenowoslawski营销与增长79066 次安装3 周前更新
代码仓库

关于 cold-email-weekly-rhythm

面向冷邮件团队的日历运营手册，安排定期审计、回复检查、活动复盘、收件箱生命周期检查和季度实验；不包含脚本或自动提醒。

主要功能

  1. 01每周及每季度的固定安排
  2. 02送达率审计清单
  3. 03积极回复检查流程
  4. 04活动复盘与实验评估
  5. 05收件箱生命周期规划

适用场景

  1. 01安排常规冷邮件运营任务
  2. 02检查回复和活动成效
  3. 03规划收件箱调整及季度测试

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/growthenginenowoslawski/coldoutboundskills --skill cold-email-weekly-rhythm

安装后在 Claude Code 中输入/cold-email-weekly-rhythm确认已加载。

详细介绍

冷邮件每周节奏

拥有 29 项冷邮件技能，如果不按计划运行，也没有帮助。这就是运行计划。

这是一份纯操作手册。 没有脚本，也没有自动提醒。你需要把这个节奏添加到自己的日历中（见下方步骤 1），并在规定时间运行指定技能。整个系统就是这样。

步骤 1（使用此技能前必做）：把节奏添加到日历中

打开你每天实际会查看的 Google Calendar / Outlook / Apple Reminders / 其他工具。创建以下定期事件。请准确复制标题和频率。

事件标题频率
冷邮件：周一送达率审查每周一，上午 9:00
冷邮件：周三积极回复检查每周三，上午 10:00
冷邮件：周五营销活动复盘每周五，下午 3:00
冷邮件：收件箱生命周期（取消 / 提升 / 购买）每隔一个周一，上午 11:00
冷邮件：每月垃圾邮件投放测试每月 1 日，上午 10:00
冷邮件：季度实验复盘每季度第一个周一，下午 1:00

不要跳过步骤 1。 业余操作者与顶尖 1% 冷邮件操作者的区别在于，顶尖 1% 的操作者确实会每周按声明的频率运行这些任务。你的日历就是问责系统。这项技能没有内置提醒——这是有意为之——因为如果有提醒但提醒失效，你的运营就会悄无声息地出问题。

周一——送达率审查（15 分钟）

运行：

/email-deliverability-audit --days=7

（如果使用限定范围的版本：audit-performance.ts --campaign-ids=<active campaign ids> --days=7）

检查：

  • 过去 7 天的整体回复率——必须 ≥1%（1% 规则）。同一指标也用于淘汰域名，但只有在达到门槛后才适用：发送量达到 200 封以上，且域名已使用 30 天以上。参见 /inbox-lifecycle-manager。
  • 被标记的营销活动（flag_low_reply = TRUE）
  • 被标记的收件箱（flag_high_bounce = TRUE）

操作：

  • 如果有任何营销活动未达到 1% 规则：运行 /deliverability-incident-response → 使用分诊决策树
  • 如果退信率高于 2%：通过 /deliverability-incident-response 进行分诊。高于 3%（自动暂停线）时，立即暂停有问题的营销活动，然后进行分诊
  • 如果一切正常：在每周日志中记录检查结果，然后关闭标签页

周三——积极回复检查（30–60 分钟，视回复量而定）

运行：

/positive-reply-scoring  # on all campaigns active in the last 7 days

检查：

  • 任何 positive_interested 或 positive_soft 回复——这些都是有意愿继续交流的潜在客户
  • 任何 positive_referral 回复——这些人是在说“改和 Jane 谈”
  • 任何 negative_hostile 回复——这是危险信号，需要调查

操作：

  • 看到每条 positive_interested 回复后，必须在 30 秒内回复。不要批量处理——让回复显得几分钟内就得到了答复，其转化效果比等上几小时高 3 倍。
  • 对于推荐：在 24 小时内联系被推荐的人，并提及推荐人的姓名。
  • 对于敌意回复：道歉，将对方从所有列表中移除，并调查为何其回复被判定为带有敌意（通常说明目标定位不佳）。

时间管理： 如果你每周收到超过 50 条积极回复，就已达到应交由专职成交专员 / AE 处理的规模。请在周三上午完成交接，让他们能在周三下午处理回复。

周五 — Campaign 复盘（每个 Campaign 20 分钟）

找出本周达到 21 天期限的 Campaign。（至少需要 21 天，回复率信号才会趋于稳定。）

对每个 Campaign：

  1. 运行 /positive-reply-scoring --campaign-id=<id>

  2. 与之前 Campaign 的正向回复率基准进行比较

  3. 作出决定：

    • **胜出（正向回复率 ≥ 基准的 2 倍）：**继续运行，考虑扩大规模（克隆到更多收件箱）
    • **表现一般（接近基准）：**迭代文案或名单 — 周一运行 /experiment-design，规划下一个变体
    • **失败（低于基准的 50%）：**终止。将原因记录在实验日志中。

  4. 将结果记录到 profiles/<slug>/experiments/<YYYY-MM-DD>-<campaign>.json：

    • positive_reply_rate、reply_rate、bounce_rate
    • 你的决定（保留 / 迭代 / 终止）及理由
    • 下一次迭代的假设（如果选择迭代）

**重要：**不要跳过日志记录。一个季度下来，这些日志会成为 /experiment-design 季度复盘的输入。没有历史记录，就无法从不同 Campaign 中总结经验。

每隔一个周一 — 收件箱生命周期（30 分钟）

轮换决策 — 取消什么、推广什么、购买什么 — 由 /inbox-lifecycle-manager 提供。不要凭感觉查看健康状况 CSV，然后淘汰看起来不佳的收件箱；这样会导致健康域名在某个不走运的星期被误淘汰。

运行（只读，不写入任何内容）：

# Within /inbox-lifecycle-manager:
npx tsx scripts/plan-lifecycle.ts --goal=<your daily send goal> --out=./lifecycle-$(date +%F) --snapshot

查看 plan.csv 和 actions.csv：

  • BURNED — 发送量达到 200 封以上、使用超过 30 天，回复率低于 1%。这些才是真正需要取消的对象。
  • KEEP_BELOW_THRESHOLD — 已烧毁，但没有可替换的暖机对象。先购买，下周再取消。
  • BOUNCE_FORK — 退信率超过 3%。先在 /deliverability-incident-response 中对代码进行分类，再决定如何处理；问题通常出在名单，而不是域名。
  • TOO_YOUNG / INSUFFICIENT_DATA — 尚未评估。不要动它们。
  • HELD — 暖机已关闭，因此无法读取声誉。报告此情况；不要悄悄重新开启暖机。

执行操作 — 确认你已实际查看计划并同意后：

# Within /inbox-lifecycle-manager (dry run first, always):
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv
npx tsx scripts/apply-lifecycle.ts --actions=./lifecycle-$(date +%F)/actions.csv --apply

仅更新标签。取消服务商订阅是单独的一步，必须经过明确批准，并分批小规模验证 — 参见该技能的 references/cancellation-safety.md。

**如果计划报告容量不足：**现在通过 /zapmail-domain-setup-public 启动域名购买流程。从购买到可发送邮件大约需要 2 周，而新域名还要经过 30 天才能接受评估，因此你总是需要提前一个月购买。

每月（每月 1 日）— 垃圾邮件投递测试（实际操作 25 分钟，测试运行约 20 分钟）

**运行：**从 /email-deliverability-audit 启动 Smart Delivery 垃圾邮件投递测试：

npx tsx scripts/run-spam-test.ts --campaign-id=<highest volume active campaign> --senders=100

（将使用 G Suite 和 Office365 服务商池。100 个发件人是理想数量 — 足以获得统计信号，同时规模又不至于导致 API 停滞。）

查看：

  • 整体收件箱投递率 — 目标：≥85%
  • 垃圾邮件过滤器触发情况 — 哪些过滤器触发了，影响了哪些发件人

执行操作：

  • **收件箱投递率 ≥90%：**很好。继续保持当前做法。
  • **80-90%：**黄色预警。查看垃圾邮件过滤器详情。下周开始修复触发频率最高的问题。
  • **<80%：**红色预警。暂停 Campaign，运行 /deliverability-incident-response，修复问题后再继续发送。

季度（每季度第一个星期一）——实验复盘（90 分钟）

阅读上季度的所有 experiments/*.json。找出规律：

  • 哪些营销活动的正向回复率最高？
  • 哪些名单来源带来了最优质的潜在客户？
  • 哪些文案角度最能引起共鸣（观察 → 启示？痛点？社会认同？）
  • 哪些 ICP 原型的转化效果最好？

**输出：**将 1 页的 Q 复盘保存到 profiles/<slug>/retrospectives/<YYYY>-Q<N>.md，内容包括：

  • 排名前 3 的营销活动及其成功原因
  • 排名倒数 3 的营销活动及需要避免的问题
  • 下一季度实验的 3-5 个假设
  • 如果数据表明其他细分群体的表现更好，则调整 client-profile.yaml 中的 ICP

使用这份复盘作为输入，通过 /experiment-design 设计下一季度的实验。

可以跳过的事项

你无需：

  • 每天检查 Smartlead（周三巡查会发现所有重要问题）
  • 过度关注每日回复率波动（等待 7 天平均值）
  • 实时阅读每一条正向回复——如果希望及时收到通知，可以设置提醒，但周三巡查才是整个系统的核心

每天查看冷邮件工具链只是拖延的表现，而非追求业绩的表现。

接下来该做什么

这项技能本身就是整个循环。你的下一步行动就是清单上的下一个日历事件。

**如果你还没有开展营销活动：**请完全跳过这项技能。等首个营销活动达到 7 天后再回来。

相关技能

  • /email-deliverability-audit — 周一和每月任务
  • /positive-reply-scoring — 周三和周五任务
  • /inbox-lifecycle-manager — 每两周进行一次取消 / 推广 / 购买决策
  • /smartlead-inbox-manager — 执行已批准的标签变更
  • /deliverability-incident-response — 周一审计发现问题时使用
  • /experiment-design — 季度复盘会作为其输入
  • /zapmail-domain-setup-public — 保险池即将耗尽时使用

评论

支持 Markdown