Why Event Sourcing Matters

The first time you click into a lead’s detail page and scroll down to the timeline, you’re looking at something most CRMs don’t actually give you: the history of how that lead got where it is, not just the current state.

That difference comes from a single design choice — every change to a lead is recorded as a permanent event, and the column the lead sits in is computed from those events. Most CRMs work the other way: the status column is the truth, and changes are silent updates that overwrite whatever was there before.

This page is the case for the version we ship.

The frustration this design is solving

A scenario any broker who has run a team for more than a year has lived through:

A deal collapses. You’re trying to figure out what happened, who had the lead at the time, whether anybody knew the buyer was wobbling, and what changed between “everything looks great” and “they walked.” You open your CRM. The status column says Lost. The notes field has three lines from your agent. There’s no record of the lead ever being in Under Contract. There’s no timestamp on when it moved to Lost. There’s no record of the prior agent who had this lead before the reassignment.

All of that was a silent UPDATE on a row in a database. The information existed at some point. Now it doesn’t.

The platform’s event-sourced lifecycle is the version of the same CRM where that information does not get destroyed.

What “silent UPDATE” actually loses

When a status column is the source of truth, every change rewrites the past:

You can answer today	You cannot answer tomorrow
”What state is this lead in right now?"	"What state was this lead in last Tuesday at 2pm?"
"Who is this lead currently assigned to?"	"Who had this lead before the reassignment three weeks ago, and when did it move?"
"Is this lead marked unsubscribed?"	"Was this lead unsubscribed in March, re-subscribed in April, and unsubscribed again in May?"
"Did this deal close?"	"How long was this deal in `Committed` before it executed, and was there a moment when it was `Committed → Qualified → Committed` because something fell through and came back?”

The right-hand column is what a broker actually needs to coach a team, resolve a dispute, or analyze a market shift. The standard “update the status column” architecture cannot answer any of it without a parallel notes discipline that nobody maintains for long.

What the event log gives you instead

Every change to a lead’s state, every flag set, every assignment, every reason for a demotion — they’re all rows in a permanent log, ordered by time, attributed to a named actor (the agent or Scribe, the system). Nothing is overwritten. The “current status” you see on the board is computed by replaying that log.

Concretely, that buys you four things you couldn’t have under the silent-UPDATE model:

1. Reassignment history without a separate tool

Right now, the platform’s reassignment story is one row in the log per ownership change, with the from-agent, the to-agent, the timestamp, and (when the change has a reason) why. You can scroll through a lead’s timeline and read: “Joe handed off to Ryan on April 14th because of the schedule conflict. Ryan held until May 2nd. Reassigned to Josh after Ryan went on PTO.”

In a silent-UPDATE CRM the assigned_agent_id column has one value — the current one. The history is either in a tribal-knowledge spreadsheet your team forgets to update, or it’s gone.

2. Deal-collapse analytics that are real, not vibes

The state machine refuses to demote a lead from COMMITTED → QUALIFIED without a reason code. Same with IN_CONTRACT → QUALIFIED. You can’t accidentally lose the why of a deal collapse; the system blocks the move until you record one.

This means a year from now, “how often do our deals fall apart at the buyer’s-agreement stage vs. after contract execution?” is a question that has a real answer. So is “did the deals that fell through last quarter share a financing-related reason, or were they spread across categories?” The reason codes are the input to those analyses.

A silent-UPDATE CRM gives you the same Lost value whether the deal collapsed because of inspection findings or because the buyer disappeared. Both look identical six months later. You can’t coach to a pattern you can’t see.

3. “Why is this lead in QUALIFIED?” has an answer

A lead in QUALIFIED could have arrived from:

CONTACTING → QUALIFIED (the normal forward path).
COMMITTED → QUALIFIED (deal collapsed before contract).
IN_CONTRACT → QUALIFIED (contract voided — financing fell through, inspection killed it, mutual release).
ARCHIVED → CONTACTING → QUALIFIED (a re-engaged dormant lead that re-qualified).

These four scenarios look identical in the status column — all four show QUALIFIED. They are not identical situations for an agent. The first is a healthy new pipeline addition; the third is a wounded recovery that needs different tactics. Reading the timeline tells you which.

For a broker reviewing a team’s pipeline, the value compounds: a QUALIFIED column full of “fresh from CONTACTING” leads is a healthy pipeline. A QUALIFIED column full of “demoted from COMMITTED last week” leads is a problem you need to act on. The board can’t tell you that. The timeline can.

4. Demotion tracking as a coaching tool

When a deal collapses, the demotion is a real event in the log with a reason code. Pull the count of deal_collapsed events per agent per quarter and you have a coaching artifact — not as a punishment, but as a conversation starter. “These three deals fell through. The reason codes are: financing, financing, inspection. Let’s talk about whether we’re qualifying buyers’ pre-approval strength deeply enough before recommending offers.”

A silent-UPDATE system gives you the per-agent close rate. It does not give you the structured why of the deals that didn’t close. The event log does.

What this design costs

The event-sourcing pattern is not free. Two real costs to be honest about:

Empty timelines for old leads. Leads that were in the platform before the lifecycle feature shipped (2026-05-16) don’t have an event history. Their timelines look sparse — sometimes empty — because the system has no record of what happened to them under the old model. A backfill that synthesizes events from the old status fields is on the roadmap; until it lands, expect leads older than mid-May 2026 to look quiet on the detail page even when they aren’t actually inactive.

More writes per lead. Every state change, flag set, and (eventually) reassignment writes a row. The cost is small — write volume on lifecycle events is far below what session-tracking already does — but it’s real. The trade is “more rows in a log table” against “permanent audit history of every operationally interesting change.” For the work you do, that trade pays off.

What it doesn’t change

Event sourcing is about how state is recorded. It doesn’t:

Change what agents see day-to-day. The board, the cards, the chips — the UI is the same whether the underlying model is event-sourced or status-column.
Slow down the system. The current state is cached as a normal column on the lead, computed lazily; you don’t pay a replay cost on every page load.
Mean nothing can ever be edited. Mistakes can be corrected — but the correction is itself an event, so the mistake and its correction both stay in the record. That’s the point.

The takeaway

A status column gives you the answer. An event log gives you the answer and the question, the timing, the actor, and the reason. Brokers who have run a team through one disputed deal collapse, one agent dispute, one client asking “why did your CRM say I was unsubscribed when I never asked to be?” — those brokers understand the difference.

The lifecycle feature is built so that, when you need the history, it’s there. Not as a notes field someone forgot to fill in. As a permanent, ordered, attributed record of what actually happened.

Lifecycle reference — the full conceptual model on one page
Interpret the lifecycle dashboard — what the board’s shape tells you about team health
State machine card — the eight states, the transitions, the reason codes
Glossary: Scribe and audit trail — the vocabulary this page rests on