Timothy Solomon
Philosophy

CRM Ontology: Why Naming Matters

Before you can fix your pipeline, you need to fix your categories. The names you give things determine what questions you can ask, what actions you can take, and what problems you can even see.

Every CRM implementation begins with a question that most teams skip entirely: What kinds of things are we tracking?

Not "which fields should we have." Not "what workflows do we need." But something more fundamental: what categories of existence does our pipeline contain? What are the basic types of objects in our universe?

This is ontology—the branch of philosophy concerned with what exists and how it relates. It sounds abstract, but it's the most practical thing you'll ever think about. Because the categories you create determine everything downstream:

  • What questions you can ask
  • What reports you can generate
  • What actions you can automate
  • What problems you can even see

Get the ontology wrong, and no amount of engineering can save you. Get it right, and everything else becomes straightforward.

The Naming Problem

Consider a typical CRM. It contains objects called "Leads" and "Contacts" and "Accounts" and "Opportunities." What do these words mean?

In Salesforce's traditional model:

  • A Lead is an unqualified record—someone you're not sure about yet
  • A Contact is a qualified person attached to an Account
  • An Account is a company
  • An Opportunity is a potential deal

Simple enough. But look closer and the cracks appear.

When a Lead "converts," it becomes a Contact. But what changed in reality? The person is the same person. The company is the same company. Nothing in the world changed—only the CRM's categorization.

This conversion isn't capturing a real-world transition. It's an artifact of a database design decision made decades ago, when leads were kept in a separate table to reduce storage costs. The "conversion" is a data migration, not a business event.

Yet entire businesses are built around "Lead to Contact conversion rates"—a metric that measures database operations, not sales success.

Ontology as Infrastructure

The categories you create become infrastructure. Like roads or plumbing, they enable and constrain what's possible.

Consider the category "MQL" (Marketing Qualified Lead). Most organizations define it something like: "A lead with a score above 65."

This definition creates an infrastructure that enables certain things:

  • Counting MQLs (easy—just query for score > 65)
  • Tracking MQL volume over time (easy)
  • Setting MQL quotas (easy)

But it constrains other things:

  • Understanding why leads qualified (hard—score is opaque)
  • Diagnosing qualification failures (hard—which factor failed?)
  • Aligning marketing and sales on quality (impossible—65 is arbitrary)

A different definition—"A lead who has engaged with content AND matches a target persona"—creates different infrastructure. Now you can:

  • See exactly which conditions were met
  • Diagnose which conditions fail most often
  • Have meaningful conversations about what "qualified" means

The ontology determines the infrastructure. The infrastructure determines the possibilities.

Three Ontological Errors

After working with hundreds of pipeline implementations, I've identified three categories of ontological error that appear again and again.

Error 1: Treating Derived Quantities as Primitive

A primitive is a basic, irreducible category. A derived quantity is calculated from primitives.

"Lead Score" is often treated as primitive—as if it were a direct measurement of something in the world. But lead score is derived. It's calculated from other attributes: firmographic data, behavioral signals, engagement patterns.

When you treat derived quantities as primitive, you lose the ability to understand their components. You end up asking "why is this lead score 73?" without being able to answer. The derivation is hidden.

Proper ontology distinguishes:

  • Primitives: Engagement events, firmographic attributes, explicit signals
  • Derived quantities: Scores, aggregates, indices

Both are useful. But they're different types of things.

Error 2: Conflating Temporal and Structural

Some properties are structural—they describe what something is. Company size, industry, persona.

Other properties are temporal—they describe where something is in time. Last activity date, time in stage, decay rate.

Most CRMs mash these together. Lead score often includes both structural factors (persona fit) and temporal factors (recent engagement). This conflation obscures urgency.

A lead might have:

  • High structural fit (perfect persona, ideal company)
  • Low temporal urgency (no activity in 30 days)

When these are combined into one score, you can't distinguish "great fit going cold" from "mediocre fit staying warm." But these require completely different responses.

Proper ontology maintains the distinction:

  • Score: Structural fit (relatively stable)
  • Health: Temporal urgency (constantly changing)

Error 3: Category Boundary Confusion

This is the deepest error. It occurs when you're uncertain what category something belongs to, but proceed anyway.

"Is this an MQL or not?"

If you have to ask, your categories aren't crisp. The boundaries are blurry. And blurry boundaries create problems:

  • Inconsistent classification (same lead, different outcomes)
  • Gaming (manipulate data to cross boundaries)
  • Conflict (marketing says MQL, sales says garbage)

Clear categories have necessary and sufficient conditions. If X satisfies conditions A, B, and C, then X is in category Y. Full stop.

When conditions are clear, the question "is this an MQL?" has a definite answer. When conditions are vague ("leads that seem ready"), the question has no definite answer.

The Map and the Territory

There's a famous aphorism in philosophy: "The map is not the territory."

Your CRM is a map. Reality is the territory. The map represents the territory but isn't identical to it.

This matters because maps can be wrong. They can have categories that don't correspond to real distinctions. They can lack categories for real distinctions that exist.

Map with missing categories: Your CRM doesn't distinguish between "no contact info" and "bad contact info." Both show as "incomplete record." But they require different actions: finding info vs. correcting info.

Map with false categories: Your CRM treats "Demo Requested" and "Pricing Requested" as identical "High Intent" signals. But they might indicate very different things: one is exploration, one is evaluation.

The goal isn't a perfect map—that's impossible. The goal is a useful map: one where the categories correspond to meaningful distinctions and the relationships support actionable decisions.

Building Better Ontology

Here's how to think about constructing better CRM ontology.

Start with Questions, Not Objects

Don't begin by asking "what objects should exist?" Begin by asking "what questions do we need to answer?"

Questions determine necessary distinctions. If you need to ask "is this lead ready for sales?", you need categories that can answer that question. If you need to ask "is this lead going cold?", you need temporal categories.

Common questions and their ontological requirements:

Question Required Distinction
Is this lead a good fit? Structural attributes (persona, firmographic)
Is this lead ready for sales? Qualification predicates (intent signals)
Should we act now or wait? Temporal dimension (health, decay)
What's the expected value? Probability/scoring dimension
Who owns this lead? Assignment and routing categories
What happened and when? Event/activity tracking

Define Categories by Conditions, Not Examples

Bad definition: "An MQL is a lead like the ones that converted last quarter." Good definition: "An MQL is a lead where (condition A) AND (condition B) AND (condition C)."

Examples are useful for illustration. But categories need crisp boundaries. That requires explicit conditions.

Separate Observation from Inference

Some facts are observed directly:

  • Lead visited pricing page (tracked event)
  • Lead's company has 500 employees (firmographic data)
  • Lead requested demo (explicit action)

Other facts are inferred:

  • Lead is "in-market" (inferred from behavior)
  • Lead is "a good fit" (inferred from profile)
  • Lead is "ready to buy" (inferred from signals)

Both are valuable. But they should be tracked differently. Observations go in one place (events, attributes). Inferences go in another (scores, classifications).

Mixing them causes problems. "Demo requested" (observation) and "high intent" (inference) might seem equivalent, but the observation is certain while the inference is probabilistic.

Build for Compositionality

Good ontology is compositional: complex categories are built from simpler ones.

is_MQL = has_engagement AND has_fit AND not_excluded
has_engagement = (content_downloads >= 2) OR (webinar_attended) OR (demo_requested)
has_fit = (persona_match) AND (company_in_range) AND (industry_in_target)
not_excluded = NOT(is_competitor) AND NOT(is_current_customer)

Each piece is independently defined. The whole is assembled from parts. This supports:

  • Understanding (you can trace any decision to its components)
  • Debugging (you can identify which component failed)
  • Evolution (you can modify pieces without breaking the whole)

Maintain Orthogonality

Orthogonal categories are independent—they don't overlap or interfere.

Score, health, qualification, and readiness are orthogonal:

  • Knowing someone's score tells you nothing about their health
  • Knowing their qualification stage tells you nothing about their score
  • Each dimension is independent

Non-orthogonal categories create confusion:

  • If "lead score" includes both fit AND engagement, you can't separate structural from behavioral
  • If "MQL" means both "marketing generated" AND "ready for sales," you can't distinguish source from readiness

When categories are orthogonal, combinations become meaningful. A lead can be high-score/low-health (great fit, going cold) or low-score/high-health (poor fit, very engaged). These combinations support nuanced action.

The Objects of CRM

Given all this, what should the core objects of a CRM actually be?

Here's a framework:

Entity Layer (What exists)

Contact: A person. Has attributes (name, email, role). Persists over time.

Organization: A company or entity. Has attributes (size, industry). Contains contacts.

Product: Something you sell. Has attributes (price, features). Can be associated with opportunities.

State Layer (Where things are)

Qualification Stage: Position in the pipeline (Lead, MQL, SQL, Opportunity, Closed). Categorical. Governed by predicates.

Health Level: Temporal urgency (high, medium, low). Continuous, decaying. Based on recent activity.

Readiness Status: Actionability (ready, blocked, waiting). Boolean per action type.

Measurement Layer (What we assess)

Fit Score: Structural match to ideal profile. Relatively stable. Projection of multi-dimensional attributes.

Intent Signals: Evidence of buying intention. Probabilistic, updateable. Based on behaviors and explicit signals.

Opportunity Value: Expected revenue. Probabilistic. Based on stage, product, and historical conversion.

Event Layer (What happened)

Activities: Things that occurred. Timestamped. Include engagement events, communications, meetings, changes.

Transitions: Stage changes. Timestamped. Include condition snapshots at transition time.

This structure separates concerns. Entities persist. States change. Measurements are computed. Events are recorded. Each layer has its own logic.

Ontology in Practice

Let me make this concrete with an example.

Before (typical CRM):

Contact:
  - lead_score: 73
  - stage: "MQL"
  - last_activity: "2026-01-01"
  - notes: "Seemed interested in demo"

What can you answer?

  • Is this a good lead? Sort of (73 is above average?)
  • Is this lead ready? Unclear (what does MQL mean?)
  • Is this lead urgent? Unclear (how stale is "2026-01-01"?)
  • What should we do? Unclear (no actionable information)

After (ontological CRM):

Contact:
  Entity:
    - name: "Jane Smith"
    - organization: "Acme Corp"
    - role: "VP Marketing"

  Structural Fit:
    - fit_score: 85
    - persona_match: TRUE
    - company_in_range: TRUE
    - industry_match: TRUE

  Temporal State:
    - health_score: 35 (decayed from 80 over 3 weeks)
    - days_since_activity: 21
    - decay_trajectory: "declining"

  Qualification:
    - stage: "MQL"
    - mql_since: "2025-12-15"
    - conditions_met: [engagement, persona_match, not_excluded]
    - conditions_pending: [intent_expression]

  Readiness:
    - ready_for_sales_outreach: FALSE
    - ready_for_nurture: TRUE
    - blocking_factors: ["no_recent_engagement", "no_intent_signal"]

  Activity History:
    - [2025-12-10] Downloaded whitepaper
    - [2025-12-15] Attended webinar → triggered MQL
    - [2025-12-18] Visited pricing page
    - [no activity since]

Now you can answer:

  • Is this a good lead? Yes (85 fit score, all structural conditions met)
  • Is this lead ready? No (health is low, no intent signal)
  • Is this lead urgent? Yes! (great fit going cold—needs re-engagement NOW)
  • What should we do? Re-engage immediately before we lose a high-fit prospect

The ontology makes the situation legible. The action becomes obvious.

Why This Matters

I've spent this essay on something that might seem academic. Categories. Naming. Ontology.

But here's the thing: every failed pipeline implementation I've seen failed because of bad ontology.

  • Marketing and sales can't agree on MQL definition? Ontology problem.
  • Leads slip through the cracks? Ontology problem (missing states).
  • Reports don't match reality? Ontology problem (categories don't map to business).
  • Automations do the wrong thing? Ontology problem (conditions aren't crisp).
  • Team can't diagnose pipeline issues? Ontology problem (derived quantities hide components).

The technology is easy. The data is available. The hard part—the part that determines success—is getting the categories right.

And categories are choices. They're not given by nature. You decide what distinctions to maintain, what to collapse, what to ignore. Those choices have consequences.

Choose well.

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

Related Reading: