What is an MQL?

What it means

An MQL is a routing decision dressed up as a noun. It answers exactly one question: is this lead worth a salesperson's next hour? Everything else people attach to the term (interest, intent, readiness) describes the evidence, not the definition.

The reason the term exists is arithmetic. A rep who works twenty-five conversations a week cannot look at four thousand monthly leads. Something has to sort them, and if that something is not a written rule it becomes whichever lead happened to fill in a form while a rep was refreshing the list. The MQL threshold replaces that accident with a rule two teams have agreed on and can argue about later with data in hand.

A working definition always has three parts, and a definition missing any of them will not survive a quarter:

• A fit component. Firmographic and demographic attributes: company size, industry, geography, job title, technology in use. Fit answers whether you could sell to them.
• A behaviour component. Actions with a timestamp: pricing page visits, demo requests, trial signups, replies to outbound. Behaviour answers whether they are thinking about it now.
• A window. Behaviour without a time bound is archaeology. The score has to describe the last N days, not the lead's entire history.

Fit without behaviour gives you a list of companies you would like to sell to, which is a prospecting list, not an MQL list. Behaviour without fit gives you enthusiastic students and competitors doing research. The threshold has to require both.

The formula, written out

There are two formulas people mean when they say "MQL number", and confusing them is the source of most reporting arguments.

1. The qualification rule. A lead L is an MQL at time t when:

FitScore(L) >= F AND BehaviourScore(L, t - W, t) >= B

• FitScore(L): the sum of weighted firmographic attribute points for the lead, typically normalised to 0-100.
• BehaviourScore(L, t - W, t): the sum of weighted points for scored events whose timestamp falls inside the trailing window.
• F: the fit threshold, a constant you choose.
• B: the behaviour threshold, a constant you choose.
• W: the window length in days.

2. The reporting metrics. Two ratios, both of which need their denominator stated out loud:

MQL rate = (distinct leads that first crossed the threshold in the period / new leads created in the period) x 100

MQL-to-SQL rate = (MQLs accepted by sales / MQLs handed to sales) x 100

Note the two words doing the heavy lifting: distinct and first. Drop either one and the number stops being comparable to last month's.

A worked example, end to end

A mid-market B2B software company runs a 30-day window with F = 60 and B = 40. In March it created 4,180 new leads.

1,436 of those leads reached a fit score of 60 or more. That is 34.4%, which is roughly what you expect when paid traffic is targeted but not perfectly so. Of those 1,436, exactly 612 also reached a behaviour score of 40 within thirty days of their first touch. Those 612 are March's MQLs.

MQL rate = 612 / 4,180 = 14.6%

Sales worked the 612 and accepted 268 of them into the pipeline.

MQL-to-SQL rate = 268 / 612 = 43.8%

Of the 268, 61 closed won at an average contract value of 4,900, producing 298,900 in bookings.

Revenue per MQL = 298,900 / 612 = 488

That last number is the one that makes the metric useful. If demand generation spends 96,000 in March, cost per MQL is 96,000 / 612 = 157, against 488 of revenue per MQL, a gross ratio of roughly 3.1 to 1. Now the threshold is not an abstract preference, it is a lever with a price attached. Loosening B from 40 to 30 might produce 900 MQLs at 107 each, but if acceptance falls to 31% you have handed sales 288 more conversations in exchange for 11 more accepted leads, and the reps will notice before the dashboard does.

Three ways the number goes wrong

Counting re-qualifications as new MQLs. This is the most common failure and it is almost always accidental. If the scoring job writes an MQL row every time the score crosses the threshold, a lead whose score oscillates around 40 generates several. In the March cohort above, allowing re-triggers turns 612 distinct leads into 790 MQL events. Nothing changed in reality, but the reported MQL-to-SQL rate falls from 43.8% to 268 / 790 = 33.9%, and a quarter later somebody proposes tightening a threshold that was never loose. The fix is to count distinct contact IDs and store re-qualification as its own event type.

Using the wrong denominator. Dividing MQLs by every contact in the database instead of by leads created in the period gives a number that only ever falls, because the database only ever grows. With 61,000 total contacts, March's MQL rate reads as 1.0% instead of 14.6%, and the trend line measures database age rather than marketing performance.

Mixing cohort and period accounting. A lead created on 20 February that crosses the threshold on 4 March belongs to February's cohort but to March's period. Both views are legitimate, averaging them is not. Cohort accounting answers "how good was February's traffic", period accounting answers "how busy was sales in March". Pick one per report and label it.

How an MQL is actually derived from CRM data

In a CRM the MQL is not a field somebody sets, it is a computation over three tables plus a calendar.

• The contact record holds the fit attributes and a created_at timestamp that anchors the cohort.
• The scored-event log holds one row per qualifying action with an occurred_at timestamp and a points value. The behaviour score is a windowed sum over this table, not a stored counter, because a stored counter cannot expire.
• The stage-transition log records the moment the contact moved into the MQL stage, who or what moved it, and the acceptance or rejection that followed.

The edge cases are where implementations diverge, so decide them explicitly:

• Duplicates. Two form fills from maya@acme.com and m.yilmaz@acme.com are two leads and possibly one buyer. Deduplicating on email domain over-merges at large companies; not deduplicating at all double-counts at small ones. A workable rule is to count leads distinctly but cap MQLs per account per window.
• Leads that skip the funnel. An inbound demo request arrives already above both thresholds. It is still an MQL, and it should still be logged as one at the same instant it becomes an SQL, otherwise your best source vanishes from the conversion report.
• Backfilled data. An enrichment job that fills in company size on Tuesday can push a lead over the fit threshold retroactively. Score with the enrichment timestamp, not the original event timestamp, or your March number will change in April.
• Manual overrides. Reps will promote leads by hand. Keep those in a separate source field. They are useful training data for the next threshold review and poison in the conversion rate.

Why it matters

The MQL threshold is the only place in a go-to-market system where marketing volume gets converted into sales capacity. Set it too low and reps spend their week on people who were never going to buy, which shows up first as slower response times and later as reps ignoring the queue entirely. Set it too high and you starve the pipeline while paying for traffic that never gets a conversation.

The second reason is diagnostic. When bookings miss, the MQL chain tells you where. A drop in MQL rate is a traffic-quality problem. A drop in MQL-to-SQL with a steady MQL rate is a scoring-model problem. A steady MQL-to-SQL with falling win rates is a product or pricing problem. Without the intermediate counts every miss looks the same.

Common mistakes

• Treating MQL count as a marketing target. Any number a team is measured on can be manufactured. If the target is MQL volume, the threshold quietly loosens.
• No rejection reasons. If sales can reject an MQL without coding why, the definition can never be improved.
• An unbounded behaviour window. Lifetime behaviour scores make every old contact look warm.
• Scoring email opens. Image-proxy prefetching by mail clients fires opens nobody performed. Score clicks and replies instead.
• One threshold for every segment. A 12-person agency and a 4,000-person bank do not produce comparable behaviour volumes. Segment first, then threshold.

Related concepts

• SQL (Sales Qualified Lead): the next stage, and the thing an MQL is judged against.
• Lead scoring: the mechanism that produces the fit and behaviour numbers.
• ICP: where the fit attributes and their weights come from.
• Lead routing: what has to happen the moment a lead becomes an MQL.
• Conversion funnel: the full view the MQL rate is one step of.
• Lead magnet: the top-of-funnel offer that fills the denominator.

How Pinlyx handles it

Pinlyx computes fit and behaviour scores separately, keeps the scored-event log with per-event timestamps so windowed sums stay honest, and records every stage transition with its actor and reason code. MQL thresholds are per pipeline, so a self-serve motion and an enterprise motion can run different rules in the same workspace, and the acceptance and rejection reasons feed the monthly threshold review instead of living in a spreadsheet.