ROI measured in execution, not estimated in the proposal
Every automation vendor promises a return in a spreadsheet before the contract. Few show the return afterwards, with real execution data. If you have to defend the automation investment in front of the board, you need the second number, not the first.
Why automation ROI usually does not hold up
The problem is rarely the bot. It is the lack of continuous measurement after it goes into production.
The return was calculated once, at the sale
The estimate used an average manual execution time given by whoever wanted the project approved. It was never reconciled with the bot’s real time in production.
Nobody knows which bots pay the bills
Without duration per execution and per node, you cannot tell whether ten automations are producing a return or whether two carry the result and eight consume maintenance.
Silent failures do not show up in the calculation
Executions that abort, repeat or exceed the expected time still count as successes in the original spreadsheet. The declared return ends up higher than the real one.
How it works
The calculation starts from the telemetry the bot itself produces. Nothing is typed by hand.
Continuous collection during execution
Every execution records start, end, duration, processing node and process identifier. Collection is automatic and happens on every run, not by sampling.
Outlier detection
Executions outside the expected duration range are isolated. That set reveals a degraded bot, an environment bottleneck and a scenario that changed without notice.
Comparison with the manual baseline
The automated execution time is compared with the time of the same process before automation, measured with the operation and stored as a versioned reference.
Dashboard in the Customer Portal
The result is available in the logged-in area, with execution volume, average duration, distribution by node and history. You open it and see it, without asking for a report.
What is measured
The basis of the calculation is the execution, not the estimate.
| Dimension | What it represents | Use in the calculation |
|---|---|---|
| Duration | Time between the start and the end of the execution | Direct comparison with the manual baseline |
| Node | Machine or environment that processed it | Separates infrastructure bottlenecks from process bottlenecks |
| Volume | Number of executions in the period | Turns unit gain into accumulated gain |
| Outlier | Execution outside the expected range | Stops silent failures from inflating the return |
| Process | Identifier of the bot and the scenario | Shows which automations pay the bills |
Numbers
Real operating data.
- 31.2KExecutions per monthMeasured in the operation of a large customer.
- 2KAutomated scenariosMeasured in the operation of a large customer.
Frequently asked questions
Does the calculation include the cost of maintaining the bot?
It should, which is why measurement is continuous. Automation that needs frequent repair shows up as more outliers and longer execution times before it shows up on the invoice.
Do I need automation already running to start measuring?
For a calculation with real data, yes. Before that, what exists is an estimate, and it should be treated as one: with a stated assumption and a scheduled review.
Where is the result available?
In the Customer Portal, in your company’s logged-in area, next to tickets, schedule and project documents.
See also
Want to see the return of the automations you already have?
Bring a process that is already automated. We show how continuous measurement changes the number you present today.