Automation
Automation that proves it ran.
Most automations are judged by whether they threw an error. Ours are judged by whether the work actually happened. Every build comes with its own receipt: a record of what ran, what it produced and what it skipped, that you can read without asking anyone.
We use AI where it helps. Sometimes a simple rule or a better spreadsheet is enough, and we'll say so.
The terms
Scoped per build
- Price
- Fixed per build, agreed before we start
- Scope
- What it does and what counts as done, written down up front
- Where it runs
- On systems you already use, wherever possible
- Proof it ran
- Built in from day one, and in the price
- Handover
- Your team can run it without us
When people call us
Usually there is one job you don't trust.
01
The audit found a gap.
A job that stopped, or one that said it finished and did nothing. You want it rebuilt so it can't go quiet again.
02
There is a manual task you'd hand over if you trusted it.
Someone does it by hand every week because the last attempt to automate it went wrong and nobody noticed for a month.
03
Someone else built it and has gone.
An automation everyone relies on and nobody understands. It probably works. Nobody can show you that it does.
04
Your systems just changed.
A new finance system, a new CRM, a new rule to meet. The links between your systems have to be rebuilt, and this time you want to know they work.
What every build includes
The automation, and the proof that it ran.
- 01The automation itself, built on systems you already run wherever possible
- 02A check that every run happened, and that it produced what it should have
- 03A message the same morning if a run is missed, sent by the automation itself
- 04A person's sign-off wherever a wrong answer costs money or a filing
- 05A weekly note in plain English: what ran, what it produced, what it skipped
- 06A written handover so your own team can run and change it without us
Why the checks aren't extra
An automation that can stop without telling anyone is the problem we audit for. Selling one without the checks would be selling the next audit finding, so they are part of the build and part of the price.
What the receipt looks like
The weekly note
Illustrative example, not a client's system.
- Mon 06:00Ran
Sanctions check on new customers
38 checked, none on the list
- Tue 02:00Ran
Delete records past their retention date
112 records removed
- Wed 06:00Missed
Sanctions check on new customers
Didn't start. Alert sent at 06:30, re-run at 07:10, 41 checked
- Thu 18:00Empty
Send the day's invoices to the finance system
Ran, but sent nothing. The invoice list arrived empty. Fixed and re-sent Friday
- Fri 06:00Ran
Sanctions check on new customers
52 checked, 1 possible match passed to compliance
| When | Job | Result | What happened |
|---|---|---|---|
| Mon 06:00 | Sanctions check on new customers | Ran | 38 checked, none on the list |
| Tue 02:00 | Delete records past their retention date | Ran | 112 records removed |
| Wed 06:00 | Sanctions check on new customers | Missed | Didn't start. Alert sent at 06:30, re-run at 07:10, 41 checked |
| Thu 18:00 | Send the day's invoices to the finance system | Empty | Ran, but sent nothing. The invoice list arrived empty. Fixed and re-sent Friday |
| Fri 06:00 | Sanctions check on new customers | Ran | 52 checked, 1 possible match passed to compliance |
Every run this week is accounted for. One missed and recovered the same morning. One empty, cause found.
Built and run
We run these ourselves.
This is how we found the problem the practice is built around: a job of our own that had reported success for weeks without running once. Everything we build now has to prove it ran.
Publishing for this business
Blog and LinkedIn posts go into a review queue. Nothing goes out until a person approves it, and a scheduled job publishes it on a set day.
News drafting for a sports marketplace
Industry news is drafted twice a day into the same kind of queue. A person reads every draft before anything is published.
One page for every run
This business's automations report each run to one dashboard: what ran, what it produced, and what is waiting for review. A run that finished but produced nothing shows amber, not green.
Outreach for a recruitment firm
A client build that researched target companies, scored them and drafted messages. Nothing was sent until a person approved it, and a daily report showed whether every step had run.
What this isn't
- AI for its own sake. If a simple rule does the job, that is what you get.
- An automation with no person in the loop where a mistake costs money. Those get a sign-off step.
- Something only we can maintain. If your team can't run it after the handover, it isn't finished.
Questions
Before you get in touch.
How is automation priced?
Per build, once we have agreed exactly what it does and what counts as done. The checks that prove it ran are part of the build, not an add-on, so they are in the price from the start.
Do you use AI?
Where it helps, such as reading documents or drafting text for a person to check. A lot of useful automation needs no AI at all, and we'd rather give you something simple that works than something clever that needs watching.
What do you build with?
Whatever fits what you already run. Usually n8n, Microsoft Azure or plain .NET code. We'd rather extend what your team already knows than add a tool they have to learn.
What happens if it does stop?
You hear about it the same morning, from the automation itself, not weeks later from a customer or an auditor. That is the point of building the checks in.
Do I need the audit first?
No. If you already know which job you want automated, we can start there. The audit is useful when you aren't sure what else is running quietly.
Which job would you automate tomorrow if you trusted it?
Tell us about it. We'll tell you whether it is worth automating, whether it needs AI, and what the proof that it ran would look like.