HubSpot lifecycle stages: a practical setup guide

If marketing calls every form submission an MQL while sales expects a qualified buyer, a workflow will pass that disagreement straight into the CRM. I would start with a written definition that both teams can use.

Then check which changes HubSpot already makes. Add automation for the decisions your process still needs, with someone responsible for reviewing exceptions.

Lifecycle stage, deal stage and lead status

Lifecycle stage describes a contact or company's relationship with your business. Deal stage describes a specific sales opportunity; one contact can have several deals. Lead status describes sales follow-up, such as Attempted to Contact or Connected. HubSpot positions it within the SQL lifecycle stage. See HubSpot's property definitions.

HubSpot includes eight default lifecycle stages, which you can customize. Use them as a starting point for your own definitions:

HubSpot's lifecycle guide documents the defaults and update behavior. Keep activities such as attempted calls in lead status, so the lifecycle property can describe the broader relationship.

Agree what qualifies an MQL and SQL

For MQL, separate fit from engagement. Fit might mean a relevant role, company size or market. Engagement might mean a demo request or a scoring threshold. A pricing-page visit alone says little about whether the person is a plausible buyer.

Write a rule the team can check: “A contact becomes an MQL when they meet our fit criteria and show the agreed engagement.” Specify the actual properties and thresholds before building.

For SQL, agree what sales must review and accept. Assigning a contact to a rep is not evidence that the review happened. A sales-acceptance checkpoint can use a custom review property, with an owner and a rejection reason. It does not have to become another lifecycle stage.

For rejected or poorly timed leads, keep the review outcome separate from lifecycle stage when you need to retain qualification history. Decide how those records can be reconsidered later.

Check native automation before adding workflows

Under Settings → Objects → Contacts → Lifecycle Stage → Automate, review the settings already enabled:

• Record creation: a default stage can be set for new contacts and companies. Check form-level defaults and connected-app behavior too.
• Deals: creation of the first associated deal, or a deal being won, can set a selected lifecycle stage on associated contacts and companies.
• Associated leads: a setting can update lifecycle stage when a lead is associated. Leads created by automation are an exception.
• Company sync: the primary company's stage can update associated contacts. A contact's stage does not update its company through this setting.

These settings move stages forward. Check the automation rules and exceptions before enabling them, including what happens to existing records. A missing association needs investigation; another workflow cannot identify the right customer by itself.

Add workflows for your qualification rules

Use the native deal settings where they fit. For custom qualification, a possible design is:

1. Lead to MQL: enroll contacts at the intended starting stage who meet the agreed fit and engagement filters. Set MQL, then notify the owner or create a task if needed.
2. MQL to SQL: use an explicit acceptance decision, such as a custom MQL Review property set to Accepted. Record rejection reasons separately and define the follow-up responsibility.
3. Review stalled records: flag contacts that have stayed in MQL or SQL without relevant activity. A quarterly review of records older than 90 days is an example; choose a threshold that fits your sales cycle.

The workflow property-update action requires a Professional or Enterprise account. Confirm the actions available in your subscription before choosing the design.

Test a small set of records first: an eligible lead, an existing customer, a rejected MQL and a record with missing associations. Check enrollment and re-enrollment rules, property history and any notifications. Existing customers should not be treated as new MQLs because they submit another form.

For stage-based review, use the entry date or the time since lifecycle stage changed. HubSpot's calculated latest/cumulative time values have special behavior while a record is still in a stage; check the property guidance before using them as triggers.

Correct existing records in controlled batches

Start with evidence you trust, such as purchase records, deal history and recorded qualification decisions. Keep uncertain cases for review rather than forcing every record into a guessed stage.

Before a bulk import or workflow update:

• Export record IDs and current values, and identify automation that could react to the change.
• Agree the mapping and review a representative sample with marketing and sales.
• Test a small batch, inspect property history and downstream effects, then expand the update.
• Assign an owner to unresolved records and repeat the check after the next relevant data refresh.

You can manually move a stage backward. Imports, forms, APIs and workflows require the current value to be cleared before setting an earlier stage. A manual backward move can reset legacy “Became a” dates; newer calculated history properties behave differently. Check the documented date effects before clearing or resetting values. A property export alone does not restore every historical date or downstream action.

Measure the handover using your own definitions

For MQL-to-SQL conversion, define the MQL cohort and how long it has to reach SQL. Measure the proportion accepted under the same criteria, then compare sources and rejection reasons. A generic benchmark cannot tell you whether the issue is fit, follow-up or a different definition of SQL.

My data quality case shows how I separate a detected mismatch from the decision to correct it. For the surrounding sales process, see my pipeline review approach.

Questions about the setup? You're welcome to compare notes.