Scope the before and after so you can prove it later

A head of revenue operations at a SaaS company told me about the most frustrating win of her year. Her team had built an AI assistant that helped account managers prep for renewal calls. It pulled the customer’s usage, flagged risks, and drafted talking points. The account managers liked it. She believed it was working. When her CFO asked her to show that it was working, she had nothing.

The problem was not the feature. The feature was fine. The problem was that six months earlier, when they scoped the project, nobody wrote down what renewal prep looked like before the AI. How long it took. How often a manager walked into a call unprepared. What the renewal rate was for the accounts that got good prep versus rushed prep. All of that was knowable in advance. None of it was captured. So when the question came, she could describe an improvement she could not measure against anything.

No baseline, no proof

This is the quiet failure mode of AI projects that otherwise go well. You build the thing. It helps. And then someone with a budget asks whether it helped, and you realize the honest answer is that you feel like it did. Feeling is not evidence, and in a room deciding next year’s spend, it loses.

The reason this happens is that the before-state is invisible once you are living in the after. The moment the AI ships, the old way of working is gone. You cannot go back and measure how long renewal prep used to take, because nobody does it the old way anymore. The window to capture the baseline closes the day you launch. If you did not capture it during discovery, it is gone.

A colleague who leads support at a hardware company hit the same wall from the other direction. Her team automated part of the ticket triage and could not tell, a quarter later, whether resolution times had actually improved, because the ticketing system had also changed and nobody had a clean read on the old numbers. The AI might have helped a lot. She could not separate its effect from everything else that shifted. Without a baseline pinned before the change, the result was unprovable.

Capture the before during discovery

The fix is cheap and it has to happen early. When you scope an AI project, you scope the measurement alongside it. Write down the current state in numbers you can get today, while the old way is still running. You do not need a perfect experiment. You need an honest snapshot of the before, so the after has something to stand against.

For the revenue-ops leader, the baseline she wished she had captured was small:

How long a manager spent prepping a renewal call, on average, the old way.
How many calls happened with no real prep at all.
The renewal outcome for well-prepped versus rushed accounts.
A simple read on how managers felt about walking into those calls.

None of that needed the AI. All of it needed to be recorded before the AI existed. A few hours of measurement during scoping would have turned an unprovable win into a defensible one.

There is a second benefit. Capturing the baseline forces you to name what success even means before you build. If you cannot describe the current state in terms you would want to improve, you do not yet know what the feature is for. The measurement plan and the scope sharpen each other.

How we handle it at Density Labs

Baseline capture is a deliverable of the AI Opportunity Assessment, our two-week fixed engagement at $2,500. Before anyone builds, we define what the current process produces, in numbers we can pull while the old way is still live, and we agree on what better would look like. That way, when the feature ships and someone asks whether it earned its keep, the answer is a comparison, not a feeling. Scoping the before-state costs almost nothing during discovery and is impossible to recover afterward.

Decide how you will prove the result before you build the thing that produces it. Capture the before, because the after cannot capture it for you.