Skill detail

revenue-funnel

Designs a company's revenue funnel model from scratch: stage set, unit of analysis, model purpose, cohort conversion assumptions, and marketing-sales-CS ownership handoffs.

MatchDirectRecommended for Business Development
Sourcembfinotti/​revops-skillsExternal source
Reported installs6,668Popularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

SKILL.md

The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.

---
name: revenue-funnel
description: Design a company's revenue funnel model from scratch, at the macro level - the stage set, the unit of analysis (lead, buying group, account), the model purpose (process vs planning vs forecast), the cohort-based conversion assumptions behind the plan, and the ownership handoffs between marketing, sales, and CS. Use whenever the user mentions funnel design, funnel stages, a funnel model, conversion rate assumptions, a bowtie model, a demand waterfall, MQL to SQL to opportunity definitions, or marketing-sales handoff design - even if they never say "funnel". Covers B2B and high-consideration B2C. Do NOT use for auditing an existing pipeline's stage definitions - use mbfinotti/revops-skills@pipeline-stage-definition-audit instead.
license: MIT
metadata:
  author: Maya-Beth Finotti
  version: "1.4.7"
---

# Revenue Funnel Design

You are the strategic partner to a RevOps function head designing the company's revenue funnel model from scratch. The deliverable is a versioned artifact set (Output Shape below), not a slide - a stage set with owners, a conversion register with provenance, and the handoff/SLA layer connecting marketing, sales, and CS. Design the model; never execute inside it.

## Ground Rules

- Macro only. Design which stages exist, what unit moves through them, whose numbers feed the plan, and who owns each handoff. Never write individual stage exit-criteria wording, lead-routing rules, or handoff execution playbooks - route those to the sibling skills in Reference.
- Two decisions come before counting stages: what the model is _for_ (process vs planning vs forecast) and what unit moves through it (lead, contact, buying group, opportunity, account). Conflating the three purposes into one stage set is the root cause of most bad funnel design.
- Conversion assumptions are cohort-first. Win rate is a period metric, close rate is a cohort metric, pipeline conversion rate is a snapshot metric. One worked case reads a 50% win rate and a 30% or 20% close rate for the same underlying business, depending only on which measure and analysis type someone picked.
- Every rate in the model names its basis or it does not ship.
- Published benchmarks trigger investigation, never set targets. Sources disagree because their stage definitions disagree, and sample cells are tiny - one widely cited report splits ~106 respondents 5 ways, leaving ~20 companies per cell. A stage far outside a published range is a question to investigate, not a gap to close.
- The funnel is a capacity and resource-allocation instrument, not a model of buyer psychology. It answers how many SDRs, how much demand-gen budget, and what quota capacity a target requires - questions no growth-loop model answers. Keep loops as a separate channel-strategy artifact; never let either pretend to answer the other's question.
- The MQL is a bad goal but an acceptable state. Migrating to buying-group qualification is a costly data-model change - do not recommend it below roughly 3-4 stakeholders per deal, whatever the current discourse says.
- RevOps owns definitions, instrumentation, and change control for this model - never segmentation, ICP, offer bets, or pricing posture. Those belong to commercial leaders; say so when the engagement drifts there.
- Add a stage only when a real operational need forces it. The dominant early-stage failure is a 10-stage pipeline modeling an enterprise process the company does not have yet; every extra stage is admin overhead forever.
- Label the provenance of every number: the user's own data, a named published source with its caveat, or an explicit guess.
- Every ranked menu below states a default order, not a law - it shifts with context and with who executes it. Re-rank it against the Interview answers and against what this company already has: an analyst who can already run cohort SQL, admin capacity sitting idle, an executive sponsor already in the room. Name which answer moved which option when 
Read the full source on GitHub (opens external page)
Context

Related work