Sales pipeline stages explained (and how to define yours)

A sales pipeline stage is a gate with an entry test and a clock attached, not a label on a column. The common six are Lead, Qualified, Proposal, Negotiation, Won and Lost, and the labels are the least important part of them. What makes a pipeline useful is the answer to two questions per stage: which facts must exist on a deal before it is allowed in, and how long is too long to sit there. Get those right and the board reports reality. Get them wrong and you have a colourful list of opinions.

A stage is a gate, not a label

Most teams define a pipeline by naming columns and stop. That produces a board where a deal moves because a rep felt optimistic on a Thursday, and a forecast that is the sum of those feelings.

The alternative is to treat every stage as a gate that a deal has to pass a test to enter. In Autocloz that is a literal mechanism rather than a metaphor: each stage carries a required_fields list, and moving a deal into a stage whose gate it fails is refused with a 422 and the message Cannot move to '': required field(s) missing or empty: followed by the field names, in the order you wrote the gate. A gate can require core fields — value, expected_close_date, close_reason, owner_user_id, lead_id, company_id, probability — or any custom field you have defined on a deal.

Two details in how "present" is decided are worth knowing before you build a gate on them, because both will surprise you exactly once. A numeric field of zero counts as missing, which is deliberate: a deal with a value of 0 has not had its value filled in. And an empty list counts as present, so a multi-select custom field with nothing selected satisfies a gate that requires it. If you need a genuine "the rep chose something" test, use a single-select or a text field rather than a multi-select.

The reason this matters more than the naming exercise is that a gate is the only part of a pipeline definition that survives a busy week. A rule written in a wiki is followed until somebody is behind on quota.

The six default stages, and what each one has to prove

A new Autocloz workspace is seeded with six stages, each carrying a default probability that gets applied to deals dropped into it: Lead at 10, Qualified at 25, Proposal at 50, Negotiation at 75, Won at 100, and Lost at 0. Won is flagged is_won and Lost is flagged is_lost, which is how every metric in the product finds the terminal columns without matching on their names — so renaming them breaks nothing.

Here is what each one should be required to prove. Adapt the fields; keep the discipline that every stage has a test.

• Lead. A company and a person exist, and somebody owns the record. Gate on owner_user_id. Nothing else, because at this point you genuinely do not know anything.
• Qualified. You have confirmed, from a conversation rather than a database, that there is a problem you address and a person who cares about it. Gate on a custom field recording the qualifying event — who said what, and when. Not a checkbox.
• Proposal. A number and a date exist. Gate on value and expected_close_date. This is the single highest-value gate in the set, because a proposal-stage deal with no value is the exact row that makes a forecast a work of fiction.
• Negotiation. Terms are in dispute, which means somebody on their side is spending time on you. Gate on a custom field naming the open point. If nobody can name it, the deal is in Proposal.
• Won. Gate on close_reason_category so you learn something from success as well as failure.
• Lost. Gate on close_reason_category too. More on why below.

The move endpoint applies close-reason fields from the request body before it evaluates the gate, so a close-with-reason dialogue can satisfy a gate that requires close_reason in the same action. That ordering is what makes a reason gate usable instead of a two-step annoyance.

Entry criteria beat exit criteria, and the reason is mechanical

Sales-methodology writing usually talks about exit criteria: what must be true before a deal leaves a stage. That framing is fine as a thought but wrong as an implementation, and the difference is where the check runs.

An exit criterion has no natural moment. Nothing happens when a deal "leaves" — the event a system can observe is the deal *arriving* somewhere else. So an exit rule is enforced by whoever remembers it, which means it is enforced on calm weeks and not on the last day of a quarter, which is precisely when it matters.

An entry criterion has an obvious moment and an obvious actor. The deal is being moved, the person moving it is present, and the system can refuse. Write every rule as a condition on the destination stage. "You cannot leave Qualified without a number" becomes "Proposal requires value", and now it is a property of the software rather than a property of your memory.

There is one honest limit to this. A gate can test that a field is filled in. It cannot test that the field is *true*. A rep who needs to move a deal will type a number. What the gate buys you is that the number exists and is attributable, which is enough to make the conversation in a pipeline review a specific one.

Two clocks every stage needs, and only one is obvious

Everyone tracks the expected close date. Fewer teams track the other clock, and the other clock is the one that finds dead deals.

Autocloz stamps stage_entered_at on every deal at creation and re-stamps it on every stage transition, and exposes days_in_stage on the deal. An intra-stage reorder — dragging a card up or down within the same column — deliberately does not reset it, so tidying the board cannot launder a stale deal into a fresh-looking one.

Use the two clocks differently.

Expected close date is a forecasting input and it should be gated. It is also easy to abuse: a deal whose close date has moved four times has told you something, and the honest response is to look at days_in_stage rather than at the latest date. Note that the closing-soon roll-up counts only deals whose expected close date is between today and 90 days out; an open deal whose date has already passed is overdue, not closing soon, and counting it as closing soon inflates the number that everyone reads first.

Days in stage is a hygiene input. Set a threshold per stage — a Proposal older than 21 days is a different animal from a Lead older than 21 days — and review anything over it. The action is usually not "chase harder"; it is "move it to Lost with a reason, or move it back".

Probability and forecast category are two different numbers

A stage carries a default_probability from 0 to 100 that is applied to deals entering it. A deal carries its own probability, which is what the weighted forecast actually multiplies by. Those can diverge, and the divergence is the point: the stage is a base rate and the deal-level number is a correction.

Separately, every open deal carries a forecast_category constrained at the database level to exactly four values — pipeline, best_case, commit, omitted — with pipeline as the default so any deal nobody has touched lands in the neutral bucket. The forecast roll-up buckets open-deal value by category independently of stage probability, and omitted is surfaced but never folded into the other three.

The reason to keep both is that they answer different questions. Stage probability answers "historically, what fraction of deals in this column close?". The forecast category answers "does the person who spoke to this customer last week believe this one closes this period?". A team that only has the first has no channel for the second, and the second is usually better information.

One caution about weighted forecasts generally. Multiplying every open deal by its probability and summing produces a number that is right on average across many deals and meaningless for any particular quarter, which is why the comparison of forecasting methods matters more than the arithmetic. Sum-of-weighted-value is a smoothing device, not a prediction.

A worked example, and where the forecast starts lying

Illustrative numbers, chosen so the arithmetic is visible. Substitute your own.

Sixty open deals. Twenty in Qualified at the stage default of 25%, twenty-five in Proposal at 50%, fifteen in Negotiation at 75%. Average deal value ₹4,00,000 across all of them.

• Qualified: 20 × ₹4,00,000 × 0.25 = ₹20,00,000
• Proposal: 25 × ₹4,00,000 × 0.50 = ₹50,00,000
• Negotiation: 15 × ₹4,00,000 × 0.75 = ₹45,00,000
• Weighted total: ₹1,15,00,000 against an open pipeline of ₹2,40,00,000.

Now introduce one realistic defect. Eight of the twenty-five Proposal deals have no value recorded, so they carry the model default of 0. Those eight contribute ₹0 to both the open total and the weighted total, and the weighted figure drops to about ₹94,00,000 — an apparent 18% collapse caused by nothing but eight empty fields. A team without a value gate on Proposal reads that as a pipeline problem and starts a hiring conversation.

Reverse the defect and it is worse. Suppose instead that fifteen deals sit in Negotiation because they were dragged there during a review and nobody moved them back. At 75% they contribute ₹45,00,000 of a ₹1,15,00,000 forecast — 39% of the total from the stage with the loosest evidence. Check days_in_stage on that column before you believe any weighted number, because a stale Negotiation deal is the most expensive row on the board.

The generalisation: a weighted forecast is a measurement of your data hygiene before it is a measurement of your pipeline. That is the argument for gates, stated numerically. If you want the surrounding numbers, what a lead actually costs to acquire sits on the other side of the same board, and the metrics worth tracking for outbound covers the funnel that feeds it.

Autocloz's free plan covers 5 users and 10 mailboxes, and the configurable deal pipeline with stage gates and forecast categories is in it — start free and build the gates before you import a single deal.

Why a lost deal earns a reason code more than a won one

Won deals get celebrated and analysed. Lost deals get closed and forgotten, which is backwards, because the lost pile is where the information density is.

Autocloz stores two fields on close: close_reason_category, a short machine key such as price, champion, timing, competitor, no_decision or budget, and close_reason, the free text somebody typed. The category is indexed so you can group by it. The free text is where the actual explanation lives.

Keep the category list short — six values, maximum — and resist adding a seventh. A long list produces inconsistent tagging, and inconsistent tagging produces a report nobody trusts. The one category worth arguing about is no_decision, because it is usually the largest bucket in B2B and it is not a loss to a competitor. It is a loss to inertia, and the fix for it is upstream in qualification rather than in the closing conversation.

The reporting move that pays: group Lost by category and by the stage the deal was in when it died, alongside whatever the reporting surface tells you about the touches that preceded each one. Losses concentrated in Qualified mean your list or your targeting is wrong, which is a problem for how the lead list gets built. Losses concentrated in Negotiation mean pricing or process. Those two findings lead to entirely different quarters of work, and the raw win rate cannot distinguish them.

When to add a stage, when to add a pipeline, and when to do neither

Three questions, in order.

Does something different happen at this boundary? If the same person does the same next action on both sides of a proposed new stage, it is not a stage. Two adjacent columns that produce identical behaviour just split your deals in half and halve the sample size of every per-stage statistic.

Do these deals pass through a different sequence of events? If yes, that is a second pipeline, not more stages. Autocloz supports several named pipelines per workspace, each with its own ordered stages, and a deal's pipeline_id is kept consistent with its stage's on every create, move and stage change. Renewals, partner-sourced deals and a services attach motion are the usual honest cases.

Is this actually a filter? Region, deal size, product line and rep are properties of a deal, not places in a process. They belong to filters and views. Splitting a pipeline by region gives every region its own too-small sample and makes the board impossible to read at a glance.

The failure this prevents is the eleven-stage pipeline, which every growing team builds once. It looks rigorous and it produces two effects: deals skip stages, so per-stage conversion is uncomputable, and no single person is accountable for any stage, because there are more stages than people. Four to seven columns is where most B2B teams land, and the reason is organisational rather than analytical. If you are starting from nothing, building a pipeline from scratch is the sequencing, and the pipeline glossary entry is the one-screen version.

What a pipeline stage cannot tell you

Four limits, each worth knowing before you build a process on top of one.

A stage cannot verify that a field is true. Gates check presence, not accuracy. A gate on value gets you a number that exists and has an author; it does not get you a number that is right. That is a review conversation, not a software control.

A stage does not mean revenue. A deal in your Won column records a sales belief. Revenue recognition under IFRS 15, effective for annual reporting periods beginning on or after 1 January 2018, has its own five criteria in paragraph 9 — including that the parties have approved the contract and are committed to perform, and that it is probable the consideration will be collected. Finance will test your Won column; it will not inherit it.

Nothing in this product knows why a deal really stalled. The engagement score cached on each deal is computed nightly from recent activity such as email opens, replies, meetings and notes. That is a proxy for attention, and it is only as good as the activity that was actually logged. Work that happened outside the workspace is invisible to it, and a quiet deal that is progressing on a phone call nobody recorded looks identical to a dead one.

A pipeline says nothing about whether the top of it is healthy. A perfectly gated board fed by a bad list produces disciplined, well-documented losses. The qualification boundary that decides what is allowed in is a separate design problem, covered in the difference between an MQL and an SQL; the tooling comparison for teams weighing a dedicated pipeline tool against an all-in-one is on the Autocloz and Pipedrive comparison. Neither of those is a stage definition, and neither is fixed by adding one.