Why State and Temperature Are Separate

The pipeline tracks two things about every lead, separately:

State — where they are in the buying process. NEW, CONTACTING, QUALIFIED, COMMITTED, IN_CONTRACT, CLOSED, ARCHIVED, TRASHED.
Temperature — how engaged they are right now. Cold, Warm, Hot, computed from behavioral signals.

The first instinct for anyone coming from a category-based CRM (BoomTown’s Hot / Watch / Nurture, kvCORE’s tiers, Top Producer’s stars) is to ask why these aren’t one thing. They look like they describe the same fact about the lead — and most lead-management tools have shipped them as one column.

They aren’t the same fact. And shipping them as one column degrades both signals.

State and temperature answer different questions

Question	Axis that answers it
”Where is this lead in my pipeline?”	State.
”Should I prioritize this lead today?”	Temperature.
”What’s my next action with this lead?”	State and temperature together.
”How do I forecast revenue this quarter?”	State (which deals are close to IN_CONTRACT).
”Which leads have gone quiet?”	Temperature drop, regardless of state.
”Why is this lead in QUALIFIED?”	Timeline. (Neither state nor temperature alone tells you the cause.)

State is categorical and discrete — a lead is in exactly one column. It changes via explicit events: a logged outreach, a signed buyer’s agreement, a closing. State changes are agent actions or strict timeouts.

Temperature is continuous and decaying — a numeric score that drifts up and down as the lead does or doesn’t interact with the platform. Nobody “sets” a lead to Hot; the system observes engagement and computes it.

The two axes change for different reasons, at different cadences, by different actors.

A worked example: same state, different temperature

Two leads are both in QUALIFIED. Both have buyer pre-approval. Both are working with your brokerage.

Marcus Williams is Hot. He logged in three times this week, saved four new favorites, requested a Saturday tour, and replied to your last text within an hour. His temperature score sits around 92.

A cold qualified lead — call them Lead B — is also in QUALIFIED. Pre-approved a month ago, made it to two showings, then stopped opening your emails. Last session 18 days ago, no favorites added, no replies. Temperature is around 14.

A single “lead score” would have to weigh state and behavior together. In practice it produces one of two bad outcomes:

State dominates. Marcus and Lead B both look “qualified-good.” You can’t tell from the score that Lead B is fading. You only find out when you call and discover they’ve already started touring with someone else.
Temperature dominates. Marcus shows as “hot,” Lead B shows as “warm-going-cold.” But the score doesn’t tell you that Lead B is pre-approved; another lead with no pre-approval but lots of browsing activity scores higher. Your time goes to the wrong lead.

With both axes visible, the tactic for each is obvious and different:

Marcus (QUALIFIED + Hot) — keep the cadence. Get the next showing on the calendar. Prep offer scenarios.
Lead B (QUALIFIED + Cold) — pause the search-tier drips. Reach out personally with a question, not a property dump. Try a different channel than the one they stopped opening.

Both leads stay in the same column. Their right-next-actions are nothing alike. That’s the value of keeping the axes separate.

Why not just add “fading” as a state?

You could imagine adding states like QUALIFIED_FADING or QUALIFIED_HOT to bake engagement into the column structure. This is the obvious alternative — and it breaks down for three reasons.

State proliferation. Every existing state would need a hot / warm / cold variant. The 8-state pipeline becomes a 24-state pipeline. The transition table grows by 16×. The Kanban becomes unreadable.

Asynchronous change rates. State changes are discrete events (a contract signed, a deal closed). Temperature drifts continuously. Forcing temperature into the state column means re-firing state-transition events every time a score crosses a band — a noise stream that drowns out the events that actually matter.

Different actors, different audit trails. Agent-driven state changes need reason codes and accountability. Temperature recalculations are passive observations by the system. Mixing them collapses two distinct audit trails into one and makes the “why is this lead where it is?” question harder to answer, not easier.

The single-column model also makes filtering and reporting worse. “How many hot leads do I have right now?” becomes “give me the count of [LIST OF 8 STATE VARIANTS].” That’s a worse query than “give me leads where temperature ≥ 70.”

Querying on both axes

The separation makes common operational questions one-line filters:

Question	Filter
”Who needs me right now in QUALIFIED?“	state = QUALIFIED AND temperature ≥ 70
”Which CONTACTING leads should I escalate?“	state = CONTACTING AND temperature ≥ 30
”Who’s gone quiet on me at any stage?“	temperature < 30 AND state IN (CONTACTING, QUALIFIED, COMMITTED)
“Anyone in ARCHIVED warming back up?“	state = ARCHIVED AND temperature ≥ 30
”What’s stuck in IN_CONTRACT but cold?“	state = IN_CONTRACT AND temperature < 30 (probably a flag you want raised)

Each of those questions is incoherent on a single-column model.

The takeaway

State and temperature are two different facts. Treating them as one collapses real information. Keeping them separate lets the board do its primary job (show pipeline shape) while still surfacing urgency without distorting the columns.

When a workflow needs both — “high-priority leads in late pipeline” — you read both axes. The combination is more than either alone.

State machine card — the discrete-and-categorical axis
Temperature signals — the continuous-and-decaying axis
Your first day — both axes in action with the demo dataset