5.4Measuring the ROI of an automation
The essentials in 30 seconds
- Basic formula: time saved ≈ (duration × frequency) − supervision — the gain lies in repetition.
- Broad benefits, real costs: quality + responsiveness + avoided costs versus subscriptions, operations, build, maintenance.
- Decision: positive ROI AND stable process AND reasonable effort — otherwise, simplify first.
Running case — Lina arbitrates between three projects
In Oran, Lina has three ideas: automatic reminders, a real-time dashboard, smart request triage. Rather than going by feel, she estimates for each duration × frequency, supervision and costs, plus process stability. Reminders win: frequent, stable, simple to build. Continuation of cases 5.1-5.3 — Lina prioritises instead of automating in all directions.
Continuation of cases 5.1-5.3 — Lina puts figures first before investing automation time.
1. Calculating time saved
Automate, yes, but for what benefit? Measuring ROI (return on investment) lets you prioritise and justify your projects. The basic calculation: time saved = (task duration × frequency) − supervision time of the automation. Lina estimates her reminders: a few minutes each, dozens per month — the monthly total reveals the real volume, where the «unit» view misleads.
The classic trap: judging a task «per unit» («it's only a few minutes»). Always multiply duration × frequency over a month or a year, and add hidden costs: mental load, oversights, errors, interruptions of focused work.
2. Benefits versus costs
Beyond time, value quality (fewer oversights and errors), speed (responsiveness), and avoided cost (hours, costly mistakes). Against that, put the real cost: subscriptions, consumed operations, build and maintenance time. Lina compares both columns for each project, without inflating gains or forgetting maintenance.
A good ROI is time saved exceeding those costs, on a stable task. This measurement guides: what to automate first, and when an automation is not worth it.
3. Prioritise, don't automate everything
A positive ROI is necessary but not sufficient: factor in the stability of the process (a process that keeps changing makes the automation obsolete fast), the risk (a poorly supervised critical automation costs dearly on a silent error) and the effort to build. Lina discards smart triage: still-shifting process, high effort — she postpones it until after standardisation.
Prioritise tasks with high ROI AND stable AND reasonable to build. Sometimes it is better to first simplify or standardise a process before automating it.
🔎 Concrete example — Lina's arbitration
Duration × frequency, with no promises.
Reminders: unit duration × monthly frequency − supervision + errors avoided.
− costs (subscription + operations + build + maintenance).
→ project A (reminders): frequent + stable + simple → priority.
→ project C (triage): shifting + costly → postponed until after standardisation.Reading: the comparison is relative between projects, not a promise of gain.
Lesson: always multiply over a month or a year before deciding.
Section vocabulary
- ROI
- Ratio between benefits (time, quality, avoided costs) and costs (subscriptions, build, maintenance).
Simple example: Lina compares reminders, dashboard and triage on the same grid.
What it is not: a guaranteed quantified promise of gain.
Reflex: did I price both columns before deciding?
- Time saved
- Saving = (duration × frequency) − supervision of the automation.
Simple example: Lina aggregates her reminders over a month instead of judging them one by one.
What it is not: isolated unit duration («it's only a few minutes»).
Reflex: always multiply over a month or a year.
- Maintenance cost
- Time and money to keep the workflow alive after setup.
Simple example: Lina plans adjustments when the process moves.
What it is not: only the initial build cost.
Reflex: who maintains, and how long per month?
- Avoided cost
- Spending not incurred thanks to automation (hours, costly errors).
Simple example: Fewer forgotten reminders at Lina's.
What it is not: an automatic, guaranteed gain.
Reflex: which errors does the automation really prevent?
- Prioritisation
- Choosing projects by ROI, stability and effort.
Simple example: Lina launches reminders, postpones triage.
What it is not: automating everything as soon as it is technically possible.
Reflex: stable AND reasonable, or merely profitable on paper?
In practice — Calculating and tracking ROI
- For one workflow, estimate the manual task time × its monthly frequency = gross time saved.
- Subtract supervision/maintenance time and add quality gains (errors avoided, responsiveness).
- Price the costs: subscriptions, consumed operations, initial build time.
- Compare: is the ROI positive and lasting? Rank your projects by ROI to prioritise the next ones.
Ready-to-say script — defending an ROI priority
«In Oran, I compared our three projects with the same grid: duration × frequency, supervision, costs and stability. Reminders come first: frequent, stable, simple. I suggest launching them first, with no promise of figures: we'll measure real time after one month and arbitrate the rest. »
Say in an arbitration meeting to prioritise on a shared method, without promising a quantified result.
Copy-paste template — ROI grid
ROI — PROJECT SCORECARD
PROJECT: _______________
DURATION × FREQUENCY (monthly): ___ × ___ = ___
− SUPERVISION / MAINTENANCE: ___
+ QUALITY (errors avoided, responsiveness): ___
COSTS (subscriptions + operations + build): ___
STABLE? YES / NO · REASONABLE EFFORT? YES / NO
DECISION: launch / postpone / simplify firstSolo / small budget
Lina alone: a three-row table is enough — one project at a time, measured after one real month.
Small business / small team
Compare at most two projects with the same grid, decide fast, measure afterwards.
SME in Oran
Lina presents the grid in a meeting in Oran: same assumptions for all, visible arbitration.
Team getting started
Everyone prices one project with the grid, then assumptions are challenged before deciding.
✓ Best practices
- Multiply duration × frequency (the gain lies in repetition).
- Also value quality and responsiveness, not just hours.
- Prioritise tasks with high ROI AND stable AND reasonable to build.
✗ Common pitfalls
- Judging a task «per unit» (a few minutes is nothing).
- Automating an unstable process (costly maintenance).
- Believing a positive ROI is enough (stability and risk count too).
Key takeaways
- ROI = benefits (time saved, quality, avoided costs) − costs (subscriptions, build, maintenance).
- Time saved ≈ (task duration × frequency) − supervision.
- Also value quality (fewer errors) and responsiveness, not just hours.
- Measuring ROI guides prioritisation: what to automate first, and what not to automate.
48h challenge — apply tomorrow
Fill in the ROI grid for 2 projects (duration × frequency + costs): which comes first, and which do you postpone?
- I can write the time-saved formula from memory.
- My 2-project grid is filled in and arbitrated.
- I know why a positive ROI is not enough.
Frequently asked questions
How to price the gain when the task only takes «a few minutes»?
Look at cumulative frequency, not the unit: multiply duration × frequency over a month or a year to reveal the real volume. Add hidden costs: mental load, oversights, errors, interruptions. A micro-task repeated hundreds of times is often a better candidate than a rare big task. ROI hides in repetition, not in unit duration.
Should everything be automated as soon as ROI is positive?
No. A positive ROI is necessary but not sufficient: factor in process stability, risk (silent error on a critical one) and build effort. Prioritise tasks with high ROI AND stable AND reasonable. Sometimes it is better to first simplify or standardise before automating.
How to measure the ROI of an automation?