Why the audit comes before the build

Most failed automation projects I get called into did not fail on the technology. They failed because the process being automated existed only in someone’s head, and the version in their head was the version that works on a good day.

The exceptions are the actual work

A process map that covers the happy path is not a process map. The interesting parts are what happens when a client pays half an invoice, when a vendor sends the wrong file, when someone is on vacation and the approval sits for a week. Those branches are where automation quietly breaks, and they are almost never in the first description anyone gives you.

If you cannot write the exception down, you cannot automate around it. You can only find it in production.

So the first week is spent tracking, not building. You keep a simple log of what actually eats the day. No workshop, no discovery call that goes nowhere. A week of real evidence beats an hour of opinions, and it usually turns up two or three things nobody thought to mention.

What comes out of it

The audit produces three things:

• A written map of every step, handoff, and exception — including the awkward ones.
• A build list ranked by hours saved against effort, each item with a fixed price.
• A plain statement of what you should not automate. Some work is cheaper left alone.

That last one matters more than it sounds. Automating a task that runs twice a month and takes four minutes is a way to spend real money buying ~1.6 hours a year back, and then owning a piece of software forever. The honest answer is often to leave it.

If any of this sounds like your operation, the audit is the place to start.