# Building a PQL Scoring Model

> Build a product qualified lead model that sales will actually work: event selection, weighting, account rollup, thresholds and the routing SLA behind it.

Source: https://saas-marketing.net/guides/pql-scoring-model/
Topic: SaaS Growth Marketing
Type: guide
Published: 2026-09-11
Last updated: 2026-09-11
Publisher: SaaS Marketing (saas-marketing.net)
License: CC BY 4.0. Quote or republish with attribution and a link to https://saas-marketing.net/guides/pql-scoring-model/

## Short answer

A PQL scoring model assigns a score to a free or trial user based on the three to five product events that correlate with purchase, rolls those user scores up to an account level score for multi seat products, and fires an alert to sales above a threshold set by sales capacity rather than by statistical elegance. Most models fail on data plumbing and sales trust, not on the maths. Ship a narrow high precision model first and widen it only once the sales acceptance rate holds above 70 percent.

## Key takeaways

- Three to five events beat twenty. Every extra signal dilutes the score and makes it harder to explain to a rep.
- Set the threshold against sales capacity. If reps can work 60 PQLs a week, the threshold is whatever produces 60.
- Roll user scores up to account level for multi seat products, or you will route five people from the same company.
- Identity resolution between the product database and the CRM is where most PQL projects actually die.
- A PQL sales ignores twice is dead permanently. Precision first, recall later.
- Track acceptance rate weekly. Below 70 percent, stop widening and fix the 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.

Logins, dashboard views, help doc reads and feature page visits. All of them correlate with converters simply because converters use the product more overall. They add no independent signal and they let a curious tyre kicker cross the threshold. Run the lift calculation and cut anything under 2x, however intuitive it feels.

The full derivation of event selection is worked through in [PQL scoring and routing](/guides/product-qualified-lead-scoring/). If you are still arguing about whether PQLs should replace MQLs, settle it first with [MQL vs PQL in B2B SaaS](/comparisons/mql-vs-pql/), 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.

| Signal | Type | Weight | Rationale |
| --- | --- | --- | --- |
| Invited 2 or more teammates | Behaviour | 25 | Highest observed lift, implies team adoption |
| Connected an OAuth integration | Behaviour | 20 | Requires an internal decision about access |
| Imported over 100 real records | Behaviour | 15 | Distinguishes evaluation from experimentation |
| Created a second workspace | Behaviour | 15 | Spread beyond the original use case |
| Hit a plan limit | Behaviour | 10 | Purchase trigger and conversation opener |
| Company size 50 to 1,000 employees | Firmographic | 10 | ICP fit, from enrichment |
| Target industry | Firmographic | 5 | Weak but free |
| Personal email domain | Penalty | -20 | Strong negative for B2B |
| No activity in 10 days | Decay | -15 | Stale signal is not a signal |

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.

**3 to 5** Product events in a well performing first version PQL model

## 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](/glossary/product-qualified-lead/) and its growth focused counterpart, [PQL for growth teams](/glossary/product-qualified-lead/).

## 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.

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](/playbooks/product-qualified-lead-email-plays/). Two tiers is where you want to end up, but not in version one.

A rep who works three PQLs and finds all three worthless will deprioritise the queue, and the second time it happens they stop opening it. Recovering that trust takes two quarters. Start with a threshold so high it feels conservative, prove the acceptance rate, then lower it by five points at a time.

## 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.

**Product event to CRM alert**

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

| Object | Field | Type | Example |
| --- | --- | --- | --- |
| Account | PQA Score | Number | 74 |
| Account | PQA Tier | Picklist: Hot, Warm, Watch | Hot |
| Account | PQA Reasons | Text, 255 | "3 users active, Slack connected, hit seat limit" |
| Account | PQA Score Date | Date | 2026-09-08 |
| Contact | Top User Flag | Checkbox | true |
| Contact | Last Product Action | Text | "Invited 2 teammates, 6 Sep" |

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.

'Data wrong' dispositions above 10 percent mean your identity resolution is broken, and no amount of model tuning will fix it. Stop scoring, fix the join, and republish the match rate. Teams that push through this because the score looks good in aggregate end up with a queue sales has quietly stopped reading.

## 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](/saas-growth/) and the comparison framing in [MQL vs PQL](/comparisons/mql-vs-pql/), plus the metrics definition in [PQL as a reporting metric](/glossary/product-qualified-lead/) and the MQL counterpart in [marketing qualified lead](/glossary/marketing-qualified-lead/).

## Frequently asked questions

### What is a PQL scoring model?

It is a rule or weighted formula that turns product usage into a sales signal. You pick the events that correlate with purchase, assign weights, sum them for a user, roll them up to the account, and route accounts above a threshold to sales. Unlike traditional lead scoring, the inputs are behaviours inside the product rather than form fills and email opens.

### Which events should be in a PQL model?

Events that require real effort and imply the product is being embedded in work: inviting a teammate, connecting an integration, importing production data, creating a second project, hitting a plan limit. Avoid passive events like logging in or viewing a dashboard, because they correlate with curiosity rather than commitment.

### How do you set the PQL threshold?

Backwards from sales capacity. Calculate how many accounts a rep can genuinely work in a week, multiply by the number of reps, and set the score cutoff that produces that volume. A statistically optimal threshold that generates 400 alerts for a team that can work 60 is worse than useless, because reps stop trusting the queue entirely.

### What is the difference between a PQL and a PQA?

A PQL is a qualified individual user. A PQA, or product qualified account, aggregates all users at a company into one account level signal. For any product sold by seat or team, PQA is the right unit, because sales sells to companies. Keep the user scores underneath so the rep knows which person to contact and why.

### How do you know if your PQL model works?

Two numbers. Acceptance rate, meaning the share of routed PQLs sales agrees are worth working, which should hold above 70 percent. And conversion lift, meaning PQL to closed won compared with non PQL signups. If a PQL converts at three or more times the baseline, the model has real signal.

### Why do PQL programmes fail?

Plumbing and trust, not maths. Identity resolution between product and CRM breaks, so records duplicate or never match. Alerts fire without context, so reps open them and see nothing useful. Volume overwhelms capacity, so the queue gets ignored. Every one of those is an operations problem, and none of them is solved by a better weighting scheme.

### Do you need a data warehouse to build a PQL model?

Not for version one. You can ship a useful rule based model with product analytics and a reverse ETL or even a scheduled job writing three fields to the CRM. You need a warehouse once you want historical backtesting, account rollups across many events, and a score that changes daily without manual work.