Timothy Solomon | Builder, Thinker, Systems Architect

"What's the probability this lead will convert?"

This question seems natural—even scientific. We want to know our odds. We want to predict outcomes. We want to make data-driven decisions.

But it's the wrong question.

The right question is: "Have the qualifying conditions been met?"

This isn't semantic nitpicking. It's a fundamental shift in how qualification works. And getting it wrong is why your pipeline handoffs fail, your conversion rates are unpredictable, and your MQL definition is a source of endless conflict.

Predicates vs. Probabilities

Let's get precise about terms.

A probability is a number between 0 and 1 representing the likelihood of an outcome. "There's a 73% chance this lead converts."

A predicate is a logical statement that is either true or false. "This lead has requested a demo."

These are different types of things. A probability is continuous (any value from 0 to 1). A predicate is categorical (true or false, nothing in between).

Lead qualification is predicative, not probabilistic.

A lead either is or isn't qualified. The definition of "qualified" is a set of conditions—predicates—that must be satisfied. When they're satisfied, the lead is qualified. When they're not, it isn't. There's no "73% qualified."

This might seem pedantic until you consider how most organizations actually handle qualification.

The Score-Threshold Trap

Here's how it typically works:

Marketing builds a lead scoring model
The model assigns points for various attributes and behaviors
Marketing declares: "A lead is an MQL when their score exceeds 65"
Sales receives "MQLs" and complains they're garbage
Marketing raises the threshold to 70
Sales still complains
Cycle repeats

What's happening? Marketing is using a probability proxy (the score) to make a categorical decision (is this an MQL?). The score might loosely correlate with conversion probability, but that's not the same as defining qualification.

The threshold is arbitrary. Why 65? Why not 64? Why not 70? There's no principled answer because score thresholds don't define qualification—they approximate it, badly.

What Qualification Actually Means

Qualification is about meeting conditions, not exceeding thresholds.

An MQL (Marketing Qualified Lead) should be defined by predicates like:

is_MQL = (
    has_engaged_with_content = TRUE
    AND matches_target_persona = TRUE
    AND from_addressable_market = TRUE
    AND not_competitor = TRUE
    AND not_existing_customer = TRUE
)

Each clause is a boolean—it's either satisfied or it isn't. The lead is an MQL if and only if all clauses are TRUE.

This is unambiguous. There's no judgment call, no threshold-tuning, no "kinda sorta MQL." Either the conditions are met or they're not.

The State Machine Model

When you think of qualification predicatively, the pipeline becomes a state machine.

             engage           express_intent      validate_budget      deliver_proposal       sign
[Lead] ─────────────> [MQL] ───────────────> [SQL] ──────────────> [FTP] ─────────────> [RTP] ─────> [Closed]
           │                      │                    │                    │
           │   (missing           │   (missing         │   (missing         │   (declined/
           │    content           │    demo            │    budget          │    stalled)
           │    engagement)       │    request)        │    confirmation)   │
           v                      v                    v                    v
       [Lead]                 [MQL]                [SQL]                [FTP]
       (stays)               (stays)              (stays)              (stays)

Each state (Lead, MQL, SQL, FTP, RTP, Closed) is a position in the pipeline.

Each transition (engage → express_intent → validate_budget → etc.) requires specific conditions to be met.

A lead can't skip states. A lead can't be "partially" in a state. They're either in a state or they're not.

State Definitions

Lead: A contact exists in the system.

Entry condition: Record created
No qualification implied

MQL (Marketing Qualified Lead): Ready for sales engagement.

Entry condition: has_content_engagement AND matches_persona AND in_target_market
Meaning: Marketing believes this contact is worth sales attention

SQL (Sales Qualified Lead): Sales has accepted and validated.

Entry condition: has_expressed_intent AND sales_has_reviewed AND sales_accepts
Meaning: Sales agrees this is a real opportunity worth pursuing

FTP (First-Time Purchaser): Ready for proposal.

Entry condition: budget_confirmed AND timeline_defined AND decision_process_understood
Meaning: All preconditions for proposal are met

RTP (Ready To Purchase): Awaiting signature.

Entry condition: proposal_delivered AND proposal_accepted AND contract_pending
Meaning: Deal is in final stages

Closed: Deal complete.

Entry condition: contract_signed
Meaning: Revenue recognized

Why State Machines Work

The state machine model has several advantages:

Unambiguous handoffs. When a lead transitions from MQL to SQL, everyone knows exactly what that means—the SQL conditions have been verified.
Clear accountability. Marketing is responsible for the Lead→MQL transition. Sales is responsible for MQL→SQL. Each team owns their criteria.
Diagnostic clarity. If conversion rates drop at MQL→SQL, you know exactly where to look. Which SQL condition is failing?
No gaming. You can't inflate MQL numbers by adjusting a threshold. The conditions are explicit—either met or not.
Forecasting accuracy. Stage-based forecasting works because stages mean something consistent.

The Predicate Structure

Let's look more closely at how to structure qualification predicates.

Basic Structure

A qualification predicate has the form:

is_[STAGE] = CONDITION_1 AND CONDITION_2 AND ... AND CONDITION_N

Each condition is a boolean. The lead is in the stage if all conditions are TRUE.

Condition Types

Explicit conditions: Directly observable facts

has_requested_demo = TRUE
company_size > 100
role_is_decision_maker = TRUE

Derived conditions: Calculated from other data

engagement_score > minimum_threshold (Note: this is a threshold, but on a specific derived metric, not a composite score)
content_touches >= 3

Human-verified conditions: Require judgment

sales_accepts = TRUE
pain_point_validated = TRUE

The key is that each condition, however derived, evaluates to a boolean. The combination is conjunctive (AND)—all must be true.

Example: MQL Definition

A well-structured MQL definition might be:

is_MQL = (
    # Engagement requirement
    (content_downloads >= 2 OR webinar_attended = TRUE OR demo_requested = TRUE)

    # Fit requirement
    AND (persona_match IN ['CMO', 'VP Marketing', 'Marketing Director'])
    AND (company_employees >= 50)
    AND (industry IN target_industries)

    # Exclusion filters
    AND (is_competitor = FALSE)
    AND (is_existing_customer = FALSE)
    AND (email_is_generic = FALSE)  # no gmail, yahoo, etc.
)

Every clause is a predicate. The overall result is a boolean. A contact is MQL or they're not.

Why Probability-Based Qualification Fails

"But wait," you might say. "Probabilities are more nuanced. Why throw away that information?"

Fair question. Here's why probabilistic qualification doesn't work:

1. Probability is Not Actionable

A 62% conversion probability doesn't tell you what to do. Do you pursue it? Nurture it? Disqualify it? The probability alone doesn't map to an action.

Qualification is actionable by design. MQL means "ready for sales outreach." SQL means "accepted for active pursuit." The stage determines the action.

2. Probability is Unstable

Model-derived probabilities fluctuate based on model inputs, recalibrations, and data drift. A lead that was "65% likely" yesterday might be "58% likely" today without anything changing.

Predicates are stable. Once a condition is met, it stays met (unless explicitly invalidated). A lead who requested a demo has requested a demo—that's not subject to model drift.

3. Probability Creates False Precision

"72.3% likely to convert" sounds precise but probably isn't. The model has massive uncertainty. The extra decimal places are noise, not signal.

Predicates are honest about their precision. The lead either meets the criteria or doesn't. There's no fake precision.

4. Probability Obscures Process Failures

If conversion rates drop, what went wrong? With probabilistic scoring, it's hard to know. Maybe the model is off. Maybe lead quality changed. Maybe something else.

With predicative qualification, diagnosis is straightforward. Which condition started failing? When? Why?

5. Probability Allows Gaming

Score-based thresholds can be gamed. Marketing can "generate more MQLs" by adjusting the definition, inflating numbers without improving quality.

Predicates are harder to game. You can't redefine "has requested demo" without being obvious about it.

The Probability-Predicate Bridge

Now, I'm not saying probability has no role. It absolutely does—just not in qualification.

Use probability for:

Prioritization: Among MQLs, which should sales call first?
Resource allocation: How much should we invest in this segment?
Forecasting: What's our expected pipeline value?
Analytics: How is lead quality trending?

Use predicates for:

Stage transitions: When does a lead become MQL/SQL/etc.?
Process definition: What does it mean to be qualified?
Handoffs: When should marketing pass to sales?
Accountability: Who's responsible for what?

The bridge: Within a stage (defined by predicates), probability can prioritize. Among all SQLs (predicate-qualified), conversion probability helps decide who gets attention first.

Implementing Predicative Qualification

Here's how to transition from score-based to predicate-based qualification:

Step 1: Define Your Stages

What are the meaningful positions in your pipeline? Most B2B organizations need:

Lead (unqualified contact)
MQL (marketing qualified)
SQL (sales qualified/accepted)
Opportunity (validated deal)
Closed (won or lost)

Adjust for your business, but keep it minimal. More stages = more complexity.

Step 2: Define Transition Criteria

For each transition, specify the predicates that must be TRUE:

Lead → MQL:

Engagement requirement (specify exact criteria)
Fit requirement (specify persona/firmographic filters)
Exclusion filters (competitors, existing customers, etc.)

MQL → SQL:

Intent requirement (demo request, pricing inquiry, etc.)
Sales review (human approval)
Sales acceptance (explicitly accepted into pipeline)

SQL → Opportunity:

Budget validation
Timeline definition
Decision process identification
Champion identification

And so on. Each transition is a predicate.

Step 3: Implement Boolean Fields

Create explicit boolean fields for each condition:

has_content_engagement (boolean)
matches_target_persona (boolean)
has_expressed_intent (boolean)
sales_accepted (boolean)

Don't embed this logic in a score. Make it explicit.

Step 4: Build Automated Transition Logic

IF has_content_engagement = TRUE
   AND matches_target_persona = TRUE
   AND in_target_market = TRUE
THEN
   stage = 'MQL'

When conditions are met, transition happens. When conditions aren't met, it doesn't.

Step 5: Report on Conditions, Not Just Stages

Don't just report "200 MQLs this month." Report:

How many met all conditions?
Which condition was hardest to satisfy?
What's the distribution of condition satisfaction?

This diagnostic reporting reveals process health.

The Logic of Pipeline

At its core, this approach treats pipeline management as applied logic—the study of valid inference and correct reasoning.

A predicate is a logical statement. A qualification is a compound predicate (conjunction of conditions). A pipeline is a state machine governed by predicates.

This framing has philosophical weight. Logic is about truth values—statements are true or false. Qualification inherits this crispness. A lead is MQL or isn't. There's no fuzzy middle ground.

This might feel uncomfortably binary in a world that loves nuance. But the binarity is a feature, not a bug. At the moment of handoff, at the moment of action, you need a decision. "Probably MQL" isn't actionable. "Is MQL" is.

The nuance exists elsewhere—in scoring, in prioritization, in forecasting. Qualification is where nuance gets resolved into action.

Conclusion: From Prediction to Definition

The shift from probabilistic to predicative qualification is a shift from prediction to definition.

The old question: "What's the probability this lead converts?" The new question: "What must be true for this lead to be qualified?"

The old answer: A number (73%). The new answer: A logical conjunction (conditions A AND B AND C).

The old failure mode: Endless threshold adjustment, ambiguous handoffs, gaming. The new clarity: Explicit conditions, unambiguous stages, accountable transitions.

Lead qualification isn't about predicting the future. It's about defining the present—specifying exactly what "qualified" means, and applying that definition consistently.

When you get this right, everything downstream improves. Handoffs work. Forecasts stabilize. Accountability is clear. And your MQL definition stops being a source of conflict.

This essay is part of the CRM Framework series. For implementation in software, see Oblio. For strategic consulting, see Hire Timothy Solomon.

Related Reading:

Lead Qualification is a Predicate, Not a Probability