An MQL meets marketing’s agreed threshold for fit and or engagement and merits further attention. An SQL meets the organization’s evidence-based criteria for direct sales qualification. A target-company contact who requests a demo may deserve prompt sales review, but the request alone does not prove relevant need, authority, or buying timing.
These are operating definitions, not universal standards. Before configuring scores or workflows, marketing and sales should agree on the evidence required at each transition, who makes the decision, and what happens when information is incomplete.
MQL vs. SQL: the practical difference
An MQL has met a marketing-defined threshold for follow-up. That threshold may combine company and role fit with meaningful engagement. An SQL has met the organization’s criteria for sales qualification. Depending on the process, SQL may mean ready for direct sales outreach or verified after a sales conversation. Choose one meaning and document it.
A high activity score is not proof of readiness. A contact can repeatedly open emails without having a relevant project, while an explicit product discussion request may warrant prompt review. HubSpot’s editorial definitions describe an MQL as interested but not yet ready for direct sales engagement and an SQL as ready for sales interaction. They provide useful framing, not a universal schema. See HubSpot’s MQL and SQL explainer and its sales qualification guide.
A score can prioritize attention. Qualification requires evidence that satisfies an agreed sales-readiness rule.
Where SAL fits and why the stage names matter
A sales-accepted lead, or SAL, can make the handoff visible when sales reviews an MQL before deciding whether to work it. In that model, marketing creates the MQL, sales records acceptance or rejection, and an SQL is reached only when the organization’s qualification evidence is met. HubSpot’s qualification guidance discusses SAL as a possible stage; it does not require every organization to use one.
| Stage | Operational meaning | Evidence to record |
|---|---|---|
| MQL | Marketing threshold met | Fit, engagement, rule version |
| SAL | Sales accepts or rejects review | Reviewer, decision, reason |
| SQL | Sales qualification criteria met | Qualification evidence, timestamp |
| Opportunity | Separate pipeline entry criteria met | Opportunity record and criteria |
Assignment is not acceptance, qualification, or opportunity creation. Add SAL only when sales performs a meaningful review between marketing handoff and qualification. Otherwise, name the owner of the MQL to SQL decision. Record transition timestamps and disposition reasons so operations can distinguish a slow handoff from a qualification disagreement.
Set qualification rules before choosing a score
Write the required evidence first, then decide whether scores help prioritize records. Separate fit from intent, define disqualifiers, and specify what happens when evidence is missing or contradictory.
- Fit: eligible geography, industry, company size, role, and product compatibility. Identify hard gates and fields that are useful but non-blocking.
- Intent: a demo request, substantive reply to sales, pricing question, or another event your team has agreed signals a reason to review. A form submission alone does not verify need, authority, budget, or timing.
- Disqualifiers: ineligible markets, invalid identity, suppression status, an existing sales sequence, or an active opportunity with an owner. Define whether each blocks qualification or routes the record for review.
- Ambiguity: missing company data, conflicting account matches, or unclear intent should go to a named manual owner rather than silently passing a score threshold.
HubSpot documents fit, engagement, and combined scoring, with availability dependent on subscription, object, permissions, and score type. Its current documentation lists Marketing Hub Professional or Enterprise and Sales Hub Professional or Enterprise for applicable scoring capabilities. Use a score to order review within an eligible pool, not as a universal SQL threshold. Preserve the score type, rule version, and evidence behind the decision. See the current lead-scoring documentation and score-building procedure.
For example, a proposed rule could require an eligible company and region plus a verified demo-request event to enter sales review. A missing region routes the record to marketing operations. An existing opportunity routes it to the current account owner for a decision. This is an illustrative operating rule, not a HubSpot template.
Build an auditable MQL to SQL handoff
Use the CRM as the system of record for identity, lifecycle stage, owner, and stage history. Treat source activities as evidence, not duplicate lead records. The practical chain is a qualifying event, identity and account match, rule checks, sales review or assignment, recorded disposition, and a separately governed opportunity decision.
For a HubSpot setup, supported score properties and workflow conditions can help identify records for review. Workflow owner assignment or rotation may be available when the account, seats, object, lead workflow support, and configuration qualify. Assignment does not validate SQL status or create a qualified opportunity. Check the current owner assignment documentation before implementation.
Three implementation patterns
Deterministic fit and intent routing. A new or updated record reaches the MQL review condition. Resolve the CRM identity, validate required fit fields and a high-intent event, check for an existing owner or opportunity, then send the record to a sales queue or eligible owner. Marketing operations handles missing data; sales operations handles routing conflicts.
Human-reviewed MQL, SAL, and SQL progression. Marketing records the MQL evidence and creates a sales review task. Sales accepts, rejects, disqualifies, or recycles the record with a reason. If the organization’s SQL definition requires verified buying readiness, the reviewer records the conversation evidence before changing SQL status. An opportunity is created only under its separate entry criteria.
AI-assisted prioritization. An eligible score can order the review queue, or a proposed external process can extract stated need, urgency, and product interest from supplied activity. Store the source event, confidence, model or rule version, and human disposition. Low-confidence or consequential decisions go to a person rather than directly changing SQL or creating an opportunity.
A proposed decision record might look like this. The field names and values are an illustrative operating contract, not HubSpot defaults:
{
"qualification_status": "sql_review",
"qualification_reason": [
"icp_fit_passed",
"demo_request_received"
],
"evidence_event_ids": [
"evt_illustrative_8831"
],
"definition_version": "qualification_rules_v1",
"processing_status": "pending_owner_assignment"
}
At this grain, the CRM record is the identity anchor, the event ID identifies the source observation, and the rule version makes the decision reproducible. A separate model-run record should use its own run ID and model version. A separate citation or evidence record should identify the evidence event and evidence type. Do not reuse one contact-plus-date key for multiple observations, model runs, or citations.
For broader process design, see HubSpot systems support.
Use AI as a signal, not the qualification authority
AI can prioritize records or extract stated need, urgency, and product interest from supplied activity. Keep the source event, model or rule version, confidence, and review outcome with the result. Validate extracted fields against allowed values and source evidence before they affect routing. Deterministic rules remain preferable for hard eligibility gates because they are easier to reproduce and explain.
HubSpot’s AI-assisted contact fit and engagement scoring requires Marketing Hub Enterprise and, according to its documentation, at least 50 contacts, including 25 converted and 25 non-converted contacts, to generate an AI score. HubSpot also documents predictive likelihood-to-close scoring for eligible Marketing Hub Enterprise and Sales Hub Enterprise subscriptions. It estimates the likelihood that an open contact will close within 90 days. Neither score is a complete SQL decision. See the AI scoring requirements and predictive scoring description.
HubSpot markets Prospecting Agent as capable of monitoring buying signals, sourcing or enriching contacts, and drafting outreach. Its product page is not an API specification or proof of a guaranteed SQL classifier, write-back schema, approval workflow, or deduplication behavior. Confirm product availability, permissions, data handling, and behavior for the actual account before designing around it.
Measure conversion using MQL cohorts
Calculate MQL to SQL conversion as the number of SQLs that came from an MQL cohort divided by the number of MQLs in that cohort, multiplied by 100. If 26 of 200 MQLs created in a defined cohort later become SQLs, the rate is 13 percent.
Do not divide SQLs created this month by MQLs created this month unless the timing and population genuinely align. Leads can progress across reporting periods. Preserve mql_created_at, sql_created_at, source, and definition version. Compare a cohort only after an observation window appropriate to the measured progression lag.
Same-month MQL and SQL totals may describe different populations. Cohort by MQL creation date, allow for observed time-to-SQL, and review the full timing distribution before judging recent cohorts.
Report conversion by cohort, source, and definition version alongside median and percentile time-to-SQL, sales acceptance, recycle and disqualification reasons, and reversed SQL changes. Published percentages depend on definitions and methodology. First Page Sage reports industry figures from its own client-data analysis and uses definitions that differ from HubSpot’s editorial framing. Treat those figures as directional, not universal targets. A low rate is a prompt to investigate source mix, qualification rules, routing, follow-up, sales acceptance, and cohort lag. It is not proof by itself that MQL criteria are too loose.
A practical launch check
Before enabling automation, confirm which CRM object represents each stage, where stage history is stored, and which team owns exceptions. If data is written through an integration, resolve identity before writing and send ambiguous matches to a person. HubSpot documents native deduplication behavior for contacts and companies in specified scenarios, but companies created through its API are not automatically deduplicated by domain. A lookup followed by a create is not safe against two concurrent workers.
For external events, use one row per source event. Store one separate row per qualification decision or model run, one row per stage transition, and aggregate conversion metrics in a reporting layer. Use a stable source event ID where available. An integration can enforce a unique key such as source_system + source_event_id + transformation_version in its own database and use an atomic insert or transactional upsert before attempting the CRM write. A model run needs a distinct key such as record_id + run_id + model_version. Check current API rate limits, association types, access permissions, consent, and retention requirements for the target account. See HubSpot’s deduplication guidance and applicable API limits documentation.
- Every stage has written entry criteria and an accountable decision owner.
- Identity matching, existing-owner checks, active-opportunity checks, and missing-field fallbacks have been tested.
- Source events, decisions, model runs, and stage transitions have distinct identifiers and row grains.
- Concurrent writes cannot create repeated transitions or duplicate records because uniqueness is enforced in the integration process.
- Evidence, rule version, timestamps, sales disposition, and reversal history are retained for audit.
- A limited pilot tracks ambiguous matches, duplicates, sales acceptance, time-to-SQL, and stage reversals.
For help reviewing identity, lifecycle history, and CRM system-of-record decisions, see CRM systems consulting.
