Workflow automation removes the recurring manual work your business has stopped noticing it does. Not a transformation programme — one task at a time, chosen because it is frequent, deterministic and currently done by a person.
The work worth automating is the work nobody complains about
Ask an owner what wastes the most time and you will get the dramatic answers: a difficult client, a supplier who let them down, a bad hire. Those are real, but they are episodic. The recoverable time is almost always somewhere else — in a task that happens on the same day every month, has always been done by hand, and therefore never gets escalated.
Typical examples, all of which we have seen more than once:
- Re-typing the same data into two systems because they do not talk to each other, and a person is the integration layer.
- Assembling a monthly report by exporting three CSVs and pasting them into a template.
- Matching incoming payments to invoices or tenants by eye.
- Sending the same reminder, notice or follow-up to a different name each week.
- Checking a queue, a shared inbox or a folder to see whether something arrived.
None of these are hard. That is the problem — they are easy enough that automating them never becomes urgent, and they quietly cost several hours a month indefinitely.
How we scope it
We start by mapping what actually happens rather than what the process document says. Those differ almost every time, and the gap is usually where the automation opportunity is hiding — the undocumented workaround somebody invented two years ago and never mentioned.
Then we split the task into the parts that are deterministic and the parts that need judgement. We automate the first and leave the second alone. Full automation is rarely the goal; reducing the manual work to only the cases that genuinely need a human is.
A worked example is on the automated rent ledger write-up: payments match themselves, and anything the matcher is not confident about gets flagged rather than guessed. The exception queue is the feature, not a limitation.
What we build with
Whatever fits: n8n, native APIs, scheduled scripts, or a small purpose-built service. We are not resellers for any of them and have no incentive to push one.
The tool matters far less than two other things. First, whether the automation still works in six months when somebody renames a field or rotates a credential — which is a question about error handling and alerting, not about which platform you chose. Second, whether anyone other than us can understand it. An automation nobody can maintain is a liability dressed up as an asset.
You get the source, the credentials and the documentation as a matter of course. Nothing we build is a hostage.
When automation is the wrong answer
Often enough that it is worth saying plainly.
- The process is about to change. Automating a workflow you are three months from replacing is money spent on the old thing.
- It happens twice a year. The build cost will never be recovered. Write it down instead.
- The real problem is upstream. If a report takes four hours because the data going in is inconsistent, automating the report just produces a wrong answer faster.
- It is actually a missing form. A surprising share of “we need automation” conversations end with a shared form, a validation rule, or a naming convention — and no automation at all.
Common questions
How small does a business have to be for this to be worth it?
Small is often better. A five-person company feels ten recovered hours a month immediately, where a large one absorbs it. What matters is whether the task is repetitive and manual, not headcount.
Do we have to replace the software we already use?
Almost never. Most of the value lives in the gaps between systems, not in the systems themselves. Connecting what you have is cheaper and less disruptive than replacing it, and we will say so even when a rebuild would be a bigger engagement for us.
What happens when it breaks?
It will, eventually — an API changes, a credential expires, a supplier alters a file format. That is why we build alerting in from the start and why most clients keep a light retainer. The failure mode we design against is not “it broke” but “it broke silently and nobody noticed for a month.”
How long does a first project take?
The operating review is short and cheap by design. The first automation is scoped to be genuinely small — one task, shipped and running — because a first engagement should prove the approach rather than commit you to a roadmap.
Further reading
How I automated rent reconciliation — a worked example, including the three signals that make automatic matching trustworthy and the test for whether it is worth doing at all.
Start with the operating review
Tell us which task somebody does on the same day every month. We will tell you whether it is worth automating — and sometimes the honest answer is no. See the rest of the division on CAO Technologies, or get in touch.