Implementation worksheet · 6 min read
A Product Qualified Account Definition Worksheet
Fill in five fields and then test them. The unit (account or user — pick one and be consistent), the signals (three to five behaviours, each observable in your event data today), the thresholds (a number and a window for each), the eligibility filter (who is excluded regardless of score), and the action (what happens when an account qualifies, and who owns it). Then backtest: what share of accounts that converted last quarter would have qualified, and what share of qualifiers never converted. If either number is bad, the definition is wrong, and shipping it will burn the trust of whoever works the list.
Product qualified accounts are usually defined in a single meeting, from intuition, by people who know the product well. That is a reasonable starting point and a terrible stopping point. The definition then goes into tooling, produces a ranked list, and nobody revisits it — so when sales stops working the list six weeks later, the diagnosis is 'sales is not using the tool' rather than 'the definition was never validated'.
Put it into practice
1. Pick the unit and hold it
Account or user. Mixing them is the most common structural error: a score computed per user and acted on per account silently means 'any one user did this', which is a much weaker signal than 'the account did this'. Write the unit at the top of the worksheet and check every signal against it.
2. Choose three to five signals you can observe today
Not the ones you wish you had. Each signal must map to an event that is already firing, with a field you can filter on. A definition that depends on instrumentation you have not built is a roadmap item, not a definition, and labelling it as one saves a quarter of confusion.
3. Give every signal a threshold and a window
'Used the integration' is not a threshold. 'Connected at least one integration within 14 days of signup' is. The window matters more than the number, because it separates the accounts building a habit from the accounts that tried something once. Write both.
4. Write the eligibility filter separately from the score
Excluded regardless of score: accounts in an active support escalation, accounts on a contract that already includes what you would sell, accounts in a region you cannot service, accounts who asked not to be contacted. Keeping exclusions out of the score keeps both readable — the score says 'ready', the filter says 'allowed'.
5. Backtest before anyone works the list
Take converted accounts from the last two quarters and apply the definition retroactively. Two numbers come out: coverage (what share of converters would have qualified) and precision (what share of qualifiers converted). Low coverage means too narrow. Low precision means the list will waste effort. Both are fixable before launch and expensive after.
6. Name the action and its owner
A definition with no action attached produces a dashboard. Say what happens — a sales task, an automated campaign, a nudge in the product — and name who owns it. If the answer is 'we will decide when we see the list', the programme has no owner and will not survive contact with a busy quarter.
The definition worksheet
Copy this structure into your review document and record your observed result for each row.
| Field | Your answer | Observable today | Checked |
|---|---|---|---|
| Unit (account or user) | n/a | ||
| Signal 1 + threshold + window | |||
| Signal 2 + threshold + window | |||
| Signal 3 + threshold + window | |||
| Eligibility exclusions | |||
| Coverage on last 2 quarters' converters | n/a | ||
| Precision: qualifiers that converted | n/a | ||
| Action on qualification | n/a | ||
| Owner of the action | n/a | ||
| Review date | n/a |
A failure worth checking
Optimising the definition until the list looks impressive. It is easy to raise precision by tightening thresholds until only obvious buyers qualify — the list converts beautifully and surfaces nothing anyone did not already know. A PQA definition earns its keep on the accounts a human would have missed, so track coverage alongside precision and be suspicious of a definition that only finds the easy ones.
Common questions
How often should the definition be revisited?
Quarterly, and immediately after any material change to onboarding or packaging. Both change which behaviours are possible and how quickly they happen, which silently invalidates thresholds that were correct when written.
What if we have no converted accounts to backtest against?
Then you have a hypothesis, and you should say so out loud to whoever works the list. Run it as an explicit experiment with a review date rather than presenting it as a qualified-lead programme — the honesty is what preserves trust when the first version turns out to be wrong.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.