What is a deal stage in a CRM?
A deal stage is a named step in your pipeline with a written exit test. What makes a stage real, why buyer actions beat seller intentions, and how many to have.
Syncek Team · CRM reference library
/ 4 min read / Art. #20
A deal stage is a named step in your sales pipeline that a deal occupies until it meets a written test to leave. The name is the smaller half. The test is what makes a stage real: an observable thing that has happened, not a feeling about how the deal is going. Without an exit test, a stage is a label somebody applies from memory, and the pipeline it describes cannot be forecast.
What makes a stage real
Two things: a name that describes the buyer's situation, and an exit criterion someone else could check.
Compare two versions of one stage. "Interested" describes a mood, and two people apply it differently on the same call. "Requirements confirmed in writing" describes an artifact: either the email exists or it does not.
The second survives a handover. When a colleague opens the pipeline, an artifact-based stage still means what it meant.
Name stages after the buyer, not after you
"Proposal sent" is a fact about your week. "Proposal reviewed" is a fact about the deal. The first tells you that work happened; the second tells you the buyer engaged, which is the thing you actually wanted to know.
This is the most common fix in a small team's pipeline, and it usually removes a stage or two along the way, because several seller-side stages collapse into one buyer-side one.
How many stages
Between four and seven for most small teams. Fewer and the stages stop distinguishing anything. More and people stop maintaining them, which produces a detailed pipeline nobody trusts.
The test is not the count. It is whether every stage has an exit criterion you could hand to a new hire. If two stages share one criterion, they are one stage.
Add a lost reason as a field rather than a stage: handling a lost deal is about why it ended, and a stage cannot carry that.
Where stages live
Every CRM has them. Pipedrive builds its interface around them, Attio and Syncek let you define stages per object, and a Kanban board in Notion or a status column in Google Sheets is the same idea with less structure. What differs is whether the tool records how long a deal sat in each one.
Time in stage is what turns a pipeline from a list into a diagnosis, because it shows where deals stop moving rather than only where they are. It is also how an agency keeps delivery out of the pipeline.
Set the exit criteria before the names, and re-read them the first time somebody asks whether a deal should move on. The stage hardest to write a criterion for is the one to delete, and the strictest criterion belongs on qualification.
Frequently asked questions
What is a deal stage in a CRM?
A deal stage is a named step in a sales pipeline that a deal sits in until it meets a defined test to move on. Each stage should describe the buyer's situation and carry an exit criterion another person could verify, such as "requirements confirmed in writing". Stages without a written test become labels applied from memory, and a pipeline built from them cannot be forecast reliably.
How many deal stages should a pipeline have?
Four to seven works for most small teams. Below four the stages stop telling you anything useful about where a deal is. Above seven, people stop updating them accurately, which leaves you with a detailed pipeline nobody trusts. The real test is whether every stage has its own exit criterion: if two stages share one, they are the same stage wearing two names.
What is the difference between a deal stage and a pipeline?
The pipeline is the whole sequence; a stage is one step within it. A pipeline describes how a deal travels from first qualified conversation to closed. A stage describes one position on that journey and the conditions for leaving it. Many teams run more than one pipeline, for example one for new business and one for renewals, each with its own stages.
Should "closed lost" be a stage?
Yes, as the terminal stage, but the reason it was lost belongs in a separate field rather than in the stage name. Creating stages like "lost on price" and "lost to competitor" multiplies your stage list and still cannot capture two reasons at once. One closed-lost stage plus a lost-reason field gives you a report you can actually group and count.
What does time in stage tell you?
Time in stage is how long a deal has sat where it is, and it turns a pipeline from a list into a diagnosis. Read it per stage rather than per deal. A stage where most cards are older than your usual cycle is telling you its exit criterion is unclear, or that it quietly asks the buyer for something nobody has given them yet.
Can you change deal stages after you start using them?
Yes, and most teams should after a few months of real use. Changing stage names and criteria is a configuration edit in every mainstream CRM. What needs care is history: if you rename or merge stages, past reporting may not compare cleanly to future reporting, so note the date you changed them and treat comparisons across that line carefully.