Building a PQL Scoring Model

Most PQL projects die in month four, and almost never because the scoring formula was wrong. They die because the product database and the CRM disagree about who a person is, because sales opened twelve alerts in a row with no useful context, or because the threshold produced 300 weekly alerts for a team of four reps.

So this covers both halves: the model, and the plumbing and process that decide whether anyone acts on it.

Which product events actually predict purchase?

Three to five, and you find them with the same lift analysis used for activation rather than by asking the product team which features they are proud of.

The method is straightforward. Take every account that converted to paid in the last twelve months and every account that signed up and did not. For each candidate event, calculate the share of converters who performed it within their first 14 days and the share of non converters who did. The ratio between those two is your lift. Anything under about 2x is not worth a weight.

What consistently shows high lift across B2B SaaS products, whatever the category:

• Inviting a second user from the same email domain, especially within the first week.
• Connecting an integration that requires authentication, because that involves a decision about production systems.
• Importing real data rather than using sample data.
• Creating a second project, workspace or board, which signals the tool has spread beyond one experiment.
• Hitting a plan limit, which is both a purchase signal and a conversation opener.

The full derivation of event selection is worked through in PQL scoring and routing. If you are still arguing about whether PQLs should replace MQLs, settle it first with MQL vs PQL in B2B SaaS, because a team running both without a clear hierarchy routes the same account twice.

What does a worked scoring table look like?

Here is a model for a collaboration product sold by seat, with weights derived from lift rather than opinion.

Two design choices in that table are worth defending. Firmographics carry only 15 points combined, because a perfect fit company that does nothing in the product is not a PQL, it is a target account for outbound. And the decay penalty exists because a score that never decreases fills the queue with accounts that got excited in March and vanished.

How do you roll user scores up to an account?

Sum with a cap, then add an account level bonus for breadth. Taking the maximum user score loses the team adoption signal entirely, and plain summing lets one very active power user outweigh six moderately engaged people at a larger account.

The rule that works in practice:

• Account behaviour score equals the sum of the top three user scores at the domain, which prevents a single enthusiast dominating.
• Add 15 points if three or more distinct users were active in the last 14 days, because breadth is the strongest account level predictor.
• Add 10 points if any user has an admin or billing role.
• Apply firmographic points once at account level, never per user.

Domain matching is your join key, with the obvious exclusions for gmail, outlook and the disposable domains. For enterprise accounts with multiple domains after acquisitions, you need a manual mapping table, and yes, someone has to maintain it. The distinction between the two units is covered in the product qualified lead glossary entry and its growth focused counterpart, PQL for growth teams.

How do you set the threshold?

Against sales capacity, not against a ROC curve. This is the single most important decision in the whole project and it is usually made by whoever is best at statistics rather than whoever knows how many accounts a rep can work.

Do the arithmetic explicitly. A rep working PQLs properly, meaning researching the account, reading the usage detail and sending something personal, handles 12 to 18 a week. Four reps gives you 48 to 72 a week. So your threshold is whatever score produces about 60 accounts a week, and you adjust it monthly as volume changes.

Threshold approach	Weekly volume for a 4 rep team	Acceptance rate	Verdict
Statistically optimal cut point	250 to 400	30 to 45%	Queue gets abandoned within a month
Capacity matched, high precision	50 to 70	70 to 85%	Ship this first
Two tier: PQL to sales, warm to nurture	60 to sales, 200 to email	75% on the sales tier	Best steady state, month 4 onward
No threshold, sales browses a dashboard	Whatever they feel like	Unmeasurable	Not a programme

The accounts below the threshold are not wasted. They go into automated nurture sequences, which is the natural pairing with product qualified lead email plays. Two tiers is where you want to end up, but not in version one.

What does the data path look like?

Four hops, and each one is a place the project stalls. Map it before you write any scoring logic.

Here is the CRM field spec that has survived contact with real sales teams. Six fields, no more.

The reasons field is doing the heavy lifting. A rep who opens an alert saying “score 74” has nothing to say. A rep who opens one saying three people are active, Slack is connected and they hit the seat limit yesterday has an opening line.

What SLA and feedback loop keep the model alive?

Three commitments, agreed with sales leadership in writing before launch. Without these you have a dashboard, not a programme.

Response time: first touch within 24 hours for the hot tier. Product signals decay fast, and a user who hit a limit on Monday has either solved it or left by Thursday. Chili Piper or a simple round robin with Slack alerts handles the routing.

Disposition codes, required within 48 hours, with exactly five options: working it, contacted no response, not a fit and why, already a customer, and data wrong. That last code is the most valuable one in the list because it surfaces plumbing failures that would otherwise be silently absorbed by reps who assume marketing knows best.

Monthly review of acceptance rate and conversion lift, with a standing agreement that the threshold moves based on that data rather than on whoever complains loudest. Acceptance rate is accepted divided by routed. Below 70 percent you tighten. Above 85 percent for two months running you loosen, because you are leaving volume on the table.

The tradeoff nobody mentions

A high precision PQL model deliberately ignores most of your signups. If you route 60 accounts a week out of 900 weekly signups, you are betting that the 840 you skipped are better served by automation, and some of them are not. You will lose deals that a human conversation would have won.

That is the right trade at the start, because the alternative failure is worse and permanent. A queue sales trusts and works is an asset that compounds. A queue sales abandoned is nearly impossible to revive, and the second attempt is met with the memory of the first. Accept the missed opportunity cost for two quarters, build the acceptance rate, then widen deliberately.

What to do this month

Pull twelve months of converted and non converted accounts and run the lift calculation on ten candidate events. Keep the four with the highest lift. Measure your product to CRM identity match rate before you build anything else, because that number determines whether the project is feasible at all.

Then write the six CRM fields, set the threshold to your rep capacity, and run it manually in a spreadsheet for two weeks before automating anything. Review the wider context in SaaS growth marketing and the comparison framing in MQL vs PQL, plus the metrics definition in PQL as a reporting metric and the MQL counterpart in marketing qualified lead.