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 not account health, a lead-volume target, or a close prediction; it is a governed routing decision with visible evidence of why an account qualified, when, and when the signal expires.
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. Self-serve products for individuals may score users.
Start with a business definition, not available events:
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.
Fit, Behavior, and Decay Compared
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.
| Component | Question | Typical inputs | Failure alone |
|---|---|---|---|
| Fit | Can and should we sell? | employee band, industry, region, plan, account type | High-fit accounts without product pull fill the queue |
| Behavior | Has value been experienced? | completed workflow, shared output, recurring use, limit reached | Students, agencies, or poor-fit users dominate |
| Freshness | Is the signal live? | days since event, active-seat recency, trial state | Old activity remains eligible after intent fades |
| Guardrails | Should we withhold? | bot, employee, test workspace, open opportunity, opt-out | False handoffs and duplicate seller work rise |
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 constrain behavior, not erase it.
Events That Inflate PQL Scores
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—not that they opened a builder and abandoned it. 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, not tribal knowledge. 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
| Signal | Definition and window | Points | Why it earns points |
|---|---|---|---|
| ICP employee band | 50–2,000 employees from verified enrichment | 15 | Supported sales segment |
| Paid-eligible region | Supported selling region | 10 | Avoids accounts sales cannot serve |
| Data source connected | At least one valid connection in last 30 days | 15 | Setup beyond browsing |
| Dashboard published | Published dashboard in last 14 days | 20 | Completed value workflow |
| Dashboard shared | Shared with a second verified user in last 14 days | 20 | Collaboration and possible seat growth |
| Usage limit reached | Free-plan limit in last 7 days | 15 | Demand, if value is proven |
| Product-qualified contact | Admin or champion role identified | 10 | Plausible first contact |
| Disqualifier | Bot, internal/test tenant, active opportunity, or opt-out | ineligible | Prevents unsuitable routing |
The score is not every recorded event: behavioral points decay after their window. An account with 25 ICP-fit points connected a source 10 days ago, published four days ago, shared three days ago, and hit a limit yesterday has behavioral raw score 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. Follow product rhythm, not spreadsheet convenience.
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 1,2
) 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.
Review records, not just conversion. 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. Sales judgment improves the model when feedback is categorized, not vague.
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.
| Score band | Routing rule | Review question |
|---|---|---|
| 70+ | Create sales task with score reasons | Did the seller accept and work it? |
| 50–69 | Nurture, monitor, or offer contextual in-product help | Which next behavior predicts acceptance? |
| Under 50 | Keep in product lifecycle programs | Is the account reaching first value? |
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.
PQL Scoring Is Moving Toward Evidence Logs
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. Maturity means better governance, not more coefficients.
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.
A trusted PQL score does not replace sales discovery or product judgment. It earns attention at the right moment by connecting fit, realized value, and recency—a higher standard than forwarding every active account.