PQL vs SQL: the difference and how to route each

PQL vs SQL comes down to who makes the call. For a product qualified lead (PQL), your usage data makes it: a free or trial user invited three teammates, came back four times this week, and is close to a plan limit. A sales qualified lead (SQL) needs a person instead. Someone in sales has checked the need and the timing, usually on a call, and accepted the lead as worth pursuing.

So the two are stages, not rivals: the PQL usually comes first, and it turns into an SQL once sales agrees. Treat them as the same label and every busy free user lands in an account executive's queue, which soon stops being read.

To see which of your own signups would qualify, score your product users against your ICP free and read the reason beside each one.

This post sits under our guide to B2B lead scoring, which covers how fit and intent add up to one number. Here the question is narrower: what each label means and where each lead goes next.

PQL vs SQL in one table

The MQL column is there because most pages written on this question end up comparing MQLs with SQLs instead. The row that matters most is the second one, and everything else follows from it.

A PQL is a nomination. It exists because products with a freemium plan or a trial generate behavior that says more about intent than any form fill. Someone who connected two integrations and invited a colleague has told you something a whitepaper download never could. That puts the PQL in the same slot an MQL holds in a marketing-led funnel: both put a lead forward, and neither one is a promise that the lead will buy.

The other half is acceptance. Somewhere between the nomination and the CRM opportunity, a human looked at the lead and said yes. Some teams add a sales accepted lead (SAL) step in between, meaning sales agreed to work it but has not qualified it yet. Our view is that SAL is mostly bookkeeping for companies with a separate SDR team. A five-person company can probably skip it and lose nothing.

One odd thing about this search: PQL is also the name of a pipelined query language that compiles to SQL, the database language, and the results mix the two. If that is the PQL you came for, this is the wrong post. Everything below is about leads.

How a PQL becomes an SQL

Usage data answers one question well: is this person getting value, and is it growing? It cannot answer the three questions an SQL needs. Who signs? Is there budget? Does anything make this quarter different from next year? A product analytics event has never once told a rep that the CFO froze spending.

That is why the conversion needs a person, and why it should happen fast. Research in Harvard Business Review on how quickly companies answer online leads found most respond far too slowly, and those were people who asked first. A PQL did not ask. The signal is real, but it fades the same way, so the first touch belongs in the same hour or the same day, not the next weekly pipeline review.

The handoff itself has four steps:

1. Usage crosses your rule. Three to five signals you picked from what your last upgrades did before they paid, plus an ICP fit floor. Our guide on how to identify product qualified leads covers choosing them.

2. The first touch opens on what they did. "Saw your team set up three projects this week" beats any generic check-in, because it proves the email is not a blast.

3. The conversation checks need, buyer, and timing. A short call or a reply thread is enough.

4. Sales accepts or returns the lead. Accepted, it becomes an SQL and an opportunity with an owner. Returned, it goes back to self-serve or nurture with a reason written down, so nobody calls the same person next week.

Write the rules down before the first PQL arrives:

• The signals and the threshold, in plain words: "invited two or more teammates and logged in on four of the last seven days".

• The fit floor. A student or a two-person agency can out-use a real buyer. Usage says who is ready, and fit says who is worth a sales conversation. The ICP scoring guide turns your closed-won deals into that floor.

• The response time, so "fast" means a number.

• Who owns each route, by name, not by team.

• What sends a lead back, so a rejected PQL does not return to the queue on its next login.

Routing PQL vs SQL: who gets each lead

Routing is where the PQL vs SQL difference stops being a definition and starts deciding who spends their afternoon on whom. This table works for most small product-led teams: adjust the thresholds, keep the shape.

Three rules sit underneath the table.

• Fit gates the PQL label. A poor-fit account with heavy usage is a happy customer on your cheapest plan. That is a good outcome, not a sales lead.

• Only a person writes SQL. No score moves a contact to the SQL stage by itself. The rep who accepted the lead sets it, so the SQL count stays a count of human decisions and never turns into a second PQL count.

• A stalled SQL goes back with its notes. When an accepted lead goes quiet, return it to nurture with what the call found. Sending it back to the PQL queue means the next touch opens on usage again, as if the call never happened.

Anyway, back to the second row of the first table. "Who makes the call" also tells you who should be measured on each label. Product and growth own PQL volume and quality. Sales owns how many SQLs it accepts, and how many of those close. Mix those up and both numbers start to drift toward whatever looks good this quarter.

Four signups through the PQL vs SQL rules

Say your product is a project tool with a free plan, and four people signed up in the same fortnight. The scores are illustrative.

Marcus tops the list on usage alone, and an AE would spend a call learning what the fit score already said. Elena is the other trap, in reverse: a strong account with almost no usage. She is worth a question, but calling her a PQL would teach the team that the label means nothing. Only Hannah reached SQL, and only after a person heard her say when.

In Oneprofile, the PQL half of that table runs on your own product data, and the SQL half stays with the person who accepts the lead. The PQL identification guide walks through the full build, signal by signal. Three parts decide the label:

1. Usage and fit sit beside each contact. In the Your data tab of Tools, pick Get for your users table in Postgres, or for the person in PostHog, and match on the user ID or another unique key such as email. Each record it finds costs a small flat amount, and a lookup that finds nothing costs nothing. The ICP scorer then rates each contact's company strong (70 or above), possible (40 to 69), or poor, with the facts behind it, for 3 credits. A contact with too little data comes back unscored, never marked poor.

2. The PQL rule reads both. A plain threshold fits a Write a formula function, which costs nothing. When the call needs judgment, build an agent that returns a PQL score and a one-line reason. Its price per contact shows before it runs.

3. The rep reads what the rule read. Export the score and the reason to CRM properties you create first, such as pql_score and pql_reason. The rep who accepts the lead, or sends it back, works from the same facts. The HubSpot lead scoring guide covers the properties.

Hot PQLs can start a sequence the same day: point its audience at a saved view of them, and with Keep in sync on, new PQLs join as they qualify. Usage goes stale, so set Refresh to On a schedule under Run conditions on the lookup and on the PQL score. The editor projects the monthly credit cost before you save.

The Free plan is enough to try this on a small first cohort: 200 credits a month, up to 3 integrations, 3 tables, and 100 rows per table. Team starts at $20 a month for 1,000 credits, with up to 10,000 rows per table. Write your PQL rule in one sentence, then route your first PQLs from real product usage and check the reasons against what your sales team already knows.