The CRM Framework
Most pipelines fail not from lack of data, but from lack of clarity. They conflate concepts that should be separate, measure derived quantities as if they were primitives, and use continuous scores to answer categorical questions.
This framework fixes that.
The Three Confusions
Every broken pipeline commits the same three errors. Recognizing them is the first step to fixing them.
Confusion 1: Scoring for Qualification
The error: Using a continuous score (0-100) to determine categorical readiness.
Lead scores measure fit—how well a contact matches your ideal customer profile. Qualification measures stage—whether specific conditions have been met to advance in the pipeline.
These are different types of questions:
- Score asks "how good?" → answered with a number
- Qualification asks "whether ready?" → answered with yes/no
Using scores for qualification creates arbitrary thresholds ("MQL when score > 65"), gaming opportunities, and endless marketing/sales conflict.
The fix: Define qualification as boolean predicates. A lead is MQL when conditions A AND B AND C are met—not when an arbitrary score threshold is crossed.
Confusion 2: Health for Scoring
The error: Treating temporal decay as if it were persona fit.
Lead health is about urgency—how recently has this lead engaged? Is their interest growing or fading? Health changes constantly, decaying without activity.
Lead score is about fit—does this lead match our ideal profile? Fit is relatively stable; a good-fit lead is still good-fit if they go quiet.
When you mash these into one number, you can't distinguish:
- High fit, low health → Great lead going cold (re-engage NOW)
- Low fit, high health → Poor lead very active (disqualify gracefully)
The fix: Track health as a separate dimension with explicit decay modeling. Health follows a decay function: it decreases daily without activity, and engagement injects new health.
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. Readiness tells you whether you can act on that position.
An SQL might be qualified for sales engagement but not ready for a call this week. An Opportunity might be legitimate but not ready to receive a proposal.
The fix: Track readiness separately from stage. A lead can be SQL (stage) but blocked (readiness). Surface blocking factors explicitly so sales knows what to address.
The Four Dimensions
Once you've untangled the confusions, clean pipeline management operates on four orthogonal dimensions:
| Dimension | Question | Type | Changes |
|---|---|---|---|
| Score | How good is the fit? | Continuous (0-100) | Slowly, based on profile data |
| Health | How urgent is this? | Continuous, decaying | Constantly, based on engagement |
| Stage | Where are they in the process? | Categorical (MQL/SQL/etc.) | Discretely, when predicates are satisfied |
| Readiness | Can we act now? | Boolean per action type | Based on explicit blockers |
These dimensions don't reduce to each other. A lead can be high-score/low-health (great fit going cold) or low-score/high-health (poor fit very active). Each combination requires different action.
The Pipeline State Machine
Pipeline stages should form a proper state machine with explicit transitions:
[Lead] → [MQL] → [SQL] → [FTP] → [RTP] → [Closed]
Each transition has predicates—boolean conditions that must be TRUE:
Lead → MQL:
- has_content_engagement = TRUE
- matches_target_persona = TRUE
- in_addressable_market = TRUE
- is_not_excluded = TRUE
MQL → SQL:
- has_expressed_intent = TRUE
- sales_has_reviewed = TRUE
- sales_accepts = TRUE
SQL → FTP (First-Time Purchaser):
- budget_confirmed = TRUE
- timeline_defined = TRUE
- decision_process_identified = TRUE
FTP → RTP (Ready To Purchase):
- proposal_delivered = TRUE
- proposal_accepted = TRUE
- contract_pending = TRUE
RTP → Closed:
- contract_signed = TRUE
Each transition is unambiguous. No arbitrary thresholds. No judgment calls about "how MQL" something is.
The Mathematics
For those interested in the formal structure:
Scoring is Projection
A lead score projects multi-dimensional attribute space onto a single axis. Information is necessarily lost. This is useful for prioritization but insufficient for qualification.
Mathematical form: S = w₁a₁ + w₂a₂ + ... + wₙaₙ (where a are attributes, w are weights)
Deep dive: Lead Scoring is a Projection →
Health is a Derivative
Lead health follows exponential decay with activity injection. It models how quickly leads "go cold" without engagement.
Mathematical form: dH/dt = -H/τ + A(t) (where τ is time constant, A(t) is activity function)
Deep dive: Lead Health is a Derivative →
Qualification is a Predicate
Qualification is a logical conjunction of boolean conditions. A lead is qualified when all conditions are TRUE.
Mathematical form: is_MQL = P₁ ∧ P₂ ∧ ... ∧ Pₙ (where P are boolean predicates)
Deep dive: Lead Qualification is a Predicate →
Attribution is Observer-Dependent
Attribution doesn't have a single "correct" answer. Different models (first-touch, last-touch, multi-touch) encode different assumptions and serve different decisions.
Deep dive: Attribution as Observer Physics →
Implementation
This framework can be implemented in any modern CRM, but it requires intentional design:
1. Separate Your Dimensions
Create distinct fields for:
fit_score(structural match, stable)health_score(temporal urgency, decaying)stage(categorical position)readiness_status(boolean per action type)
2. Define Explicit Predicates
Document exactly what conditions must be TRUE for each stage transition. Make them visible to all teams.
3. Build Health Decay
Implement a decay function that runs on a schedule (daily or hourly). Define which activities inject how much health.
4. Track Blocking Factors
When readiness is FALSE, capture why. "Blocked: waiting for budget approval" is actionable. "Not ready" is not.
5. Report on Dimensions
Don't just report "200 MQLs." Report "200 MQLs: 85 high-health, 60 medium-health, 55 low-health." The distribution tells you about urgency and opportunity.
About
This framework is the result of 15+ years building, auditing, and rebuilding pipeline systems across B2B and B2C organizations. It emerged from a simple observation: most pipeline failures aren't technical failures. They're conceptual failures—conflated categories, misapplied tools, confusion about what questions can even be asked.
Get the ontology right, and everything else follows.
— Timothy Solomon