HubSpot ships seven defaults. Most teams keep all seven, define none of them, and end up with reporting that describes a company that does not exist. Here is how to fix it.
Keep four or five stages. Give each one an entry condition anyone can check without asking, a single owner, and an exit. Delete the rest. Then test the definitions on ten real records with one person from sales and one from marketing, separately.
HubSpot ships eight lifecycle stages: Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist and Other. They are a suggestion from a company that has to ship something reasonable for every kind of business at once.
The trouble is that they sound self-explanatory, so nobody writes down what they mean. Six months later marketing reports 400 MQLs, sales says they received about 90 real leads, and both are looking at the same database. Neither is lying. There is simply no shared definition of the boundary.
Take ten real records from your CRM. Give the stage definitions and the ten records to one person in sales and one in marketing, separately, and ask them to sort. If they sort the same way, your stages are defined. If they do not, you have labels rather than stages, and every report built on them is fiction.
This takes twenty minutes and it is the single most useful thing you can do before rebuilding anything. It also tells you exactly which boundary is broken, which is usually the one between marketing qualified and sales qualified.
Every stage needs three things written down.
| Stage | Enters when | Owner |
|---|---|---|
| Subscriber | Gave you an email address for content, nothing more. No fit check applied yet. | Marketing |
| Lead | Matches the written fit definition and has taken any action beyond subscribing. | Marketing |
| Qualified | Fit plus a specific intent signal you agreed in advance: a demo request, a pricing view, a reply to outreach. | Marketing, handing over |
| Working | Sales accepted it and has made contact. Acceptance is an explicit act, not a default. | Sales |
| Customer | Signed. Set automatically from the deal, never by hand. | Sales |
Note what is missing. There is no separate MQL and SQL, because in most companies the distinction between them is exactly the boundary nobody can define. One qualified stage with a written definition beats two vague ones.
Most lifecycle models describe only the happy path. The one that actually improves things over time is the rejection path: when sales does not accept a qualified lead, they pick a reason from a short fixed list. Wrong size, wrong role, no budget, already a customer, bad data, too early.
Those reasons feed back into scoring and into the fit definition. Without them, the same wrong leads keep arriving and the only available response is for sales to trust marketing less.
On a database of moderate size with an existing team, expect roughly four weeks from audit to first workflow live: a week to audit what exists and where records get stuck, a week to agree the definitions with the people who will be held to them, and two weeks to build, migrate history and rewire the reports. The agreement week is the one that slips, and it is the one that cannot be skipped.
Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer, Evangelist and Other. They are a starting suggestion, not a model. Most companies need four or five of them, clearly defined, rather than all eight left vague.
Four or five for most B2B companies. Every stage you add is another boundary two people can disagree about. If you cannot describe what has to be true for a record to enter a stage in one sentence, delete the stage.
Lifecycle stage describes the relationship with a person or company and moves forward only. Deal stage describes one specific opportunity and can be lost. A person can be a Customer while a new deal with them sits at an early stage.
No. Set the property to forward-only. If a customer goes quiet, that belongs in a separate status field, not in the lifecycle stage, because moving it backwards destroys your ability to report on cohorts.
The first two weeks produce a status map of your own stack. Every piece named, colour coded by how proven it is, gaps included. You keep it whether or not we work together.