A filing cabinet that runs on the honesty of a tired person at six in the evening

It is six in the evening. A rep has had five calls, two of which went somewhere and three of which have already blurred into each other. The CRM is open on a form that wants to know what happened, what the next step is, and whether the deal should move.

What gets typed into that form is not a record of the day. It is a reconstruction of the day, made at the end of it, by a tired person, compressed into the shapes the fields will accept, by someone whose performance is partly assessed on those same fields.

That is not a character flaw and no amount of training fixes it. Recall degrades within hours. Compression is lossy in the direction of the story you already believe. And any measurement produced by the person being measured has a thumb on it, not because they are dishonest but because the form asks a question with a right answer.

Everything downstream inherits that. The forecast, the pipeline review, the coaching conversation, the attribution model, the board slide, and now an AI reading the same table and speaking with far more confidence than the tired person did. The AI does not know the fields were reconstructed. Nothing in the schema says so.

The self-report nobody counts as one

The obvious self-reported field is the call note. The one that does more damage is the stage.

A deal sits in stage three because a human decided it belonged there. Sometimes that decision follows something the buyer did. Often it follows a good conversation, an end-of-quarter push, or a manager asking why nothing has moved. Either way it is an opinion recorded in a column that everything numeric then treats as an event.

So a pipeline is, in the strict sense, a record of rep confidence over time. A forecast built on stage-weighted probability is a model of rep confidence. Rep confidence correlates with buyer behaviour, which is why the whole apparatus works at all, and it is not the same variable, which is why the apparatus is wrong in the specific way it is always wrong: it is most confident right before it is most wrong.

Shift one: let the system that owned the event write the row

The first change is unglamorous. The activity row should be produced by whatever actually witnessed the thing: the dialer for a call, the mailbox sync for an email, the calendar for a meeting. Not by a person typing a summary of it later.

That sounds like a small plumbing decision and it has a sharp edge, which our own calendar layer makes visible. The projections that put work on a calendar are read-only by contract: they are views of rows other systems own, and the sequence-step projections show what the scheduler would do without ever enqueuing, enrolling or sending anything. Capture and action are kept separate on purpose, because a system that logs by acting is a system that will eventually act in order to log.

The edge is that machine-produced data is not automatically true. The same file notes that a call session carries four different notions of when it happened, and that its kind is inferred from two columns rather than stored, which is why the translation from row to event is kept pure and heavily tested. The interesting failures here are not lies. They are ambiguities.

The measured version of that, which is worse than the story above

Here is what happens when the vocabulary of "what happened" is typed by hand in more than one place.

Our activity logging module used to hand-roll its own list of activity types. It drifted in both directions: it offered eighteen values the database would reject on insert, and omitted ten values the database actually has. A live caller elsewhere in the codebase was writing one of the rejected values, which fails at runtime.

The second copy is the one worth sitting with. A separate file keyed an activity points map with thirteen values, six of them phantom. Because the leaderboard falls back to one point for an unmapped key, the points metric was quietly counting activities instead of weighting them. Nothing went red. A number kept appearing on a dashboard every day, and it was measuring something other than what its label said.

The fix was to stop typing the list. The type is now derived from the Postgres enum, so anything the logger builds is insertable by construction, and a guard checks the generated type against the migrations, which it names as the executable source of truth. The guard also states its own limit rather than implying coverage it does not have: it checks only the enums on its list, because a sweep of all seventy-seven migration enums reports five pre-existing mismatches it has not reconciled.

Take the general point away from the CRM entirely. Self-reported data is one failure mode and it announces itself; everyone knows the notes are thin. Silently miscounted machine data is a different failure mode and it is harder to catch, because it arrives with a chart.

Shift two: move the stage on conditions, and let the move refuse

If the stage is going to carry weight, the transition has to be a decision with requirements rather than a drag between columns.

Ours is a pure function over a matrix. Contact to lead requires engagement. Lead to opportunity requires budget, authority, need and timeline. Opportunity to closed requires need and timeline. Only one step forward at a time. A signal that is missing, or that is not a real boolean, is treated as not confirmed, so the gate fails closed rather than open.

The part reps actually notice is the refusal. It does not return a bare no. It returns which signals are missing and why, which turns an argument about whether a deal is real into a list of four things and their current state.

Shift three: attach the source to the signal

Deriving qualification signals automatically only moves the problem if nobody can see where they came from. So each inferred dimension is stamped with a stable provenance ref: the reply, the call, or the meeting it came out of, with the id. The checklist renders that next to the signal, so the rep sees the source before confirming it.

The human is still in the loop. What changed is what the loop asks of them. Confirming a signal against the email it was extracted from is a review. Filling in the same field from memory at six in the evening is a recall test, and it is one that gets harder as the day gets more productive.

The meeting nothing was capturing at all

Every argument above assumes the event left a digital trace. The face-to-face meeting is the one that does not, and it is usually the meeting that decided the deal.

One tap starts a recording. The lifecycle runs through a pure state machine rather than ad hoc component state, and capture does not begin until the user confirms the other party agreed to be recorded. A four-hour cap stops it automatically. On stop, the metadata and the audio take separate paths, the audio lands behind a storage adapter seam, and the existing transcription orchestrator runs, so the post-meeting extraction and summary work on the actual recording rather than on somebody's memory of it.

Speaker separation is done by the transcription provider; a separate module owns only the deterministic part on top, assigning stable labels and handling renames and merges. That means diarization is provider dependent, and when it is absent that is recorded rather than papered over. We do not claim speaker attribution on every recording.

The honest edges

This does not remove the human, and any vendor telling you otherwise is selling the tired person a story about themselves. It changes what the human is for: confirming against an artifact instead of reconstructing from memory.

And it is not finished. The layer that would turn these captured artifacts into structured claims with sources attached, inside the AI's memory, is not generally available yet. Writing about it as if it were running would be the same failure as a rep typing a call note about a call that went differently.

So the question worth asking about any revenue system, ours included: of the fields your forecast reads, what fraction were written by something that observed the event, and what fraction by a person reconstructing it at the end of a long day? You can usually work it out in an afternoon. Whatever that ratio turns out to be, it is the ceiling on the forecast, on the coaching, and on any AI you put on top, because none of them can be more accurate than the record they read.