MQL vs SQL: what's the difference?

The difference between a marketing-qualified lead (MQL) and a sales-qualified lead (SQL) is who qualified the lead: marketing qualifies an MQL from the data it captures, and sales qualifies an SQL after working the lead. An MQL is a lead that marketing believes is worth a salesperson's time. An 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 2 teams disagree about where one ends and the other begins. The disagreement turns into missed follow-ups and a standing argument about lead quality. Marketing points at volume, and sales points at the leads that went nowhere.

What is a marketing-qualified lead (MQL)?

A marketing-qualified lead (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 customer relationship management (CRM) system adds. MQL criteria come in 2 types:

• Fit criteria. Is this the kind of buyer you serve? Right industry, right service area, a company size or project scope in range, and a budget indication above the floor.
• Behavior criteria. Did the lead do something that signals intent? Requested a quote, booked a call, or 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. An MQL definition that contains anything you can't check gets applied inconsistently. Inconsistent application is the same as no definition.

What is a sales-qualified lead (SQL)?

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

Who decides whether a lead is an SQL?

Sales decides whether a lead is an SQL, but not by feel. The call is made against written criteria. Every MQL that sales touches gets a disposition: accepted as SQL, rejected for a stated reason, or returned for nurture.

Can a rep reject a lead without recording why?

No. A rep who quietly disqualifies a lead without recording why erases the exact data you need to fix the pipeline.

Why have separate MQL and SQL stages?

Separate MQL and SQL stages mark the point where a lead passes from marketing to sales. 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, and the form. Sales controls everything after: the call, the quote, and the close. Without a marked transfer point, the pipeline leaks in 2 predictable ways.

The sales-side leak

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. Reps start cherry-picking, and some right-fit leads sit untouched because they arrived on a busy Tuesday. Once a rep has been burned enough times, "leads from marketing" becomes a category the rep deprioritizes as a whole.

The marketing-side leak

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, the problem grows, because Smart Bidding optimizes toward whatever conversion you feed it. If the only conversion the account sees is a form submission, Google finds you more form submissions, including more of the cheap ones that sales rejects. The qualification stages break that loop.

How does the handoff from MQL to SQL work?

The handoff from MQL to SQL works when it is designed as a process with an owner. Most MQL vs SQL problems are handoff problems, not definition problems. Without a designed process, a lead qualifies as an MQL and then nothing happens. A working handoff has 3 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 can't close the loop silently. Every MQL gets an outcome recorded in the CRM: SQL, rejected with a reason, or nurture.

What should the handoff agreement say?

The handoff agreement should say what makes a lead an MQL, how fast sales makes first contact, how many attempts count as a real effort, which statuses sales can assign, and what sends a lead back to marketing. Write the agreement down. One page is enough. Both team leads sign off, and the page gets revisited on a schedule rather than during an argument.

The agreement must be written by both teams, because either team writing it alone gets it wrong in its own favor. Marketing alone sets the bar too low, because volume makes marketing look good. Sales alone sets the bar too high, because a short queue of perfect leads makes sales look good. The useful line sits where neither team would put it alone. The only way to find that line is to negotiate it openly, with closed-deal data on the table.

What happens to rejected MQLs?

Rejected MQLs split into 2 groups, and each group needs different treatment.

Wrong-fit leads, such as those outside the service area, without budget, or not buyers at all, get disqualified. The rejection reasons get tallied. If one campaign generates an outsized share of wrong-fit rejections, marketing has a targeting or messaging problem it can act on this week.

Right-fit, wrong-timing leads go to nurture, and that path should be automated end to end. In ReClick's builds, a status change in the CRM triggers a tag in the email platform. The tag enrolls the lead in a lead nurture email sequence built for that segment. Nobody exports a spreadsheet or adds people to a list by hand. Before wiring that up, we clean the tag structure. We merge duplicate tags so each segment has exactly one. We 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 eventually sends the wrong email to the wrong person. A single bad send can cost more trust than many good sends earn.

How do you set the MQL line for your business?

Set the MQL line with the sales team in the room, from evidence rather than instinct. The process we use has 5 steps:

1. Pull your last 50 to 100 closed deals. Look at what they had in common at first inquiry: lead source, form answers, stated budget, company type, and service requested.
2. Work backward to criteria. The traits that closed deals shared, and that lost or junk leads lacked, become your candidate MQL criteria.
3. Keep it short. Use 3 or 4 criteria. Every criterion you add is one 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 2 people's differing memories.

When the line stays fuzzy, both leaks show up at once. Sales ignores marketing's leads because past batches burned them. Response times stretch and close rates fall, which sales reads as confirmation that the leads were bad. Meanwhile, marketing sees leads go unworked and 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, breaks that cycle.

If you outgrow a line between 2 buckets, the next step is scoring leads on a scale. That progression is covered in how to score leads.

What does the MQL-to-SQL rate tell you?

The MQL-to-SQL rate tells you how often marketing's qualified leads survive contact with sales. The rate is the share of MQLs that sales accepts. For example, if marketing produced 80 MQLs last month and sales accepted 24, the rate is 30%.

The rate reads in both directions. A very low rate means either marketing is passing leads that miss the spirit of the bar, or sales isn't working the queue. The disposition data tells you which. A rate well above what your own history sets as normal often means the MQL bar is too strict. Marketing is then filtering out leads that sales would have closed.

The rate is most useful compared across campaigns. For example, suppose your account-wide MQL-to-SQL rate is 30%, but one campaign runs at 8%. That campaign's leads pass the marketing bar and fail the sales test. The MQL definition is missing whatever those leads lack. You can act on that finding: tighten the form, adjust the targeting, or add a criterion.

Pair the rate with cost per MQL for a 2-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 strong on one number and weak on the other. You need both to know where to spend the next dollar.

How do MQL and SQL stages train Google Ads?

MQL and SQL stages train Google Ads when each stage is uploaded as an offline conversion with its own value. ReClick uses the stages this way, so the ad account learns the difference between a form fill and a future customer.

The mechanics start with the click. When someone clicks an ad, Google appends the Google click identifier (GCLID) to the URL. A hidden field on the landing page form captures the GCLID, and the lead's CRM record stores it. 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. The ladder runs from as little as $1 at first inquiry up to full contract value, inside Google's standard 90-day click window. The full setup is covered in offline conversion tracking in Google Ads.

Most of the work comes from 2 configuration details. First, each stage is its own named conversion action in Google Ads. MQLs, SQLs, and closed deals then show as separate columns per campaign and keyword. Second, only the stages we want Smart Bidding to optimize toward are marked primary, and observation-only stages stay secondary. The split lets us tell Google to find more people like the ones sales accepted, instead of more form fills.

The upload is also the strongest argument for keeping the qualification line firm. The values we upload are only as accurate 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. The account then slowly optimizes toward the loosest reading of the stages. In ReClick's work with 35+ businesses that rely on lead generation, the accounts where stage definitions hold steady are the accounts where offline conversion data moves performance.

When should the MQL definition change?

The MQL definition should change when sales capacity, the offer, or the evidence behind a criterion changes. The line is written down, but it can still move. 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 predicts nothing. If leads failing one criterion close at the same rate as leads passing it, the criterion adds friction without benefit. Drop it.

How should you change the MQL definition?

Change the MQL definition openly, never silently. Version the document, date the change, and tell both teams. A definition change looks exactly like a performance change in your charts. For example, if MQL volume changes by −20% in the month you tightened the bar, the definition is working and the campaigns are not failing. A dated note lets you read that trend correctly later. We treat definition changes like any significant account change: written down before they happen, with the expected effect stated.

Should you change the MQL definition during peak season?

No. ReClick never changes a definition during a peak-season week, because clean before-and-after reads are impossible then.

What does a working MQL and SQL system include?

A working MQL and SQL system includes a one-page written agreement, a routing and disposition process that enforces it, and a conversion ladder that reports each stage back to Google Ads. Marketing gets feedback on which leads were real. Sales gets a queue worth working. Google Ads gets trained on accepted leads instead of raw form fills.

ReClick builds the nurture half of that system, the automated sequences that catch right-fit leads who aren't ready yet, as email marketing for lead generation. That nurture runs alongside the Google Ads management it feeds.