The automation nobody owns.

Somewhere in most agencies there is a workflow that runs every night and nobody fully understands. It was built by a contractor, or by a developer who has since left, or during a busy fortnight by someone who meant to document it afterwards. It works. Nobody touches it. Everybody hopes it keeps working.

This is the most common condition of automation in production, and it is not a discipline problem. It is what happens by default, because ownership is the one part of the build that nothing forces you to complete.

Working is not the same as owned.

A workflow that runs successfully every day looks identical, from the outside, to one that is properly maintained. The difference only becomes visible at the moment it stops, and by then the questions arrive all at once.

What was it doing. Which systems does it touch. Whose credentials is it using. Why was that filter added. Is anyone else depending on its output. Who is allowed to change it.

If those answers live in one person’s memory, the automation is not an asset. It is a liability that happens to be behaving.

The four ways ownership disappears.

The builder leaves

The most obvious one. A contractor finishes, an employee moves on, an agency relationship ends. Everything they knew that was not written down goes with them, and what was not written down is usually the reasoning rather than the mechanics.

Credentials outlive people

The workflow authenticates as someone’s personal account because that was fastest during the build. When they leave and their account is deactivated, the automation stops, and nobody connects the two events for several days.

Requirements drift

Small changes accumulate. A filter here, an exception for one client there, a hardcoded date that made sense once. Each is trivial and undocumented, and together they become business logic that exists nowhere except inside the workflow.

No named owner

The most common of all. The project ends, the agency hands over, and no individual on either side is named as responsible. Everybody assumes someone else has it.

The cost is paid at the worst moment.

Unowned automations do not fail gently. They fail when the vendor changes an endpoint, when a token expires, when volume grows past a limit, and those events do not wait for a convenient week.

The cost is not the repair. It is the archaeology before the repair: reading a workflow to work out what it was supposed to do, with no specification to check against and someone asking hourly when it will be fixed. Work that would take two hours with documentation takes two days without it, and it is done under pressure by somebody who did not build it.

There is a second cost that is quieter. Nobody will change an automation they do not understand. So the client stops asking for improvements, works around its limitations by hand, and the system slowly becomes less useful than the manual process it replaced.

What ownership actually requires.

Ownership is not a feeling, it is a small set of artefacts and one name.

A named person, on both sides. Someone at the client who is accountable for it running, and someone at the agency who is accountable for fixing it. Not a team. A person, written down, with a stated route when they are unavailable.

Credentials that belong to the system. Every connection authenticated as a service account or integration user, never a personal login. This alone prevents the most common silent failure, and it means access can be revoked when someone leaves without breaking production.

An exported copy you control. The workflow definition, held somewhere outside the platform running it. If it exists only inside a vendor’s account, ownership is contingent on that account.

The reasoning, not just the steps. Anyone can read a workflow and see what it does. What they cannot recover is why. The filter that excludes one customer type, the delay before the third step, the field written twice. Each needs one sentence.

A statement of what is not handled. The failure cases deliberately left out, and why. Without it the next developer cannot tell the difference between a considered decision and an oversight, and will spend their time reimplementing things you chose not to do.

A way to tell it is working. Something a non-technical person can check without opening the builder. If the only way to know is to ask the person who built it, that person is a single point of failure regardless of what the documentation says.

The question that reveals it.

There is a fast diagnostic for any automation, yours or a client’s.

If the person who built this were unavailable for a month, could somebody else fix it when it broke?

Not improve it. Not extend it. Just restore it. If the honest answer is no, the automation is unowned, and the fix is a few hours of writing rather than anything technical.

Retrofitting an inherited one.

Clients often arrive with a workflow they did not build and cannot support. It is worth an hour before you agree to maintain it.

Read it end to end and write down what it does in order, in plain language. List every credential and whose account each belongs to. Identify what triggers it and what depends on its output, which is frequently more than anyone expects. Note every hardcoded value, because each one is a decision somebody made for a reason nobody recorded. Then work out how you would know it had stopped.

That last question usually has no answer, and adding one is the highest-value hour you will spend on an inherited system.

Say it out loud at handover.

The moment ownership is most easily established is the moment the project ends, and it is also the moment everyone is keenest to move on.

It takes one conversation. Who is responsible for this running. Who do they contact when it breaks. What have we deliberately not covered. Where is everything written down. Put the answers in writing and send them to both sides.

A system that survives its builder leaving is a different asset from one that does not, and the difference is an afternoon’s work at the end of a project rather than anything clever during it.

If your agency has inherited an automation nobody can support, or you are about to hand one over and want the ownership handled properly, send us what it does and what it connects to. We will tell you what would be needed to make it supportable. Describe it here.