PQL Scoring for PLG: From Product Events to Sales Action

A PQL score is useful only if crossing the threshold changes something. Too many teams start with a 0–100 formula, label the top quartile “hot,” and sync it to CRM. Sales gets a new list, but nobody can explain why a lead is there or whether contacting it improves conversion.

Build the system in the opposite order:

decision → success label → observation window → features → score → threshold → action

The hard part is not the SQL. It is preventing a convenient correlation from becoming an expensive sales workflow.

Define the decision first

“Find likely buyers” is not specific enough. Choose one action:

• create a sales task for an account;
• offer assisted onboarding;
• route an account to expansion review;
• show an in-product upgrade message;
• suppress outreach because the account is still evaluating;
• ask product research to investigate a blocked workflow.

Each action has different error costs. A false positive in an in-product message is an annoyance. A poorly timed sales email can damage trust. A false negative in an enterprise expansion workflow can leave material revenue unnoticed.

Write a decision contract:

The values are illustrative. Choose them from the actual sales cycle and operating model.

Define the buying unit

In a self-serve tool, one user may discover value, decide, and pay. In B2B, several people may evaluate together while procurement or an admin controls the purchase.

Use account-level features when the account buys:

• number of active members, with a clear definition of active;
• role diversity, if collected and permitted;
• repeated use of the core workflow across members;
• collaboration or sharing inside the workspace;
• consumption relative to a plan limit;
• admin or billing-page behavior;
• failures that block broader adoption;
• current contract, region, and product eligibility.

Do not simply sum user scores. Ten accidental invitations are not ten times the intent. Use bounded account features and preserve which users and events produced them.

Identity resolution needs its own rules. A shared email domain is not always one company, and a free email is not proof of a low-value lead. Domains, SSO organization IDs, billing accounts, verified invitations, and CRM mappings can conflict. Store match confidence and route ambiguous accounts for resolution rather than silently merging them.

Find value signals without label leakage

A useful feature must be observable before the decision and available in production at scoring time.

Value signals

These indicate that the product delivered part of its core job:

• a workflow completed successfully, not merely opened;
• output consumed, shared, exported, or revisited;
• repeated use on separate days;
• collaboration across members;
• an integration used in a real workflow;
• a previously blocked task completed.

Buying or expansion signals

These may indicate commercial timing:

• a relevant limit approached or reached;
• billing, plan, or admin pages viewed;
• teammates invited and activated;
• usage spreading to another team;
• a paid capability attempted;
• a procurement or security question raised.

The same event can mean frustration rather than intent. Repeated paywall hits may show value, confusion, or a broken entitlement check. Inspect examples before weighting it.

Leakage to exclude

Do not train on or score with information caused by the outcome:

• subscription_created when predicting subscription;
• a sales meeting booked after a rep contacted the account;
• CRM stage updated after qualification;
• features unlocked only on the paid plan;
• enrichment or notes created by the sales action you are trying to trigger.

Also avoid using future activity in an earlier score. Every feature query needs an as_of timestamp.

A clean event taxonomy is a prerequisite. If an event changed meaning across releases, version it or restrict the analysis window.

Create a feature table with time boundaries

A feature snapshot should represent what was known at one moment. PostgreSQL-style SQL:

WITH eligible_accounts AS (
  SELECT
    a.account_id,
    a.created_at,
    a.created_at + INTERVAL '21 days' AS score_at
  FROM accounts a
  WHERE a.is_internal = false
    AND a.deleted_at IS NULL
),
features AS (
  SELECT
    a.account_id,
    a.score_at,
    COUNT(DISTINCT CASE
      WHEN e.event_name = 'workflow_completed' THEN e.user_id
    END) AS members_completing_workflow,
    COUNT(DISTINCT CASE
      WHEN e.event_name = 'workflow_completed' THEN DATE(e.occurred_at)
    END) AS active_workflow_days,
    COUNT(*) FILTER (
      WHERE e.event_name = 'teammate_activated'
    ) AS activated_teammates,
    COUNT(*) FILTER (
      WHERE e.event_name = 'plan_limit_reached'
    ) AS limit_events,
    MAX(e.occurred_at) AS last_event_at
  FROM eligible_accounts a
  LEFT JOIN events e
    ON e.account_id = a.account_id
   AND e.occurred_at >= a.created_at
   AND e.occurred_at < a.score_at
  GROUP BY a.account_id, a.score_at
)
SELECT * FROM features;

The window must close before the label window opens. Keep event time separate from warehouse ingestion time so late events do not rewrite historical predictions without an audit trail.

Add data-quality fields: event coverage, identity confidence, late-event count, and schema version. A high score from incomplete telemetry should not create a sales task.

Start with an explainable rules model

Use rules you can defend from product knowledge and historical examples:

SELECT
  account_id,
  score_at,
  (
    CASE WHEN members_completing_workflow >= 2 THEN 2 ELSE 0 END +
    CASE WHEN active_workflow_days >= 3 THEN 2 ELSE 0 END +
    CASE WHEN activated_teammates >= 1 THEN 1 ELSE 0 END +
    CASE WHEN limit_events >= 1 THEN 1 ELSE 0 END
  ) AS evidence_points,
  ARRAY_REMOVE(ARRAY[
    CASE WHEN members_completing_workflow >= 2 THEN 'multi_member_value' END,
    CASE WHEN active_workflow_days >= 3 THEN 'repeated_core_workflow' END,
    CASE WHEN activated_teammates >= 1 THEN 'teammate_activated' END,
    CASE WHEN limit_events >= 1 THEN 'relevant_limit_reached' END
  ], NULL) AS reasons
FROM account_feature_snapshots;

The numbers are placeholders. Backtest them before use. Do not call six points “a 92% conversion probability.” It is a rule priority, not calibrated probability.

Start with a review queue rather than automatic outreach. Let sales mark:

• useful signal;
• wrong account or identity;
• real value but wrong timing;
• no commercial fit;
• already in process;
• product problem, not sales opportunity.

That feedback often improves definitions faster than adding more features.

Build the label carefully

Choose an outcome that matches the action. Paid conversion can be wrong if sales works on opportunity creation; a self-serve checkout could count as success even when outreach had no role.

For product-led sales, useful labels might include:

• sales-accepted opportunity within a fixed horizon;
• verified expansion opportunity;
• qualified meeting plus later pipeline acceptance;
• incremental paid conversion attributable to the intervention.

Store label time and source. Freeze outcomes only after the horizon closes. Exclude accounts already contacted before score_at when training a model for first outreach, or model the treatment history explicitly.

Class imbalance is normal. Report absolute counts with precision and recall; accuracy can look excellent when the model predicts “not qualified” for everyone.

Evaluate with a time split

Random train/test splits leak market and product conditions across time. Prefer:

1. train on older closed cohorts;
2. tune on a later cohort;
3. evaluate once on the newest untouched cohort;
4. repeat as a rolling backtest.

Compare at least three baselines:

• eligible accounts ranked by recent activity;
• transparent rules model;
• statistical model such as logistic regression or gradient boosting.

Evaluate:

• precision at the number of accounts sales can handle;
• recall of later successful accounts;
• calibration if the output claims probability;
• lift over the baseline ranking;
• performance by product, market, plan, account age, and acquisition source;
• stability across time;
• missing-data and identity-resolution slices.

Do not select a model only on area under a curve. The operating question is whether the top review queue is useful at real capacity.

Choose thresholds from capacity and error cost

A universal “hot at 75” threshold has no meaning. If sales can review 30 accounts weekly, inspect precision among the top 30 and expected value after contact cost. If an action is fully in-product, capacity is different but user experience still has a cost.

Use hysteresis to prevent flapping:

• enter the queue only above an entry threshold;
• leave only below a lower exit threshold or after an expiry;
• store the reasons that changed;
• suppress duplicate tasks for an open opportunity;
• make stale scores visibly expire.

Thresholds may change when capacity changes. The underlying calibrated score should not be rewritten merely to fill a queue.

Keep the production pipeline observable

Product events
  → validated event store
  → identity/account mapping
  → as-of feature snapshots
  → versioned scorer
  → eligibility and policy gate
  → review queue / in-product action
  → outcome and feedback log

Version the feature definition, model, rules, and threshold separately. For every action, retain:

• score and calculation time;
• model or rule version;
• top evidence reasons;
• eligibility decision;
• action created or suppressed;
• reviewer and outcome;
• source event references where practical.

Monitor missing features, event lag, score distribution, queue size, task delivery, identity conflicts, outcome delay, and performance drift. A live PLG dashboard should show the whole funnel, not just the count of “hot” leads.

Secrets for CRM or model providers belong in backend infrastructure. Do not call external APIs or expose CRM tokens from the client application. Use an authenticated server or edge function with least-privilege credentials, input validation, retries, idempotency, and PII-safe logs.

Use an LLM only for a grounded brief

Sales needs reasons, not a mysterious number. An LLM may summarize approved, minimal features after the score is calculated:

Create a factual review brief from the supplied account signals.
Use only these fields. Do not infer company strategy, budget, role, intent,
private identity, or use case. Do not suggest claims unsupported by evidence.

Return JSON:
{
  "observed_value": [],
  "commercial_signals": [],
  "product_blockers": [],
  "questions_for_review": [],
  "source_signal_ids": []
}

If evidence conflicts or is missing, say so. Do not recommend contacting the account.
That decision belongs to the policy gate and reviewer.

ACCOUNT SIGNALS:
{approved_aggregates}

Do not send raw prompts, document contents, emails, or sensitive product data unless the approved data boundary permits it. Observe latency, errors, cost, and unsupported-claim rate; the LLM observability guide covers the instrumentation pattern.

Test incremental value, not correlation

A model can predict conversion and still make outreach useless. High-scoring accounts may have converted anyway.

After a safe review period, run a controlled holdout among eligible accounts in the same score band:

• treatment receives the defined sales or in-product action;
• control receives business as usual;
• assignment occurs before the action;
• primary outcome and guardrails are declared in advance;
• contamination and rep overrides are logged;
• analysis follows intent to treat.

Measure incremental opportunity, conversion, revenue, unsubscribe or complaint rate, and user-experience guardrails as appropriate. The experimentation playbook explains sample sizing and stopping rules.

Privacy, direct-marketing, profiling, and sector rules vary by jurisdiction. Confirm that collection, scoring, enrichment, and outreach match notices, permissions, contracts, retention, and suppression requirements. Minimize PII and keep access auditable.

Recalibrate when the system changes

Do not recalibrate on a calendar just because “monthly” sounds disciplined. Trigger a review when:

• activation or packaging changes;
• acquisition mix or target market shifts;
• event definitions or identity mapping change;
• sales motion, capacity, or success label changes;
• score calibration or top-queue precision drifts;
• a material group receives systematically poor outcomes;
• too many tasks expire without review.

Retire features that no longer have a stable meaning. Keep old model versions so past decisions remain reproducible.

The shortest useful first version

1. Choose one account-level action and one success label.
2. Define eligibility, observation, and outcome windows.
3. Select two or three verified value/buying signals.
4. Create a weekly human review queue with reasons.
5. Record reviewer feedback and downstream outcomes.
6. Backtest only after enough outcome windows have closed.
7. Test whether acting on the score creates incremental value.

That is already a PQL system. A 100-point formula, LLM narrative, real-time stream, and ML model are optional. Traceable evidence and a better decision are not.