A product-qualified account, or PQA, scores the company rather than the person. Dave Boyce sets it out in Freemium as two scores read together: fit, from firmographic data, and readiness, from what the account's users have done in the product. The combination decides which accounts get a salesperson, which get help and which are left to succeed on their own.
How it works
Boyce's routing has three outcomes. Low-fit accounts stay on the self-serve path. High-fit accounts with low readiness get an assistance play, run by people measured on usage rather than quota, whose question is how to help the account reach value.
High-fit, high-readiness accounts get a sales play about expanding that value. Boyce reports PQAs converting at four to seven times the rate of marketing-qualified leads (Ch 14).
He adds a rule that matters more than either score: no sales contact before the account reaches First Impact. That turns one product event into a gate on the entire sales motion, and it means a tracking break does not just skew a report. It decides who gets a phone call.
What it assumes your events already do
| Event | What the framework uses it for | What it reports when the event breaks |
|---|---|---|
User-to-account joinaccount_id on every event | Every readiness signal rolls up to an account. | Users without an account identifier vanish from readiness, so the best-fit companies look idle. |
Activation or First Impact eventfirst_report_shared | The First Impact guard before any sales contact. | The guard either blocks every account from sales or lets reps call accounts that have not seen value. |
Invite sent and acceptedinvite_sent, invite_accepted | Seat growth as a readiness signal. | Untracked seat additions make expanding accounts look flat, and they are routed to self-serve. |
Core value actionreport_viewed | Usage depth inside the account. | A change in how the action fires moves readiness for every account at once, which no real buying pattern does. |
Event names are illustrative; yours will differ. The dependency map shows which other frameworks share each event.
The account called on day one
Illustrative example. The company and the figures are invented to show the mechanism.
A refactor moves the First Impact event, first_dashboard_published, behind a feature flag, and it stops firing for new workspaces. The guard now reads every new account as not activated, so sales stops calling any new account.
Pipeline dries up within a fortnight. An engineer removes the guard to unblock it, and reps start calling three-user accounts on the day they sign up. Both failures trace back to one event that nobody was watching.
Checks before you trust it
- Check that every user event carries the account identifier before building readiness on it.
- Report the First Impact rate by signup week; a sudden change after a release is a tracking question first.
- Keep fit and readiness as separate scores, so a broken usage signal cannot hide inside a blended number.
- Log each routing decision with the events that triggered it, so a wrong call can be traced.
What Dave Boyce adds in Freemium
Boyce's capacity model ties sales headcount to PQA supply: new self-serve accounts, times the PQA rate, times the close rate, gives sales. His example is 50 accounts at 10% and 20%, which yields one deal (Ch 13). If the PQA rate is wrong because its events are, the hiring plan is wrong with it.
Check the events under it
Before Product-qualified account (PQA) goes into a plan, find out whether the events it needs exist and still fire the way it assumes. The free audit maps what your product collects today: sign in, connect a GitHub repository or Supabase, and Skene returns one audit, with no card. On Pro, Skene Cloud reviews every pull request on a linked GitHub repository for removed or broken tracking, so a pull request that removes or renames one of these events is flagged before it merges.