What Scribe Does

The timeline on a lead’s detail page has two kinds of actors. One is you (or another agent, by name) — the human who logged something. The other is Scribe — the system, doing whatever the system does automatically.

Scribe isn’t an agent. It’s not an AI assistant. It doesn’t have judgment. It’s a name attached to the events the system writes on its own initiative: lead creation from contact form submissions, the routing that picks the first agent, the re-routing when a re-engaged lead’s agent can no longer take leads, and the rows the backfill reconstructed from older status fields.

This page is the longer version of why the system gets a name at all.

What Scribe is

Scribe is the actor on a timeline row when the row was written automatically by the system. Specifically, you’ll see Scribe attributed on:

Event type	What Scribe is doing
Lead received from a contact form submission	A web form was submitted → Scribe wrote the first row.
Agent assigned at intake	Routing picked the first owner → Scribe wrote who.
Agent reassigned on re-engagement	An archived lead was re-engaged and its original agent could no longer receive leads → Scribe re-routed it through the brokerage’s routing mode.
Reconstructed rows	The lead predates the lifecycle feature → Scribe wrote the minimum history that explains its legacy status, marked with a dashed “reconstructed” marker.

Two things you might expect on that list are not there. Stage changes you make are attributed to you, even the ones your action implies: logging a contact attempt writes one row, Contact attempted with New → Contacting, under your name. And the timeout archives (CONTACTING → ARCHIVED after silence, QUALIFIED → ARCHIVED after no progress) are not scheduled yet; today they are the Archive buttons, so those rows carry the name of whoever clicked them.

What Scribe never does:

Make a judgment call. If a decision requires human discretion (qualifying a lead, reactivating an archived one, picking a reason for a deal collapse), the actor is you.
Write a free-text reason. Scribe writes structured event rows — type, from-state, to-state, trigger, payload. Narrative belongs to humans.
Take an action that a real person couldn’t undo. Anything Scribe writes can be reversed by an agent action; the timeline preserves both directions.

Why give the system a name

Most CRMs attribute automatic actions to “system” or leave the actor field blank. We picked a name — Scribe — and put it everywhere a human would have signed for an action. Three reasons.

Trust through visibility

A timeline row with no actor is uncomfortable. You read it and don’t know whether something happened on its own or whether you somehow caused it. The first question becomes “did I do that?” — and the answer requires you to remember whether you clicked something.

A timeline row attributed to Scribe is unambiguous: that wasn’t me. That was the system. The mental cost of reading the timeline drops because you don’t have to second-guess the source of every row.

Distinguishability in audit

When the broker or a compliance person reads a lead’s history, the actor column is the first cut they make. “Show me everything an agent did” filters by named actor. “Show me everything the system did” filters by Scribe. Both views are useful, and the second view is impossible if the system has no consistent name.

This matters more than it sounds. Without a system-actor name, the implicit query for “show me agent actions” is not blank — which means every state-transition side-effect (which is technically agent-attributable, because the agent’s logged action triggered it) ends up in the agent’s column too. The agent’s audit timeline becomes the union of “things I deliberately did” and “things that automatically happened because I did the first set of things.” That’s not what you want.

Scribe separates the two cleanly. Your name shows up for what you deliberately did. Scribe’s name shows up for what fell out of it. Anyone reviewing the timeline can read either layer without confusion.

A handle for the mental model

Real estate agents come from systems with very different attribution models — BoomTown attributes some auto-events to the “Smart-Drip” engine, kvCORE attributes them to “Robot” actions, Top Producer often shows nothing at all. Asking an agent to internalize “the system did this, but it’s tracked here under no actor name” is asking for misreads.

“Scribe wrote that” is a sentence agents can say to each other when they’re reviewing a card together. It’s the right level of abstraction — concrete enough to refer to (“did you see what Scribe logged on the West End lead?”) but specific enough to mean exactly the right thing.

The icon on Scribe rows is a feather. The visual choice reinforces what Scribe does: it writes things down. It doesn’t think, judge, or act. It records.

What Scribe is NOT

Worth being explicit, because the temptation to treat the system actor as smarter than it is is real.

Scribe is not an AI agent. It doesn’t reason about leads, generate replies, or decide what’s important. It executes a state machine and a temperature scorer that have explicit, written rules.
Scribe is not the AI assistant on the public site. The semantic search and recommendation features for buyers have their own internals; those aren’t Scribe.
Scribe is not infallible. If a transition fires when it shouldn’t, that’s a bug to report — not the system being mysteriously wrong on purpose. Scribe rows are deterministic outputs of inputs the system saw.
Scribe is not an authority over you. If you disagree with a row Scribe wrote, say a re-routing that sent a re-engaged lead to someone else, the right move is to reassign it from the Assignment & Notes card with a note saying why. Scribe acted on the data it had; you have the data it didn’t. The same goes for an Archived: no response row a teammate clicked on a lead you were working but hadn’t logged: click Re-engage AND log the activity that should have been there.

How Scribe interacts with you

A common pattern: a lead arrives, and a little later you log a phone call. The timeline reads, oldest first:

─ Earlier ──────────────────────────────────────
  Scribe — Lead received

─ Earlier ──────────────────────────────────────
  Scribe — Agent assigned

─ Just now ─────────────────────────────────────
  You — Contact attempted   New → Contacting   [Call]
  "Left voicemail."

Scribe’s rows are the setup: the lead exists, and routing gave it to you. Your row is the action, and the stage change rides on it. The lead’s column on the board updated because of your row, not because Scribe wrote a second one.

That principle saves you confusion later. If you’re trying to figure out why a lead is in CONTACTING, you look for a Contact attempted row and read the name on it. If you’re trying to figure out why it landed on a particular agent, you look for Agent assigned or Agent reassigned and check whether the name is a person or Scribe. The chain is readable.

When Scribe doesn’t appear at all

Some things happen on a lead that never write a timeline row:

Property views on the public site (those feed the temperature scorer and show up as the temperature badge, not as rows).
Search queries (same).
Automated emails from the marketing system (those live in the email system’s own logs).
Page renders of the lead detail page by an agent (we don’t log what you read, only what you do).

The timeline is the canonical record of lifecycle events: stage changes, contact attempts and responses, assignments, and the notes typed with them. Communication preference switches keep their own history in the Lifecycle card, not on the timeline. It is not a log of every observable thing. If you need finer detail (which property the lead viewed, which search they ran), that’s the session-activity view, not the timeline.

The takeaway

Scribe is a name for a category of timeline rows that would otherwise be unattributed or attributed confusingly. The name does three things: it lets you read the timeline without second-guessing the source of each row, it lets reviewers separate agent actions from automatic side-effects, and it gives the team a shared handle for talking about what the system did.

It is not an entity with judgment. It is not an AI. It is a feather-shaped name on rows the system wrote because rules said so.

Read Scribe rows as facts about what the system observed. Read your own rows as the actions you took. The combination is the lead’s full story.

Read the timeline — how-to for interpreting individual row types, including who-did-what
Your first day — the timeline pattern in the demo, with both actors visible
State machine card — what kinds of transitions exist, and the button that fires each