How to Build Sales Pipeline Stages in a CRM

The CRM is bought, the board is open, the columns are in place. It looks like a system. A month in, the sales manager pulls up the report and finds twelve of fifteen deals sitting in "Interested" — some for three days, some for three months. Nobody flags it as a problem, because the CRM "works": it opens, people fill it in, the columns are there. The columns just don't say anything.

The cause isn't technical. Stage names describe how the rep feels about a deal in the moment, not what the customer has actually done. "Interested," "warm," "thinking it over" — none of these pass a test. Two reps put the same customer in different columns because the word means whatever each of them decides it means that day.

A stage is an action, not a feeling

Every column in a CRM should answer one question: what did the customer do? Not how the rep felt about it — what happened, and can someone else check it. "Interested" has no answer: who decided it, when, and how? "Meeting booked" has one — either there's a date on the calendar or there isn't.

In practice the difference looks like this:

• Instead of "warm lead": "answered the second call, asked about price"
• Instead of "thinking it over": "received the proposal, confirmed they opened it"
• Instead of "basically closed": "contract draft sent, signing date agreed"

Every phrase on the right leaves a trace someone else can verify — a sent email, a calendar entry, a signed document. The phrases on the left describe the rep's mood at that moment, and a mood changes daily and means something different to every rep. A report can still say "40% of deals are thinking it over," but the number measures nothing if the column itself isn't a measurement.

Every stage needs an exit condition

Renaming the columns isn't enough — each stage needs a written exit condition: what specific event moves a deal to the next one? Without it, a deal sits in a column for months, because there's no reason to move it — until someone happens to remember.

The practical fix: write one line on the stage itself — "Exits when: the customer has given a written answer to the proposal (yes / no / question)." Most CRMs (HubSpot, Zoho, Bitrix24) keep a description field on the stage for exactly this, and it usually sits empty not because nobody needs it, but because nobody was ever asked to write it down.

Only then does the average-days-in-stage number the CRM calculates on its own start to mean something. Without an exit condition, "12 days on average" is no more meaningful than a random number on paper.

A stage name is a question — what proves it? If there's no answer, it isn't a stage, it's a mood.

How many stages is enough

Some teams turn every internal step into its own column: assigned, contacted, qualified, meeting booked, meeting held, proposal drafted, proposal sent, negotiating, verbal yes, contract sent, signed. Eleven columns. It looks precise on paper; in practice every extra column is one more click that has to happen at exactly the right moment, and a click that's late — or skipped — makes the report lie.

Fewer stages, each tied to a trace visible from outside the CRM, hold up better: Contact → Meeting → Proposal → Negotiation → Closed. The small steps in between — drafting the proposal, a second call — stay as a task list on the deal card rather than a column of their own. Anyone who needs them opens the card, and they don't distort the report.

How to test the stages before you build them

A well-named stage list can still fail if the team reads it three different ways. A short three-step check before the CRM is fully configured catches that early.

1. Write down the current process

Before opening the CRM, write down what actually happens today — not the ideal version, the real one. This alone usually surfaces the first problem: the same step already has two names on the same team.

2. Ask "what proves it" for every step

Next to each item, write down what a rep can point to as proof it happened — an email, a calendar entry, a signed document. A step with no answer isn't a stage yet; it needs a definition first.

3. Test it on real deals before it goes into the system

Run the new list for a week on paper or in a simple spreadsheet, against real deals. If the team can't agree on what a stage means at this point, it's cheaper to find out now than after it's built into the CRM.

A lost deal is still a stage, not a disappearance

In many pipelines a lost deal just gets deleted or archived — the stats look clean, but the reason it was lost goes nowhere. It's the same problem as the middle stages, just at the exit: a feeling ("they went cold") gets written down instead of an action, and then the deal is forgotten entirely.

The fix is simple: "Lost" should be its own final stage with a required reason field — price, bad timing, went with a competitor, went silent. A "Lost" status with no reason attached isn't a stage, it's a delete button.

Three months in, that field becomes a report on its own: how many deals were lost to price versus to a competitor. That's a real basis for changing how proposals are written. Saying "the ads will bring leads, sales will sort it out" is easy to say, but there's nothing to check it against in a system that never records why deals actually die.

What the number is actually for

This isn't a one-time setup — a new product, a new sales channel, or a growing team will call for a review of the stages again. The principle doesn't change: every column answers "what proves it."

The difference shows up in the outcome. When stages are tied to an action, forecasting stops being a guess and becomes a calculation — the CRM shows exactly how many deals sit where, and a real revenue forecast follows from that. A new hire ramps up faster too, because the meaning of every column is written down instead of living in someone's head.

If you need a CRM built from scratch, or the stages in an existing pipeline redesigned, our CRM setup service, built around action-based stages is built for exactly this — we configure the process in HubSpot, Zoho, Bitrix24, or a system built from scratch.