There's a particular kind of disappointment that shows up a few months into an AI or automation project. The tool works, technically. It just doesn't do the thing it was meant to do, because it was built to follow a process that only ever existed in someone's head — and that person's version of "how we do it" turns out to have three exceptions nobody mentioned.
This isn't a tooling problem. It's an order-of-operations problem. Automation needs something concrete to automate, and if the underlying process was never actually written down — just understood, loosely, by whoever's been doing it the longest — there's nothing solid underneath the automation to hold it up.
The cost of undocumented processes, even without automation
Set automation aside for a moment. An undocumented process is already costing you: it's done slightly differently by whoever happens to be doing it that day, mistakes get repeated because nobody wrote down the fix last time, and the business becomes quietly dependent on specific people remembering specific things. None of that is really about AI. It's just what happens when process knowledge lives in heads instead of somewhere central.
Signs a process is still just tribal knowledge
It's usually easy to spot once you're looking for it. The process changes slightly depending on who's running it. New starters get a different explanation than the one before them. Nobody's entirely sure which version is current, so people default to whichever seems safest, or whichever way they were shown first. And when something goes wrong, the fix lives in someone's memory of "oh yeah, that happened before" rather than in a note anyone else can find.
None of this is a character flaw in the business or the people running it. It's simply what happens by default, in every business, until someone deliberately writes the process down.
Document, then store, then automate
The order matters more than it sounds like it should.
- Document what actually happens today — not the version in the old manual, the version people actually follow, exceptions included
- Store it somewhere structured and central, so it's the same answer for everyone who looks it up
- Automate only once there's something solid to automate against
Skip the first two steps and you're not automating a process. You're automating a guess, and asking it to hold up under real conditions it was never actually told about.
What this looks like in practice
Pick one process worth the effort — something that happens often enough to matter, and inconsistently enough to notice. Sit down with whoever actually does it and write down what really happens, step by step, including the judgement calls and the "unless it's this kind of client" exceptions. That becomes the source of truth. Store it centrally, where it can be checked and updated rather than quietly going stale. Only then does it make sense to ask whether any part of it could run on its own.
Why "we'll document it as we go" rarely works
It's a common compromise: skip the upfront documentation step and just capture the process while building the automation around it. In practice this tends to produce documentation shaped entirely by whatever the automation tool needed to know, rather than a genuine record of the process. The exceptions that don't fit neatly into the automation get quietly dropped instead of flagged, because nobody's explicitly job at that point is to write down the messy bits. The result looks like documentation and functions like automation config — useful for the tool, not much use to a new hire trying to understand how the job actually works.
A worked example
Take something as ordinary as processing a client refund. On paper, it might be "check eligibility, process in the system, notify the client." In practice, it's usually got exceptions nobody wrote down: a different approval path above a certain amount, a specific note required for one type of client, a workaround for a system quirk that's been there for years. Automate the paper version and the exceptions get missed every time, quietly, until someone notices the pattern of complaints.
Document the real version first — exceptions and all — and you've actually got something worth automating. The difference between those two outcomes usually isn't the quality of the automation tool. It's whether anyone bothered to write down what actually happens before they tried to teach a machine to do it.
Why this is worth doing even if you never automate anything
A documented, centrally stored process is useful on its own — for training new hires, for covering someone on leave, for catching the moment a process has quietly drifted from how it's meant to work. Automation is the bonus round, not the whole point. Getting the documentation right is what makes everything after it possible, whether "after it" is a new hire's first week or an AI agent taking on the repetitive parts of the job.