marketing-automation

营销自动化

当实际任务是选出合适的下一份营销方案时，请将此技能用作广义营销的标准入口。

任务不是生成一大堆营销活动创意，而是：

1. 将需求归类为一种工作模式，
2. 选择一条主要路径，
3. 产出一份可复用的执行者方案，
4. 明确负责人、依赖项、审批要求和证据链，
5. 如果请求实际属于规划、游戏商店发布运营或其他范围更窄的专业工作流，则转交出去。

在定稿前，请阅读以下支持文档：

• references/operating-modes-and-route-outs.md
• references/routing-heuristics.md
• references/operator-packet-and-proof-stack.md
• references/measurement-handoff.md

何时使用此技能

• 用户需要广义营销帮助，但尚不明确下一步该采用哪种方案。
• 产品、网站、漏斗、发布、入门流程或定价页面需要先准备一份结构化营销简报，再开始详细执行。
• 请求同时涉及策略、页面选择、信息传达、内容、渠道和衡量。
• 用户需要一份可复用的执行者简报，而不是一堆互不相关的建议。

何时不使用此技能

• 需求已明确属于 Steam／商店页面／节庆活动／游戏发布工作 → steam-store-launch-ops。
• 实际任务是整理待办事项、协调里程碑或拆分跨职能实施工作 → task-planning。
• 用户只想进行单项文案改写，或只需要完成的内容素材，不涉及更广泛的分流层 → 直接使用更专门的写作／执行工作流。
• 请求主要涉及产品策略、UX 研究或技术实施，而非营销分流 → 转交给更合适的相邻技能。

核心分流模型

工作模式

每次运行选择一种主要模式：

• launch-orchestration — 跨多个页面的广义发布、GTM、定价或推出顺序安排
• conversion-surface — 着陆页、定价页、注册流程、付费墙或入门转化阻力
• lifecycle-retention — 入门、激活、留存、流失、生命周期邮件、重新互动或用户教育行动
• acquisition-content — SEO、内容策略、对比页面、自然获客或面向渠道的发现工作
• measurement-experiment — 分析设置、归因、KPI 清理、营销活动复盘或实验／待办事项埋点

主要路径

选择模式后，仍需选择一条主要路径：

• CRO
• Copy & messaging
• SEO & content
• Ads & analytics
• Strategy & growth

模式说明当前属于哪类情况。 路径说明哪项营销职能负责下一份方案。

指示

步骤 1：将需求整理为一种分流概况

选择方案前，按以下简明格式记录请求：

marketing_router_profile:
  primary_mode: launch-orchestration | conversion-surface | lifecycle-retention | acquisition-content | measurement-experiment
  primary_lane: CRO | Copy & messaging | SEO & content | Ads & analytics | Strategy & growth | unknown
  objective: acquisition | activation | conversion | retention | revenue | awareness | unknown
  audience:
    segment: "who this is for"
    stage: unaware | problem-aware | evaluating | active-user | churn-risk | unknown
  surface_or_channel: landing-page | pricing-page | signup-flow | onboarding | lifecycle-email | seo-page | campaign | dashboard | launch | unknown
  offer_or_motion: "product / feature / campaign / launch motion"
  measurement_maturity: clear | partial | weak
  main_question: "what needs to be decided next?"
  delivery_owner: "who will carry the packet next"
  dependencies_or_approvals:
    - "design / analytics / engineering / legal / partner / none"
  proof_assets_available:
    - "dashboard / baseline export / campaign data / user feedback / none"
  constraints:
    timeline: immediate | this-week | this-month | longer
    brand_or_compliance_notes: "limits or promises"
    domain_specificity: general | specialist | game-store

如果缺少细节，请明确说明假设后继续，不要停滞不前。

步骤 2：收集最低限度的可信证据

不要仅凭直觉分流。提取足以支持真实决策的最小信息集：

• 目标和当前瓶颈
• 受众／细分群体／漏斗阶段
• 页面、营销活动或生命周期时点
• 可用的证明依据或限制条件
• 当前 KPI 或最佳可用的替代指标
• 谁负责下一步行动
• 哪些依赖项或审批可能阻碍执行
• 还有哪些缺失信息可能改变路径选择

第 3 步：选择一种模式、一个领域、一份数据包

使用 references/operating-modes-and-route-outs.md。

默认数据包映射：

• launch-orchestration → 通常为 Strategy & growth → launch/growth brief
• conversion-surface → 通常为 CRO 或 Copy & messaging → measurement + experiment packet
• lifecycle-retention → 通常为 Strategy & growth 或 Copy & messaging → channel-ready brief
• acquisition-content → 通常为 SEO & content → channel-ready brief
• measurement-experiment → 通常为 Ads & analytics → measurement + experiment packet

规则：

• 选择一种主要模式。
• 选择一个主要领域。
• 返回一份主要数据包。
• 选择主要数据包后，才提及次要交接事项。

第 4 步：在数据包变得庞大之前安排转交

遇到以下情况时，应转交，而不是把相邻工作也揽入其中：

• 实际需求是 Steam 愿望单／胶囊图／Next Fest／商店曝光 → steam-store-launch-ops
• 实际需求是拆分执行任务／整理待办事项／协调里程碑 → task-planning
• 该需求已经属于有更合适专用技能的狭窄专业工作流

好的入口会缩小下一步的范围，而不是靠包揽所有相邻工作来取胜。

第 5 步：编写执行者简报

使用 references/operator-packet-and-proof-stack.md。

返回以下结构：

# Marketing Routing Brief

## Intake summary
- Mode: ...
- Primary lane: ...
- Objective: ...
- Audience / stage: ...
- Surface / channel: ...
- Confidence: high | medium | low

## What matters most now
- 2-4 bullets

## Recommended packet
- Packet type: launch/growth brief | channel-ready brief | copy/messaging packet | measurement + experiment packet | marketing-routing brief
- Why this packet now: ...

## Operator packet
- Primary owner: ...
- Dependencies / approvals: ...
- Required assets or inputs: ...
- Delivery horizon: ...

## Priority decisions
| Decision | Why now | Owner | Risk if delayed |
|----------|---------|-------|-----------------|
| ... | ... | ... | ... |

## Immediate next steps
1. ...
2. ...
3. ...

## Proof stack
- Primary KPI: ...
- Leading signal: ...
- Baseline or assumption: ...
- Success threshold: ...
- Readout window: ...
- Next owner / workflow: ...

## Secondary handoffs
- Skill / workflow: ...
- Why: ...

## Not yet
- 1-3 bullets that prevent scope drift

第 6 步：将效果证明与数据包一并提供

每份输出都必须说明：

• 一个主要 KPI
• 一个先行信号
• 一个基线或明确假设
• 一个成功门槛
• 一个读数周期或审核检查点
• 一个下一步负责人或下游工作流

使用 references/operator-packet-and-proof-stack.md 获取执行者数据包格式，并使用 references/measurement-handoff.md 查看各领域的 KPI 示例。

输出格式

始终返回一份简短的执行者风格营销路由简报。

必备要素：

• 一种主要模式
• 一个主要领域
• 一份可实际交接的数据包
• 上下文不足时明确说明假设
• 指明负责人，并清楚说明依赖项／审批情况
• 需求并非真正属于此技能时安排转交
• 将效果证明逻辑附在数据包中，而非事后补上

示例

示例 1：宽泛的发布需求

输入

我们下个月要推出一套新的 SaaS 工作流，需要帮助撰写营销信息、落地页文案、引导邮件，以及衡量效果的方法。

输出概要

• 模式：launch-orchestration
• 领域：Strategy & growth
• 数据包：launch/growth brief
• 次要交接事项提及文案／营销信息和生命周期执行
• 执行者数据包指明一位负责人，以及可能的依赖项或审批事项
• 效果证明清单列出一个发布 KPI 和一个先行信号

示例 2：定价页面改版

输入

我们的定价页面有流量，但升级转化不理想。我们需要改进页面并确定测试内容。

输出概要

• 模式：conversion-surface
• 领域：CRO
• 数据包：measurement + experiment packet
• 优先决策涵盖优惠说明清晰度、CTA 层级、效果证明和转化阻力

示例 3：生命周期／引导需求

输入

试用用户激活一次后就不再回来。我们需要引导和生命周期方面的帮助，以及一个合理的 KPI。

输出概要

• 模式：lifecycle-retention
• 领域：Strategy & growth 或 Copy & messaging
• 数据包：channel-ready brief
• 执行者数据包指明生命周期负责人，以及任何分析或产品依赖项
• 效果证明清单列出激活或持续使用 KPI，以及一个先行信号

示例 4：游戏商店发布的边缘需求

输入

我们需要为游戏试玩版撰写 Steam 胶囊图文案，并获得 Next Fest 营销方面的帮助。

输出概要

• 保持回复简短
• 将执行工作转交给 steam-store-launch-ops
• 只留下简洁的交接说明，而不是提供一份庞大的通用营销计划

最佳实践

1. 扮演前台路由器，而不是通用增长顾问。
2. 先选择一种模式，再选择策略。
3. 先选择一个执行包，再列出渠道。
4. 明确标出负责人、审批和依赖项，不要假设自动化会让它们消失。
5. 明确划分上线、规划和游戏商店运营的边界。
6. 为每个执行包附上证明材料和负责人。

参考资料

• references/operating-modes-and-route-outs.md
• references/routing-heuristics.md
• references/operator-packet-and-proof-stack.md
• references/measurement-handoff.md
• ../marketing-skills-collection/SKILL.md
• ../steam-store-launch-ops/SKILL.md
• ../task-planning/SKILL.md