Discovery
The ROI matrix: what's worth automating, and what isn't
Not every process deserves attention. How we rank workflows on volume, recoverable time, risk and feasibility — and why the first project isn't the biggest one.
The most important output of discovery isn’t what can be automated. It’s what should be, and in what order.
The four questions
We ask the same four questions about every process.
1. What’s the volume?
How many cases pass through it a month, and how long does one take? A ten-minute task that happens twice a week isn’t worth automating, even if it’s technically easy. A two-minute task that happens four hundred times a day is 27 working hours a month.
The trap here is intuition. People name the annoying task, not the expensive one. Those are rarely the same. Which is why we measure rather than ask.
2. How much actually frees up?
This is the most commonly overstated number. Automating 60% of a process is not a 60% saving — the remaining 40% still needs handling, the exceptions still need review, and the new system needs supervision.
We work with realistic estimates: net savings are typically 70–80% of gross in year one. If someone promises 95%, ask what they’re doing with the exceptions.
3. How bad is it when it’s wrong?
This is where things separate. Two dimensions:
- Is it reversible? A misrouted inbound email is reversible. An initiated payment isn’t.
- Will anyone notice? If the error shows up immediately, it’s manageable. If it surfaces three months later at close, that’s a different category.
Where an error is neither reversible nor immediately visible, a human stays in the loop, regardless of how good the measurements are.
4. How hard is it to build?
- Is there an API, or is the system only reachable through its screen?
- Is there enough historical data to build an eval set?
- Does the process live inside one team, or shuttle between three departments?
The last is the most common hidden cost. A technically simple process spanning three departments is slower than a hard one inside a single team.
The matrix
The four answers collapse into two axes: value (volume × recoverable time) and difficulty (risk × implementation).
| Low difficulty | High difficulty | |
|---|---|---|
| High value | Now. Start here. | Next round. Worth it, needs groundwork. |
| Low value | If there’s room. Cheap win, not a priority. | No. Write down why, and move on. |
What goes in the “no” box
This is the part customers appreciate most, and the least impressive-looking.
For every “no” we write down what would change the decision. For example: “Not worth it today at 12 cases a month. If the planned acquisition takes that to 150, revisit.” Or: “Technically solvable, but the system has no API and the vendor contract expires next year — revisit then.”
That way the matrix isn’t a one-off verdict. It’s a document you can pick up again in six months.
Where to start
Choosing the first project isn’t purely an ROI question. There’s another criterion: it has to earn credit inside the organisation.
So for round one we pick a process that
- is big enough that the saving shows up in a report,
- is simple enough to be live within three months,
- and runs in a team that’s open to it.
That last point is technically irrelevant and practically decisive. In a resistant department the best system in the world won’t spread — and it makes the next project harder too.
The priority order is part of discovery. If you want to know what would land in your first box, let’s talk.
Questions on this topic
Why not start with the most painful process?
Because the most painful one is often the riskiest. The first project doesn't need to be heroic, it needs to succeed — that's what buys organisational credit for the second.
What does this look like at your company?
If this problem sounds familiar, let's start with one process. Tell us which department burns the most manual hours — we'll come back with a concrete proposal.