Almost every business we meet already knows it has an automation problem. What it usually does not have is a defensible answer to which piece of work to hand over first. The choice tends to get made by whoever complains loudest, or by whichever demo was most impressive that quarter — and both are bad selectors, because neither is measured against the hours the business actually loses.
The first build carries more weight than any that follow it. It sets the internal story about whether this kind of work pays, it teaches your team what to expect from us, and it funds the second one. So it is worth spending a week choosing it properly. This is the method we run in discovery, in the order we run it.
Measure four things, in this order
Two of these tell you what the process is worth. The other two tell you what it will cost to automate — which is the half most selection exercises skip, and the half that decides whether the project survives its first month in production.
Volume times handling time
How many times a month does this run, and how long does one pass actually take? Ask the person doing it, then watch them do it once. The two numbers are rarely the same, and the observed one is the one to use.
Exception rate
Out of a hundred runs, how many go a way the standard path does not cover? A process with a 3% exception rate is a build. A process with a 40% exception rate is a conversation about why the exceptions exist, and usually a different project.
Systems touched
Count every place data is read from or written to, including the spreadsheet on somebody’s desktop and the WhatsApp thread with the supplier. Each system is an integration, a credential, a permission conversation and a failure mode. Two is comfortable. Five is a programme, not a first project.
Who owns the output
One named person has to be able to say whether the automated version is right. If the output is consumed by four departments and owned by none of them, there is nobody to sign off go-live, and the build will drift for months waiting for a decision that has no owner.
The scoring sheet
Put every candidate process on one row. Fill it in from observation rather than from memory — the point of the sheet is to make two processes comparable when their advocates are not equally persuasive.
| What to record | How to get it | What it tells you |
|---|---|---|
| Runs per month | Count them in the source system, not from an estimate | Whether the saving is real or rounding |
| Minutes per run | Observe one full pass, including the interruptions | The true handling time, which is usually higher |
| Exceptions per 100 | Sample a month of real cases and count the odd ones | How much of the build is the unhappy path |
| Systems touched | List every read and write, spreadsheets included | Integration cost and the number of things that can break |
| Output owner | Name one person, not a department | Whether anybody can sign this off |
| Deadline pressure | Does it collide with month-end, payroll or a VAT return? | What happens on the day it fails |
A worked example: supplier invoices at a distributor
Take a forty-person trading business in Muscat. Supplier invoices arrive by email, as PDFs, as photographs from a driver’s phone, and occasionally on paper. Someone in accounts opens each one, reads the supplier, the date, the total and the VAT, keys it into the ERP, files the document in a shared drive, and chases the ones that do not match a purchase order.
- Runs per month: 400, counted from the ERP’s posted-document log.
- Minutes per run: 6, observed — 3 to read and key, 3 lost to filing, renaming and going back to the email.
- Annual hours: 480, which is around a quarter of one person’s year.
- Exceptions per 100: 12 — mostly photographs of poor quality, and invoices that do not match a purchase order line.
- Systems touched: 2 — the shared inbox and the ERP. The shared drive is a third, but it is a write with no logic in it.
- Output owner: the finance manager, who already reviews the posting batch daily.
That is a good first project, and it is good for reasons that have nothing to do with how interesting it is to build. The volume is real and countable. The exception rate is high enough to matter but low enough to design for. It touches two systems. Somebody already checks the output every day, so there is a person who can say whether the automated version is right — and a baseline to measure it against.
The build we would scope from that row is not "AI reads your invoices". It is: capture from the inbox, extract the six fields the ERP needs, match against the open purchase order, post the clean ones, and stop on anything unmatched with the document and the reason attached for the finance manager to resolve. The 12% goes to a person on purpose. Automating the 88% is worth roughly 420 hours a year; automating the last 12% badly is worth less than nothing, because the errors surface a month later in a reconciliation.
Four kinds of work we turn down
The rules live in one person’s head
If nobody can write down how the decision is made without saying "it depends, ask Fatima", the process is not ready. The fix is to write the rules down first — which is genuinely useful work, and cheaper than discovering the gaps mid-build.
The process changes every month
Some work is deliberately unstable: a promotion structure, a pricing experiment, a reporting format that follows whoever is asking. Automating a moving target buys you maintenance, not hours.
The output is a judgement
Whether to extend credit to a customer, whether a claim is genuine, whether a hire is right. The gathering that feeds those decisions automates well. The decision itself should stay with a person, and a system that pretends otherwise just moves the accountability somewhere it cannot be seen.
The saving is under two hours a week
Every automation has a maintenance cost: credentials expire, a supplier changes their template, an API version is retired. Below roughly a hundred hours a year, the maintenance eats the saving, and you would have been better off with a shorter form.
Size the first build so it can be judged
A first project should be finishable in two to four weeks and evaluable in one number. That is not a commercial preference; it is what makes the evaluation possible at all. A six-month first build cannot be judged until month six, by which time the argument about whether it worked is unwinnable in either direction.
- Write down the metric before anything is built — hours, cycle time, error rate. One of them, not three.
- Measure the baseline for two weeks with the current process running. Without it you are comparing against a memory.
- Cut the scope until a working version fits in a month, even if that means covering only the clean cases at first.
- Design the exception path in the same sprint as the happy path. It is not a phase two; it is half the process.
- Agree what would make this a failure, out loud, before starting. A team that cannot say what failure looks like will call anything a success.
What to measure after go-live
Check at 30, 60 and 90 days, and look at four things: hours actually moved, cycle time from arrival to posted, exception rate against the baseline, and rework — the cases a person had to touch twice. The last one is the honest measure. An automation that halves the handling time but doubles the corrections has not saved anybody anything; it has just moved the work later in the month, where it is harder to see.
If the hours have not moved, say so and find out why. Usually the answer is unglamorous: the exception rate was higher in practice than in the sample, or the people who used to do the work are still checking every case because nobody told them they could stop. Both are fixable in a week. Neither gets fixed if the project is declared a success on the day it goes live.
The short version
- Count the runs and observe the handling time. Do not accept estimates for either.
- Sample a month of real cases for the exception rate.
- Count the systems, including the spreadsheets nobody mentions.
- Name the one person who can approve the output.
- Reject anything whose rules are unwritten, unstable, judgement-shaped, or worth under two hours a week.
- Measure the baseline before the build, and pick the single number that decides whether it worked.
- Design the exception path first-class, and let it escalate to a person with the reason attached.
None of this requires a consultant, and you can run the whole exercise in a week with a notebook. If you do it and the honest answer is that nothing clears the bar, that is a real result and worth knowing — it means your time is going somewhere other than repeated work, and the next place to look is scheduling, handovers or approvals rather than automation.
Read next
Fawtara reaches SMEs in 2027. Start with your data.
Oman’s e-invoicing mandate covers the remaining VAT-registered businesses from August 2027. Most of the work between now and then is not software — it is the state of your customer and item records.