HubSpot/No. 31/6 min read
Your product knows who’s ready to buy. Your CRM never hears about it.
A trial account where seven people use the product every day is the warmest pipeline you have. In most CRMs it’s invisible, because nobody on it filled out a form.
Your product already knows which accounts are ready to buy. It knows who activated, who invited three teammates, and who hit the plan limit on Tuesday afternoon. Your CRM knows none of it. So the lead score keeps rewarding webinar attendance, the SDR calls the person who downloaded an ebook, and the account where six people use the product every day sits unrouted because nobody filled out a form.
That's the product-qualified lead problem. It isn't a definition problem. Most product-led teams can tell you what a PQL is. It's a plumbing problem: usage data lives in the product database or an analytics tool, and nothing carries it to the record your reps actually work.
A PQL is a threshold, not a vibe
A product-qualified lead is an account that crossed a defined usage threshold tied to the moment your product delivers value, and that also fits who you sell to. Both halves matter. Usage without fit is a student on a free plan. Fit without usage is just an MQL with a login.
Here's where we see teams go wrong when they try to wire this up.
They pipe raw activity and ask reps to interpret it. A contact record that says "logged in 14 times" isn't a signal. It's homework. Reps don't have time to decide whether 14 logins means anything, so they don't.
They score the person when the product is used by the account. In most B2B products, value shows up at the workspace level: seats added, data connected, a second team onboarded. Scoring one contact misses that the account just went from one user to seven.
They bolt usage points onto the MQL score. This is the most common one. Ten points for a form fill, twenty for activation, all in one number. It's the same mistake as blending fit and engagement into one lead score, with a third signal stirred in. Reps can't tell why a record scored 85, so they stop trusting all of it.
Why usage data never reaches the CRM
Three reasons, and none of them are technical limits.
Nobody owns the seam. Product analytics belongs to product and engineering. The CRM belongs to marketing ops or RevOps. The pipe between them belongs to whoever has a spare sprint, which means nobody.
Identity doesn't line up. The product knows a user ID and a workspace ID. The CRM knows an email address and a company record. Plenty of your signups use a personal email, so domain matching puts them on no company at all. If your leads don't know which account they belong to, your usage data won't either.
Teams send everything. Someone streams every click into the CRM, contact timelines fill with noise, workflows trigger on garbage, and the project gets rolled back. The lesson people take is "the CRM can't handle product data." The real lesson is that it shouldn't have to handle all of it.
The build: four pieces
This is the structure we use. It works in HubSpot and Salesforce. The examples below are HubSpot because that's where we see the gap most often.
1. Map the workspace to the company before anything else
Create a unique property on the company object: product_workspace_id. Require unique values. On the contact, store product_user_id alongside email. Now every product event can find its record by ID instead of guessing by domain, and the personal-email signup still lands on the right account because the workspace tells you where it belongs.
Do this first. Every step after it depends on the match being right.
2. Send milestones, not clickstream
Pick five to eight events that mark real progress toward value. For a typical B2B SaaS product, that looks like workspace_created, teammate_invited, integration_connected, first_report_shared, and usage_limit_reached. Not page views. Not button clicks. Moments.
In HubSpot, these are custom events. Per HubSpot's custom events documentation, you can send them via API, import them from a spreadsheet, or receive them by webhook, associate occurrences with contacts, companies, deals, or tickets, and use them as workflow enrollment triggers. Give each event a few properties (plan_tier, seat_count, feature_name) and make them enumerations, not free text, so you can actually group by them later.
3. Roll events up into properties a rep can read
Events are history. Properties are state. Reps and routing rules read state.
On the company, build a small set of rollup properties:
pql_status(picklist:not_pql,pql,pql_worked,converted,disqualified)pql_date(date, stamped once when the account first qualifies)pql_reason(picklist: which threshold tripped, such asseat_growth,integration_connected,limit_reached)active_users_30d(number)last_value_event_date(date)
A workflow listens for the milestone events, checks the threshold, and sets these values. Keep pql_reason a governed picklist. In six months it's the field that tells you which threshold actually predicts pipeline and which one just generates noise.
4. Keep the PQL signal separate from the MQL score
Fit and usage are two axes. Treat them that way. A PQL with a strong fit tier routes to a rep with an SLA. A PQL with a weak fit tier (one-person company, wrong industry, a competitor kicking the tires) goes to a low-touch nurture tied to usage milestones. An MQL with no usage stays on the marketing track.
Don't overwrite lifecycle stage to make room for PQL. Run pql_status as a parallel property and let lifecycle advance to SQL when sales accepts the record. That keeps your funnel math intact and avoids the stage confusion we cover in the lifecycle stages most HubSpot accounts get wrong.
What good looks like
A rep opens the company record and reads one line: PQL since October 2, reason seat_growth, 7 active users in the last 30 days, on the free tier. No interpretation required. They know why they're calling and what to say.
Routing triggers on pql_status equals pql and fit tier A or B. Your report shows PQL-to-opportunity conversion by pql_reason, so every quarter you can tighten the thresholds that flood reps with weak accounts and loosen the ones that are too strict to fire. Set the bar too low and sales stops opening PQLs. Too high and the best accounts self-serve right past you.
The cost of leaving it unbuilt is quiet. Sales keeps chasing form fills. The accounts already getting value from the product hit the free-plan ceiling and either stall or buy the smallest tier without ever talking to anyone. Nothing in the CRM flags it, because the CRM was never told.
Where to start
Pull your last 20 closed-won accounts that started on a trial or free plan. Ask product which three actions they took in the first 14 days. Then check whether any of those actions exist anywhere in your CRM as a property a rep could filter on.
If the answer is zero, you don't have a scoring problem. You have a missing pipe and a missing data model, and no amount of tuning the MQL score will fix it.
This is object-model work, which is where every Marketing Operations & CRM engagement we run starts: the IDs, the properties, and the rules that decide which signal reaches which rep. Then the automation, because automation built on top of a sound model actually holds.
Not sure whether your product data is reaching your reps? That's one of the things we map in the free 30-minute audit. We look at where usage lives, how it matches to accounts, and what your routing actually reads. Then we hand you the prioritized list. Whether we work together or not.