The question of whether something will pay off gets asked before the work and answered after it. The gap between those two moments is where AI budgets disappear: the hypothesis is stated in words, validated on impressions, and by the time a number is needed, nobody remembers what the process looked like to begin with.
What follows is what we fix before the first line of code. It is not a twenty-page financial model: one table is usually enough — filled in honestly, and before the start.
Baseline: the thing you cannot reconstruct later
A baseline is not a recollection of how things were. It is a recorded measurement of a specific quantity, over a specific period, from a specific source. The difference matters. “Reports used to take a day” is a memory. “In February and March, one client report took 6.5 hours on average according to the time tracker” is a baseline.
A baseline cannot be recovered after go-live. Once the process changes, the “before” data stops being produced, and asking people about their past throughput is pointless: they already work differently and judge the past through the present.
The practical consequence: if there is no data for a baseline, the project's first task is not automation but measurement. Sometimes that means two weeks of manual tracking, and that is fine. What is worse is saving those two weeks and then arguing about the result for a year.
The measurement window must be comparable to the one the result will be measured over. An admissions campaign in EdTech, December in retail, a holiday August in B2B services — seasonal periods cannot be compared with non-seasonal ones, and that is the most common way to produce a beautiful number that means nothing.
DemoThree ways to model the effect
Almost any initiative reduces to one of three effect types. They must not be merged into a single number: they differ in how reliable they are and in how long they take to appear.
Time freed up
High reliabilityHours savedcost of the role that was spending themBoth quantities are measurable and checkable: hours come from a process measurement, the hourly cost from payroll.
Additional revenue
Medium reliabilityChange in conversionvolumeaverage dealgross marginFour assumptions instead of two, and conversion depends on more than the initiative: season, price and demand mix move on their own.
Losses prevented
Low reliabilityIncident frequencycost per incidentchange in frequencyA comparison against an event that did not happen. Worth calculating; not worth presenting as a measured fact.
Use the method that gives the most reliable estimate, not the largest one.
Time freed up is the most honest way into the calculation. It has one trap: time does not turn into money on its own. If a specialist spends three fewer hours a week on reports, the effect exists only once those three hours are filled with something billable. Otherwise what changed is workload, not economics.
In our experience, the question of what exactly the freed-up time will be used for gets discussed less often at the business-case stage than it should — and it is the question that most often turns a calculated effect into an unnoticed one.
- Data source:
- Практика Aplora · 2026-08-24
- Calculation method:
- An observation across the team's assessment projects, not the result of a sampled study.
- Limitations:
- An estimate, not a measured fact: applicability to your context needs separate verification.
The cost of ownership people forget
Development cost almost always makes it into the model. Running cost almost never does — and it is running cost that determines whether the solution is still alive a year later.
Compute and recognition cost — the one line that grows with volume
The process owner's time on exceptions: a queue nobody clears halts the whole workflow
Regular recalibration of rules and criteria — processes change, and the solution changes with them
Integration maintenance: an external API change breaks data collection without warning
Quality monitoring — without it, degradation shows up only as complaints
A practical rule: if the effect stops being visible once running cost is subtracted, the initiative is better left unstarted. A solution that barely pays for itself on paper will demand more attention than it returns in practice.
What a working model looks like
- 1
The quantity and its source
What exactly is measured and where the number comes from. The source is a system, not a person: “CRM export”, not “according to the manager”.
- 2
Baseline over a comparable period
The value before the work started, with start and end dates. The period is chosen so it can be repeated after go-live.
- 3
Target value and its justification
Not “improve” but a specific number and where it came from: the physics of the process, practice in a comparable setup, or a hard ceiling.
- 4
The formula that converts it to money
How a change in the quantity becomes currency. The formula is written before measurement, otherwise it gets fitted to the result.
- 5
Assumptions, listed
Everything taken as true without checking. This is the most useful part of the model: when the result diverges from the forecast, the error is almost always here.
- 6
Stop criterion
The value below which the work ends. Defined before the start — after the start there is always a reason to move it.
When not to model at all
There are cases where modelling is a way to postpone a decision rather than make one. If an operation happens once a quarter, if the process changes faster than it can be documented, if the task has no owner — the economics can be calculated, but the work should not start anyway, and it is more honest to say so before the calculation.
A negative result from the model is still a result — and it is the cheapest way to arrive at one.
Methodology notes, by e-mail
The same material we publish here: how to model the economics of an initiative, where rollouts break, and what to verify before work starts. Once a month at most, no market news and no sales e-mail.
