- AI 技能
- 人工智能
【免费下载链接】marketingskills
Marketing skills for Claude Code and AI agents. CRO, copywriting, SEO, analytics, and growth engineering.
本篇技术指南围绕 marketingskills 仓库中 RevOps 技能模块 的核心参考资料 automation-playbooks.md 展开，系统梳理 HubSpot、Salesforce、Calendly/SavvyCal 与 Zapier 四类平台的自动化工作流配方。你将掌握 MQL 告警与分配、SLA 升级、线索评分晋级、会议预订通知、成交交接、失效商机告警、回收线索再培育等 18 套可落地的 Playbook 设计，并理解如何在 CRM 中结合生命周期阶段定义、路由规则与计分模型将其真正跑通。
一、为什么 RevOps 需要「平台级自动化 Playbook」
RevOps（收入运营）的核心目标是把市场、销售与客户成功连成一台统一的收入引擎。SKILL.md 中明确了四条核心原则：单一事实来源（以 CRM 为权威主数据源）、先定义后自动化（先把阶段定义、计分标准、路由规则写清楚再建流程）、度量每一次交接（市场→销售、SDR→AE、AE→CS 每道交接都要有 SLA 与追踪机制）、收入团队对齐（三团队对 MQL/SQL 的定义必须一致）。
这些原则落地到具体工具时，就需要一份「平台特定工作流配方」——即本文的主角 automation-playbooks.md。它把重复出现的业务模式（MQL 分配、SLA 告警、成交交接……）翻译成 HubSpot Workflow、Salesforce Flow、调度工具集成与 Zapier 跨工具自动化四类可直接照抄的配方，并与 生命周期阶段定义、路由规则、计分模型 三份兄弟文档构成完整闭环。
二、HubSpot Workflow 配方（8 个）
以下配方在 HubSpot 中通过Automation → Workflows构建，每个配方都给出触发条件、动作序列、期望结果与注意事项。可结合仓库中 hubspot.md 记录的关键对象（Contacts/Companies/Deals）与常用属性（lifecyclestage、hs_lead_status、dealstage等）来映射字段。
1. MQL 告警与分配
| 要素 | 内容 |
|---|---|
| 名称 | MQL Notification and Task Creation |
| 触发条件 | 联系人生肖属性「Lifecycle Stage」变为「Marketing Qualified Lead」 |
| 动作 | ① 在销售团队中轮转（round-robin）分配联系人所有者 → ② 发送内部邮件给所有者并附上线索上下文 → ③ 创建任务「Follow up with [Contact Name]」，4 小时内到期 → ④ 发送 Slack 通知到#sales-alerts频道 → ⑤ 加入「MQL Follow-Up」序列（如使用 HubSpot Sequences） |
| 结果 | 每个 MQL 都被即时分配并带明确 SLA |
| 注意事项 | 设置 enrollment criteria，排除已被销售代表持有的线索 |
关于 round-robin 的实现细节，可参考 routing-rules.md 中的两种做法：一是直接用 HubSpot 自带的 rotation 工具（触发「Lifecycle Stage 等于 MQL」，选择「Even distribution、skip unavailable owners」，再加延迟与任务创建）；二是自定义 rotation：创建数值属性「Rotation Counter」，按计数值分支到不同代表，递增计数（到最大值归零），最后创建带 SLA 截止时间的跟进任务。
2. MQL SLA 升级
| 要素 | 内容 |
|---|---|
| 名称 | MQL SLA Breach Alert |
| 触发条件 | 「Lifecycle Stage」等于「MQL」且「Days since last contacted」大于 0.5（即 12 小时） |
| 动作 | ① 邮件提醒当前所有者「SLA warning: [Contact Name] has not been contacted」→ ② 若 24 小时后仍无活动，告警销售经理 → ③ 若 48 小时后仍无活动，按轮转规则重新分配所有者 → ④ 为新所有者创建任务「Urgent: Contact [Contact Name] — reassigned due to SLA breach」 |
| 结果 | 没有任何 MQL 超过 48 小时无人跟进 |
| 注意事项 | 排除 last activity type 为「Call」或「Meeting」的联系人（已在互动中） |
此配方与 lifecycle-definitions.md 中「MQL-to-SQL SLA」模板完全呼应：首次联系目标 4 个业务小时内、资格判定 48 小时内，超时自动升级到销售经理。建议在配方的「SLA 计时」基础上叠加 routing-rules.md 中的速度响应升级链：5 分钟提醒原代表 → 15 分钟提醒后备代表 → 30 分钟提醒经理 → 60 分钟重新分配。
3. 线索评分更新与 MQL 晋级
| 要素 | 内容 |
|---|---|
| 名称 | Auto-MQL on Score Threshold |
| 触发条件 | 联系人属性「HubSpot Score」大于等于 65 |
| 动作 | ① 设置生命周期阶段为「Marketing Qualified Lead」→ ② 设置「MQL Date」为当前日期 → ③ 从市场培育工作流中抑制 → ④ 触发配方 #1 的 MQL 告警工作流 |
| 结果 | 线索达到计分阈值后自动晋级为 MQL |
| 注意事项 | 添加现有客户与竞争对手的抑制列表 |
阈值 65 分并非拍脑袋。参考 scoring-models.md，MQL 必须同时满足「fit（契合度）+ engagement（参与度）」：例如 PLG 模型的 65 分阈值、Sales-Led 企业模型的 75 分阈值、中端混合模型的 60 分阈值。其中计分信号（demo 请求 +30、定价页访问 +20、试用注册 +25 等）与负向信号（竞争对手域名 -50、学生邮箱 -30、垃圾投诉 -100）都建议纳入 HubSpot Score 的配置，并遵循「季度校准」节奏——用历史成交数据验证模型能否识别过去的赢单。
4. 会议预订通知
| 要素 | 内容 |
|---|---|
| 名称 | Meeting Booked Alert to AE |
| 触发条件 | 为联系人记录了会议活动（经 Calendly/HubSpot meetings） |
| 动作 | ① 发送内部邮件给所有者并附上会议详情 → ② 更新联系人属性「Last Meeting Booked」为当前日期 → ③ 若生命周期阶段为「Lead」，更新为「MQL」→ ④ 创建任务「Prepare for meeting with [Contact Name]」，会议前 1 小时到期 → ⑤ 发送 Slack 通知到#meetings频道 |
| 结果 | AE 对每场会议都有完整上下文准备 |
| 注意事项 | 在通知邮件中附带近期页面浏览与内容下载记录 |
5. 成交交接至 CS
| 要素 | 内容 |
|---|---|
| 名称 | Customer Onboarding Trigger |
| 触发条件 | 商机阶段变为「Closed Won」 |
| 动作 | ① 更新关联联系人的生命周期阶段为「Customer」→ ② 设置「Customer Since」日期为当前日期 → ③ 按细分/区域将联系人所有者分配给 CS 团队成员 → ④ 为 CS 创建任务「Schedule kickoff call with [Company Name]」，2 个业务日内到期 → ⑤ 将联系人加入「Customer Onboarding」邮件序列 → ⑥ 通知 CS 经理 → ⑦ 从所有销售序列中移除 |
| 结果 | 从销售到客户成功无缝交接 |
| 注意事项 | 在 CS 通知中包含商机备注、合同金额与关键干系人 |
此配方与 lifecycle-definitions.md 中 Customer 阶段的进入动作（触发 onboarding 序列、分配 CS 经理、安排 kickoff 电话、从所有销售序列移除）逐一对应，可直接照搬。
6. 失效商机告警
| 要素 | 内容 |
|---|---|
| 名称 | Pipeline Hygiene — Stale Deal Detection |
| 触发条件 | 商机属性「Days in current stage」大于 [该阶段平均天数的 2 倍] |
| 动作 | ① 邮件提醒商机所有者「Deal stale alert: [Deal Name] has been in [Stage] for [X] days」→ ② 创建任务「Update or close [Deal Name]」，3 个业务日内到期 → ③ 若 7 天后仍无更新，告警销售经理 → ④ 加入「Stale Deals」仪表盘列表 |
| 结果 | 管线保持干净、预测保持准确 |
| 注意事项 | 按阶段定制阈值（Discovery：14 天，Proposal：10 天，Negotiation：21 天） |
7. 回收线索再培育
| 要素 | 内容 |
|---|---|
| 名称 | MQL Recycling to Nurture |
| 触发条件 | 联系人属性「Sales Rejection Reason」有任意值 |
| 动作 | ① 更新生命周期阶段为「Recycled」→ ② 将参与度分数重置为基线（保留 fit 分数）→ ③ 加入「Recycled Lead Nurture」序列（较低频率）→ ④ 设置「Recycle Date」为当前日期 → ⑤ 设置重新触发条件：若 HubSpot Score 再次超过阈值，重新触发 MQL 工作流 |
| 结果 | 被拒绝的线索获得第二次机会，且不堵塞管线 |
| 注意事项 | 单独追踪 recycled-to-MQL 转化率指标 |
关于回收原因代码，lifecycle-definitions.md 提供了完整编码体系：FIT-01（公司太小，培育并在公司成长后重新计分）、FIT-02（行业不符，归档不回收）、ENG-01（3 次尝试无回应，90 天后回收培育）、QUAL-02（使用竞品被锁定，在续约前触发）等。回收培育序列建议双周/月度低频触达、时长 6 个月无参与则归档，并以「demo 请求、定价页回访」等高意图动作作为再 MQL 触发点。
8. 线索活动摘要
| 要素 | 内容 |
|---|---|
| 名称 | Daily Lead Activity Summary |
| 触发条件 | 定时——每天本地时间 8:00 AM |
| 动作 | ① 筛选：生命周期阶段为「SQL」或「Opportunity」且过去 24 小时有网站活动 → ② 向每个线索所有者发送其线索活动摘要邮件 → ③ 内容包括：访问过的页面、下载的内容、打开/点击的邮件 |
| 结果 | 销售代表每天开工即知哪些线索活跃 |
| 注意事项 | 只包含有意义的活动（排除单一首页访问） |
三、Salesforce Flow 等价实现（4 套）
对于使用 Salesforce 的企业，automation-playbooks.md 给出了与 HubSpot 配方一一对应的 Flow 实现。可结合 salesforce.md 中的关键对象（Lead/Contact/Account/Opportunity/Case/Campaign）与 SOQL 查询能力来理解数据流。
1. MQL 告警与分配（Record-Triggered Flow）
| 要素 | 内容 |
|---|---|
| 类型 | 记录触发流（Record-Triggered Flow） |
| 对象 | Lead |
| 触发条件 | Lead 字段「Status」变为「MQL」 |
| 流程步骤 | ① Get Records：查询自定义对象「Rep Assignment」获取下一位可用代表 → ② Update Records：将 Lead Owner 设为被分配代表 → ③ Create Records：创建任务「Contact MQL: {Lead.Name}」，到期时间 = NOW + 4 小时 → ④ Action：向新所有者发送邮件告警 → ⑤ Update Records：更新「Rep Assignment」的 last-assigned 时间戳 |
| 注意事项 | 用自定义「Rep Assignment」对象维护 round-robin 状态 |
这与 routing-rules.md 中「Salesforce 高级路由」的 Flow 方案一致：Record-Triggered Flow + 自定义「Rep Queue」对象查询下一位代表 + Decision 元素检查可用性/容量/区域 + 创建带 SLA 的任务 + 更新队列记录。
2. SLA 升级（Scheduled-Triggered Flow）
| 要素 | 内容 |
|---|---|
| 类型 | 定时触发流（Scheduled-Triggered Flow） |
| 调度 | 业务时间内每 4 小时 |
| 流程步骤 | ① Get Records：查找 Status = "MQL" 且 LastActivityDate < TODAY - 1 的 Lead → ② Decision：线索是否超过 48 小时无活动？→ YES：重新分配给下一位代表、创建紧急任务、告警经理；NO：向当前所有者发送提醒邮件 |
| 注意事项 | 与 Process Builder 配合，实现初始分配时的实时告警 |
3. 管线阶段自动化（Record-Triggered Flow）
| 要素 | 内容 |
|---|---|
| 类型 | 记录触发流 |
| 对象 | Opportunity |
| 触发条件 | Stage 字段更新 |
| 流程步骤 | ① Decision：判断变更到了哪个阶段 → ② 每个阶段对应动作：Discovery：创建任务「Complete discovery questionnaire」；Demo：创建任务「Prepare demo environment」；Proposal：创建任务「Send proposal」+ 若 ACV > $25K 告警 deal desk；Closed Won：触发 CS 交接（创建 Case、分配 CS 所有者、发送欢迎邮件）；Closed Lost：创建任务「Log loss reason」+ 加入赢/输分析报告 |
「ACV > $25K 走 deal desk」与 SKILL.md 中 Deal Desk 章节的「ACV 超过 $25K 即触发非标准商机审查」阈值一致；审批层级（标准定价自动通过、10–20% 折扣销售经理审批、20–40% 折扣 VP Sales 审批、40%+ 或自定义条款走 deal desk、多年期/企业级走财务+法务）可作扩展参考。
4. 失效商机检测（Scheduled-Triggered Flow）
| 要素 | 内容 |
|---|---|
| 类型 | 定时触发流 |
| 调度 | 每天 7:00 AM |
| 流程步骤 | ① Get Records：Days_In_Stage > Stage_SLA_Threshold 的未关闭 Opportunity → ② 循环处理：创建任务「Update stale deal: {Opportunity.Name}」、发邮件给所有者、若 Days_In_Stage > 2 倍阈值则发邮件给所有者的经理 → ③ 更新自定义字段「Stale Flag」= true，便于仪表盘可见 |
四、Calendly / SavvyCal 调度集成模式
调度工具是「会议预订通知」「成交交接」等 CRM 配方的数据来源。仓库中的 calendly.md 提供invitee.created/invitee.canceled等 webhook 事件订阅、scheduled_events/invitees查询接口；savvycal.md 则提供event.created/event.canceled事件与scheduling-links管理接口。
轮转会议调度
Calendly 设置：
- 创建包含所有合格代表的团队事件类型
- 分配方式：「Optimize for equal distribution」
- 可用性：每位代表管理自己的日历
- 缓冲：会议前后各 15 分钟
- 最短通知时间：4 小时（避免临期预订）
CRM 集成：
- Calendly webhook 在预订时触发
- 用 invitee 邮箱匹配 CRM 联系人
- 若联系人存在 → 将会议分配给联系人所有者（已持有则覆盖轮转）
- 若为新联系人 → 创建线索、按路由规则分配、记录会议
- 设置生命周期阶段为 MQL（会议 = 高意图）
SavvyCal 设置
相对 Calendly 的优势：
- 基于优先级的调度（优先某些时间段）
- 日历叠加（单视图展示团队可用性）
- 每位代表的个性化预订链接
集成模式：
- 创建带优先级规则的团队调度链接
- 预订 webhook → Zapier/Make → CRM
- 匹配或创建联系人、分配所有者、创建任务
- 发送含会议准备材料的确认信息
按条件路由会议
Booking form submitted ├─ Company size > 500? (form field) │ ├─ YES → Route to enterprise AE calendar │ └─ NO ↓ ├─ Existing customer? (CRM lookup) │ ├─ YES → Route to account owner's calendar │ └─ NO ↓ └─ Round-robin across SDR team这与 routing-rules.md 的核心原则一致——「先命中具体规则，再回退到通用规则」，并且支持按公司规模（SMB 1–50 人 / 中端 51–500 人 / 企业 501–5000 人 / 战略 5000+ 人）构建完整的分层路由树。
缺席（No-Show）工作流
| 要素 | 内容 |
|---|---|
| 触发条件 | 会议时间已过且 30 分钟内未记录会议备注 |
| 动作 | ① 等待会议时间后 30 分钟 → ② 检查：是否记录了电话或会议？→ 是：无操作；否：发送「Sorry we missed you」邮件 → ③ 创建任务「Reschedule with [Contact Name]」，下一个工作日到期 → ④ 若第二次缺席：标记联系人并告警经理 |
五、Zapier 跨工具模式（6 个）
Zapier 是跨工具粘合剂，将 CRM、Slack、邮件、广告、分析平台连接起来。仓库中的 zapier.md 显示其 SDK（@zapier/zapier-sdk）支持 8000+ 应用集成，Agent 可直接调用zapier.apps.hubspot().createContact()、zapier.apps.slack().sendChannelMessage()等方法，也可用 Webhooks（POST https://hooks.zapier.com/hooks/catch/{webhook_id}/）接收或发送数据。
1. 新线索 → CRM + Slack + 任务
| 要素 | 内容 |
|---|---|
| 触发条件 | 新表单提交（Typeform、HubSpot、Webflow） |
| 动作 | ① 在 CRM 中创建/更新联系人 → ② 用 Clearbit 富化（如可用）→ ③ 将富化数据发布到 Slack#new-leads→ ④ 在项目管理工具（Asana、Linear）中创建任务 |
2. 会议预订 → CRM + 准备邮件
| 要素 | 内容 |
|---|---|
| 触发条件 | 新的 Calendly/SavvyCal 预订 |
| 动作 | ① 查找或创建 CRM 联系人 → ② 更新生命周期阶段为 MQL → ③ 向被分配代表发送准备邮件（含 CRM 链接、LinkedIn 主页、近期活动）→ ④ 创建会前任务 |
3. 成交 → Onboarding 技术栈
| 要素 | 内容 |
|---|---|
| 触发条件 | CRM 商机阶段变为「Closed Won」 |
| 动作 | ① 在 CS 工具（Vitally、Gainsight、ChurnZero）中创建客户记录 → ② 加入 onboarding 项目模板 → ③ 通过邮件工具发送欢迎邮件 → ④ 创建 Slack 频道#customer-[company-name]→ ⑤ 在 Slack 中通知 CS 团队 |
4. 线索计分 → 跨工具同步
| 要素 | 内容 |
|---|---|
| 触发条件 | CRM 线索分数跨越 MQL 阈值 |
| 动作 | ① 更新营销自动化平台状态 → ② 加入再营销受众（Facebook、Google Ads）→ ③ 触发 SDR 外呼序列 → ④ 在分析工具（Mixpanel、Amplitude）中记录事件 |
5. SLA 违规 → 多渠道告警
| 要素 | 内容 |
|---|---|
| 触发条件 | CRM 任务逾期（MQL 跟进任务） |
| 动作 | ① 发送 Slack DM 给代表 → ② 发送邮件给代表 → ③ 若逾期 2+ 小时，Slack DM 给经理 → ④ 若逾期 4+ 小时，通过 webhook 回写 CRM 重新分配 |
6. 每周管线摘要
| 要素 | 内容 |
|---|---|
| 触发条件 | 定时——每周一 8:00 AM |
| 动作 | ① 查询 CRM 获取管线摘要（总价值、新商机、失效商机、预期成交）→ ② 格式化为摘要 → ③ 发布到 Slack#sales-team→ ④ 向销售管理层发送邮件摘要 |
六、从 Playbook 到收入引擎：衔接三份关键定义
automation-playbooks.md 中的所有配方都不是孤立脚本，它们的正确运行依赖 RevOps 模块内三份定义文档：
生命周期阶段定义：为配方提供字段依据。例如配方 #1 的「Lifecycle Stage = MQL」需要 Subscriber/Lead/MQL/SQL/Opportunity/Customer/Evangelist 各阶段的进入与退出标准；配方 #5 的「Customer」阶段进入动作直接决定交接内容；回收原因代码体系（FIT-01 到 QUAL-03）是配方 #7 判断是否回收、如何回收的输入。
路由规则：为分配类配方提供算法。round-robin 的跳过不可用代表、按配额达成加权、分配计数每周/每月重置；ABM 场景下目标账户域名匹配直接路由到账户所有者（Tier 1 战略账户响应 SLA 1 小时、Tier 2 4 小时、Tier 3 当日）；速度响应链（5 分钟 → 15 分钟 → 30 分钟 → 60 分钟）可直接内嵌到配方 #1/#2。
计分模型：为配方 #3/#7 提供阈值与信号。fit 维度（公司规模、行业、职位、技术栈）、参与维度（demo 请求、定价页、试用）与负向信号（竞品域名、学生邮箱、垃圾投诉）共同决定 MQL 阈值；校准节奏按业务类型区分（PLG 每月、中端季度、企业季度到半年）。
三份文档 + 本 Playbook 的组合使用路径是：先用生命周期定义统一阶段口径 → 用计分模型定 MQL 阈值 → 用路由规则定分配算法 → 最后按本 Playbook 把上述逻辑编码为 HubSpot Workflow / Salesforce Flow / Zapier 自动化——这正是 SKILL.md 中「Define Before Automate」原则的完整落地顺序。
七、落地检查清单
在复制任一配方前，建议完成以下核对（依据 SKILL.md 的 RevOps 度量仪表盘基准）：
- SLA 是否显式：MQL 首次联系 ≤ 4 业务小时、资格判定 ≤ 48 小时、SQL 转 Opportunity ≤ 5 业务日；MQL-to-SQL 率基准 30–50%，SQL-to-Opportunity 50–70%。
- 路由是否有回退：每个分配类配方都要有 fallback owner，未分配线索会快速冷却并浪费管线。
- 计分是否含负向信号：没有负向计分的模型会让不合格线索漏过。
- 交接是否可度量：每次交接（市场→销售、SDR→AE、AE→CS）都有 SLA、追踪机制与负责人。
- 速度是否被优先：5 分钟内响应资质概率最高（routing-rules.md 中有详细速度-转化对照），告警与升级链应优先于其他非关键动作。
- 数据是否单一来源：CRM 作为权威主数据源，调度工具、营销自动化、CS 工具都向 CRM 同步（或经 Zapier 回写）。
按照 SKILL.md 的输出规范，落地交付物应包含：生命周期阶段文档、计分规格、路由规则文档、管线配置与指标仪表盘规格——五份文档每份都可独立实施，本 Playbook 即为其中「管线配置与自动化触发」的直接参考实现。
- AI 技能
- 人工智能
【免费下载链接】marketingskills
Marketing skills for Claude Code and AI agents. CRO, copywriting, SEO, analytics, and growth engineering.
相关推荐
Cal.diy 与 Zapier 集成实战指南：用 8000+ 应用自动化你的日程调度工作流
Cal.diy 与 Zapier 集成实战指南：用 8000+ 应用自动化你的日程调度工作流 Cal.diy（本项目仓库）内置了与 Zapier 的官方集成：用
后端前端企业应用Garak 命令行一次跑通：单命令完成一轮 LLM 漏洞扫描
Garak 命令行一次跑通：单命令完成一轮 LLM 漏洞扫描 接手一个新模型、上线前想确认它有没有明显的安全缺口时，你其实只需要敲一条 Garak 命令行命令。
人工智能大模型模型评测红蓝对抗提示词注入防护模型安全AI 安全治理利用DeepSeek-Coder-V2实现代码智能化的完整指南
利用DeepSeek Coder V2实现代码智能化的完整指南 DeepSeek Coder V2是一款革命性的开源代码智能模型，它打破了闭源模型在代码智能领域
人工智能大模型代码模型DeepSeek
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
