Start with one workflow that costs the most manual time. Prove value there before expanding.
Step 1: Set the baseline before you automate anything
Calculate AI ROI using metrics you can track from day one.
Before launch, record exactly how the process performs today: how long it takes, how many errors occur, what it costs in staff time. Without this number, any improvement afterward is a guess dressed up as a measurement.
This baseline does not need to be perfect or elaborate. A week or two of honest measurement of the current process is usually enough to give you a number worth comparing against later.
Write the baseline down somewhere everyone involved in the project can see it, and agree on it before launch. A baseline that only exists in one person’s notes tends to become a point of disagreement later, right when you need it most.
A slightly imperfect measurement of the right thing beats a precise measurement of the wrong thing.
Step 2: Track the metric that matters, not the one that’s easiest to pull
It is tempting to report on whatever number is already sitting in a dashboard. Resist that. Go back to the actual reason you built the system, faster response times, fewer errors, lower cost per transaction, and track that specific outcome, even if it takes more work to pull.
If the metric that actually matters is hard to measure directly, find the closest reliable proxy and say clearly that it is a proxy. A slightly imperfect measurement of the right thing beats a precise measurement of the wrong thing.
Get agreement on this metric from whoever originally championed the project, before launch, not after. It prevents the goalposts from quietly moving once the early numbers come in and someone would prefer a different measure of success.
Working on something similar?
Let's talk →Step 3: Give it enough time before you judge it
Working on something similar?
Let's talk →New systems have a settling-in period. Staff are learning the new process, edge cases are surfacing, and early numbers are often worse than they will be once everyone adjusts. Judge results after a full normal cycle of your business, not the first two weeks.
This is especially true for anything involving a change in how staff work day to day. People need time to trust a new system before they use it the way it was actually designed to be used.
A simple guardrail: agree on the review date before launch, and stick to it. Reviewing too early almost always makes a genuinely useful system look worse than it actually is.
Step 4: Separate the cost of the tool from the cost of running it
A full ROI picture includes the subscription or development cost, but also the ongoing time spent maintaining, reviewing exceptions, and fixing issues. A system that saves time on the core task but generates a steady stream of exceptions to review manually may be less valuable than it first appears.
Track this exception-handling time explicitly for at least the first few months. It is the cost most commonly left out of an ROI calculation, and it is often the difference between a project that looks good on paper and one that actually is. If exception volume stays high well past the settling-in period, that is a signal the system needs adjustment, not just patience.
Review this cost alongside the baseline you recorded before launch, not in isolation. A system that costs more to maintain than expected can still be a good investment if the baseline it replaced was expensive enough, and the only way to know that for certain is to compare the two numbers directly, side by side, in the same currency and over the same period of time.
Your pre-decision checklist
Before you move forward, confirm:
- You recorded a clear baseline for time, cost, and errors before launch.
- You agreed on the specific metric that reflects why the project was built.
- You are measuring after a full normal cycle, not the first two weeks.
- You are including staff time saved, not just direct cost changes.
- You are tracking ongoing maintenance time as part of the true cost.
- Someone reviews these numbers on a set schedule, not only when asked.
- You have written down the agreed review date and shared it with everyone involved.
