A PQL Score Sales Can Trust: Events, Fit, Decay, and Thresholds

Send sales every active account and they learn to ignore the alerts within a week. A team that can work 40 new leads a week will not triage 300. A product-qualified lead score only earns its keep when it can say why this account, why now, and when the signal goes stale.

Sales Needs a Defensible Signal

Forwarding every active account to sales creates a predictable dispute: product sees usage; sales sees no budget, buying role, or reason to change. Alerts are ignored and PQL loses meaning.

A PQL score asks which accounts show enough current product value and commercial fit for human sales action now. It is a governed routing decision that shows why an account qualified, when, and when the signal expires. Account health, lead-volume targets and close prediction are separate questions.

Build the Score From Observable Evidence

A useful score has three layers: fit identifies profitable-customer resemblance, behavior shows meaningful value, and freshness stops six-week-old activity looking current.

Match scoring to the motion. B2B SaaS usually scores accounts, aggregating identified-user activity, because sales sells to an organization with buying processes, security review, and stakeholders. A mid-market purchase usually involves several people, from the person who runs the trial to the manager who signs and the security reviewer who can stall everything, and most of their evaluation happens where sales cannot see it. In a product-led motion much of it happens inside the product, which is exactly why account-level usage is worth scoring. Self-serve products for individuals may score users.

Write the business definition first and only then look at which events exist:

A qualified account is in the target segment, has completed a value-bearing workflow, and has recent evidence of collaborative or capacity-driven demand.

“Completed a value-bearing workflow” is stronger than “logged in”; “recent” needs a window; “target segment” needs data ownership and a missing-firmographic policy. If this sentence cannot be written, it is too early to assign points.

Define an action contract: 70 might create an account-executive CRM task within one business day; 50 might enter a monitored queue or trigger an in-product offer. Without action, scoring is a dashboard without an operating consequence.

Each Component Fails on Its Own

A single activity counter favors large accounts and accidental traffic; fit alone routes attractive companies that have not found value. Combining components gives sales a trustworthy reason for handoff.

Fit answers whether we can and should sell at all: the employee band, industry, region, plan, and account type. On its own it fills the queue with attractive companies that have felt no product pull. Behavior answers whether value has actually been experienced, through a completed workflow, shared output, recurring use, or a limit reached; left alone it lets students, agencies, or poor-fit users dominate. Freshness answers whether the signal is still live, reading days since the event, active-seat recency, and trial state, and without it old activity stays eligible long after intent has faded. Guardrails answer the opposite question of when to withhold, catching bots, employees, test workspaces, open opportunities, and opt-outs before a false handoff doubles a seller's work.

Rule-based scoring is the right starting point for most teams: it is explainable, auditable, and a shared language for product, operations, and sales. Predictive models may later rank accounts within a trusted pool, but cannot repair vague events or biased historical opportunity data. Use rules until tracking and closed-loop outcomes are stable and complexity has a clear purpose.

Company size is not universally positive. A 2,000-person company can score high on fit while one evaluator runs a trial. For collaboration products, three active users creating and sharing work may matter more than employee count. Fit should narrow the pool that behavior is judged in, while behavior still decides who inside it gets routed.

Events That Inflate PQL Scores

Each component is only as trustworthy as the events feeding it, and most failures begin in the event dictionary: teams reward easy-to-track actions rather than value-proving ones. login_completed can support onboarding analysis but should rarely trigger sales; neither should page views, email opens, or generic feature_clicked.

Use verb-object names and an inclusion rule. report_published, for example, means a user saved a report that passed validity checks and became available to an intended audience. Opening the builder and abandoning it does not count. Define events in plain language before instrumentation.

Instrumentation sets the ceiling for score quality. Teams without stable value events should first measure feature adoption before analytics instrumentation, rather than build PQLs from clickstream noise.

Treat three exclusions explicitly:

• Bots and automated traffic: known user agents, synthetic monitoring, load tests, and nonhuman bursts.
• Employees and administrators: staff domains, support impersonation, agency admins, and partner demo tenants can be active without buying intent.
• Test and duplicate workspaces: sandboxes, seeded demos, internal QA, merged accounts, and deleted trials must not reach sales.

Store exclusions as fields or suppression rules that anyone can query, instead of leaving them in a few people's heads. Sellers should see pql_eligible = false and a reason such as internal_domain or open_opportunity.

A Worked SaaS Scoring Model

Consider a fictional analytics SaaS for mid-market product teams. Value arrives when a workspace connects a data source, publishes a dashboard, and shares it with colleagues. This is adaptable, not a benchmark.

Document the Event Dictionary

The score is not every recorded event: behavioral points decay after their window. Take an account with 25 ICP-fit points that connected a source 10 days ago, published four days ago, shared three days ago, and hit a limit yesterday. Its raw behavioral score is 70.

Use:

decay(days) = MAX(0.20, 1-0.03 × days_since_event)

Apply it to each behavioral event. Connection contributes 15 × 0.70 = 10.5; publication 20 × 0.88 = 17.6; share 20 × 0.91 = 18.2; limit 15 × 0.97 = 14.55. Behavior totals 60.85; full score is 25 + 60.85 = 85.85.

The 0.20 floor keeps an old valid setup action from vanishing; shorter publication and sharing windows tie handoff to current use. A workflow with a monthly natural usage interval should not use aggressive daily decay. Set the decay rate from how often a healthy account naturally repeats the workflow.

Score Equation and PQL SQL

PQL score = fit points + Σ(event points × decay) + contact points

Eligibility is separate:

eligible = not_bot AND not_internal AND not_test AND no_open_opportunity AND not_opted_out

Exclude a bot rather than assigning negative 500 points. Separation keeps audit logs readable and prevents accidental routing when events are added.

This simplified SQL calculates daily account-level scores; fields and date functions vary by warehouse.

WITH eligible_accounts AS (
 SELECT a.account_id,
   CASE WHEN a.employee_band IN ('50-199','200-999','1000-2000') THEN 15 ELSE 0 END
 + CASE WHEN a.sales_region_supported THEN 10 ELSE 0 END AS fit_points
 FROM accounts a WHERE a.is_bot=FALSE AND a.is_internal=FALSE AND a.is_test=FALSE
 AND a.has_open_opportunity=FALSE AND a.marketing_opt_out=FALSE
), scored_events AS (
 SELECT e.account_id, CASE e.event_name
  WHEN 'data_source_connected' THEN 15 WHEN 'dashboard_published' THEN 20
  WHEN 'dashboard_shared' THEN 20 WHEN 'usage_limit_reached' THEN 15 ELSE 0 END
 * GREATEST(0.20,1-0.03*DATE_DIFF(CURRENT_DATE,DATE(e.event_at),DAY)) AS decayed_points
 FROM product_events e WHERE e.event_name IN ('data_source_connected','dashboard_published','dashboard_shared','usage_limit_reached')
 AND e.event_at >= CURRENT_TIMESTAMP-INTERVAL '30 day'
), account_scores AS (
 SELECT ea.account_id,ea.fit_points+COALESCE(SUM(se.decayed_points),0) AS pql_score
 FROM eligible_accounts ea LEFT JOIN scored_events se ON se.account_id=ea.account_id GROUP BY ea.account_id, ea.fit_points
) SELECT account_id,pql_score FROM account_scores WHERE pql_score>=70;

Production SQL also needs user-account identity resolution, repeated-event deduplication, timezone rules, event versioning, and a snapshot date to reproduce past scores. Retain fit_points, contributing events, exclusion status, score version, and calculated timestamp in CRM or warehouse rather than overwriting results.

Backtest the Handoff Before Routing

Before alerts, run the score on historical accounts. Freeze data at a past cutoff, calculate each score as it existed then, and compare it with later CRM outcomes in a fixed observation window. This does not prove causality; it tests whether rules distinguish useful handoffs from noise.

Build a review table with account ID, cutoff score, component breakdown, owner, later opportunity status, stage reached, closed reason, and seller notes. Split by segment, acquisition source, plan, and geography: averages can hide a score that works for product-led mid-market accounts but fails for startups or partner-created tenants.

Inspect both misses. A false positive reaches sales but is rejected for poor fit, duplicate demand, no urgency, or no response after agreed follow-up. A false negative was not routed but later created a qualified opportunity. False positives waste attention; false negatives miss product-led revenue. The acceptable balance depends on sales capacity and deal size.

Read the individual records as well as the conversion rate. False positives from free agencies may require an account-type exclusion; false negatives among teams with five active users may mean collaboration matters more than a plan-limit event. Seller feedback improves the model once it arrives as a reason code, such as poor fit or no urgency, instead of free-text frustration.

Calibrate Thresholds With Sales Feedback

The first threshold is a capacity decision. If sales can work 40 new PQLs weekly, inspect score distribution and choose a manageable cutoff. A lower threshold may suit automated nurture or a pooled development team, but rarely a senior account executive’s direct queue.

Once the cutoff is set, routing follows the band. An account at 70 or above creates a sales task carrying its score reasons, and the review question is simply whether the seller accepted and worked it. The 50-69 band goes to nurture, monitoring, or a contextual in-product offer, where the question worth tracking is which next behavior predicts acceptance. Anything under 50 stays inside product lifecycle programs, and the thing to watch is whether the account is reaching first value at all.

During first release, calibrate weekly. Product operations owns score integrity; sales operations owns CRM routing and outcome fields; product analytics validates event coverage; sales leaders define acceptance. Review volume, acceptance, time to first touch, opportunity creation, false positives, false negatives, complaint rate, and opt-out rate.

Do not raise a threshold just because conversion is low. Check seller follow-up, whether scoring preceded the opportunity, and whether unlike segments are compared. Raising a cutoff can improve a dashboard while hiding emerging accounts; lowering it can create unworked volume. Thresholds are commercial policy as well as analytics. Judge sellers on PQL conversion and the score quietly becomes their target: the weights get nudged toward accounts that are easy to convert, whether or not they are the valuable ones, and nobody has to cheat for it to happen.

Keep an Evidence Log for Every Handoff

The shift is from opaque intent labels to inspectable evidence. Sales does not need an account called “hot”; it needs a timeline: two analysts published dashboards, an admin invited colleagues, the workspace reached its plan limit, and all occurred this week.

Predictive ranking can help with reliable feedback and stable definitions, but must sit atop eligibility rules and an event dictionary. A complex model that cannot explain an account’s appearance will struggle in disputes, territory changes, privacy reviews, and pipeline audits. Adding coefficients rarely helps until that explanation is in place.

Put a Governed Score Into Production

Start with one product motion, one account segment, and a score a seller can explain in under a minute. Publish the event dictionary, exclusions, formula, score version, routing rule, and owner. Backtest before launch; inspect accepted and rejected PQLs weekly until failure patterns are clear.

Expect the first version to be wrong in specific, useful ways: a segment that floods the queue, an event that fires on abandoned work, a decay window that is too short for monthly users. Bump the score version each time one of those is fixed, and keep earlier versions reproducible so a disputed handoff can be traced to the exact rule that sent it. Sales discovery and product judgment still decide what happens after the handoff.