What a Sales Pipeline Is For

Almost every business that sells anything eventually draws a pipeline: a row of stages with deals moving left to right. It is such a standard picture that its purpose rarely gets examined, which is why so many pipelines end up as decoration — updated dutifully, believed by nobody.

The failures are worth separating, because they come from two different misunderstandings of what the thing is for.

Misunderstanding one: the pipeline as a forecast

The most common use of a pipeline is to predict revenue. Multiply each deal by the probability attached to its stage, add it up, and call the result the forecast.

The arithmetic is fine. The inputs are not.

Stage probabilities are almost always invented once, early, by someone estimating, and then never revisited against outcomes. If "proposal sent" is marked at 60% and in reality one proposal in five closes, every forecast built on it is wrong by a factor of three — consistently, in the same direction, invisibly.

Worse, the probability is attached to the stage rather than the deal, which means it encodes an average across situations that are not alike. A proposal to a returning customer and a proposal to a stranger who found you last week are not both 60%.

A pipeline can support a forecast, but only if the probabilities are derived from your own closed history rather than assumed. If nobody has ever compared the two, the forecast is a number-shaped opinion.

Misunderstanding two: the pipeline as a task list

The other common use is as a work queue: look at the board, see what is in front of you, do the next thing.

This fails differently. A pipeline organises deals by stage, not by urgency, and those are unrelated. A deal sitting in an early stage for two months needs attention far more than one that entered a late stage yesterday, but the board displays the second more prominently.

The result is a team that works the deals that look advanced and neglects the ones that have quietly stopped moving — which is precisely backwards, since the stalled ones are where the recoverable value sits.

What it is actually good for

A pipeline earns its place as a shared description of where things stand, and its value is almost entirely in what it makes visible to people other than the deal owner.

It answers questions that are hard to answer any other way. Where do deals stop? Not which stage has the most deals, but which stage they enter and never leave. That is where the process is broken, and it is invisible to the person handling each deal individually, because from inside each one it looks like an ordinary delay.

It answers: what is nobody working on? Every pipeline has deals that are technically open and practically abandoned. Making them countable is the first step to either reviving them or closing them honestly.

And it answers: are we short of work in six weeks? The early stages are the only forward-looking part of a business's information, and they are usually the least maintained.

The condition that makes any of it work

All three of those uses depend on the stages meaning the same thing to everyone, and this is where most pipelines quietly break.

If "qualified" means "I had a good call" to one person and "budget confirmed" to another, then counting deals by stage is counting two different things. The number goes up, the meaning goes down, and after a few months people stop citing it.

The fix is unglamorous: write down what has to be true for a deal to be in each stage, in one sentence per stage, and make the criteria observable rather than felt. "They have told us their budget" can be verified. "They seem keen" cannot.

Fewer stages help. Most pipelines have more stages than the business has distinct decisions, and every stage beyond the real number is a place for deals to accumulate ambiguously.

Do not let it become a data-collection exercise

The instinct when a pipeline is not trusted is to require more information: mandatory fields, forced next-step dates, notes on every stage change.

This reliably makes it worse. Required fields get filled with whatever passes validation, and the pipeline gains the appearance of rigour while losing accuracy. The rule worth applying is the one we apply to data generally — not collecting it speculatively "in case it is useful later" [1]. Every field on a deal should have a person who reads it and a decision it changes.

The portability point that is easy to miss

A pipeline is not only an internal tool. It contains personal data about identifiable people — their names, their employers, what they said, what they wanted, and often someone's private assessment of them.

Two things follow. Those individuals have a right to receive that data "in a structured, commonly used and machine-readable format" and to transmit it elsewhere [3], and a business that cannot produce it on request is not in a position to honour that. And you should be able to get the whole thing out for your own purposes — for us, a JSON export of all your records [2] — because a pipeline you cannot extract is a pipeline you cannot analyse, migrate, or check.

Both are reasons to be thoughtful about what goes in the notes field, which in most organisations is the least governed and most candid part of the entire system.

The test

Before that, though, one habit is worth adopting, because it costs nothing and fixes the most common complaint about pipelines — that they are always out of date.

Update the pipeline as a by-product of doing the work, never as a separate administrative act. If moving a deal forward requires opening a second system and remembering to do so, it will be done in batches, late, from memory, by someone reconstructing the week. That reconstruction is where accuracy dies: not through dishonesty, but because a stage change recorded on Friday for something that happened on Tuesday loses the timing, and timing is most of what the pipeline was going to tell you.

The practical version is that the place you write the email, log the call, or send the quote should be the place the stage changes — ideally automatically, as a consequence of the action. Any design where the record and the work live apart will drift, and no amount of discipline holds it together indefinitely.

The test

Ask two people to define your third stage without conferring.

If the answers differ, nothing built on that pipeline means what you think it means — and no amount of reporting will fix a definition problem.