Sales Qualified Leads: What Counts When You Sell on Calls

A sales qualified lead (SQL) is a lead your sales team has judged worth a sales conversation, because the person fits what you sell and shows real intent to buy. For a coach, consultant or agency that sells on calls, make it concrete: an SQL is a person who passed the bar in your application (problem fit, ability and willingness to pay, decision authority and a timeline) and has booked or accepted a sales call. Count those, cost those and point your ads at those, not at raw leads.

What is a sales qualified lead?

The textbook definition comes from CRM lifecycle stages. HubSpot defines a sales qualified lead as "a contact or company that your sales team has qualified as a potential customer". It sits one stage after the marketing qualified lead, which marketing has "qualified as ready for the sales team."

Those stages were built for B2B demand generation. The SiriusDecisions Demand Waterfall, first launched in 2006, became the industry standard for defining and measuring the stages of the B2B demand management process. The model assumes a marketing team that scores leads on behavior (a whitepaper download, a pricing page visit, a webinar), a formal handoff, and a sales team that works the lead for weeks or months.

A high-ticket service business that sells on calls does not look like that. The buyer is often one person. There is no lead score and no handoff between departments. The path from ad to calendar can take ten minutes: ad, page, application, booking. Scoring someone on content downloads tells you little when the application has already asked the four questions that decide the sale.

The definition we use when you sell on calls

For a call-based offer, a lead is sales qualified when both of these are true:

1. They passed the bar in the application. Answers you defined in advance, checked automatically, not judged by gut feel.
2. They booked or accepted a sales conversation. A slot on a closer's calendar, or a yes to a setter's call.

The bar covers four things:

• Problem fit. They have the problem your offer solves, at the stage you solve it.
• Ability and willingness to pay. They can invest in your price range and say they are ready to, not only that they could.
• Decision authority. They make the decision, or the person who does will be on the call.
• Timeline. They want to start inside a window you can serve.

Both halves matter. A qualified applicant who never books is a follow-up job, not an SQL yet. A booked call from someone who failed the bar is not an SQL either. It is a cost on your closer's calendar.

MQL vs SQL: what each stage means in a booked-call funnel

Marketers, lead vendors and sales teams use these words loosely. Pin them down before you compare numbers, because each stage has its own count and its own cost.

The gap between booked calls and SQLs is the one most funnels never measure. Referrals who skip the application, a calendar link pasted into an email, borderline applicants a setter waved through: they all count as bookings. If you only count bookings, a looser funnel looks like a better one.

The intent line is the same one the B2B world draws. LinkedIn's marketing glossary describes SQLs as "high-quality leads that are scored as being in the consideration or purchase phase of the sales funnel". In a booked-call funnel, the application is where that score comes from.

How to qualify a lead: BANT, CHAMP and MEDDIC in one minute

Most qualification frameworks are acronyms for the same handful of questions. Three cover nearly everything you will read:

• BANT: Budget, Authority, Need, Timeline. HubSpot's sales qualification guide calls it "the Old Faithful of sales qualification frameworks." It maps almost one to one onto a four-question application.
• CHAMP: Challenges, Authority, Money, Prioritization. The same ground as BANT, with the problem asked first and money later. That is the order a buyer is comfortable answering in.
• MEDDIC: Metrics, Economic buyer, Decision criteria, Decision process, Identify pain, Champion. Created inside PTC in 1996 for complex enterprise deals with buying committees. Too heavy for a founder buying a coaching program. Useful if you are an agency or consultant selling to companies where several people sign off.

Our take: the framework matters less than writing the bar down. Pick BANT or CHAMP, turn each letter into one multiple-choice question in the application, and decide in advance which answers pass. A bar that lives in a closer's head moves every week. For the questions themselves, see how to qualify leads before they book a strategy call.

How to set the SQL bar from your own close data

Do not copy someone else's bar. Set yours from the calls you have already held.

1. Pull every held call from the last three to six months, with the application answers and the outcome: closed or not.
2. Group the calls by answer. Investment readiness, revenue band, timeline, who decides. For each answer, count held calls and closes.
3. Find the answers that almost never close. If people who chose "not in a position to invest right now" rarely buy, that answer is a disqualifier. Route it to a lower-priced offer or nurture, not to your calendar.
4. Find the answers that close at or above your average. Those define the bar. Everything in between is borderline: a short setter call, not a full slot with a closer.
5. Check capacity. Closers booked solid a week out: raise the bar. Calendar half empty: lower it and let borderline applicants through to a short call.
6. Write it down and re-check monthly. One sentence the ad buyer and the closer both sign off on: "An SQL is an applicant who answered A, B and C and booked a call."

Two rules keep this honest. Do not move the bar on an answer with a handful of calls behind it: wait until there is enough volume to mean something. And when you raise the bar, watch total closed deals, not only close rate. A higher close rate on half the calls can still mean fewer clients.

If the application answers do not sit next to the call outcome on the same CRM record, fix that first. Our guide to attribution when you sell on calls covers how to carry the source and the answers through to the deal.

How to measure SQL rate and cost per SQL

Six numbers, in funnel order. Write the definitions down and keep the denominators fixed, or the trend lines mean nothing.

Here is why cost per lead misleads. Round, made-up numbers to show the math: Ad A brings leads at $40 and 20% of them become SQLs, so each SQL costs $200. Ad B brings leads at $90 and 60% become SQLs, so each SQL costs $150. Ads Manager says Ad A is more than twice as efficient. Your calendar says Ad B is 25% cheaper where it counts.

Measure by cohort: take the leads from one week and follow them until their calls have happened. Calls booked this week that have not taken place yet are not no-shows. Split everything by ad, so the budget goes to the ad that produces SQLs, not the ad that produces cheap opt-ins.

How much does a sales qualified lead cost?

There is no honest universal number, because it depends on your price, your market and your funnel. For one reference point, Belkins, a B2B appointment-setting agency, published market estimates in January 2024: $20 to $200 per lead on pay-per-lead deals, with qualified leads in complex, high-ticket B2B industries passing $1,000 each. Treat that as one vendor's read of its own market.

The better question is what an SQL is worth to you: cash collected per sale, times show rate, times close rate. Illustrative numbers again: a $10,000 program that holds 70% of booked SQL calls and closes 25% of held calls makes each SQL worth $1,750 in cash collected. Spend up to the cost per SQL that leaves you the margin you need, and no further. For the same math one step earlier in the funnel, see how much you should pay for a lead.

Why paying for leads instead of SQLs wrecks your ad optimization

Ad platforms optimize for the event you give them. Meta's ad set reference describes its website conversion goal plainly: it "will optimize for people more likely to make a conversion in the site". Whatever fires as the conversion describes the person Meta goes looking for.

Meta's own definition of the standard Lead event is loose: "When a sign up is completed." Fire Lead on a free guide opt-in and you pay Meta to find people who like free guides. They are cheap to find, so cost per lead falls, the dashboard looks great, and the calendar fills with people who never planned to buy. The same standard events reference lists SubmitApplication for "when a person applies for a product, service, or program you offer."

Our rule: the Meta standard Lead event fires only on a submitted application. Nothing lighter.

• Opt-ins, video views, form starts and apply button clicks: custom events.
• Application submitted: Lead.
• Application that passes the bar: its own custom event, so you can report qualified applications by ad.
• Call booked: one booking event per confirmed booking, sent as Schedule or as a custom event.
• Call held and deal closed: recorded in the CRM against the ad that started it.

Why not optimize straight for SQLs? You can, once there are enough of them. Meta's custom conversions exist to "optimize ads delivery based on online and offline conversion events that you define." But the deeper the event, the fewer of them fire, and an ad set that records a handful of conversions a week has little to learn from. The submitted application is the floor: the lightest event that still describes a buyer. Move deeper when the volume is there.

Meta has built toward the same idea for its own lead forms. The ad set reference lists a QUALITY_LEAD goal for "people who are likely to have a deeper conversation with advertisers after lead submission," and the Conversion Leads goal, fed with CRM stages through the Conversions API, works only with Instant Forms and asks for at least 200 leads a month, a daily upload and a target stage reached within 28 days. A high-ticket funnel with its own application page cannot use that goal, so the event map above is the practical version. When we run Meta ads for high-ticket offers, that map goes in before the first dollar is spent.

The same thing happens off the ad platform. Pay a vendor per lead and you get what the contract counts. Write your SQL definition into the agreement, or you will be paying for opt-ins with a new label.

What changes when you count SQLs instead of leads

A coaching brand selling a $25K program, in 90 days on the same traffic budget: opt-in rate from 11% to 34%, show-up rate from 42% to 71%, close rate from 18% to 39%. Opt-ins roughly tripled and the close rate still more than doubled. When volume comes from a lower bar, close rate falls. Here it rose, which is the pattern you want when you judge a funnel on held calls and closes instead of on leads.

Counting SQLs changes three decisions:

• Which ads get budget. The ad with the lowest cost per SQL, not the lowest cost per lead.
• What the page is for. Pulling in the right buyer and turning away the wrong one, not maximizing form fills.
• What your closers do all day. Calls with people who can say yes, prepared from their application answers.

If leads come in but calls do not get booked, the problem sits earlier: work through why a funnel gets traffic but no booked calls. For the full path from click to closed deal, read our booking funnel guide.

Paying for leads your closers never want to talk to? See how we fix the funnel between the click and the call.