Every business that has automated anything has a piece of automation nobody understands. It works, it has worked for years, and the person who built it left in 2023.
This is a bigger operational risk than the manual process it replaced, because at least the manual process could be observed.
How it happens
Nobody sets out to build a dependency. Someone capable notices a repetitive task, writes something to handle it, and it works. It runs on their machine, under their account, using a folder they created.
Nobody asked them to document it, because nobody knew it existed. It just quietly did its job.
Then they leave, and within a few weeks something stops. Often the symptom appears far from the cause — a report stops arriving, a file stops being produced, a customer notices something before anyone internally does.
The five properties of automation that survives
1. It runs somewhere central, not on a person's machine
A scheduled task on somebody's laptop stops when the laptop is replaced, updated, or taken home. Automation that matters belongs on a server or a platform designed to run it.
2. It runs as a service identity, not as a person
Automation running under a personal account breaks when that person changes their password, enables new security settings, or leaves.
Use a dedicated identity with only the permissions it needs, and record what it is for. Modern platforms support application identities that do not depend on a person at all.
3. It fails visibly
Silent failure is the defining characteristic of dangerous automation. If it stops and nobody is told, the business carries on assuming it is running.
Every automated process needs: an alert when it fails, and a heartbeat when it succeeds for anything critical. The second matters because a process that stops running entirely produces no failure alert at all.
4. It is documented in business terms
Not a technical description. A page saying: what this does, why it exists, what triggers it, what it reads and writes, what happens if it does not run, who owns it, and where the code lives.
Written so that a competent person who has never seen it can understand what would break.
5. Somebody owns it
Named, and reviewed when people change roles. Ownership means being responsible for noticing it has failed and for deciding whether it is still needed.
The test of a well-built automation is not whether it works. It is whether a new person, on their first week, could find out what it does and why.
Finding what you already have
Most businesses have more undocumented automation than they think. Places to look:
- Scheduled tasks on servers and on individual workstations
- Mailbox rules that move, forward or auto-reply
- Spreadsheet macros, particularly on files that get emailed around
- Anything producing a recurring email or file at a fixed time
- Integration platforms with connections nobody remembers configuring
- Website forms sending to addresses that may no longer exist
Then ask your staff a direct question: what happens automatically that you do not understand? People know about these and assume somebody else does too.
The register
Keep a single list of every automated process. For each: what it does, who owns it, where it runs, what it touches, and what happens if it stops.
This sounds bureaucratic and it takes an afternoon. It is the difference between a departure being an inconvenience and a departure being an investigation.
Review it when somebody leaves, and when somebody joins — a new person is the best opportunity to test whether the documentation is adequate.
What to do when you inherit something nobody understands
Do not switch it off to see what breaks. That is how you find out during a busy week.
Instead: find out what it reads and writes, and work backwards from the outputs to who consumes them. Add logging so you can see what it actually does. Then document what you learn, even partially — a page saying "we believe this does X, it writes to Y, it runs at 6am" is far better than nothing.
Once understood, decide whether to keep it, rebuild it properly, or retire it. Frequently the requirement has changed and the automation is maintaining something nobody needs.
The rule to adopt
Nothing goes into production without an owner, documentation and failure alerting. It is a small overhead at build time and it is the entire difference between an asset and a liability.
This applies equally to automation built by a supplier. Ask where the code is stored, whether you have a copy, and what happens if they are unavailable — the same questions as in who owns your website.
Our automation team builds processes for UK businesses with documentation, alerting and ownership as standard, and audits inherited automation nobody understands. Start a conversation.
