Deal lifecycle stages come up all the time in my work. Nine times out of ten, something’s been customized. And nine times out of ten, I walk away wondering if it needed to be.

I’ve been on both sides of it. I’ve helped clients build custom stages from scratch, and I’ve been the one three months later asking ‘wait, what does this one mean again?’ Here’s what I’ve landed on.

The defaults exist for a reason

Most CRMs ship with deal stages that look something like this: MQL, SQL, Appointment Scheduled, Qualified to Buy, Proposal Sent, Negotiation, Closed Won, Closed Lost. The specific names vary by platform, but the concept is the same. They represent a progression from “this person showed some interest” to “this person is paying us money.”

These stages aren’t arbitrary. They’re based on how the vast majority of B2B sales processes work. The terminology is widely understood, which means your team, your future hires, and anyone who’s worked in B2B before will immediately understand what they mean.

When you customize, you lose that shared understanding. “Stage 3: Engaged Prospect” might make perfect sense to the person who created it, but six months from now, your new sales hire has no idea what it means or how it’s different from “Stage 2: Active Lead.”

What most teams actually need

Instead of customizing the stage names, spend time defining what each default stage means for your specific business. This step is sometimes skipped, and it’s the one that matters most.

For each stage, write down three things:

The definition. What does it mean for a contact to be in this stage? Be specific. “Lead” is not a meaningful definition. “Someone who has filled out a contact form on our website” is clear and precise.

The entry criteria. What has to happen for a contact to move into this stage? This should be concrete and observable. “Downloaded a whitepaper and visited the pricing page” or “Sales rep has had a discovery call and confirmed budget.”

The exit criteria. What moves someone out of this stage and into the next one? And what moves someone backward? Yes, deals should be able to move backward. If an SQL goes dark for 60 days, they probably shouldn’t still be an SQL.

Set up the rules

Once you’ve defined each stage, build the automation. Most CRMs let you create workflows that automatically advance contacts when they meet certain criteria. Instead of relying on your team to manually update deal stages, let the system do it or send explicit owner prompts based on the rules you defined.

A few things to think about:

Days in stage. How long should someone sit in a stage before something happens? If a lead has been an MQL for 30 days and nobody’s contacted them, that’s a process problem, not a data problem. Set up rep alerts or manager reports that flag stale contacts.

Gates. Some transitions should require a human decision. Moving from MQL to SQL might need a sales rep to confirm that they’ve qualified the contact. That’s important. Build it as a task or an approval step, not a fully automated workflow.

Backward movement. If a deal falls apart, the contact shouldn’t stay at the Opportunity stage forever. Define what triggers a backward move and automate it. “No activity in 90 days” is a reasonable starting point.

When customization actually makes sense

There are cases where the defaults don’t work. If your sales process has a genuinely unique step that doesn’t map to any standard deal lifecycle stage, adding a custom stage might be the right call. For example, some companies have a “pilot” or “trial” stage between Opportunity and Customer. That’s a legitimate business process that deserves its own stage.

But “I don’t like the name MQL” is not a good reason to customize. “Our team doesn’t use that terminology” is also not a reason. Try to adopt the terminology. It’s industry standard for a reason, and fighting it can create more confusion than it solves.

Platform-specific resources

If you want to dig into the specifics of how deal lifecycle stages work in your CRM, here are the official docs:

The bottom line

Strong definitions and clear rules matter more than custom stage names. Get those right first. Try using the defaults. Write internal documentation that explains exactly what each stage means for your business. Set up automation to move contacts through the stages based on observable criteria. Revisit every quarter to make sure the definitions still match how your team actually works.

If you’ve done all that and there’s still a gap that the defaults can’t cover, then customize. But a lot of teams may never get there, and that’s a good thing.

If this is the kind of problem you're working through, I'm happy to talk it over. No pitch, no pressure.

Let's talk
← All resources