Four figures without which there is nothing to calculate
- Volume: how many operations pass through the process each month — requests, documents, enquiries, checks.
- Cost per operation today: employee time multiplied by the cost of their hour, plus the cost of errors and rework.
- The share you can really hand over to the system: not one hundred per cent — the complex cases will stay with people.
- Running cost: model calls or infrastructure, plus maintenance and quality control.
Monthly savings equal the volume multiplied by the cost per operation and by the share handed over, minus the running cost. The payback period is the project budget divided by those savings. Everything else in the calculation refines these four numbers.
Where calculations usually lie
Time saved is treated as money saved
Half an hour freed up for each of ten employees does not turn into money by itself: it has to be either filled with other useful work, or used to avoid hiring the next person as volume grows. If neither happens, the savings exist only in the presentation.
One hundred per cent automation is assumed
The realistic share you can hand over is established on the pilot, and it is almost never complete. Calculate on a conservative estimate, not on the ideal scenario — and budget separately for the share of cases where a human check is added on top of the system’s work.
The cost of review is forgotten
While autonomy is partial, someone looks at the results. That work costs money and belongs in the calculation — otherwise the project “pays off” on paper, while the workload has simply moved from the person doing the work to the person checking it.
Tokens are counted instead of processes
The price of a thousand tokens says nothing about the cost of a solved task: one task can take dozens of calls, retries after errors and requests to external systems. The unit of the economics is a completed business process, not a request to the model.
The cost of data is ignored
If the task needs documents put in order or history collected, that is part of the project budget. This item is most often larger than the development — and it is exactly the one usually forgotten.
Three sources of effect, each calculated differently
- Lower costs: less manual work at the same volume. Calculated directly and easy to check — the most reliable type of effect for a first project.
- Lower losses: fewer errors, fines, missed deadlines and rework. Calculated from historical incident statistics; it requires that such statistics are kept at all.
- Revenue growth: faster replies to customers, more requests processed, higher conversion. The most attractive source and the most disputable — too many factors affect it, so it is better left out of the case for a first project.
How to calculate before the project if there is no data
A lack of exact figures is no excuse for fantasy. This order works:
- Measure by hand: take 20–30 real operations and time each one. It takes a day and gives the calculation its base.
- Take a conservative share to hand over and calculate with it. Keep the optimistic scenario separate, for comparison.
- Budget the running cost with a margin: at the start it is the least known figure.
- Work out the volume at which the project stops paying off. That threshold is more useful than the ROI figure itself.
What a decision on the project must contain
- the metric by which success is judged, fixed before the start;
- the baseline value of that metric today — otherwise there is nothing to compare against;
- the period over which the effect is expected, and the sign that the hypothesis has not held;
- the cost of stopping: what is lost if the project is wound down after the pilot;
- who on the company side is responsible for data and access — this derails timelines more often than development does.
When not to start the project
If payback comes out at more than a year, that usually points not to bad technology but to a scenario that is too broad. Narrow the task to the part with the highest volume and calculate again. If it still does not add up, the process is either too rare, or it needs to be redesigned first rather than automated. Automating a bad process makes it fast and bad.