Before you automate it, watch someone do it.

There is a specific failure mode in automation work that I have seen in businesses of every size: the automation that works perfectly, consistently, at scale—and produces the wrong result every time.

It usually happens when the people building the automation documented what the process is supposed to do rather than watching what it actually does.

Two versions of a process

A sales operations team I worked with had a process for sending new clients their onboarding pack. Simple on paper: client signs, contract is marked complete, pack goes out automatically within an hour. They wanted to automate this.

Before building anything, I asked to watch it happen.

What I saw was different from the documented process. The contract was sometimes marked complete before the client had actually paid a deposit. The onboarding pack had three versions—one for retainer clients, one for project clients, one for hybrid—and the version selection happened in someone's head, not in the system. Two out of five packs were manually edited before sending because they contained incorrect pricing assumptions. The CSM who managed this kept a separate spreadsheet tracking which clients had "actually" started versus "technically" started.

If you automate the documented process, you automate the sending of wrong packs to clients who have not yet paid. Reliably. At scale.

What observation reveals

Watching someone do a job for thirty minutes typically reveals:

Workarounds. The steps that are not in the documentation because they developed as coping mechanisms. These exist for a reason, and they need to be understood before being removed.

Judgement points. The moments where a human reads context and makes a micro-decision. "This client is a new business, so I'll use the simplified version." These are the moments that automation most often breaks—not because the automation is wrong, but because it lacks the context to make the call.

Exception frequency. How often the standard path actually applies. In the onboarding example above, the standard path (single version, no edits, immediate send) applied to fewer than half the cases. An automation that handles the standard path perfectly but ignores exceptions creates more work than it saves.

Data reliability. What the system says versus what the person knows. The spreadsheet a CSM keeps because the CRM cannot be trusted is a data quality problem dressed as an administrative quirk.

The automation question

After observation, the question I ask is: which part of this process actually requires automation?

Not "how do we automate this process"—but "which part of this process should be automated, which part needs to be redesigned, and which part genuinely requires human judgement?"

In the onboarding example, the right answer was not to automate the existing process. It was to:

• Fix the data model so that "contract signed," "deposit received" and "client status" were distinct fields with distinct meanings.
• Define clear criteria for pack selection that could be captured at contract stage.
• Automate the standard path with a human review flag for exceptions.
• Retire the spreadsheet by making the CRM reliable enough to replace it.

This took longer than automating the original process would have. It also produced a system that reliably sent the right pack to the right client at the right time, which is what they actually wanted.

Apply this

Before building any automation, spend time watching the work:

• Ask to observe the process being done, not have it described to you.
• Count how many steps are not in the documentation.
• Identify every point where a human makes a decision that is not in the instructions.
• Measure exception frequency: how often does the "standard" path actually apply?
• Find the gap between what the system records and what the person knows.

The automation that comes after this observation is smaller, simpler, and far more useful than the automation you would have built from the documentation alone.

The most expensive automations are the ones that faithfully encode a broken process. Observation is the cheapest form of insurance against that.