What it means
An SQL is an acceptance, not a score. Somewhere in your CRM a rep looked at a contact, spent time on them, and decided the company should invest more time. That decision is the entire content of the term. If a rule can produce an SQL without a human in the loop, you have not built an SQL stage, you have built a second MQL threshold with a different label.
The distinction matters because the two stages fail in opposite directions. MQLs fail by being too generous: the model says yes to people who were never buyers. SQLs fail by being too convenient: reps accept everything so their acceptance rate looks cooperative, or reject everything so their pipeline coverage looks lean. Both failures are invisible without disposition codes.
The qualification frameworks people argue about, BANT, MEDDIC, CHAMP, SPICED, are all the same shape underneath: a fixed list of questions, an evidence standard for each, and a rule about how many can be unknown before you decline. Which acronym you pick matters far less than whether the answers are written down on the record. An SQL whose qualification lives only in the rep's head cannot be reviewed, coached, or forecast from.
The formulas, written out
Four ratios do all the work. Each one needs its denominator named.
SQL acceptance rate = (MQLs accepted as SQL / MQLs handed to sales) x 100
SQL-to-opportunity rate = (SQLs with at least one opportunity created / SQLs accepted) x 100
SQL win rate = (SQLs with a closed-won deal / SQLs accepted in the same cohort) x 100
Value per SQL = total closed-won revenue from the cohort / SQLs accepted in the cohort
Variables:
- MQLs handed to sales: distinct leads that entered the sales queue in the period, counted once each.
- SQLs accepted: leads with an acceptance event recorded by a named owner, with a timestamp.
- Cohort: the period the SQL was accepted in, not the period the deal closed in. Mixing the two is the reason win rates look better in slow quarters.
A worked example, end to end
Continuing the same company as the MQL page: 612 MQLs were handed to sales in March.
Reps attempted contact on all 612 within one business day. 268 were accepted as SQLs. 344 were rejected with a coded reason: 141 "no budget in horizon", 92 "not a decision maker and cannot reach one", 68 "wrong company profile", 43 "no response after five attempts".
SQL acceptance rate = 268 / 612 = 43.8%
Of the 268 accepted, 191 produced at least one opportunity with an amount and a close date.
SQL-to-opportunity rate = 191 / 268 = 71.3%
By the time the cohort had aged out, 61 of those opportunities were closed won, at 298,900 total.
SQL win rate = 61 / 268 = 22.8%
Value per SQL = 298,900 / 268 = 1,115
The interesting figure is not any one of those, it is the pair. A 43.8% acceptance rate with a 22.8% win rate says the scoring model and the checklist are roughly calibrated to each other. If acceptance were 80% and the win rate 9%, reps would be accepting everything and discovering the truth later, which is expensive because rejection has moved from a two-minute decision to a three-week opportunity. If acceptance were 15% and the win rate 45%, the reps are cherry-picking and marketing is paying to generate leads nobody works.
Rejection codes carry their own arithmetic. 141 of 344 rejections, 41%, were "no budget in horizon". Those are not bad leads, they are early leads. Routed into a dated nurture instead of a dead status, a recycling rate as modest as 18% returns 25 more SQLs the following quarter at zero acquisition cost. That is the practical reason coded rejection reasons are worth the extra click.
Three ways the number goes wrong
Accepting on a booked meeting instead of a held one. This is the most expensive error in the set because it looks like good news. Suppose the same team accepts the SQL when the calendar invite is sent. 268 becomes 362, because 94 meetings were booked and never happened. Acceptance rate jumps from 43.8% to 59.2% and everyone is pleased, while the win rate drops from 22.8% to 61 / 362 = 16.9% and value per SQL falls from 1,115 to 826. Nothing about the business changed. A no-show is not a qualified lead, it is an unanswered question.
Double-counting recycled leads. A lead rejected in January, nurtured, and accepted in April is one lead and two acceptance events. If the April report counts it against April's handover volume without excluding it from the new-lead denominator, acceptance rate inflates for reasons that have nothing to do with lead quality. Tag recycled acceptances with their original source and report them as a separate line.
Silent rejection. When a rep can simply not touch a lead, the denominator becomes unknowable. In a queue of 612 where 71 were never opened, the honest acceptance rate is 268 / 612 = 43.8% but the reported one is often 268 / 541 = 49.5%, because the untouched records never entered anyone's report. Untouched leads are the most important number in the whole chain and the one most often missing: they are the only category where you are certain of losing a lead you already paid for.
How an SQL is actually derived from CRM data
The SQL is a state transition, so it lives in the transition log rather than on the contact:
- Contact or lead record: identity, source, and the MQL timestamp it inherited.
- Ownership event:
assigned_atandowner_id. The clock for the acceptance service-level agreement starts here, not at lead creation. - Activity records: calls, emails, DMs with direction and outcome. "Contact attempted" and "contact made" are different states and a qualification framework needs the second.
- Disposition event:
accepted_atorrejected_at, plus a reason code from a closed list, plus a recycle date when the reason is timing. - Opportunity record: created from the SQL, with its own amount and close date, linked back to the accepting event.
Edge cases worth deciding before you build the report:
- The lead that skips a stage. An inbound demo request from a target account is qualified during the first call and an opportunity is created in the same hour. If your report requires an MQL row to exist before an SQL row, this deal is invisible. Write the MQL event at the same instant, or count SQL-sourced deals separately.
- Ownership changes. A lead accepted by rep A and transferred to rep B still belongs to rep A's acceptance cohort. Attribute acceptance to the owner at the time of the event, which means the report must read the event, not the current
owner_idon the record. - Multiple contacts, one account. Three people at the same company each become SQLs. That is one buying process. For lead-quality reporting count all three, for pipeline coverage count the account once, and never mix them in the same chart.
- Re-opened rejections. A rejected lead that later replies should re-enter the queue rather than being re-created, so its full history stays attached and its second acceptance can be identified as a recycle.
Why it matters
Everything downstream of the SQL is expensive. Discovery calls, demos, security reviews and pricing negotiations consume the most costly hours in the company. The SQL gate is the last cheap place to say no. A team that qualifies well spends its quarter on twenty serious evaluations, and a team that does not spends it on sixty conversations that were never going anywhere and then blames the forecast model.
It is also the join between two departments' numbers. Marketing reports leads, sales reports deals, and the SQL is where the two reconcile. When the numbers do not reconcile, the argument is almost always about definitions rather than performance, which is why the checklist and the reason codes matter more than the frameworks people name in meetings.
Common mistakes
- Free-text rejection reasons. Two hundred distinct strings that all mean "too early" are the same as no data at all.
- No time limit on the decision. Leads that sit in "assigned" for three weeks are neither accepted nor rejected, and they quietly remove themselves from every ratio.
- Qualifying on enthusiasm. A friendly call is not evidence of budget. Write down which criterion each answer satisfied.
- Letting the SQL count drive quota relief. If reps are measured on SQL volume, acceptance stops being a judgement.
- One checklist across segments. The evidence standard that works for a 30-seat deal is theatre for a 3,000-seat one, and vice versa.
Related concepts
- MQL: the stage before, and the thing SQL acceptance grades.
- Sales pipeline: where an accepted SQL becomes a forecastable deal.
- Pipeline velocity: the metric that turns accepted SQLs into revenue per day.
- Lead scoring: the model whose accuracy the acceptance rate measures.
- Lead routing: how the lead reached the rep who accepted it.
- Conversion funnel: the end-to-end view all four ratios belong to.
How Pinlyx handles it
Pinlyx records acceptance and rejection as events with an actor, a timestamp and a reason drawn from a closed list you configure per pipeline. Untouched leads surface as their own queue rather than disappearing, ownership history is preserved so cohort reports read the accepting owner rather than the current one, and recycled leads keep their original source so a second acceptance never gets counted as a fresh one.