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.
To build it alongside the guide, connect your CRM and product database in a free workspace before you start.
What is a product qualified lead? Activation, depth, expansion
A product qualified lead is a free or trial user whose in-product behavior says they are ready to buy, at an account that also fits who you sell to. 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.
Fit is the half most PQL definitions leave out. A student exploring your free plan can out-use a buyer, so usage tells you who is ready and fit tells you who is worth a sales conversation.
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 |
Define your PQL signals before you build anything: three to five, 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. Raw login counts often say less than you expect, and a teammate invite in the first week can outweigh 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 run another pipeline to copy 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 database user, or connect your product analytics tool. Add each signal:
login_count_7d,features_activated,teammates_invited. Turn on scheduled refreshes for the table and each signal 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 a higher 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. Create two CRM properties once, pql_score and pql_reason, and map the score and the reason to them. The write-back runs on every paid plan. Run the export after each scoring pass and it skips contacts whose score has not changed, 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, where the signal sits beside the account's customer health score.
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, 200 credits a month, and 100 rows per table, enough to score your current trial cohort and see whether the reasons hold up before you pay anything. Get started free and score the cohort today.
