When Too Much of the Business Depends on Copying and Pasting
An order arrives. Someone copies the customer into another system. Someone else checks the payment. Another person creates the paperwork. A spreadsheet is updated. Somebody emails to say it is done. No single step is difficult. The problem is doing it two thousand times.
Does this sound familiar?
The same information is typed into two systems, by two people, on the same day.
Somebody’s morning is spent checking whether things that should have happened have happened.
A routine report is assembled by hand because the numbers live in three places.
Approvals move by email, and nobody can say where a particular one has got to.
A spreadsheet has quietly become the system that runs a department.
You have hired someone whose job is mostly re-keying.
Automation does not start with AI. It starts with the process
Manual work accumulates because each step was reasonable when it was added. A check was introduced after something went wrong. A spreadsheet was a quick fix for a month and is now four years old. An export exists because two systems could not talk, and somebody bridged the gap with their morning.
None of that is visible on an org chart, and it rarely appears in a budget, because the cost is spread thinly across a lot of people’s days. It shows up instead as a team that is busy without being productive, and as errors that are nobody’s fault.
So the first piece of work is mapping where the time actually goes — not guessing. Once the repetition is visible, the right tool is usually obvious, and it is often unglamorous.
Automation has to save more than it costs
Automation has a fixed cost and manual work has a per-occurrence one, so the arithmetic matters. A process that runs twice a year and takes an hour is not worth automating — the build would cost more than a decade of doing it by hand, and it becomes one more thing to maintain.
Equally, if two systems already expose decent APIs, the answer is a connection rather than a new platform. And if a task genuinely needs a person’s judgement, the right outcome is to give that person better information, not to replace their decision with a worse one.
We would rather tell you which of your processes are not worth automating than quote for all of them.
And where the repetition exists because two systems cannot speak to each other, the answer is usually a connection rather than an automation.
Six hands, or one exception
Before
After
The second version is not faster because a computer is quick. It is faster because five of the six handovers stopped needing a person — and the one that still does now arrives with the reason attached.
What automation actually turns out to be
Usually not AI. Most of the time it is a scheduled process that runs at four in the morning, an API call that replaces a copy and paste, a webhook so one system tells another that something has happened, or a small piece of bespoke software that applies a rule nobody should be applying manually.
The recurring shapes are status changes, approvals, notifications, document generation, imports and exports, recurring reporting, payment reconciliation, stock updates and customer communications. None of them is exotic. All of them are expensive when a person does them a thousand times.
Where AI genuinely helps is the part that needs judgement on unstructured material: classifying a document, pulling a figure out of an invoice that has never been in the same place twice, summarising a long thread, routing an enquiry to the right team. We use it there and not as an answer to everything.
Automation should make exceptions visible, not invisible
The failure mode of automation is that it hides things. A process that silently succeeds 99 times and silently fails once is worse than one that always needed a human, because now nobody is looking.
So the design rule is that the automated path stays quiet and the exception gets a person. Our own product works this way: Order Exceptions watches refunds and raises one alert per problem — not one per check — so the only thing reaching a human is the case that actually needs someone.
How we approach it
Understand
Map where staff time disappears, and how often each thing actually happens.
Decide
Work out what is worth automating, what only needs connecting, and what should be left alone.
Build
Implement it with the simplest tool that holds — usually a scheduled job, an API or a small application.
Move
Run it alongside the manual process until the two agree, then retire the manual one.
Stay
Watch it. An automation nobody monitors is a manual process with a longer feedback loop.
We’ve solved this before
Order Exceptions — our own product
A store marks an order refunded the moment the merchant clicks it. That is a commercial record. The money moves under a separate payment transaction, which can sit pending, fail hours later, or never happen at all. Checking that by hand means opening two systems per order, for every order, forever — so in practice nobody does, and the gap is found by a customer.
Order Exceptions connects with read-only access and follows every refund through to the payment underneath. Three rules cover the ways a refund quietly does not happen, and it raises one alert per problem rather than one per check. The automation stays silent; the exception gets a person.
What this usually involves
Questions we get asked
Do we need AI for this?
Usually not. Most of what looks like an AI problem is a missing integration or a scheduled job. We use AI where judgement on unstructured material is genuinely required, and say so when it is not.
How do you decide what is worth automating?
Frequency times effort, against the cost of building and maintaining it. Something that happens twice a year rarely clears that bar, and we will tell you.
Will this replace people?
In our experience it removes the part of the job people like least and cannot do reliably at volume. The judgement stays with them, and they get better information to apply it to.
What happens when the automation gets something wrong?
It should raise the exception rather than hide it. We design for the failure case first, because a silent failure is worse than a manual process.
Can you automate around systems we do not own?
Often yes, through their APIs or a scheduled exchange. Where a supplier gives no route in, we will tell you that rather than build something fragile against their user interface.
What does your team do every day that they shouldn’t have to?
You don’t need to know the technical answer yet. Tell us what is causing the problem. We’ll start there.
Building and running business systems since 2000. The same team that builds it stays to run it.
Start a Conversation