Marketing Automation

Marketing Automation

Use this skill as the canonical broad marketing front door when the real job is choosing the right next marketing packet.

The job is not to generate a giant campaign brainstorm. The job is to: 1. classify the ask into one operating mode, 2. choose one primary lane, 3. produce one reusable operator packet, 4. name the owner, dependencies, approvals, and proof stack, 5. route out when the request is actually planning, game-store launch ops, or another narrower specialist workflow.

Read these support docs before finalizing the packet:

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

When to use this skill

• The user asks for broad marketing help and the right next packet is still ambiguous.
• A product, website, funnel, launch, onboarding flow, or pricing surface needs one structured marketing brief before detailed execution starts.
• The request mixes strategy, surface choice, messaging, content, channels, and measurement.
• The user needs a reusable operator brief, not a pile of disconnected suggestions.

When not to use this skill

• The ask is already clearly Steam/store-page/festival/game launch work → steam-store-launch-ops.
• The real job is backlog shaping, milestone coordination, or cross-functional implementation slicing → task-planning.
• The user wants only one atomic copy rewrite or finished content asset with no broader routing layer → use the narrower writing/execution workflow directly.
• The request is mostly product strategy, UX research, or technical implementation rather than marketing routing → route to the stronger adjacent skill.

Core routing model

Operating modes

Use one primary mode per run:

• launch-orchestration — broad launch, GTM, pricing, or rollout sequencing across multiple surfaces
• conversion-surface — landing page, pricing page, signup flow, paywall, or onboarding conversion friction
• lifecycle-retention — onboarding, activation, retention, churn, lifecycle email, re-engagement, or user education motion
• acquisition-content — SEO, content strategy, comparison pages, organic acquisition, or channel-facing discovery work
• measurement-experiment — analytics setup, attribution, KPI cleanup, campaign readout, or experiment/backlog instrumentation

Primary lanes

After choosing the mode, still choose one primary lane:

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

The mode explains what kind of situation this is. The lane explains which marketing discipline owns the next packet.

Instructions

Step 1: Normalize the intake into one routing profile

Capture the request in this compact form before choosing the packet:

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

If detail is missing, proceed with explicit assumptions instead of stalling.

Step 2: Gather the minimum credible evidence

Do not route from vibes alone. Pull the smallest packet that supports a real decision:

• objective and current bottleneck
• audience / segment / funnel stage
• surface, campaign, or lifecycle moment
• available proof points or constraints
• current KPI or best available proxy
• who owns the next move
• which dependencies or approvals can block execution
• what is still missing that could change the lane choice

Step 3: Choose one mode, one lane, one packet

Use references/operating-modes-and-route-outs.md.

Default packet mapping:

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

Rules:

• Choose one primary mode.
• Choose one primary lane.
• Return one primary packet.
• Mention secondary handoffs only after the main packet is chosen.

Step 4: Add route-outs before the packet sprawls

Route out instead of absorbing adjacent work when:

• the ask is really Steam wishlists / capsules / Next Fest / store visibility → steam-store-launch-ops
• the ask is really execution slicing / backlog organization / milestone coordination → task-planning
• the ask is already a narrow specialist workflow with a better dedicated skill

A good front door narrows the next move. It does not win by claiming every neighboring job.

Step 5: Build the operator brief

Use references/operator-packet-and-proof-stack.md.

Return this structure:

# 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

Step 6: Keep proof attached to the packet

Every output must name:

• one primary KPI
• one leading signal
• one baseline or explicit assumption
• one success threshold
• one readout window or review checkpoint
• one next owner or downstream workflow

Use references/operator-packet-and-proof-stack.md for the operator packet shape and references/measurement-handoff.md for lane-specific KPI examples.

Output format

Always return a short operator-style Marketing Routing Brief.

Required qualities:

• one primary mode
• one primary lane
• one packet that can actually be handed off
• explicit assumptions when context is thin
• named owner plus dependency/approval visibility
• route-outs when the ask is not really this skill
• proof logic attached to the packet, not bolted on later

Examples

Example 1: broad launch ask

Input

We are launching a new SaaS workflow next month and need help with messaging, landing page copy, onboarding emails, and how to measure whether it worked.

Output sketch

• Mode: launch-orchestration
• Lane: Strategy & growth
• Packet: launch/growth brief
• Secondary handoffs mention copy/messaging and lifecycle execution
• Operator packet names one owner plus likely dependencies or approvals
• Proof stack names one launch KPI and one leading signal

Example 2: pricing-page refresh

Input

Our pricing page gets traffic, but upgrades are weak. We need help with the page and what to test.

Output sketch

• Mode: conversion-surface
• Lane: CRO
• Packet: measurement + experiment packet
• Priority decisions cover offer clarity, CTA hierarchy, proof, and friction

Example 3: lifecycle / onboarding ask

Input

Trial users activate once and disappear. We need onboarding and lifecycle help, plus a sensible KPI.

Output sketch

• Mode: lifecycle-retention
• Lane: Strategy & growth or Copy & messaging
• Packet: channel-ready brief
• Operator packet names the lifecycle owner and any analytics or product dependency
• Proof stack names activation or retained-usage KPI plus a leading signal

Example 4: game-store launch near miss

Input

We need Steam capsule copy and Next Fest marketing help for our game demo.

Output sketch

• Keep the response short
• Route execution to steam-store-launch-ops
• Leave only a concise handoff note instead of a giant generic marketing plan

Best practices

1. Act like a front-door router, not a generic growth advisor. 2. Choose one mode before you choose tactics. 3. Choose one packet before you list channels. 4. Keep owner, approvals, and dependencies visible instead of assuming automation removes them. 5. Keep launch/planning/game-store boundaries explicit. 6. Attach proof and ownership to every packet.

References

• 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

Measurement and Handoff Rules

marketing-automation should leave a small but durable measurement plan in every output.

Minimum measurement payload

• Primary KPI — one number that matters most now
• Leading signal — early sign that the work is helping
• Baseline — current state or explicit assumption
• Success threshold — what improvement would count as a win
• Owner — who should implement or read the result next

By lane

CRO

• KPI: conversion rate, signup completion, checkout completion, CTA CTR
• Leading signal: CTA clicks, form starts, step completion rate
• Handoff: page/flow owner + experiment backlog

Copy & messaging

• KPI: CTR, reply rate, conversion rate, demo-booking rate
• Leading signal: scroll depth, email opens, CTA clicks, qualitative resonance
• Handoff: copy owner, designer, lifecycle marketer, or PMM

SEO & content

• KPI: ranking, organic sessions, assisted conversions, qualified traffic
• Leading signal: indexation, impressions, click-through rate, internal-link coverage
• Handoff: content/SEO owner with page brief or outline

Ads & analytics

• KPI: CAC, CTR, CPA, tracked conversion rate, clean event coverage
• Leading signal: event firing, audience match, campaign tracking hygiene
• Handoff: analytics owner or paid media operator with spec/checklist

Strategy & growth

• KPI: launch conversion, activation, retention, trial-to-paid, churn reduction
• Leading signal: milestone completion, launch asset readiness, first-week funnel movement
• Handoff: launch owner, PMM, growth lead, or lifecycle owner

Anti-patterns

• Do not leave measurement blank just because the user asked for copy.
• Do not list ten KPIs; keep one primary KPI and one leading signal.
• Do not assume implementation ownership is obvious; name the next owner or workflow.

Operating Modes and Route-Outs

Use this page when marketing-automation has already activated and you need the smallest next decision.

Mode picker

Tie-break rules

1. If the ask names a surface but not a KPI, bias toward conversion-surface. 2. If the ask names a KPI or reporting gap but not the surface, bias toward measurement-experiment. 3. If the ask spans many surfaces and the team mostly needs sequencing, bias toward launch-orchestration. 4. If the ask is about user behavior after signup or activation, bias toward lifecycle-retention. 5. If the ask is search/discovery-first, bias toward acquisition-content.

Route-outs

Minimal response shape

A strong front-door answer usually fits this outline: 1. Mode: the one mode you chose 2. Lane: the one primary lane you chose 3. Packet: the single packet to hand off next 4. Measurement: KPI + leading signal + owner 5. Route-out: only if the task is really adjacent or specialist

Operator Packet and Proof Stack

Use this file when marketing-automation has already chosen the mode and lane and now needs the smallest packet that can survive real operator handoff.

Core idea

A good marketing packet is not just tactics. It is the smallest artifact that names: 1. the owner, 2. what must happen next, 3. which approvals or dependencies can block delivery, 4. what proof will decide whether it worked.

This reflects how teams actually operate across docs, PM boards, CRM/lifecycle tools, analytics stacks, and launch trackers.

Minimal operator packet

## Operator packet
- Primary owner: ...
- Dependencies / approvals: design | analytics | engineering | legal | partner | none
- Required assets or inputs: ...
- Delivery horizon: immediate | this week | this month

Guidance

• Primary owner — name the person or function that should carry the packet next.
• Dependencies / approvals — surface blockers early instead of hiding them in execution notes.
• Required assets or inputs — list only the inputs without which the packet cannot be actioned.
• Delivery horizon — make the packet usable for near-term coordination.

Proof stack

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

Guidance

• Primary KPI — one number that matters most now.
• Leading signal — the first credible signal before the KPI fully matures.
• Baseline or assumption — current state if known, otherwise the explicit assumption.
• Success threshold — the smallest improvement that counts as a win.
• Readout window — when the team should review results instead of leaving measurement vague.
• Next owner / workflow — who reads the proof next or which system owns the readout.

Packet patterns by mode

Launch orchestration

Use when the team needs one launch/growth brief.

• Owner often: PMM, growth lead, founder, launch owner
• Common dependencies: design, engineering, analytics, support, sales, partner teams
• Common proof stack: launch conversion KPI, early funnel movement, launch readout after first week or milestone review

Conversion surface

Use when the team needs one page/flow brief or experiment packet.

• Owner often: CRO lead, PMM, copy owner, growth PM
• Common dependencies: designer, web owner, analytics, experimentation tooling
• Common proof stack: conversion rate, CTA clicks, form starts/completions, readout after enough traffic or one experiment window

Lifecycle retention

Use when the team needs one lifecycle/journey packet.

• Owner often: lifecycle marketer, CRM owner, PMM, growth lead
• Common dependencies: analytics, product events, copy, email/notification tooling
• Common proof stack: activation or retained-usage KPI, early open/click/step-completion signal, readout after one lifecycle cycle

Acquisition content

Use when the team needs one content/SEO brief.

• Owner often: SEO lead, content strategist, PMM
• Common dependencies: SME input, editor, designer, analytics/search tooling
• Common proof stack: organic sessions or qualified visits, impression/indexation signal, readout after indexing + early traffic window

Measurement experiment

Use when the team needs one analytics or experiment packet.

• Owner often: analytics lead, growth PM, paid operator
• Common dependencies: event instrumentation, dashboard owner, engineering, media buyer
• Common proof stack: clean event coverage, tracked conversion, experiment cadence, readout tied to launch or experiment checkpoint

Anti-patterns

• Do not output a packet with no named owner.
• Do not leave approvals or dependencies invisible when they obviously govern the timeline.
• Do not list ten KPIs; choose one KPI and one leading signal.
• Do not make readout timing implicit.
• Do not treat downstream tools as proof that routing is solved.

Routing Heuristics

Use this file to choose the primary lane for marketing-automation.

Choose CRO when

• The user wants more signups, purchases, or completions from an existing page/flow
• The main object is a landing page, pricing page, form, signup flow, or onboarding flow
• The next useful packet is a test plan, friction analysis, or page/flow brief

Choose Copy & messaging when

• The main bottleneck is positioning, page copy, subject lines, CTA text, or narrative clarity
• The user already knows the surface but needs the words to convert better
• The next useful packet is a copy deck, messaging hierarchy, or rewrite brief

Choose SEO & content when

• The request centers on keywords, search intent, comparison pages, content clusters, or structured content plans
• Organic discovery is the main goal
• The next useful packet is an SEO brief, outline, comparison-page structure, or programmatic template

Choose Ads & analytics when

• The request is about paid channels, event instrumentation, attribution, dashboard setup, or test/readout design
• Measurement clarity is the bottleneck
• The next useful packet is an analytics spec, campaign-measurement checklist, or experiment plan

Choose Strategy & growth when

• The request spans launch planning, pricing, retention, churn, referrals, or experiment prioritization
• The right answer needs cross-channel sequencing before asset production
• The next useful packet is a launch brief, growth brief, or prioritized backlog

Tie-break rules

1. Pick the lane that reduces ambiguity fastest. 2. If the user named a KPI but not a surface, bias toward Strategy & growth or Ads & analytics. 3. If the user named a surface but not a KPI, bias toward CRO or Copy & messaging. 4. Mention secondary handoffs only after choosing the primary lane. 5. If the task is actually game-specific launch/store work, defer to steam-store-launch-ops.