sales-process-designlisted

# Sales Process Design Turn an ad-hoc sales motion into defined stages with clear exit criteria — so deals move for real reasons and the pipeline actually means something. ## When to use When pipeline stages are vague or every rep uses them differently, reps disagree on what "qualified" means, forecasts are unreliable because the stages aren't defined, or the team is scaling and the motion needs to be repeatable. ## Before you start 1. **Read the brand/product context first.** Pull the ICP from `.agents/product-marketing.md`. If none exists, ask the user. 2. **Gather inputs:** how deals actually flow today, the average deal size and sales cycle, and who's involved (SDR / AE / SE). 3. **Confirm the objective:** a process the team can follow that makes the pipeline trustworthy. If the user needs forecasting math, that's `pipeline-and-forecast`; if they need the first-call script, that's `discovery-call-framework` — this defines the stages those live inside. ## Method Design the process around how customers actually buy, not your internal steps. Every stage needs a verifiable exit criterion — something objective that must be true to advance — so two reps would agree a deal has moved. Bake a qualification framework sized to the deal into those criteria, and keep the whole thing to a few sharp stages. ## Workflow 1. **Map the buyer's journey first** — how customers decide and buy — then design stages to mirror it. 2. **Give every stage a verifiable exit criterion** ("econ