marketing-automation

マーケティングオートメーション

実際の作業が、次に適切なマーケティングパケットを選ぶことである場合、このスキルを幅広いマーケティングの正式な窓口として使用してください。

目的は、膨大なキャンペーンのブレインストーミングを生成することではありません。目的は次のとおりです。

1. 依頼を1つの運用モードに分類する
2. 主要レーンを1つ選ぶ
3. 再利用可能なオペレーターパケットを1つ作成する
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リサーチ、または技術的な実装である → より適した関連スキルに誘導してください。

基本の振り分けモデル

運用モード

1回の実行につき、主要モードを1つ使用します。

• launch-orchestration — 複数の画面にまたがる幅広いローンチ、GTM、料金設定、または展開の順序付け
• conversion-surface — ランディングページ、料金ページ、登録フロー、ペイウォール、またはオンボーディングにおけるコンバージョンの摩擦
• lifecycle-retention — オンボーディング、アクティベーション、リテンション、チャーン、ライフサイクルメール、リエンゲージメント、またはユーザー教育の施策
• acquisition-content — SEO、コンテンツ戦略、比較ページ、オーガニック獲得、またはチャネル向けのディスカバリー施策
• measurement-experiment — アナリティクスの設定、アトリビューション、KPIの整理、キャンペーンの分析、または実験／バックログの計測設定

主要レーン

モードを選んだ後も、主要レーンを1つ選んでください。

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

モードは、どのような状況なのかを説明します。 レーンは、どのマーケティング分野が次のパケットを担当するのかを説明します。

手順

ステップ1：受付内容を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：モード、レーン、パケットをそれぞれ 1 つ選ぶ

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

ルール：

• 主要なモードを 1 つ選びます。
• 主要なレーンを 1 つ選びます。
• 主要なパケットを 1 つ返します。
• セカンダリの引き継ぎ先は、メインのパケットを選んだ後にのみ記載します。

ステップ 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 を 1 つ
• 先行シグナルを 1 つ
• ベースラインまたは明示的な仮定を 1 つ
• 成功のしきい値を 1 つ
• 効果測定期間またはレビューのチェックポイントを 1 つ
• 次の担当者または後続のワークフローを 1 つ

オペレーターパケットの形式には references/operator-packet-and-proof-stack.md を、レーン固有の KPI の例には references/measurement-handoff.md を使用してください。

出力形式

常に、短いオペレーター形式のマーケティングルーティングブリーフを返します。

必須事項：

• 主要なモードを 1 つ
• 主要なレーンを 1 つ
• 実際に引き継げるパケットを 1 つ
• コンテキストが不足している場合は明示的な仮定
• 担当者の明記と、依存関係／承認の可視化
• 依頼がこのスキルの対象ではない場合はルートアウト
• 後付けではなく、パケットに根拠を組み込む

例

例 1：幅広いローンチの依頼

入力

来月、新しい SaaS ワークフローをローンチします。メッセージング、ランディングページのコピー、オンボーディングメール、効果の測定方法について支援が必要です。

出力の概要

• モード：launch-orchestration
• レーン：Strategy & growth
• パケット：launch/growth brief
• コピー／メッセージングとライフサイクル施策の実行へのセカンダリの引き継ぎ先を記載
• オペレーターパケットに、担当者 1 名と想定される依存関係または承認事項を明記
• 根拠スタックに、ローンチ KPI を 1 つ、先行シグナルを 1 つ明記

例 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. 戦術を選ぶ前に、1つのモードを選びます。
3. チャネルを列挙する前に、1つのパケットを選びます。
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