Stop doing the same thing every Tuesday.
Every business has jobs that are done by hand because nobody ever got round to not doing them by hand: the weekly export, the reminder somebody has to remember, the same three fields copied between two systems. Each is small. Together they are a part-time job nobody was hired for.
- Starts with your actual process
- Failures raise an alarm
- Nothing sent in your name without approval
Not robots. Rules that run themselves.
Automation is writing down a decision your business already makes — "when a job is marked complete, raise the invoice and email the customer" — and having software make it consistently, at three in the morning, on the day the person who normally does it is on holiday. The value is not speed. It is that it happens every time, which is something no human process achieves for long.
- The step nobody forgets, because nobody has to remember it
- The same result whoever is on shift
- A record of what ran, when, and what it did
- Work that continues outside office hours
- Staff time back for the parts that need a person
The work that should not be work
If a task has no judgement in it and happens more than once a month,
it is a candidate.
- The same figures exported from one system and typed into another
- A reminder that only happens if a particular person remembers
- Invoices raised by hand from information already in the system
- Reports assembled the same way every month, by hand, from the same sources
- Chasing approvals by email and losing track of who has replied
- Nobody noticing a job failed until a customer points it out
What it looks like automated
- Data moves between systems on its own, in a defined format
- The reminder goes out on schedule, to whoever holds that role today
- Invoices raised from the record that was already there
- The report is in the right inboxes before anyone asks
- Approvals routed, recorded, and chased without anybody chasing
- A failure raises an alarm at us, not a complaint from a customer
Automating a process that is wrong does not fix it. It makes it wrong faster, and more consistently. We look at the process first.
What businesses automate first
Scheduled processes
Anything on a timetable: nightly imports, weekly reports, monthly billing runs, end-of-quarter exports.
Notifications and reminders
A renewal approaching, a document expiring, a job unassigned for two days — told to the right person while it still matters.
Moving data between systems
Website to CRM, CRM to accounts, orders to stock. Once, properly, instead of by re-typing.
Approvals and sign-off
A request routed to whoever must approve it, recorded when they do, and chased when they do not.
Documents generated
Quotes, invoices, certificates and reports built from the data already held, in your own format.
Onboarding and offboarding
The eleven things that happen when a customer signs up or a member of staff leaves, none of them forgotten.
Data checks and tidying
Duplicates flagged, missing fields reported, and a check that two systems still agree.
Filing and archiving
Documents named, stored and retained by a rule instead of by whoever saved them.
Most of these need to read or write somebody else's system, which is why automation and API integration usually arrive as one project.
How we do it, and what we will not do
How an automation is built
- We map the process as it really runs, not as the manual describes it
- We say which parts should be automated and which should stay human
- It is built to be safe to re-run, so a retry cannot duplicate work
- Every run is logged: what it did, to what, and when
- Failures alert somebody instead of passing silently
- A dry-run mode where the consequences justify one
- Anything sent to a customer is agreed with you first
- You can see what it is doing, and switch it off
What we will not automate
- A decision that needs judgement, dressed up as a rule
- Messages sent to your customers in volume without their consent
- Scraping a service in a way its terms forbid
- A process nobody can explain — we will map it with you first
- Anything that moves money without a human approving it
- A workaround for a system fault that should simply be fixed
Automation that sends email or messages to customers has to respect consent and the current marketing rules. We build the sending; you own the list and the consent.
The difference between automation and a time bomb
An automation nobody is watching is not saving you work — it is deferring it. These are the things that decide which one you have.
A log of every run
What ran, when, what it touched, and what it decided. The first thing you need when something looks wrong.
Failures are loud
A job that fails raises an alert. Silence means it worked, and that only means something if failure is noisy.
Safe to re-run
Built so running it twice does not send the email twice or raise the invoice twice — because one day it will run twice.
Limits and guards
Sensible ceilings on how much one run may do, so a bad input cannot turn into two thousand emails.
Visible to you
A screen showing what is scheduled, what ran and what failed — not a black box only we can see into.
An off switch
Every automation can be turned off without a deployment, by you, immediately.
Map it, then automate it
1. Watch the process
What actually happens, including the exceptions and the bit somebody does from memory. This is where most of the value is found.
2. Decide what to automate
Not all of it. The steps with no judgement in them, and a clear handover to a person for the ones that have.
3. Simplify first
A process with a redundant step should lose the step, not gain an automation for it.
4. Build it safely
Logged, re-runnable, alerting on failure, and switchable off — before it is trusted with anything that matters.
5. Run it alongside
For the first cycles it runs in parallel with the manual process, and the two are compared. Then the manual one stops.
6. Watch and adjust
Processes change. An automation that is not reviewed becomes a rule your business no longer follows.
Automations need an owner
Something it depends on will change — a supplier alters a file format, a password expires, a system is upgraded. When that happens the automation stops, and somebody has to notice. That is what the support arrangement is for.
- Failure alerts monitored
- Run history reviewed
- Changes when your process changes
- Credentials and integrations kept current
- New automations, quoted first
- A named person who knows your setup
Automation questions
What should we automate first?
The task that is done most often, by the most people, with the least judgement in it. Frequency matters more than how long each one takes — a two-minute job done forty times a week is a better candidate than a half-day job done twice a year.
A useful test: if two members of staff would do it identically, it is a rule, and rules can be automated. If they would do it differently and both be right, it needs a person.
Is this AI?
Usually not, and that is deliberate. Most business automation is a set of rules that must be right every single time — raise the invoice, send the reminder, move the record — and rules are the right tool for that, because they are predictable, testable and explainable when somebody asks why.
Where a job genuinely involves reading unstructured text or classifying something ambiguous, a language model can be the right component, with a person checking the output before it has consequences. We will say which of the two your job is, and we will not add AI to a process that does not need it.
Do you use tools like Zapier or Make?
They are good at what they are good at, and if one of them solves your problem for a few euros a month we will tell you so rather than quote for a build. Custom work earns its place when the logic is more complicated than those tools express cleanly, when the volume makes per-task pricing expensive, or when the process is central enough that you do not want it living in a third-party account.
What happens when an automation fails?
It alerts. Every automation we build logs what it did and raises an alarm when it cannot complete, because the dangerous failure is the quiet one — the job that stopped running in March and was noticed in June.
Where it makes sense, failed runs retry automatically, and they are built so that a retry cannot duplicate what the first attempt already did.
Will this replace staff?
That is your decision, not ours, and it is worth being straight about. In the businesses we work with, automation usually absorbs work that was being squeezed into evenings and Saturdays rather than removing a role — but we are not going to pretend it never has that effect anywhere.
Can you automate something in software we did not build?
Sometimes. It depends entirely on whether that software offers an API, a reliable export, or a documented way in. If it does, this is an integration question. If it offers nothing at all, we will tell you that honestly rather than build something fragile that screen-scrapes it.