14 dates. No receipts. Zero counted at go-live

No receipt, no Stage 1.

TL;DR — the short version

Do any of these sound familiar?

The forecast and the calendar disagree about how many first meetings happened this quarter.
A deal hit Stage 1 the same afternoon it was created.
Someone cleaned up the CRM before the board meeting, and the quarter looked better overnight.
Every pipeline report has an asterisk, and nobody remembers what it means.

This summer a client’s sales team moved to a stricter definition of Stage 1: a meeting that actually happened, with someone from the buyer’s decision team. A new forecast was going live on top of it. Before it did, I put a data contract between the CRM and the reports: a short list of rules every deal had to pass before the forecast was allowed to count it.

A date is a claim. Dates in a CRM get typed, defaulted and bulk-edited as often as they get earned.
Check it against the receipt: a stage change in the history and a meeting that was actually held.
Don’t fix misses quietly. They go to a queue a person clears. The system can suggest a date. It can’t write one.
Do it before go-live, when a miss is a test result instead of a board-deck correction.

A data contract checks stage history and completed meetings before the forecast counts a date. Unsupported dates counted fall from 14 in testing to zero at go-live; exceptions go to human review.

14 unsupported dates in the first test. Zero counted at go-live. Here’s the gate that made the difference, and the source choice I got backwards first.

A Stage 1 date is a claim, not a fact

A date field in a CRM gets filled in a lot of ways. A rep types it. A workflow stamps it when a stage changes. A bulk update sets it during a cleanup. On this engagement we had just moved 129 deals back from Stage 1 to Stage 0 when we checked whether their meetings had actually happened, so a lot of dates had been touched recently, by a lot of hands.

Only some of those ways mean a meeting took place. The forecast couldn’t tell the difference. It read the field, and the field always had a value.

I didn’t need to know how each bad date got there. I needed the forecast to stop counting them.

Illustrative. The field looks fine on its own. The stage history and the meeting record are what tell you whether to believe it.

Put the evidence check before the forecast

A data contract sounds heavier than it is. It’s an agreed list of rules about what the data should look like and what it means, checked by code at the point where one system hands data to another. Nothing reaches the forecast without passing it. This one checked four things:

Source. The Stage 1 date comes from the stage history: the record of when a deal actually moved, not the field that says when it did.
Receipt. There’s a completed meeting behind it, with someone from the buyer’s decision team on it.
Shape. The columns the forecast reads can’t be renamed or dropped without failing a check before the change is merged.
Exceptions. Anything that fails goes to a queue. Not into the forecast, and not into the trash.

I trusted the field first. That was backwards.

My first version read the CRM field and used the stage history only as a fallback when the field was empty. It seemed sensible. The field was what everyone looked at.

It was the wrong way round. The field was almost never empty, so the fallback almost never ran. And a filled-in field was exactly the problem. A few days before go-live I reversed it: stage history first, the field only as a cross-check. That one change is most of the reason the number reached zero.

The lesson I keep relearning: the source that’s always filled in isn’t the source that’s always right.

Misses go to a person, never back into the CRM on their own

It would have been easy to have the system correct the dates itself. The meeting record usually suggests the right one. I didn’t, for the same reason I don’t let an AI agent merge its own code: propose freely, merge never.

So the S0 meeting-exception queue shows each failing deal with what the field says, what the history says, and a suggested date. A person approves it before anything is written back. The suggestions save time. The approval keeps the CRM honest.

From the dev test run a week before go-live. Every miss went to the queue for a person to clear.

The same test run recorded another change: AI-scored accounts showing up in pipeline went from 233 to 378. That result sits alongside the date check; it does not, by itself, establish what caused the increase.

A failed check needs an owner

There are three common places to enforce a rule like “Stage 1 needs a real meeting.” Only one of them puts the miss in front of a person.

	In the dashboard filter	In a CRM validation rule	In a data contract
Who sees a miss	Nobody. It’s filtered out.	The rep, at data entry	A named person, in a queue
Bad dates already in the CRM	Hidden, if the filter is right	Untouched	Checked on every run
Survives a report rebuild	No. It lives in one report.	Yes	Yes. Every report reads through it.
A renamed column	Breaks the report on the day	Not covered	Fails before the change is merged
Cost	Cheap, and quietly copied wrong	Friction for every rep	A few days of engineering, once

Test it with the person who will own it

The contract ran in a development copy first, with the analytics engineer who was taking the platform over at the keyboard. In order:

First test run. 14 Stage 1 dates with nothing behind them. Found in dev, a week before anyone saw the forecast.
Exception queue shipped. Every miss became a row a person could work, not a log line.
Suggested dates gated. Nothing written back to the CRM without an approval.
Go-live. The forecast counted zero dates without a receipt.

Doing it with the next owner driving mattered as much as the code. When I left a few weeks later, the person who understood the contract best wasn’t me.

Five checks before your next forecast goes live

Pick the one date your forecast leans on hardest. Usually Stage 1, or whatever your team calls the first real meeting.
Find its receipt. The stage history, the meeting record, the signed form. Something a person didn’t just type.
Count the misses in a test copy before anyone sees a forecast built on them.
Send misses to a person. Suggest the fix, never apply it silently.
Fail on shape changes before they merge, not in Monday’s pipeline review.

Which field in your forecast gets treated as fact because it’s always filled in?

If your forecast and your calendar disagree, start with the date field they both depend on. I build the definitions, evidence checks, and exception workflows behind those numbers. Book a Consultation.