Timothy Solomon
CRM

The Three Confusions Killing Your Pipeline

Your CRM says 'Lead Score: 73.' What does that actually mean? Probably nothing actionable—because you're conflating three fundamentally different questions.

Your CRM says "Lead Score: 73."

What does that mean? Is this a good lead? Is it ready for sales? Should you act now or wait? The honest answer, in most organizations, is: nobody knows. That number—73—is trying to answer at least three different questions at once. And by trying to answer all of them, it answers none of them well.

This is the central pathology of modern pipeline management. Not a lack of data. Not poor tools. Not even bad process. The problem is conceptual conflation—the failure to distinguish between fundamentally different questions that require fundamentally different answers.

I call these the Three Confusions, and they're killing your pipeline.

The Three Confusions

Most CRM implementations commit the same categorical errors. They're so common that they've become invisible—the water we swim in. But once you see them, you can't unsee them. And once you fix them, everything changes.

Confusion #1: Scoring for Qualification

The error: Using a continuous score to determine categorical readiness.

Lead scoring produces a number—usually 0-100—based on firmographic fit, behavioral signals, and engagement patterns. This is a projection: you're taking multi-dimensional data about a contact and flattening it onto a single axis.

Projections always lose information. That's their nature. When you project a three-dimensional object onto a two-dimensional surface, you lose depth. When you project a complex set of attributes onto a single score, you lose nuance.

But the deeper problem isn't information loss—it's category error. Scoring tells you about fit, not stage. A lead with a score of 85 might be an excellent match for your product who isn't ready to buy for six months. A lead with a score of 45 might be a mediocre fit who needs to make a decision by Friday.

Qualification is categorical, not continuous. It's not "how much" but "whether." Have the qualifying conditions been met? Is this contact an MQL? Have they moved to SQL? These are boolean questions—yes or no—not matters of degree.

When you use scoring for qualification, you get absurdities: "Leads above 65 become MQLs." But what's magic about 65? Why not 64? Why not 70? The threshold is arbitrary because you're using the wrong tool for the job.

Confusion #2: Health for Scoring

The error: Treating temporal decay as if it were persona fit.

Lead health is fundamentally different from lead score. Health is about urgency—how fresh is this opportunity? When did they last engage? Is this lead alive or dying?

Health is a derivative: it changes over time based on the rate of engagement. A healthy lead is one with recent activity. An unhealthy lead is one going cold. This has nothing to do with fit—a perfect-fit lead can go cold, and a poor-fit lead can be highly active.

Yet most CRMs mash these together. A lead goes quiet for two weeks, their "score" drops, and suddenly they look like a worse fit than before. But they're not a worse fit—they're just less urgent. These require different responses:

  • Low fit → disqualify or nurture long-term
  • Low health → re-engage immediately before they're lost

When you confuse health for scoring, you waste time on cold leads that were never good fits, and you let hot leads cool down because their "score" looked fine.

Confusion #3: Qualification for Readiness

The error: Assuming that reaching a stage means being ready for that stage's actions.

Qualification tells you where a lead is in the pipeline. MQL, SQL, Opportunity, Closed-Won. These are states in a state machine—positions on a board.

Readiness tells you whether you can act on that position. An SQL might be qualified for sales engagement but not ready to take a call this week. An Opportunity might be legitimate but not ready to receive a proposal.

The confusion here creates premature action. Sales reps pounce on new SQLs who aren't actually prepared for conversations. Proposals go out to opportunities that haven't been properly scoped. The pipeline looks active, but the close rates crater.

Why This Matters

The cumulative effect of these confusions is a pipeline that no one trusts.

Marketing says: "We sent you 200 MQLs last quarter."

Sales says: "They were garbage. Only 10 were real."

Marketing says: "Your close rate is the problem."

Sales says: "Your lead quality is the problem."

Both are wrong. The problem is that "MQL" doesn't mean anything coherent. It's a score threshold that conflates fit with readiness with stage with urgency. No wonder the handoffs fail.

What a clean pipeline looks like:

Dimension Question Tool Type
Score How good is the fit? Projection Continuous (0-100)
Health How urgent is this? Derivative Continuous (decaying)
Qualification What stage are they in? State Machine Categorical (MQL/SQL/FTP/RTP)
Readiness Can we act now? Boolean Check Binary (yes/no)

These four dimensions are orthogonal. They don't reduce to each other. A lead can be:

  • High score, high health, MQL, ready → Perfect. Engage immediately.
  • High score, low health, SQL, not ready → Great fit going cold. Re-engage first.
  • Low score, high health, MQL, ready → Active but poor fit. Disqualify gracefully.
  • High score, high health, Opportunity, not ready → Good deal but needs more info before proposal.

When you separate these dimensions, your pipeline becomes legible. Everyone knows what they're looking at. Handoffs work because the criteria are clear. Forecasting improves because you're measuring real states, not composite fictions.

The Framework: Orthogonal Dimensions

The solution isn't more data or better tools. It's better ontology—the right categories, properly separated.

Dimension 1: Scoring (Fit)

Build your score from attributes that don't change moment-to-moment:

  • Firmographic data (company size, industry, revenue)
  • Technographic data (current tools, stack)
  • Persona match (role, seniority, department)
  • Historical patterns (companies like this convert at X rate)

Scoring should be relatively stable. If a lead was a good fit yesterday, they're probably a good fit today. Don't pollute your score with engagement signals—that's what health is for.

Dimension 2: Health (Urgency)

Health should follow a decay function. Think of it like radioactive decay: every day without engagement, health decreases. Every meaningful interaction resets or boosts the health.

dH/dt ≈ -H/τ + A(t)

Where:

  • H is health (0-100)
  • τ (tau) is the "contact lifespan" parameter—how quickly leads go cold in your business
  • A(t) is the activity injection from new engagements

This isn't just theory—you can implement this directly. Set a base decay rate. Define which activities inject how much health. Let the math run.

Dimension 3: Qualification (Stage)

Build a proper state machine. Not arbitrary score thresholds—actual states with defined transitions.

Lead → MQL → SQL → FTP → RTP → Closed

Each transition has criteria—boolean conditions that must be true:

  • Lead → MQL: Has engaged with content AND fits persona criteria
  • MQL → SQL: Has expressed intent (demo request, pricing inquiry, etc.)
  • SQL → FTP: Has budget authority AND timeline defined
  • FTP → RTP: Proposal delivered AND decision process confirmed
  • RTP → Closed: Contract signed

These criteria are predicates, not scores. "Has budget authority" is yes or no. "Decision timeline defined" is yes or no. No arbitrary thresholds.

Dimension 4: Readiness (Actionability)

Separate from stage. A lead can be in the right stage but not ready for action:

  • Just returned from vacation (not ready)
  • In the middle of another major initiative (not ready)
  • Explicitly said "call me in two weeks" (not ready until then)
  • Has all information and awaiting next step (ready)

Readiness is often tacit knowledge that lives in sales reps' heads. Make it explicit. Create a readiness field. Track it.

What To Do

If you're recognizing your organization in these confusions, here's how to start untangling them:

Step 1: Audit Your Current State

Map your existing "lead score" to these four dimensions. What's actually in there? You'll likely find a mix of:

  • Fit attributes (good—belongs in score)
  • Engagement signals (should move to health)
  • Stage indicators (should be separate qualification field)
  • Time-based factors (part of health, not score)

Step 2: Separate the Dimensions

Create distinct fields:

  • lead_score (fit only, relatively stable)
  • lead_health (urgency, time-decaying)
  • qualification_stage (categorical state machine)
  • readiness (boolean or short list)

Step 3: Redefine Your Transitions

Replace score thresholds with boolean criteria. "MQL when score > 65" becomes "MQL when (engaged_with_content AND persona_match)."

Step 4: Train Your Teams

The hardest part isn't technical—it's conceptual. Your teams have been thinking in conflated terms for years. Give them the vocabulary and framework to think clearly.

Step 5: Update Your Reporting

Old report: "MQLs generated this month" New report: "Contacts reaching MQL status, by health band and score tier"

The old report is a single number hiding everything. The new report shows you where to focus.


The Deeper Picture

This framework isn't just about pipeline management—it's about ontology, the study of what kinds of things exist and how they relate.

Most business problems aren't technical problems. They're problems of categorization. We create concepts ("MQL"), treat them as real things, and then wonder why reality doesn't conform to our reports. The map isn't the territory, but we forget that and optimize the map.

The Three Confusions are ontological errors. They treat different kinds of things as the same kind of thing. Score (a projection), health (a derivative), and qualification (a predicate) are not the same type of object. They live in different mathematical spaces. They answer different questions.

When you fix the ontology, the technology follows. When you get the concepts right, the implementation becomes obvious. This is why I focus on framework before features—because the framework determines what features are even possible.


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

Related Reading: