How to Document an Automation So Anyone Can Maintain It

Write down five things: what the automation does, what starts it, what tools and logins it touches, what it looks like when it breaks, and who to call. That is the whole list. It does not need a technical manual. It needs to survive you or the builder being unavailable for a while.

What actually needs to be written down?

• What it does. One plain sentence, the actual outcome, not the code. Something like "sends a welcome email and adds the new member to the community platform."

• What starts it. The trigger: a form submission, a daily schedule, a new row in a sheet, whatever kicks it off.

• What it touches. Every tool and account it logs into or writes to, and who owns each login.

• What broken looks like. The real signal: a missing email, an error message in one specific place, a report that stops updating.

• Who to call, and what to check first. One person or company to contact, and the first thing they should look at before anything else.

Do you need a full technical manual?

No. Most of what gets written about this online is built for IT teams running hundreds of systems, and none of it fits a small business with one or two automations. You do not need diagrams, escalation tiers, or a change log. A short page a normal person can actually read beats a technical spec nobody opens.

Where should the document live, and who should have it?

Not in the builder's inbox, and not only in their head. Keep it somewhere you already check: a shared drive folder, a doc your team already uses, or wherever you keep other business records. Whoever owns the business should be able to open it without asking anyone for access first. If a password manager holds the logins, note where that is too. Never put the actual passwords in the document itself.

What happens if you never write it down?

The automation does not stop working. It just becomes a black box. Nobody touches it because nobody understands it, so small problems sit unfixed, and the day it actually breaks you are stuck hunting for who built it and how it worked instead of just reading a page. That is the exact spot covered in what happens when the person who built your automation leaves, and this document is the fix for it, written before you need it instead of after.

The point of the document is not to be complete. It is that a stranger could pick it up cold and know where to start.

What does the actual template look like?

1. One sentence: what it does and why it exists.

2. What starts it, the trigger.

3. Every tool and login it touches, and who owns each one.

4. What it looks like when it breaks.

5. Who to contact first, and what to check before calling them.

6. The date it was last updated, and by whom.

Six lines. One page. Fill it out when the automation is built, not after it breaks.

How is this different from documenting your whole business process?

A process document explains how your business runs: who does what, in what order, and why. This is narrower. It only covers one automation's mechanics: what it does and how to keep it alive. You can have a great process document and still lose an automation the day the builder leaves, because the automation itself was never written down anywhere. Do both. They are not the same job.

---

We hand every client this same short brief when we build them an automation or an AI agent, one page, filled out before the project ends, not after something breaks. Pair it with agreeing on ownership before you hire (see what to agree on before you hire an AI agent builder), and you close the gap that usually costs small businesses the most: not the build itself, what happens after it. If you want to see what a trained AI agent actually looks like before you build one, try the demo.

---

FAQ

Do I need special software to write this down?

No. A plain document, a shared note, or a page in whatever tool you already use for other business records works fine. The template matters more than the tool.

Should the builder write it, or should I?

Ask the builder for a first draft while everything is fresh, then read it yourself and make sure you understand every line. If you cannot follow it, it is not done.

How often should I update it?

Only when something about the automation changes: a new tool, a new trigger, a different owner. It does not need a schedule. It needs an update whenever the facts change.

What if I already have an automation with nothing written down?

Write it now, even after the fact. Open the tool, trace through what it actually does, and fill in the five items above. Worth doing before anything breaks, not after.

Does an AI agent need different documentation than a simple automation?

Same five items, plus one: what content or data the agent was trained on, so a new owner knows what to update if the source material changes. Everything else on the list stays the same.