MQL-to-SQL Conversion Rate: Formula, Cohorts, and Diagnosis

An MQL-to-SQL conversion rate is useful only when the team can state who or what is being counted, which stage transition qualifies, and how much time each MQL had to progress. Without those rules, the percentage can change because of CRM cleanup, a new scoring threshold, or a shorter reporting window rather than a real change in pipeline quality.

Define the rate before counting it

Start by writing down what an MQL and an SQL mean in the current process. The definitions should include the observable evidence required to enter each stage and the action the stage triggers. A general guide to MQL versus SQL criteria and handoff covers those definitions; this article focuses on measuring the transition between them.

There is no single CRM-independent definition of either stage. For example, HubSpot describes lifecycle stages as a way to categorize contacts and companies by where they are in a marketing and sales process. Salesforce’s lead-conversion workflow describes a record operation that can create or associate a contact, account, and opportunity. Those platform concepts are useful, but they do not make a particular field or conversion event the universal definition of an SQL. Use your documented operating rules and keep them stable during comparisons.

Use one numerator, denominator, and entity

For a fixed MQL-entry cohort, calculate:

MQL-to-SQL conversion rate = eligible MQLs from the cohort that reach SQL within the observation window ÷ eligible MQLs in that cohort with a complete observation window × 100.

The numerator and denominator must use the same unit. Choose contacts, accounts, or another explicitly defined entity. In account-based programs, counting five contacts from one buying group as five independent conversions may overstate movement; account-level measurement may be more useful. Contact-level reporting can still be useful when the buying process is genuinely person-led. State which question the report answers and do not mix the two views.

Also choose how to treat recycled records. A contact may become an MQL, return to nurture, and qualify again later. Either count the first MQL entry per entity for the period or count each re-entry episode as a separate opportunity to progress. Do not combine first-entry denominators with repeat-entry numerators.

Build a mature MQL cohort

Group records by the date they entered MQL, not by the month when they later became SQL. Otherwise the report divides SQLs created this month by MQLs created this month even though the SQLs may have come from much older records.

Select an observation window using the team’s historical time from MQL entry to SQL. The right interval depends on the sales motion and the stage rules; it is not a universal 30-, 60-, or 90-day standard. Compare cohorts only after they have had the same full window to progress. Show more recent, still-open cohorts separately as “not yet mature” rather than treating every recent MQL as a failure.

For each cohort, preserve at least the MQL entry date, SQL entry date, entity ID, stage-definition version, source at MQL entry, and any exclusion reason. If a record was merged, duplicated, disqualified, or moved back to an earlier stage, apply the same documented rule to every cohort.

Separate sales acceptance from SQL qualification

Some teams use a Sales Accepted Lead (SAL) stage between MQL and SQL. SAL records that Sales has reviewed and accepted a lead for follow-up; SQL records a later qualification decision under the company’s sales criteria. The stages answer different questions, so do not report them as one transition. See the SAL definition and handoff guide.

When SAL is used, report at least two rates from the same MQL cohort:

• MQL→SAL acceptance rate: MQLs accepted by Sales within the agreed review window ÷ eligible MQLs with a complete review window.
• MQL→SQL qualification rate: MQLs that meet the documented SQL criteria within the chosen observation window ÷ eligible MQLs with a complete observation window.

The first helps reveal routing, response, and capacity issues. The second shows how much of the original MQL cohort progressed to the defined sales-qualified state. For general rules on stage-to-stage comparisons, see how to calculate pipeline conversion rates fairly.

Example: calculate the rate for a mature cohort

Suppose 120 eligible contacts entered MQL in a cohort and all had the full observation window chosen by the team. Eighteen reached the documented SQL stage during that window:

18 ÷ 120 × 100 = 15%.

If 27 were accepted for follow-up as SALs, the MQL→SAL acceptance rate would be 27 ÷ 120 = 22.5%. The nine additional accepted records that did not reach SQL remain visible in the transition between acceptance and qualification; they should not be silently counted as SQLs.

This is an illustrative calculation, not a market benchmark or a recommended target. A real report should show the counts with the percentage—for example, “18 of 120”—and show the selected time window. If another 40 MQLs entered recently and have not completed that window, list them separately as an immature cohort.

Diagnose the result instead of chasing a percentage

Compare the same mature cohorts by a small set of useful dimensions: original source or campaign, account fit, offer, region, segment, and sales team. Keep the cohort size beside each rate. If volume is small, combine periods or label the result as directional instead of ranking teams or channels on a few records.

Use the pattern of measures to decide what to inspect:

• If MQL→SAL acceptance and MQL→SQL both fall, check routing coverage, response time, sales capacity, and whether the MQL trigger still reflects the intended audience.
• If acceptance is stable but SQL qualification falls, review discovery notes, disqualification reasons, the SQL criteria, and the source or segment mix.
• If the rate rises while opportunity creation or qualified-meeting volume falls, check whether SQL criteria became easier to satisfy or stage updates changed. A higher rate is not automatically more pipeline.
• If one source performs differently, verify source capture and account mix before crediting the channel. Keep source assignment consistent, such as the source recorded when the entity first entered MQL.

Pair this measure with downstream outcomes such as opportunity creation, qualified meetings, and contribution. The cost-per-qualified-meeting guide shows one later acquisition-quality measure. The separate lead-to-opportunity conversion guide measures a later transition and should not be substituted for MQL→SQL.

Is there a good MQL-to-SQL conversion rate?

There is no single percentage that works as a reliable target across companies. Stage definitions, sales cycles, account mix, products, and observation windows differ. A benchmark is useful only if it measures the same entity, transition, cohort rules, and time window. Do not compare your rate with a number that leaves those details unstated.

Build a baseline from several mature cohorts using one stable definition. Then review it alongside cost per qualified outcome and later opportunity or revenue measures. If stage rules or CRM data changed, mark the break in the series before treating the new percentage as a performance shift.

Keep the measurement specification with the report

Before setting a target, save a short measurement note beside the dashboard: stage definitions and effective dates; contact- or account-level unit; first entry or re-entry rule; cohort date; observation and review windows; source assignment; duplicate and exclusion treatment; and the CRM fields used to identify progression. When the rule changes, mark the date and avoid presenting old and new definitions as one uninterrupted trend.

That discipline makes the rate useful to Marketing and Sales: it shows whether a defined group of MQLs progressed to a defined qualification outcome, while leaving the team room to inspect response time, fit, and downstream revenue before changing spend.