Pipeline stages are the backbone of forecasting, reporting, and coaching. Strkr ships flexible stage design with probability bands per stage, forecast posture configuration, velocity analysis, and multi-pipeline support for teams running different motions on the same tenant.
A stage on Strkr is more than a column label. Each stage carries probability, forecast category, required fields, typical duration, and semantic meaning. The configuration drives pipeline math and reporting; a well-designed stage set makes forecasting and velocity analysis accurate without additional tuning.
Probability band
The percent chance of close.
Each stage carries a probability band: Prospecting might sit at 10 percent, Discovery at 25, Proposal at 50, Negotiation at 80. The probability drives weighted pipeline math (sum of amount times probability) that gives executives a rough expected-value forecast. Reps also see the probability on the deal detail for sanity-check against their own call.
Forecast posture
Committed, best case, pipeline, excluded.
The forecast posture classifies the stage for forecasting purposes: Committed (Negotiation, Verbal Yes), Best Case (Proposal), Pipeline (Discovery), Excluded (Prospecting, Closed Lost). The posture drives automatic bucket defaults when reps submit the weekly forecast; a rep moving a deal to Negotiation sees the Committed suggestion.
Semantic
Open, closed-won, closed-lost.
Three semantic tags cover the three terminal states: Open (any in-flight deal), Closed Won (revenue recognized), Closed Lost (opportunity ended without purchase). Reports and workflows use the semantic rather than the stage label so a team can rename stages without rewriting reports. The posture matters when designing multi-stage pipelines where terminal states need consistent treatment.
Typical duration
How long records sit in this stage.
Each stage carries a typical duration (median days spent, 90th percentile, maximum). Reports flag records exceeding the maximum as stuck. Managers coach based on comparison to the typical; a rep whose Negotiation duration runs double the team median usually needs help on close-plan execution.
Required fields
Data the stage demands.
Each stage can require specific fields populated before a record can occupy it. Opportunity in Discovery requires discovery call completed and primary stakeholder identified; in Proposal requires close plan and procurement contact; in Negotiation requires signed MSA and legal reviewer. The required-field posture prevents stage inflation (reps advancing deals without actually doing the work).
Stage color
Visual signal on the board.
Stages carry a color used on the Kanban board column header and on deal cards. The color is a visual coaching tool: terminal states in distinct colors prevent confusion, mid-stage colors create visual progression. The admin picks the palette; the pattern aids glanceable pipeline review.
Stage models by motion
Four shipped shapes for four motion types.
Different sales motions want different stage models. A high-volume transactional SMB motion needs fewer stages than a 180-day enterprise motion. The library ships four reference models; teams fork and customize from the closest fit rather than designing from scratch.
Transactional SMB
Four stages, under 30 day cycle.
The transactional SMB model runs four stages: New (just arrived), Qualified (budget confirmed, decision maker reached), Proposal (quote sent), Closed. The shape fits deals that close in days rather than months. The absence of a Discovery stage reflects that transactional SMB sellers qualify in the first conversation; a separate stage would create artificial pipeline inflation.
Mid-market SaaS
Six stages, 60 to 90 day cycle.
The mid-market SaaS model runs six stages: Prospecting, Discovery, Technical Evaluation, Business Case, Proposal, Negotiation, Closed. The shape distinguishes technical evaluation (demos, trial setup) from business case (ROI quantification, procurement engagement). Teams running the shape see cleaner forecast accuracy than teams running a four-stage shape on a 90-day motion.
Enterprise multi-threaded
Eight stages, 120+ day cycle.
The enterprise multi-threaded model runs eight stages: Target, Prospecting, Discovery, Validation, Business Case, Proposal, Negotiation, Legal Review, Closed. The shape acknowledges that enterprise deals carry a distinct Legal Review phase that transactional deals do not need. Executive sponsorship identification lives inside the Validation stage; teams that lose at Legal Review often skipped Validation discipline.
Field service
Service work order lifecycle.
The field service model runs: Request Received, Technician Assigned, En Route, On Site, Work Complete, Invoiced, Paid. The shape maps to a service motion rather than a sales motion. Reports slice technician utilization, average completion time, parts-availability impact. The pattern suits home services, HVAC, plumbing, and similar trades.
Partner channel
Dual-track direct and partner-sourced.
Partner channel pipelines run a parallel stage track: Registered, Co-Selling, Approved Discount, Partner-Signed, Vendor-Signed, Closed. The shape distinguishes direct and partner-sourced motions for correct attribution math. Partner managers see partner-pipeline distinct from direct-pipeline on the dashboard.
Real estate
Listing to close shape.
Real estate pipelines run: Lead, Qualified, Property Showing, Offer, Under Contract, Due Diligence, Closed. The shape matches the real estate transaction lifecycle rather than a software sales motion. Reports slice closing agent, title company, and listing source. The pattern suits brokerages and property management teams.
Multi-pipeline
Separate pipelines for separate motions.
Teams running multiple distinct sales motions (new business plus expansion, direct plus channel, SMB plus enterprise) typically need separate pipelines. Strkr supports multiple pipelines per tenant with per-pipeline stage design, probability bands, and reporting. Users assigned to a pipeline see its stages; cross-pipeline reports roll up at the executive level.
Pipeline per motion
New business vs expansion vs renewal.
A SaaS tenant might run three pipelines: New Business (acquiring new customers), Expansion (growing existing customers), Renewal (keeping existing customers). Each pipeline has its own stages. An AE focused on new business sees the New Business pipeline on their board; a CSM focused on renewal sees the Renewal pipeline. The reports roll up by pipeline type.
Pipeline per team
Commercial, enterprise, SMB separate boards.
Teams with distinct motions by segment often maintain separate pipelines per segment: Commercial, Enterprise, SMB. Each segment has its own stage model; the SMB stage count is lower than the Enterprise stage count. Reps see their segment pipeline; executives see cross-segment rollup on the pipeline dashboard.
Pipeline per product
Different products, different stages.
Multi-product teams occasionally need per-product pipelines when the motions diverge (self-serve product vs enterprise product). The product-indexed pipelines keep the forecast accurate for each; mixing a 7-day self-serve cycle with a 180-day enterprise cycle in one pipeline distorts both velocity and forecast math.
Movement between
A deal can transition pipelines.
A deal that starts in SMB can graduate to Enterprise when the account expands. The transition is explicit: the rep changes the pipeline on the deal; the stage realigns to the matching stage in the new pipeline (Discovery to Discovery, Proposal to Proposal). Historical state preserved on the deal; the transition writes to the audit log.
Report scope
Per pipeline, cross pipeline, both.
Reports and dashboards scope to a pipeline, to a cross-pipeline rollup, or to custom combinations. The pipeline slicer sits on the dashboard header; executives flip between views without separate dashboard rebuilds. The flexibility avoids the common per-motion dashboard clone sprawl.
Permission scope
Users see assigned pipelines.
Pipeline visibility respects the tenant permission matrix. An AE assigned to the Commercial pipeline sees Commercial deals on their board; an Enterprise AE sees Enterprise deals. Cross-pipeline visibility requires explicit permission grant. The posture lets a tenant run segregated motions on one Strkr tenant without rep cross-contamination.
Velocity and health
How fast records move, where they stall.
A pipeline is only as useful as the measurement that calibrates it. Stage velocity reports show how long records sit in each stage, which stages produce the highest fallout, and which reps run cycles faster than peers. The measurements drive refactor decisions and coaching priorities.
Median duration
The typical time in each stage.
The velocity report shows median duration per stage, trending over quarters. Deals spending 42 days median in Discovery when the historical median was 28 is a signal of qualification motion drift; the team dives into recent deals to find the pattern. The quarterly trend is more informative than single-period math.
Fallout rate
The percent of deals that leave each stage lost.
Fallout rate shows what percent of deals that entered a stage ultimately closed lost rather than progressing. A stage with 70 percent fallout deserves examination: maybe qualification is too permissive, maybe the stage represents a critical decision point that teams underestimate. The pattern surfaces where the funnel actually narrows.
Progression rate
Deals that move forward per period.
Progression rate counts deals that advanced forward from one stage to the next in a given period. A healthy pipeline sees roughly 20 to 40 percent of deals in any stage progress per quarter; lower rates indicate a stuck motion. The rate benchmarks against industry norms and against the team historical baseline.
Age-in-stage
Flag records exceeding typical duration.
Deals exceeding the stage typical duration flag as stuck. Stuck deals surface on the manager dashboard with the duration and the responsible owner. The flag drives Monday pipeline review; the manager asks each owner for a status on each stuck deal and either nudges the deal forward or marks it closed lost.
Rep velocity comparison
Who runs faster, who runs slower.
Rep velocity compares each rep stage duration against the team median. A rep whose Discovery runs 50 percent longer than the team median might run deeper discovery (which can be good or bad depending on close rate correlation). The comparison is a coaching input, not a punitive measure; the goal is identifying patterns worth examining.
Historical lineage
Watch the pipeline shape evolve.
The pipeline configuration itself versions over time. A reports cross-reference between the current state and historical state helps the team understand whether a stage change caused a velocity shift or whether external factors drove it. The audit log preserves every pipeline edit with the author identity.
Common anti-patterns
Mistakes to avoid when designing stages.
Six anti-patterns show up repeatedly in pipeline design conversations. Avoiding them saves teams from the common rework cycle where the stages do not match the motion and the forecast drifts. The patterns are specific, not vague.
Anti-pattern one
Too many stages for a short cycle.
A transactional SMB motion with a 7 to 21 day cycle running an eight-stage enterprise shape produces stage noise. Reps advance deals through stages mechanically without the stage representing a real motion milestone. The forecast gains no accuracy from the extra granularity. Fix: collapse stages to match the actual cycle length.
Anti-pattern two
Too few stages for a long cycle.
A 180-day enterprise motion with four stages buries critical motion detail. A deal spending 90 days in Discovery might be legitimately progressing or might be stuck; the stage cannot distinguish. The forecast suffers. Fix: split long stages into motion-specific intermediate stages (Validation, Business Case, Technical Review).
Anti-pattern three
Stage names that describe nothing.
Stage names like Working or Active or In Progress tell reviewers nothing about what the deal actually needs. Stage names should name the motion milestone (Decision Maker Reached, Technical Validation Complete, Business Case Signed). The pattern makes pipeline review conversations substantive rather than vague.
Anti-pattern four
Probability inflation.
Setting Discovery probability at 50 percent so the pipeline math looks healthier is a common temptation and a bad practice. Realistic probability bands match historical close rates; a Discovery stage that historically closes at 15 percent should sit at 15. Inflation produces a forecast nobody trusts, which erodes the forecast motion.
Anti-pattern five
Required fields that nobody fills.
Required fields that reps bypass with placeholder data (unknown, TBD, 123) are worse than no requirement. The field appears populated but carries no information. Fix: require fields that actually drive the motion forward; require fewer, require them well, and trust reps on the rest.
Anti-pattern six
One pipeline for divergent motions.
Running SMB and Enterprise motions on one pipeline distorts every metric. The velocity math averages a 14-day cycle with a 180-day cycle. The forecast math weights 10 small deals equally against 1 large deal. The fix is multi-pipeline design; the migration cost is low given the shipped pipeline-per-motion support.
Audit your pipeline stages in forty-five minutes.
Bring your current stage definitions, probability bands, and last-quarter velocity report. We will walk the anti-patterns, propose two or three edits that typically improve forecast accuracy inside a quarter.
How many pipeline stages is the right number for a typical B2B sales motion?
Five to seven stages suits most B2B motions in the 45 to 120 day cycle range. Four stages fits short transactional motions under 30 days. Eight or more fits long enterprise motions over 120 days with distinct legal and procurement phases. The count matters less than whether each stage captures a distinct motion milestone that teams actually run. A pipeline where reps cannot articulate the difference between Stage 3 and Stage 4 is a pipeline that will inflate forecasts.
Can we change our pipeline stages after we have hundreds of open deals?
Yes. Pipeline stage changes publish to a new configuration version while in-flight deals keep their stage assignment under the old version until the next stage transition. The admin can also run a migration script that remaps old stages to new stages for all open deals (useful when renaming or merging stages). Historical stage transitions preserve their original labels in the audit log; reports can slice by old or new stage names during a transition quarter.
What is the right probability band for a Discovery stage?
The right band matches your historical close rate for deals that reached Discovery. If 20 percent of your Discovery-stage deals historically close won, set Discovery at 20 percent. The band should calibrate to data, not aspiration. Teams running the data-calibrated approach see weighted-pipeline math match actual close within 5 to 10 percent; teams setting bands by gut feel often see a 30 to 50 percent variance. The reports on Strkr show the historical close rate per stage so the calibration conversation stays evidence-based.
How do pipeline stages interact with Strkr Flow automation?
Stage transitions are first-class triggers in Strkr Flow. A deal moving to Proposal can trigger proposal document generation; a deal moving to Closed Won can trigger the onboarding project fan-out; a deal moving to Closed Lost can trigger loss-reason capture and reactivation enrollment. The automation runs on stage change events; nothing about the pipeline configuration itself specifies automation. The separation keeps stages focused on motion milestones and flows focused on downstream actions.
Can one tenant run both a sales pipeline and a service work order pipeline on the same opportunity object?
No. The practical pattern is separate record types rather than separate pipelines on one record type. A sales motion runs on Opportunity; a service motion typically runs on a Case or a custom Work Order object. Each record type has its own workflow and pipeline. The two record types link via the Account record. Attempting to run sales and service motions on one object creates reports that cannot cleanly separate the two.
Does the pipeline configuration carry its own permission scope?
Yes. Pipeline configuration permissions sit in the standard tenant permission matrix. Admins carry full pipeline configuration; team managers can author team-scoped forks; reps see pipelines they are assigned to but cannot modify. The permission posture lets large tenants delegate pipeline iteration to team managers without opening the base tenant configuration to the full org. Every change writes to the audit log with the author identity.
No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.
We use cookies.
Essential cookies keep the site working. If you accept, we also enable Google Analytics
so we can see which pages help and which don't. Reject to opt out entirely. Details in our
Privacy Policy.
