MQL vs SQL: Definitions, the Handoff, and How to Set the Line for Your Business

A marketing qualified lead (MQL) is a lead that marketing believes is worth a salesperson's time. A sales qualified lead (SQL) is a lead that sales has looked at and accepted as a real opportunity. The MQL vs SQL distinction sounds like process jargon until the two teams disagree about where one ends and the other begins. Then it turns into missed follow-ups and a standing argument about lead quality, with marketing pointing at volume and sales pointing at the leads that went nowhere.

This article covers what each stage means in practice, how the handoff between marketing and sales should work, why the line has to be set with the sales team and written down, and how we use these stages to feed better conversion data back into Google Ads.

Why the MQL and SQL Stages Exist

Marketing and sales own different parts of the same pipeline. Marketing controls everything up to the point where someone raises their hand: the ads, the landing page, the form. Sales controls everything after: the call, the quote, the close. The MQL and SQL labels exist to mark the transfer point, because without a marked transfer point the pipeline leaks in two predictable ways.

The first leak is on the sales side. When every form fill lands in the sales queue unsorted, reps quickly learn that half of them are students, job seekers, people outside the service area, or tire kickers. So they start cherry-picking, and some genuinely good leads sit untouched because they arrived on a busy Tuesday. Once a rep has been burned enough times, "leads from marketing" becomes a category they deprioritize as a whole.

The second leak is on the marketing side. If nobody tells marketing which leads were real, marketing optimizes toward the only number it can see: raw lead count. In a Google Ads account, this problem compounds, because Smart Bidding optimizes toward whatever conversion you feed it. If the only conversion the account sees is a form submission, Google will find you more form submissions, including more of the cheap ones that sales rejects. The qualification stages are how you break that loop.

MQL vs SQL: The Working Definitions

The definitions only work if they're specific enough to check against real data. Here is how we frame each one.

What counts as an MQL

An MQL is a lead that clears a written bar before any sales conversation happens. The bar is a short list of criteria that marketing can verify from the form submission and whatever enrichment the CRM adds. Criteria come in two types:

• Fit criteria. Is this the kind of buyer we serve? Right industry, right service area, a company size or project scope in range, a budget indication above the floor.
• Behavior criteria. Did they do something that signals intent? Requested a quote, booked a call, asked a specific question about the service, rather than downloading a PDF and going quiet.

The test for a good MQL criterion is that a person (or an automation) can answer yes or no from data you capture. "Shows strong buying intent" is not a criterion. "Selected a project budget of $10,000 or more on the form" is. If your MQL definition contains anything you can't check, the definition will be applied inconsistently, and inconsistent application is the same as no definition.

What counts as an SQL

An SQL is a lead that sales has worked and accepted. Sales has made contact (or completed a defined number of contact attempts), confirmed there is a real need, confirmed the lead has the authority and rough budget to buy, and agreed on a next step: a site visit, a proposal, a demo. The specific checklist varies by business, but the structure is constant: an SQL requires a human judgment from the sales side, made against written criteria.

That last part matters. SQL status is sales's call, but it is not made by feel. If a rep can quietly disqualify a lead without recording why, you lose the exact data you need to fix the pipeline. Every MQL that sales touches should get a disposition: accepted as SQL, rejected for stated reason, or returned for nurture.

The Handoff: Where Leads Fall Through the Cracks

Most MQL vs SQL problems are not definition problems. They are handoff problems. A lead qualifies as an MQL and then nothing happens, because the handoff was never designed as a process with an owner.

A working handoff has three parts:

1. Routing. The moment a lead becomes an MQL, a specific person is assigned by name, not a shared inbox or a distribution list.
2. A response-time agreement. Both teams agree on how fast an MQL gets first contact and how many attempts count as "worked." Response speed decides deals, so set the agreement tighter than feels comfortable.
3. A required disposition. Sales cannot close the loop silently. Every MQL gets an outcome recorded in the CRM: SQL, rejected with reason, or nurture.

The handoff criteria both teams must agree on

Write the agreement down. One page is enough, and it should answer: what exactly makes a lead an MQL (the checkable criteria), how fast sales will make first contact, how many attempts constitute a real effort, which statuses sales can assign, and what triggers a lead being sent back to marketing. Both team leads sign off, and the page gets revisited on a schedule rather than during an argument.

The reason this must be co-authored is simple: either team writing it alone gets it wrong in their own favor. Marketing alone sets the bar too low, because volume makes marketing look good. Sales alone sets it too high, because a short queue of perfect leads makes sales look good. The useful line sits where neither team would put it unilaterally, and the only way to find it is to negotiate it explicitly, with closed-deal data on the table.

What happens to leads that get sent back

Rejected MQLs split into two groups, and they need different treatment.

Wrong-fit leads (outside the service area, no budget, not a buyer) get disqualified, and the rejection reasons get tallied. If one campaign generates a disproportionate share of wrong-fit rejections, that's a targeting or messaging problem marketing can act on this week.

Right-fit, wrong-timing leads go to nurture, and this path should be automated end to end. In our own builds, a status change in the CRM triggers a tag in the email platform, and the tag enrolls the lead in a lead nurture email sequence built for that segment. No spreadsheet exports, no one remembering to add people to a list manually. Before wiring that up, we clean the tag structure first: consolidate duplicate tags so each segment has exactly one, and write plain rules for who enters each flow (for example, right-fit prospects who are not current clients and have had at least one real interaction). A nurture system built on messy tags sends the wrong email to the wrong person eventually, and one bad send costs more trust than ten good ones earn.

How to Set the Qualification Line for Your Business

Set the line with the sales team in the room, and set it from evidence rather than instinct. The process we use looks like this:

1. Pull your last 50 to 100 closed deals. Look at what they had in common at the moment of first inquiry: lead source, form answers, stated budget, company type, service requested.
2. Work backward to criteria. The traits that closed deals shared, and lost or junk leads lacked, become your candidate MQL criteria.
3. Keep it short. Three or four criteria. Every criterion you add is a criterion someone has to check on every lead, and long checklists get skipped.
4. Make each one checkable. If the data isn't captured on the form or in the CRM today, either add the field or drop the criterion.
5. Write it down and date it. The definition lives in a shared document, not in two people's differing memories.

When the line stays fuzzy, both failure modes from earlier show up at once. Sales ignores marketing's leads because past batches burned them, so response times stretch and close rates fall, which sales reads as confirmation the leads were bad. Meanwhile marketing, seeing leads go unworked, optimizes harder toward cost per lead, which pulls in cheaper and worse leads. Each team's rational response to the fuzzy line makes the other team's problem worse. A written line, enforced with dispositions, is the only exit.

If you outgrow a binary line, the next step is scoring leads on a scale rather than sorting them into two buckets. We cover that progression in lead scoring 101.

Feeding the Stages Back Into Google Ads

We also use these stages to train the ad account. Each stage maps to a conversion value that gets uploaded to Google Ads as an offline conversion, which is how the ad account learns the difference between a form fill and a future customer.

The mechanics, briefly: when someone clicks an ad, Google appends a click ID (GCLID) to the URL. A hidden field on the landing page form captures it, and it gets stored on the lead's CRM record. From then on, every stage change in the CRM can be matched back to the original ad click. When a lead becomes an MQL, we upload a conversion with a modest value. When sales accepts it as an SQL, we upload a larger one. When the deal closes, we upload the actual contract value. We run this progressive ladder from as little as $1 at first inquiry up to full contract value, inside Google's standard 90-day click window.

Two configuration details do most of the work. First, each stage is its own named conversion action in Google Ads, so we can see MQLs, SQLs, and closed deals as separate columns per campaign and keyword. Second, only the stages we want Smart Bidding to optimize toward are marked primary; observation-only stages stay secondary. That distinction lets us tell Google "find more people like the ones sales accepted" instead of "find more form fills."

This is also the strongest argument for keeping the qualification line firm. The values we upload are only as honest as the stage definitions behind them. If reps mark leads as SQLs loosely, or the MQL bar drifts month to month, the bidding algorithm trains on noise, and the account slowly optimizes toward whatever the loosest interpretation of the stages happened to be. Across the 35+ lead generation businesses we've worked with, the accounts where the stage definitions hold steady are the accounts where offline conversion data moves performance.

Measuring the Line: What the MQL-to-SQL Rate Tells You

Once the stages exist, the ratio between them becomes one of your most useful diagnostics. MQL-to-SQL rate is the share of marketing qualified leads that sales accepts. If marketing produced 80 MQLs last month and sales accepted 24, the rate is 30 percent.

The number reads in both directions. A very low rate means either marketing is passing leads that don't meet the spirit of the bar, or sales isn't working the queue, and the disposition data tells you which. A very high rate, above roughly what your own history establishes as normal, often means the MQL bar is set too strict and marketing is filtering out leads sales would have happily closed.

The rate is most useful compared across segments. Suppose your account-wide MQL-to-SQL rate is 30 percent, but one campaign runs at 8 percent. Those leads pass the marketing bar and fail the sales test, which means the MQL definition is missing whatever that campaign's leads lack. That's a finding you can act on: tighten the form, adjust the targeting, or add a criterion.

Pair the rate with cost per MQL and you get a clean two-number readout per campaign: what it costs to produce a lead that clears the bar, and how often those leads survive contact with sales. A campaign can look great on one and terrible on the other, and you need both to know where to spend the next dollar.

When Definitions Should Change

The line is written down, but it isn't carved in stone. Legitimate reasons to move it:

• Sales capacity changed. A team drowning in leads needs a higher bar. A team with idle reps needs a lower one. The right MQL definition depends partly on who's available to work the queue.
• The offer changed. New service lines, new pricing, or a new market mean the old fit criteria no longer describe your buyer.
• The data says a criterion doesn't predict anything. If leads failing one criterion close at the same rate as leads passing it, the criterion is friction without benefit. Drop it.

What matters more than when you change the definition is how. Never change it silently. Version the document, date the change, and tell both teams, because a definition change looks exactly like a performance change in your charts. If MQL volume drops 20 percent the month you tightened the bar, that is the definition working, not the campaigns failing, and future-you needs the dated note to read the trend correctly. We treat definition changes the way we treat any significant account change: written down before it happens, with the expected effect stated, and never during a peak season week when clean before-and-after reads are impossible anyway.

Agree on the Line, Then Automate Both Sides of It

The MQL vs SQL distinction pays off when it exists as a one-page written agreement, a routing and disposition process that enforces it, and a conversion ladder that reports each stage back to your ad platform. Marketing gets honest feedback, sales gets a queue worth working, and Google Ads gets trained on accepted leads instead of raw form fills. The nurture half of that system, the automated sequences that catch right-fit leads who aren't ready yet, is what we build in our email marketing for lead generation service, run alongside the Google Ads management it feeds.