Ivara Labs
Most first automations are chosen by whoever complained loudest at the last team meeting. It is an understandable way to pick, and it is usually wrong.
Complaints track irritation, not cost. The task people bring up is typically long, infrequent and memorable — a quarterly report, a month end close. The task that actually drains the year is short, constant and invisible, because four minutes never feels worth mentioning.
Getting this choice wrong is expensive twice. You spend the build budget, and you spend the organisation's patience. A first automation that removes four hours a month rarely earns a second one.
The loudest complaint is the wrong signal
Here is the pattern we see in nearly every operation we map. Two workflows, the same team, one obvious and one invisible.
Illustrative figures, but the ratio is the point, and it holds more often than not.
The report is the one that gets named. The status answering costs more than three times as much, and it never comes up, because no single instance of it is worth complaining about.
It is also the better automation target by some distance. It is high frequency, low variance, and entirely mechanical — the answer already exists somewhere in the system, it just has to be found and repeated by a person. Where the asker is a client rather than a colleague, a portal removes the question rather than answering it faster.
Frequency beats duration. A four minute job done two hundred times a week outruns a four hour job done monthly, every year, without fail.
Look for workarounds, not opinions
Asking a team what to automate returns opinions. Looking at what they have built for themselves returns evidence.
Every workaround is a receipt for a broken workflow. When you map an operation, these are what you hunt for:
- A spreadsheet that lives outside the system of record, maintained by hand
- A recurring calendar reminder somebody set for themselves, to do a thing the system should have prompted
- A saved email draft used as a template, copied and edited each time
- A person who is the only one who knows the current state of something
- The same number re-typed into a second system because the two do not talk
- A group chat that exists purely to chase status
Nobody proposes these in a meeting. People are quietly a bit embarrassed by them, which is exactly why they are reliable evidence. A workaround is what remains after somebody decided the official process was not going to work and solved it themselves.
Put a number on it before you choose
Once you have a shortlist, cost each candidate. Most teams count only the time spent doing the work, which understates the answer badly. There are three lines, not one.
WAITING occurrences/week × hours sitting in a queue × 52
REDOING occurrences/week × error rate × minutes to fix × 52 ÷ 60 × rate
──────────────────────────────────────────────
use a loaded rate: salary + tax + benefits + overhead
Waiting is the line people forget, and it is often the largest. An approval that takes ninety seconds of actual work but sits in an inbox for three days costs you the three days. The client does not experience ninety seconds. Neither does the job behind it in the queue.
Redoing is the line people hide. Nobody logs rework honestly, so ask a different question: how often does this have to be corrected after the fact, and who catches it? A workflow with a fifteen percent correction rate is not a workflow, it is a workflow plus a second undocumented workflow.
Rank the shortlist by the total of those three lines. The order will not match the order of complaints. That is the point of doing it.
Four gates before you build
The most expensive workflow is not automatically the right one to automate. Run the top candidates through these four gates. A candidate has to clear all four.
| Gate | The question | Build | Stop |
|---|---|---|---|
| Volume | How often does it actually run? | Weekly or more | A few times a year |
| Stability | Will it still look like this in a year? | Settled process | Mid restructure |
| Exceptions | What share of cases need a human call? | Under ~15% | Over ~30% |
| Detectability | If it gets one wrong, do you find out? | Caught same day | Found by a client |
The exception rate is the gate that decides the shape of the build. Under roughly fifteen percent, you automate the main path and route the rest to a human queue. Over thirty percent, you are not looking at a workflow at all. You are looking at a judgement call wearing a workflow costume, and automating it will produce confident wrong answers at speed.
Detectability is the gate people skip, and it is the one that causes real damage. An automation that fails loudly is a nuisance. An automation that fails quietly — a missed follow up, a mis-read invoice line, a client who never got the thing — is worse than the manual process it replaced, because at least a person occasionally noticed.
What to rule out
Leave these alone, at least for now
- Judgement that should stay human. Pricing exceptions, clinical calls, anything where the right answer depends on context a system cannot see. Some afternoons are supposed to be somebody's job.
- Broken processes. Automating a bad process does not fix it. It industrialises it. Fix the process on paper first, then automate the fixed version.
- Anything mid restructure. If the team is about to change how this works, you will build twice.
- Low frequency work. Under about once a week, the build rarely pays back before the process changes underneath it.
- Expensive-and-invisible failures. Where a wrong answer costs real money and nothing surfaces it, the automation needs a human approval step — or it needs to wait.
Pick one, with a number attached
Choose a single workflow. Write down what it costs today, in hours and in currency, before anything is built. Then build that one, ship it, and measure the same number again.
This matters more than it sounds. Teams that skip the baseline can never prove the automation worked, which means the second build has to be argued for from scratch instead of funded by the first. A number measured before you start is the cheapest thing you will ever produce, and the only evidence you will have later.
Ship one workflow completely rather than three partially. A finished automation with an exception queue and an owner keeps returning hours every week. Three half-built ones return nothing and quietly become somebody's maintenance problem.
How we do this
Before we build anything, we map the operation — not the org chart version, the real working version, where work stalls and people invent workarounds. What comes out is a written map of the real process, the handoffs costing time, what AI should carry and what it should not, and a build plan you could hand to anyone.
You keep the map either way, whether or not you build with us. Across our own operation and our clients', that method now runs 120+ automations in production and removes roughly 900 hours of manual work a month.
If you want the map, that is where our approach starts. If you already know which workflow is bleeding and want it gone, that is what we build.
Frequently asked questions
- What should a small business automate first?
- The highest frequency workflow that clears all four gates — volume, stability, a low exception rate, and detectable failures. In most operations that is intake, status answering, or moving the same data between two systems, not the monthly report everyone complains about.
- How do I calculate what a manual process costs?
- Add three lines: the time spent doing it, the time it spends waiting in a queue, and the time spent correcting it afterwards. Multiply by frequency across a year and by a loaded hourly rate. Waiting is usually the largest line and the one most often left out.
- Should I automate a process that is not working well?
- No. Fix it on paper first. Automating a broken process makes it fail faster and more consistently, and it hard-codes the flaw into a system that is then expensive to change.
- How many exceptions are too many to automate?
- As a rough rule, under 15% of cases needing a human decision is comfortable — automate the main path and route exceptions to a queue. Above about 30%, the work is judgement rather than process, and automating it produces confident wrong answers.
- Should the first automation be big or small?
- Small and complete. One workflow shipped fully, with an exception queue and a named owner, returns hours every week and pays for the next build. Several partial automations return nothing and create maintenance work.