The honest answer, up front.
You cannot measure the ROI of AI across your company, and you should stop trying. There is no single number that captures what AI did for an $8M-$50M business, because a company is not a workflow. The question only becomes answerable when you shrink it to the thing you actually commissioned: one workflow, with one baseline cost, measured before and after. Ask "what is the ROI on AI" and you get a story. Ask "what did this workflow cost us before the build, and what does it cost us now" and you get a measurement. That shift, from the company to the workflow, is the whole memo.
The reason the company-wide question is a trap is that it sounds rigorous while being impossible to answer. Spread AI across a dozen workflows and the gains and costs blur into a figure nobody can attribute or defend. Any number you produce is assembled from estimates, and estimates are where vendors live. The disciplined operator refuses the company-wide frame on purpose and measures the one place a clean before-and-after actually exists.
This matters more for a mid-market company than for an enterprise, because you do not have a finance team standing by to model attribution across a portfolio of initiatives. You have a workflow, a cost, and a question about whether the spend was worth it. The good news is that the smaller frame is the more honest one anyway. A single workflow with a named baseline is something an owner-CEO or a COO can verify personally, in an afternoon, without commissioning a study to measure the study. The company-wide ROI deck is the thing that looks sophisticated and proves nothing; the one-workflow before-and-after is the thing that looks modest and settles the argument.
The baseline you can name, or cannot.
Here is the readiness test, and it is harsher than it looks. If you cannot name the number the target workflow costs you today, you are not ready to commission a build. Not "we think it is a lot." A number: this workflow consumes roughly this many staff hours a month, or it produces roughly this much error and rework cost, or it loses us roughly this much cycle-time and speed that maps to revenue we can see. If you cannot produce that figure, the inability is itself the finding, and it is a valuable one. It means the workflow is not understood well enough to build against yet.
Naming the baseline is step one of measuring ROI, and it is the step almost every operator skips. People reach for the projected upside ("this could save us a fortune") before they have anchored the thing it is saved against. The baseline is the anchor. Without it, every later number floats, and a floating number is indistinguishable from a guess. The work of naming it (counting the hours, pricing the rework, tracing the lost speed to dollars) is not overhead on the engagement. It is the engagement starting.
This is also where the cost side of the decision gets concrete, and it pairs with the spend you are weighing; we walk through the real numbers in what a mid-market AI engagement costs. A baseline you can name on one side and a commission price you can name on the other is the only honest version of an ROI calculation.
Hard dollars versus vanity metrics.
Once you have a baseline, the measurement is a matter of counting the right things and refusing to count the wrong ones. Three categories are hard dollars, and they are the only categories that prove an engagement paid for itself.
Headcount avoided or redeployed. The workflow used to require people, or a fraction of people's time, and now it requires less. That is a real number you can put against payroll, whether it shows up as a role you did not have to hire or hours given back to people who now do higher-value work.
Cycle time that converts to revenue or capacity. The workflow used to take a week and now takes a day, and that speed maps to something countable: deals closed faster, more volume through the same team, a response time that wins business you were losing. Speed only counts when you can name what it buys.
The cost of errors removed. The workflow used to produce mistakes that cost money to fix, or cost money when they reached a client. Remove them and you remove a real expense that was hiding in rework and goodwill.
Everything else gets discounted, hard. Generic "time saved" estimates with no dollar attached, usage and seat counts, "productivity" as a feeling: these are how vendors inflate ROI decks, and they are seductive because they are always large and always favorable. A metric that cannot be traced to money that shows up in the business is a vanity metric. It may be fine for tracking adoption. It does not prove the engagement was worth its cost, and you should never let it stand in for the proof.
The payback period, in nameable months.
A properly scoped single-workflow commission should pay back in a number of months you can state out loud. This is not optimism; it is arithmetic. If the workflow costs a concrete amount every month in staff hours and error cost, and the commission costs a concrete amount once, you divide one into the other and you have a payback period. The number is only available because the baseline is concrete, which is exactly why naming the baseline came first.
The diagnostic is the inverse. If nobody on the team can state the payback period, the problem is almost never that the build is too risky to forecast. The problem is that the workflow was not scoped tightly enough to measure. A scope that sprawls across "improving operations" has no baseline and therefore no payback period, and that is the tell that the engagement is shaped wrong. The fix is to tighten the scope until a single workflow with a single baseline emerges; that workflow is the one to build. This is the same discipline that separates a buy from a build in the first place, which we lay out in build vs buy AI for a mid-market company.
A payback period also keeps everyone honest about magnitude. A workflow that costs you a few hundred dollars a month in hours is not worth a six-figure commission no matter how satisfying the build would be, and the arithmetic says so immediately. A workflow that quietly costs you tens of thousands a month in rework or lost speed justifies a serious build and justifies it fast. The point of the number is not to produce a flattering slide; it is to tell you, before you spend, whether the math closes at all. Most of the engagements that go wrong were ones where nobody did this division, because the moment you do it, the bad ones disqualify themselves.
Set the measurement before the build.
The single most common way operators fool themselves on AI ROI is measuring against a story told after the fact. The build ships, something feels better, and a number gets reverse-engineered to justify what was already spent. That number is not a measurement; it is a press release. The only honest comparison is against the baseline you wrote down before the engagement started, because that baseline was recorded when you had no incentive to flatter it.
So the measurement plan is part of the scope, not an afterthought. Before the build begins, you decide which hard-dollar numbers you will track, you record their baseline values, and you agree on when you will re-measure. This sounds obvious and is almost universally skipped, because the moment of greatest enthusiasm (kickoff) is the moment nobody wants to slow down and write down what failure would look like. Writing it down anyway is what makes the eventual ROI claim defensible. A build that drifts past this point is also how engagements stall without anyone noticing, a pattern we trace in why mid-market AI rollouts stall in month four.
How to run the measurement without us.
You can do most of this before any vendor is involved. Pick the one workflow that is your actual bottleneck. Name its baseline cost in the three hard-dollar categories: hours, error and rework, lost speed that maps to revenue. If you cannot, stop; that is your answer for now, and it is a finding worth having. If you can, you have both the case for the build and the yardstick to judge it by, and you can hold any vendor to it.
If you want the sorting done for you, our AI Maturity Index surfaces the workflow worth measuring and the baseline questions to ask of it, and our diagnosis process exists to set that measurement before any money is spent. The framing to keep is simple. Measure per workflow, not per company. Name the baseline first. Count hard dollars and discount the rest. And set the yardstick before the build, not after, because a number you wrote down in advance is the only one anybody should believe.