Read the Timeline

The timeline on a lead’s detail page is the canonical history of that lead. The current column on the board, the active flag chips, the temperature score — all of those are projections of the timeline. When the rest of the UI surprises you, the timeline answers the question.

This page walks you through what each row is telling you.

Anatomy of a timeline row

The timeline runs oldest first: the lead’s arrival is at the top, the latest action at the bottom. Every row has some of these parts:

Part	What it tells you
Time	When the event happened (shown in your local time).
Event	What was done, labelled the way the button was: Contact attempted, Motivation confirmed, Deal collapsed, and so on.
Stage change	`<from> → <to>`, shown only when the stage moved.
Channel	A chip (Call, Email, Text, In person, Other) on contact attempts and responses.
Reason	The reason code in monospace, on setbacks and bogus marks.
Note	Whatever was typed in the dialog, as a quoted block.
Actor	Who did it: your or a teammate’s name, or `Scribe` with a feather for system actions.
Markers	An amber entered later marker on backdated rows; a dashed reconstructed marker on rows synthesized by the backfill.

The actor is the first thing to look at. It tells you whether something was an explicit human action or an automatic side-effect. The markers are the second: they tell you how much to trust the timestamp.

Two kinds of actor: you, and Scribe

You (or another agent, by name) appear as the actor on anything done by hand:

Logged a contact attempt or a lead’s response.
Moved a lead to a different column with one of the Next step buttons.
Archived a lead, or marked one as bogus.
Reassigned the lead to a different agent from the Assignment & Notes card.

Scribe appears as the actor on anything the system did automatically:

Lead creation from a contact form submission (Lead received) and the routing that picked the first agent (Agent assigned).
Agent reassigned when re-engaging an archived lead re-routed it because the original agent could no longer receive leads.
Reconstructed rows synthesized from a lead’s legacy status when the lifecycle feature was backfilled.

Your own actions are attributed to you even when they move the stage: logging a contact attempt writes one row, Contact attempted with New → Contacting, under your name. Scribe does not write a second row for the stage change.

If you can’t remember whether you moved a lead or the system did, the timeline answers it. The actor column is unambiguous.

See What Scribe does for the longer version of the actor model.

Event types you’ll see

Stage changes

The most common row. The event label is the action that was taken, and the stage change sits beside it:

You — Contact attempted   New → Contacting   [Call]
"Left voicemail, mentioned the inquiry on the West End property."

The label matches the button that fired it: Log contact attempt writes Contact attempted, Confirm motivation writes Motivation confirmed, Closing complete writes Closing complete. See how you fire these on the state machine card for the full mapping.

Setbacks with reason codes

When a lead moves backwards (Committed → Qualified after a buyer’s agreement falls apart, In Contract → Qualified after a contract is voided, New → Trashed for bad data) the row carries the reason code in monospace:

You — Deal collapsed   Committed → Qualified
financing_fell_through
"Buyer changed jobs, lost pre-approval"

The reason code is one of a fixed list picked from the dialog’s dropdown; the quoted note is what you typed. Both stay on the record. See why reverse transitions need reasons.

Re-entry

You — Lead re-engaged   Archived → Contacting
"Saw new activity on West End listings, reaching out."

Scribe — Agent reassigned

The first row is the Re-engage button. The second appears only when the original agent could no longer receive leads (disabled, inactive, or no longer a lead recipient). The lead was re-routed through the brokerage’s routing mode, and Scribe, not a person, is the actor.

Lead responded (no stage change)

You — Lead responded   [Text]
"Replied asking about weekend availability."

The one action that leaves the stage where it is. It records that the conversation became two-way, and there is no from → to on the row because nothing moved.

Assignment rows

Scribe — Agent assigned
Joe Kroetch — Agent reassigned

Agent assigned is written while the lead is still NEW, whether routing picked the first owner or a broker did. Agent reassigned is written for any later change from the Assignment & Notes card, attributed to the person who made it, or to Scribe when re-engagement re-routed the lead automatically.

Markers

Two markers can appear on a row. Both mean “read the timestamp carefully”:

Marker	Looks like	Meaning
entered later	Amber	The row was backdated with This happened earlier…. It is shown at the time the thing happened. Hover the marker to see when it was actually typed in.
reconstructed	Dashed	The row was synthesized from the lead’s legacy status when the lifecycle feature was backfilled. Nobody witnessed it as it happened, and the timestamp is approximate.

A row with neither marker was recorded live by the actor shown.

Reading the timeline backwards from a problem

The timeline is most useful when something looks wrong. A few common patterns:

“Why is this lead in CONTACTING and not QUALIFIED?”

Scroll the timeline. Look for a motivation_confirmed trigger. If you don’t see one, the lead hasn’t been explicitly qualified — even if the conversation feels like they’re qualified, the state machine doesn’t infer it from notes. Add an explicit “qualified” action.

”Why did this Hot lead suddenly drop to Cold?”

Look at the most recent temperature events. If the score dropped without new behavioral signals, it decayed on its own — the score lowers over time when there’s no recent activity. If new signals are present and the score still dropped, something’s behaving unexpectedly; flag it.

”Why is this lead in ARCHIVED when I was working it last week?”

Look for the most recent Archived: no response or Archived: no progress row. Today those are buttons, not scheduled timeouts, so the row carries the name of the person who clicked it. If you were “working it last week” without logging anything, that person had no way to know.

The fix isn’t only re-engaging the lead. It’s logging contact attempts and responses as they happen, so the timeline shows the work and nobody archives over it.

”Did I already reassign this lead, or am I about to?”

Look for an Agent reassigned row. Every change made from the Assignment & Notes card writes one, attributed to the person who made it. A reassignment attributed to Scribe means the lead was re-routed automatically when it was re-engaged from ARCHIVED. Leads that changed hands before reassignment rows were recorded have no row; for those, ask the previous agent directly.

What the timeline does not contain

Outbound emails sent automatically — those live in the email-system logs, not the lifecycle timeline.
Property views and favorites — these are session events that feed the temperature scorer. They show up as the temperature badge, not as rows.
Search queries — same as above. They contribute to temperature, they don’t get rows.
Communication preference switches — Do Not Contact, No Call, and the rest keep their own set and clear history with who flipped them and when. They are shown in the Lifecycle card, not on the timeline.
Internal notes — the free-text field in the Assignment & Notes card is a scratchpad, not an event.

If you need the underlying behavioral detail for a lead, the session activity view shows it. The lifecycle timeline shows what happened to the lead: stage changes, contact attempts and responses, assignments, and the notes typed with them.

What Scribe does — why the system has a name and what it’s tracking
Why reverse transitions need reasons — what the reason code on a reverse move is for
State machine card — the transition table the timeline rows correspond to