How to Identify Product Qualified Leads (PQLs)
How to Identify Product Qualified Leads (PQLs)
Identify product qualified leads: pull in your signups, add product usage data, score every signup with AI, and write PQL scores back to your CRM.
No credit card required
Free 200 credits every month
Your database already knows which signups are about to buy. The columns are sitting right there: last_login_at, teammates_invited, a usage meter creeping toward its plan limit. None of it reaches the CRM where your sales team decides who to call, so reps prioritize by job title and company size while your best product qualified leads sit invisible in Postgres.
Score leads on Stripe billing data and product usage signals together: bring subscription status, plan tier, last login and features activated alongside each CRM contact, then let AI rate every signup 0 to 100 with a one-line reason for the number. Both the score and the reason sync back to your CRM.
This guide shows how to identify product qualified leads in Oneprofile: pull your signups in, add product usage data straight from your product database or analytics tool, let AI score every signup and write the reason, then push scores back to your CRM. Setup takes about 30 minutes.
The signals behind product qualified leads: activation, depth, expansion
A product qualified lead is a free or trial user whose in-product behavior says they are ready to buy. Someone who connected two integrations, invited a teammate, and logged in four times this week is closer to paying than someone who downloaded a whitepaper. The signal comes from what they did, not what they clicked.
Useful signals cluster into three categories:
Activation: did the user reach your product's core value moment? For us, that is a new prospect showing up already researched, with no manual lookups. For a project management app, it might be a project with a second collaborator on it.
Depth: is usage sustained after activation? Login frequency over seven days, distinct features used, session length trending up or down.
Expansion: is the user outgrowing their plan? Teammates invited, usage limits approached, gated features attempted, pricing page visits after a week of steady use.
Signal | Category | What it predicts |
|---|---|---|
| Activation | The value moment happened |
| Depth | The product is becoming a habit |
| Depth | Usage is widening, not just repeating |
| Depth | Interest is rising or fading |
| Expansion | The account is spreading internally |
| Expansion | The current plan is running out |
| Expansion | They are pricing the upgrade |
Pick three to five signals, not fifteen. The honest way to choose is to pull your last 50 free-to-paid conversions and look at what each account did in the two weeks before upgrading. When we ran this on our own signups, login counts told us almost nothing, and a teammate invite in the first week outweighed a month of solo activity. Your mix will differ, but expect one signal to embarrass the rest.
One opinion while we're here: the industry has made PQL definitions far too ceremonial. You do not need a quarter of cross-functional alignment meetings to agree that a free user who invited three teammates deserves a call. Pick the signals, ship the list, and let close rates correct you.
Put product usage next to your CRM contacts
Most PQL guides send you to a warehouse at this point: instrument an SDK, pipe events into Snowflake, model a score in SQL, then reverse-ETL it back to the CRM. If a data team already runs that stack for you, it works, and it may honestly be the better fit. Most teams under 200 people are not that team.
The Oneprofile build:
Pull your signups in. Create a table from your CRM contacts, or directly from your product's
userstable. Each signup is matched to its CRM record by email.Add product usage data. Connect your Postgres database with a read-only connection string, or connect your product analytics tool. Add each signal:
login_count_7d,features_activated,teammates_invited. Each signal updates from its source automatically and stays current.Add billing data from Stripe.
plan_statusand monthly revenue turn "active free user" into "active free user on a team that already pays you", which is a different conversation.
The whole pipeline is three data points and a connection string. GTM data tools that read product usage at all tend to route it through a warehouse connection gated to an enterprise tier. Here it is a direct Postgres, PostHog, or Stripe connection, and every connection in this guide is included on the $20 Team plan.
Score product qualified leads with AI
This is where product qualified leads stop being a definition and become a ranked list. With usage, billing, and firmographic data in one place, add AI scoring. The prompt holds your ICP and signal weights in plain language: what activation means for your product, which signals matter most, what disqualifies a signup outright. AI reads all of a signup's usage, billing and firmographic data, scores it 0 to 100, and writes a one-line reason next to the number.
The reason is the part reps actually use. "Invited 3 teammates this week, free plan near its usage limit, fits ICP" tells a rep how to open the conversation. Formula-based scoring in a CRM can add points per condition, but it cannot explain a record, and it never notices that two weak signals together make a strong one.
You also see what a scoring run will cost in credits before you start it, and enrichment lookups that come back empty cost nothing. For the fundamentals of scoring models before you write the prompt, the lead scoring guide covers demographic, behavioral, and predictive approaches.
Write PQL scores and reasons back to your CRM
A score that lives in a list nobody opens is a report, not a pipeline. Map the score and the reason to CRM properties, pql_score and pql_reason, and Oneprofile creates the properties on the CRM side when they do not exist yet. The write-back is two-way on every paid plan, so when fresh usage data moves a score, the CRM record moves with it.
This works whether "your CRM" means a mature Salesforce instance or a HubSpot free account. Reps sort their view by pql_score descending and read pql_reason before the first touch. For the CRM-specific details, which properties to create and where the native scoring tools fit, see the HubSpot lead scoring guide or the Salesforce setup.
Route product qualified leads by tier: warm, hot, expansion
Not every product qualified lead needs a phone call, and sending all of them to an AE queue is how the queue starts getting ignored.
Hot (score 80+, activated, hitting limits): direct AE outreach within the hour. Enrol that view in a sequence with the reason attached, so the first email references what they actually did.
Warm (40 to 79, activated, light usage): an automated nurture sequence with setup tips and upgrade prompts.
Expansion (already paying, adding seats or attempting gated features): route to customer success, not sales.
Two habits keep the tiers honest. First, re-run scoring on a schedule, because scores should decay as signals age. A signup who stopped logging in three weeks ago is not a PQL anymore, and the next run will say so in the reason. Second, once a quarter, compare closed-won and closed-lost deals against their scores at the time. If 40-score contacts close as often as 80-score contacts, your weights are off. Rewrite the prompt and re-score every signup in one pass, which is the adjustment a CRM formula rebuild never makes easy.
Start with the smallest version this afternoon: your CRM contacts, last_login_at, teammates_invited, and plan_status as signals, one AI score, write-back on. The free plan covers three connections and 100 rows per table, enough to score your current trial cohort and see whether the reasons hold up before you pay anything.
What is a product qualified lead?
What are common PQL criteria?
Do I need a data warehouse to identify product qualified leads?
How is PQL scoring different from lead scoring?
How do PQL scores get into my CRM?
How do I score leads using Stripe and product usage data?