The page I want beside every AI spend request
The page I want beside every AI spend request
An AI pilot can look healthy right up to the meeting where it asks for more budget. There is a demo, a spend line, and a sponsor who can point to activity.
Then finance asks a much plainer question: what changed in the work, and what would make us stop?
If the room has to search through slides, Slack messages, and memory for the answer, the pilot has not earned its next quarter yet.
CIO Dive recently reported on US firms that lost revenue on AI projects that missed their expected value. I would not use that number as a proxy for another market.
I would use the decision problem: what would make this specific project pause, change course, or receive more money?
"Giving space does not mean indefinite patience."
CIO Dive quoted this in the context of a kill-or-scale decision. It is a good rule for a pilot review too.
The one-page record I would bring
I would put a short decision record in front of the COO, finance lead, and the person closest to the workflow. Use it alongside proper measurement and a business case, so the next decision has one home.
Work to improve: The real task, such as preparing the first claims review. "Explore AI" is not a task.
Decision owner: The person who can continue, pause, or stop the work.
Expected change: What should be different in the workflow if the pilot is helping.
Weekly signal: The small check the owner will inspect before the renewal meeting.
Stop signal: The condition that means no more spend until the design changes.
Next decision date: The date when the sponsor will make the call.
The stop signal is often the blankest line on the page. It is also the line that stops a temporary pilot becoming permanent by inertia.
There is a second benefit to writing these fields before launch. It separates a pilot's intended result from the signals that are easy to count. A team may have plenty of activity, yet still be unable to show that the claims handler, relationship manager, or reviewer has a better working day.
That distinction matters at the renewal meeting. A dashboard can show usage; it cannot tell the sponsor whether people are quietly correcting every output, avoiding the tool for difficult cases, or passing the review burden to someone else.
The weekly signal needs to be cheap enough to collect while the pilot is still running. If the team needs a separate analytics project to find out whether the work improved, the decision will arrive too late. A short sample review, a time comparison, or a manager check can be enough when it is tied to the job the pilot was meant to improve.
The same goes for ownership. The decision owner does not have to personally inspect every output. They do need to know who brings the evidence to the next meeting, and who can say that the current design should not continue unchanged.
What a usable stop signal sounds like
A stop signal should describe a condition in the work, not a feeling about the technology. It might be any of these:
The claims manager still spends as long checking the summary as they did before the pilot.
The team cannot keep the agreed customer-data boundary in place.
Corrections keep rising after the agreed test period.
The people doing the work have quietly gone back to the old route.
None of those conclusions says the team was foolish to try AI. They say the team learned enough to make a better decision before more money is committed.
Take a claims-summary pilot. The original job might be to reduce the time needed to prepare a first review without making important details easier to miss. The weekly signal could be a small manager-checked sample that records preparation time and required corrections.
If the corrections remove the time saving for two consecutive reviews, the sponsor has something concrete to discuss. The next step might be to change the prompt, narrow the case type, add a review step, or pause the work. It should not be another month of spend with the same unanswered question.
Run the review from the work outward
I would start with a small sample of real cases, not the dashboard. Ask the person doing the work what changed, what still takes time, and where the tool added a new review step.
Then compare that answer with the record. If the expected change and the weekly signal no longer match, the pilot may need a different question before it needs more budget.
Finally, read the stop signal aloud. It makes the decision less personal. The room is not voting on whether they like the sponsor or the product. It is deciding whether the work has earned another step.
This also gives the people closest to the workflow a safer way to disagree. They do not have to argue that AI is good or bad. They can say that the agreed signal is not appearing, that the review burden is growing, or that the data boundary has become harder to maintain.
That is a more useful conversation than an optimistic progress update. It gives the sponsor a decision they can explain to finance, risk, and the team doing the work.
Copy these six lines into the next portfolio review:
Work to improve
Decision owner
Expected change
Weekly signal
Stop signal
Next decision date
The record should be short enough to use in a real meeting, and specific enough that a new owner can understand why the team continued, paused, or stopped.
Save the first version before the pilot begins. It gives the sponsor a fair way to say yes, no, or not yet when the work asks for more money.
Keep the record with the project material, rather than in the private notes of the person who set the pilot up. When the sponsor changes, the next owner should be able to see what the team expected, what it measured, and why the next decision was made.