How to standardize a process before automating it.

When people talk about standardizing, many think of heavy manuals, bureaucracy, work locked into place. It’s the opposite. Standardizing means removing pointless variability, the kind that makes the same process produce different results depending on who runs it.

Take preparing a quote. If three salespeople produce three different quotes for the same request, with discounts decided on a hunch and unpredictable turnaround, that process is ready for no automation at all. An agent working on a base like that only multiplies the inconsistency. Here’s the difference between before and after.

The first step is to capture how the process works today, for real. And here’s the first trap: the flow people describe almost never matches the one they execute.[1] On the official document, the order comes in and gets fulfilled in four steps. In reality, in between, there’s a phone call to the warehouse, a check against someone’s personal Excel, and an email to clear an exception that comes up one time out of three.

To map the real as-is, don’t ask “how is it done,” observe. Sit alongside whoever runs the process while they work (shadowing), note every click, every switch between tools, every decision made on the fly. The goal isn’t the perfect diagram: it’s surfacing the hidden steps, the shortcuts, and the exceptions no one ever put in writing.

Mapping the steps isn’t enough. The real value of a process is often in the decisions the senior makes on instinct: how they spot a risky customer, when it’s worth making an exception, which supplier to call first. That’s tacit knowledge, and if it stays in one person’s head, the agent can never inherit it.

Three practical techniques work to pull it out.[2] The first is the targeted interview: instead of “how do you do your job,” ask “tell me about the last time it went wrong, and what you did.” Stories surface the unwritten rules. The second is recording: filming or recording the expert at work captures the automatic checks they’d never think to state out loud. The third, today, is AI: transcribing calls, tickets, and chats and having it extract the recurring criteria cuts weeks off the slowest part.

A process that’s ready for automation has no gray areas. Every fork needs a rule written in the form “if X happens, do Y.” It’s the step that turns the senior’s “it depends” into something anyone, or an agent, can execute.

Back to the quote: “whoever prepares it decides the discounts” isn’t a rule, it’s a gray area. “Discount up to 10% decided by the salesperson; above 10% needs the manager’s sign-off; never above 25%” is a rule. The exceptions need to be written the same way: what to do if the customer is already past due, if the request is off-catalog, if a piece of data is missing. The exceptions you don’t write down are exactly the points where automation will break.

A standard process needs standard data. If the information you need is scattered across the back-office system, an Excel on someone’s desktop, and a shared folder, no procedure holds up for long, and no agent can work on top of it reliably.

The work here is choosing, for that process, where the official data lives and making sure everyone uses it. You don’t need to rebuild all the systems: you need to decide which is the source of truth for the few pieces of information that workflow touches, and switch off the shadow copies. It’s the same prerequisite that later makes it possible to give that data to an agent without propagating errors.

Now put it all together into a standard operating procedure, the SOP. It doesn’t have to be a treatise: it has to be clear enough to let a new person run the process without asking for help. Short sentences, one action per line, and the elements that matter.

One last element, often forgotten: the baseline. Before automating, measure how the process performs now, how long it takes, how many errors it produces, how much rework. Without a starting point you’ll never know whether the agent, afterward, is really making things better. The baseline is what turns “it seems to work” into a number.

And yes, there’s an opposite school of thought, which holds that it’s better to automate right away and standardize as you go.[4] For low-risk processes, and when the standard is impossible to define at a desk, it can make sense. But for a core, high-impact process, skipping the standard is the shortcut that leads straight into the 95% of projects that fail.

Let’s line up the five steps on a concrete case. A services company wants to automate onboarding new customers, today handled differently by each of its three account managers.

Map (step 1). Sit alongside the three accounts for a week. You discover that the “four-step” onboarding actually has eleven, and that two critical steps (collecting documents and the initial setup) are done in a different order by each one.

Capture (step 2). Interviewing the most experienced account surfaces a rule no one had written: for enterprise customers, they always run an alignment call before the setup, and this halves the problems afterward.

Rules (step 3). “If the customer is enterprise or the contract exceeds €20,000, an alignment call is mandatory before the setup.” The exceptions (missing documents, incomplete data) become explicit steps with an owner.

Source of truth (step 4). Customer data lives only in the CRM, no longer also in the three accounts’ personal sheets. One record, kept up to date.

SOP and baseline (step 5). The procedure is written on a single page. The baseline says: today onboarding takes 9 days on average, with 30% of cases bouncing back for missing data. Now there’s a number to beat.

Only at this point is the process ready for an agent. And it’s no accident that the first piece of work, the one that actually created value, didn’t require a single line of AI code. After building the agent there’s one last link, adoption: getting the team to actually use the new flow. We cover it in how to get your team to adopt AI.