Three Minutes, Twelve Times a Day
Small manual work never shows up on a calendar or in a report, and still eats weeks of the year. Four questions that decide what to automate first, and where AI actually earns its place.
The arithmetic nobody does
Every business has one of these. Someone opens an email, copies an order number out of it, moves to another system, pastes it in, checks the row landed, ticks a box in a spreadsheet. Three minutes. No big deal.
Three minutes, twelve times a day, is thirty-six minutes a day. Three hours a week. Close to 140 hours a year — three and a half full-time working weeks, on one action nobody would ever call a problem.
And that is the cheap part. The expensive part is that on a busy day someone copies the wrong number, and you hear about it two weeks later from the other side — a client, a supplier, or the accountant.
Why it doesn’t feel like a problem
Because each instance is too small to be irritating. Nobody blocks out “13:40 — manual copy” in a calendar, nobody invoices for it, and it appears in no report. It is simply “how we work”.
What does show up are two indirect signs: an employee who is always busy and never quite accounted for, and faults that keep recurring at the same point in the process. Both point at the same place.
The first mistake: automating whatever annoys you most
Ask a business owner what weighs on them and the answer is almost always the dramatic thing — the quarter close, the annual report, that reconciliation that always gets stuck. Those are genuinely painful, but they happen four times a year, and each one differs from the last.
The right candidate for a first automation is usually boring: something that repeats every day, that nobody complains about, that takes a few minutes each time. Boring is precisely what a machine does excellently and a person does badly.
Four questions before automating anything
Before a single line of code is written, the process has to pass four questions. Failing one doesn’t mean it can’t be done — it means the price jumps, and you are probably better off starting elsewhere.
1. Does it repeat the same way?
Not “similarly” — the same way. If someone applies different judgement each time, what you have is not a process but a decision. Decisions get automated last, if at all.
2. Can the rules be stated in words?
If the person who owns the process can explain it to a new hire in five minutes, it can be programmed. If the explanation ends with “it depends, you get a feel for it” — the rule has to come out of that person’s head first, and only then into code. A large share of the work in projects like these is exactly that stage, and it happens at a whiteboard, not a keyboard.
3. Is the data already digital?
Email, file, spreadsheet, API — all fine. A page that arrives by fax and stays in a binder is a different story, not because it can’t be read, but because someone still has to get it inside. There is an answer for that too, and it comes next.
4. What happens when it gets it wrong?
This is the least-asked question and the most important one. An automation that sends a wrong reminder is a small embarrassment; an automation that sends a payment to the wrong supplier is something else entirely. The cost of an error is what decides how many checks, how many human approvals and how much audit trail go into the solution — not the budget and not the technology.
Where AI really comes in — and where it doesn’t
“Automation” and “AI” have collapsed into the same word over the past two years, and that confuses things. The split I work by is simple: if the rule can be stated precisely, ordinary code will run it faster, cheaper, and with the same result every time. A language model in place of an IF is waste — and worse, it introduces uncertainty where there was none.
Where models genuinely change the picture is unstructured input. A document that arrives from every supplier in a different shape, an email written in free text, a scan. Until recently that is exactly where automation ended and a person with a keyboard began.
That is the heart of FreightBridge: bills of lading reach freight forwarders in dozens of different layouts, and no regular expression on earth covers them all. The model reads the document — and the system around it is what validates, cross-checks against the known fields, and flags what needs a human eye.
FreightBridge — automated bill-of-lading intake→
And one point worth saying out loud: a model that is right 95% of the time, inside a process that needs 100%, is not a prompt-wording problem. It is an architecture problem. The answer is a verification stage — a business rule, a cross-check against another source, or a person who sees only the exceptions instead of everything.
Where you actually start
Not with a platform. The expensive mistake on the other side of the fence is to start by choosing tools, build infrastructure to cover every future scenario, and discover six months later that nothing is running in production yet.
You start with one process, end to end, one you can show a result on. And you measure it beforehand: how many times a day, how long, how many errors a month. Without that number there is no way to know whether it worked, and nothing to show whoever approves the next step.
My rule of thumb: if the first version isn’t running within two or three weeks, the scope is too large. Not because big things can’t be built — but because a process running in production teaches you within a week what it is actually missing, and a requirements document never teaches you that.
This doesn’t contradict what I’ve written elsewhere about thinking ahead — quite the opposite. The scope starts small; the structure starts wide. The first action you automate is one, but it is built assuming others will join it, or the second process will take the first one apart.
On that same thinking ahead: Two Glasses by the Bed→
In closing
Good automation doesn’t feel like a revolution. It feels like quiet, "a still small voice": the email that arrives already sorted, the report waiting in the morning, the row that entered the system without anyone typing it. Nobody is excited about it two weeks later — which is exactly the sign that it works.
And if you’re weighing up where to begin — look for the action that takes three minutes and that nobody complains about. That, usually, is where the first three weeks you get back are waiting.