Sales

A pipeline is supposed to answer two questions: what is going to close, and what is going wrong. Most of them answer neither, and the reason is usually one of three things that are all fixable.

The stages came with the software. Prospecting, qualification, proposal, negotiation, closed. Those describe a particular kind of business to business sale and describe almost nothing else. A firm doing admissions, a contractor tendering, an agency pitching and a wholesaler quoting all have real processes with real stages, and none of them look like that. When the stages do not match the process, people put deals in whichever column seems least wrong, and the board stops meaning anything.

There is no probability, or it is fictional. A pipeline without weighting produces one number: the total of everything open, which is always enormously more than will close and is therefore ignored. A pipeline with likelihoods someone invented in 2019 and never revisited produces a number that is precise and wrong, which is worse.

History is overwritten. A deal moves from one stage to the next and the previous state is gone. That single design decision destroys the ability to answer every diagnostic question worth asking: how long things take, where they stall, and whether your forecast was any good last quarter.

What this does instead

Stages you name, with a likelihood on each that you can correct once you have data. History kept, so how long each opportunity sat at each stage is a fact rather than a memory. Totals that count the whole column. And a close reason on everything, because the least numerical output of a pipeline is the most useful one.

The test is whether the probabilities are comparable

Two kinds of work belong in separate pipelines when a deal at the same stage in each has a genuinely different chance of closing. A renewal at eleven months and a new customer at proposal stage are not comparable numbers, and adding them together produces a forecast that is wrong in both directions at once: it overstates the total and it hides the risk in the renewals.

The same applies to work of very different sizes and timescales. An agency pitching for a retainer and quoting for a single project. A provider running admissions for individuals and corporate bookings for employers. In each case one set of stages cannot describe both without describing neither.

The renewal pipeline has a different shape

It is worth saying explicitly, because organisations try to make renewals look like a funnel and it does not work. A renewal pipeline is closer to a set of dates with health attached: healthy, review due, in discussion, renewed, notice served. What you want from it is not a probability of closing but a list of accounts where something is wrong, early enough to act on.

When not to

Do not create a pipeline per salesperson, per region or per product line. Those are filters on one pipeline rather than separate processes, and splitting them makes every cross cutting number harder to produce for no gain. If the stages would be identical, it is one pipeline with a field.

Fewer stages than you think

Every additional stage is a decision somebody has to make correctly under time pressure. Five stages that everyone applies consistently produce better data than eleven stages applied approximately, and the eleven stage board will look more sophisticated while telling you less.

Move deals when the world changes, not when you remember

The value of the stage history depends entirely on stage changes happening at roughly the right time. A weekly ritual of updating the board is better than nothing and much worse than moving a card when the customer actually does something, because the history is what you are measuring.

Record the reason on everything you lose

Twenty seconds. It is the only route to knowing whether the thing costing you work is price, timing, a competitor, a capability you do not have or a market you should stop advertising in. Read twenty reasons in a row after a quarter and the patterns are obvious in a way no report produces.

Correct the likelihoods after one quarter

The initial likelihoods are guesses and should be treated as such. After a quarter you have real data on what proportion of deals reaching each stage closed. Replace the guesses with the measurements, and the forecast stops being decorative.

What has not moved?

Start here rather than at the top of the board. Everything that has sat in the same stage longer than that stage's usual duration, which the stage history gives you. These are the deals that will quietly disappear, and they are invisible in any review that works through the pipeline in order, because they look exactly like the ones that are progressing normally.

The output of this question is a decision on each, and lost is a perfectly good decision. What matters is that a deal stops being alive by someone choosing rather than by everyone forgetting.

What is due to close this period, and is that still true?

Filter to the close dates inside the current period. For each, the only question worth asking is whether anything has happened since the date was set that changes it. A close date nobody has revisited is a guess with a timestamp.

What does the weighted number say, and does anyone believe it?

Read the forecast out loud. If no one in the room believes it, that disagreement is the most valuable thing in the meeting, and it is nearly always about likelihoods rather than about individual deals. Write down what people think it should be, and check against the actual outcome at the end of the quarter. After two quarters of doing that, the argument stops happening.

What did we lose, and what did the reasons say?

Read them together rather than one at a time. A single lost deal always has a satisfying individual explanation. Ten read together frequently say something else entirely, and it is usually a pattern no one would have described in a meeting: a segment that never converts, a competitor that turns up in one stage, a delay that happens at the same point every time.

This is the least numerical output of a pipeline and the most useful. It is also the one that disappears entirely if lost deals are deleted rather than closed, which is the strongest argument for keeping them.

The four writes

The opportunity itself changes stage. If the new stage is a closing one, the outcome becomes won or lost, the reason you typed is stored on the record and the closed date is set to now. Move it back to an open stage and all three of those are cleared again, because a deal cannot be simultaneously open and closed for a reason.

A row goes into stage history: which stage it came from, which stage it went to, when, and who moved it. The first row of every opportunity's history has no from stage, because it was created rather than moved, and that row is written at creation whether the opportunity was typed onto the board or arrived by converting a lead.

The relationship the opportunity belongs to gets a timeline entry naming the opportunity and the stage it moved to. No one links anything for this to happen. It is why opening a customer's record shows their sales movement in with their meetings and their correspondence rather than in a separate place you have to remember to look at.

And the audit trail gets an entry recording the move with the stage it came from and the stage it went to, plus your reason if you gave one. All four writes are in one transaction, so there is no state in which the card moved and the history did not.

The permission that gets checked, and where

Moving a card asks for the update permission on opportunities, and it asks about that particular record rather than about the module. Someone whose role is scoped to what they own can move their own deals and not a colleague's, and the same condition is applied inside the query that builds the board, so a card they may not move is a card they never see.

The same check happens at an unexpected moment on the paid plans: attaching a quotation to an opportunity asks for permission on that opportunity, at the point of attachment. The reason is that accepting the quotation later closes the opportunity as won at the quotation's value. Checking at acceptance would be too late, because by then a customer has agreed a price and refusing is no longer a thing you can do to them.

When the sale closes itself

An accepted quotation moves its opportunity to the first won stage of that opportunity's own pipeline, records the reason as the quotation reference, and writes the stage history row attributed to the quotation rather than to a person. That attribution matters when you read the history back: nobody moved that card, an event did.

The people come across properly

There is a contact import that takes a CSV file, reads your headers and proposes a mapping, then shows you what it found before anything at all is written: how many rows are valid, how many are duplicates of somebody you already have, and every problem row listed with its line number and what is wrong with it. Duplicates are matched on email address rather than on name, because two people share a name far more often than they share an address. You look at that preview and then decide.

The opportunities come across too

There is an opportunity import, on the same preview. It reads a name, the customer, a value and a currency, an expected close date, an outcome, and a pipeline and stage by their names rather than by an identifier, so the mapping is written in your own words. A row naming a stage you do not have stops with that line and that reason instead of landing somewhere approximate, which is the failure that makes an imported pipeline untrustworthy.

It is still worth asking whether you want it. The only deals worth carrying over are usually the open ones, and in an organisation of this size that is a morning's work by hand. Everything you have already won or lost is history, and history is fine where it is: keep the old export, and note that the export you take out of here later contains every table, stage history included.

Stage history cannot come across at any price

This is the part people underestimate. Even where your old system recorded stage changes, those are its stages and its dates, and mapping them onto a set of stages you have just redesigned produces durations that are confidently wrong. Stage history here begins on the day someone first moves a card.

The consequence is worth planning around. For the first weeks, every deal you typed in appears to have been created on the day you typed it, so the durations are wrong for exactly as long as it takes one full sales cycle to pass through. If your cycle is three months, the stage history is not worth reading for three months. That is the cost of starting, it is unavoidable, and knowing it is better than discovering it.

Likelihoods should not come across

If your previous system had them, they were set for someone else's stages by someone who probably guessed. Set new ones, treat them as guesses too, and replace them with measurements at the end of the first full cycle.