How to measure automation ROI without a system of record
The ROI of an automation is the gap between what the process cost before and after, and both numbers have to come from the same place. If the process lives in spreadsheets and messages, the "before" is recorded nowhere. The automation works and the return has no proof. The first step is deciding where the data is born.
Why does automation ROI depend on a system of record?
Because return is a comparison, and a comparison needs two points measured the same way. The "after" point almost always exists: the automation runs, writes a log, counts executions. The "before" point exists only if the manual process left a structured record. In most small and mid-sized companies, it did not.
Take the process of checking orders against stock. Whoever does it will tell you it "takes all morning." That number never went through a system. It lives in one person's perception, and perception shifts when the process changes. Six months after the automation, nobody remembers whether it was three hours or five, and the board asks if it was worth it.
This is where the problem stops being about technology. The automation tool delivers what was configured. What is missing is an architecture decision: in which system does the process record what it does, before and after the automation? Without that decision, any automation ROI calculation rests on estimates made from memory.
What does the data say about return and about systems?
It says return is rarer than the enthusiasm suggests and that the systems base of the average company is still thin. The two facts are connected.
In Gartner's survey, run in November and December 2025 with 782 infrastructure and operations leaders, only 28% of AI use cases fully met the expected return, and 20% failed outright. Among the 57% who reported at least one failure, many said they had expected too much, too fast. Among the factors associated with success, 33% pointed to integration into existing systems and processes. The sample is IT operations and AI, not the business processes of a smaller company. What the survey offers is a pattern: return depends on the initiative sitting where the operation already records what it does.
On the systems side, Eurostat's 2025 data on enterprise e-business, published in May 2026, shows ERP as the most widely used application in the EU, at 41% for small enterprises and 89% for large ones, a gap of 48 percentage points. So roughly six in ten small European enterprises run without an ERP. That does not mean they run without software. But a subscription per department produces data in five places, and none of them measures the process end to end.
The two sources cover different universes (corporate IT, and EU enterprises by size) and should not be added together. Read side by side, they point to the same conclusion: automation arrives in an operation whose "before" was rarely measured.
What data should a process leave before it is automated?
Five, and none requires a large project to exist.
Volume is how many times the process runs per week. Without volume, you do not know whether the automation serves 50 cases or 5,000, and the payback changes by an order of magnitude.
Time is how long each run takes end to end, including the waiting between steps. The wait often weighs more than the work itself, and it only shows up when each step records when it started and when it finished.
Errors are the share of runs that come back for correction. This is the most expensive data to reconstruct later, because an error fixed quietly leaves no trace.
Rework is the time spent on those corrections. It separates the automation that eliminates the error from the one that just moves it elsewhere.
Owner is the person who answers for the number. Data without an owner is data nobody updates.
What matters most is where these five points are born. If the record depends on someone filling in a spreadsheet at the end of the day, it fails in exactly the peak weeks, which are the ones that matter most. An internal system records as a side effect of the process happening: the order came in, the check started, the error was flagged. That is the logic behind, for example, the Reatop environmental management system, where the data is born inside the workflow and not after it.
A practical example: the return nobody could prove
The scenario below is hypothetical, and the numbers are illustrative assumptions, not measurements. A distributor with 90 employees automates order checking. The team says the process used to take "a morning a day" from two people. The project is approved with an informal target of saving 20 hours a week.
Three months later the automation runs without failures and the board wants the return. What exists? A verbal estimate of the 20 hours, given by the people who lived the process. No record of how many orders came in per week before, how many came back with errors, or how long an order waited between arrival and checking. The automation reduced something, but nobody can say how much, and the question "was it worth it?" becomes a debate about perception.
Now the same project with one earlier step. For four weeks, before automating, orders go through a simple register that records arrival, start and end of checking, and flagged errors. Even if the result is modest, it is demonstrable: the board sees before and after under the same criterion. And the record reveals something the verbal estimate hid, for example that the largest cost was the wait between the order arriving and the check starting, not the check itself. The automation is then redesigned to attack the wait.
The change in order is small. What it alters is the quality of the decision about what to automate.
How do you start without stopping the operation?
Start with the process you most want to automate and put the record in place before the automation, for a short, defined period. Four weeks usually show the variation between normal and peak weeks, but that period is a planning reference, not a measurement.
Then decide where the record will live. A shared spreadsheet works for a one-month experiment. To be the base for return, the data needs to sit in a system where the process actually happens, with required fields and history. That is the logic of when to replace spreadsheets with custom software: the spreadsheet is the starting point of the survey, and the system is where the return becomes reliable.
The SuperVida case shows this move at another scale. The benefits-card network in Maranhão, Brazil, managed contracts on an improvised Airtable base, and Yowpi migrated the operation to a custom system with contracts, beneficiaries, sellers and partners in one place. The SuperVida case has no return figures, and this text does not invent any. What it illustrates is the precondition: with the operation in a single record, any future automation has somewhere to be measured.
Frequently asked questions
My team is used to spreadsheets. Does that get in the way of measuring return?
It does not have to. Start with what the team already uses and add only the five minimum data points, for a short period. The goal is to have the "before" recorded, not to swap tools on day one. Migration to a system comes when the spreadsheet starts failing at peak.
I do not know whether automation pays back financially. How can I tell before investing?
You tell by measuring first. With four weeks of volume, time and errors recorded, the cost of the current process becomes a number, and the maximum possible return of the automation is capped by it. If the process cost is low, the payback does not come, and finding that out before you buy is a good result.
I do not have a qualified team to implement it. Can it still work?
Yes, because the minimum record does not require a technology team: it requires deciding which five data points matter and who answers for them. The technical part, when it arrives, can be done by a partner. The decision about what to measure has to be yours, because it depends on knowing the process.
The next step
If you want to know which system your process should record its work in before it is automated, the Operational Architecture Diagnostic, a 30-minute conversation, is the place to start: get in touch with Yowpi.
Related case studies
Did you recognize your operation in this article?
Book the Operational Architecture Diagnostic: 30 minutes to map where your operation's bottleneck is. No proposal in the first conversation.
Book a diagnostic