The Zero Friction Method: why we eliminate before we automate

The Zero Friction Method is the operational order we apply when we enter a company: five verbs in strict sequence. One, eliminate what shouldn’t be there — the steps no member of the team can defend when asked directly. Two, standardise what remains — define the canonical for each variation the operation has been postponing for years. Three, simplify what’s heavy — cut the trivial human decisions that don’t need a committee. Four, automate the deterministic — real code, OCR, integrations, not Excel-as-glue. Five, augment with AI — only for what needs judgement at scale. AI is step 5, not step 1, and skipping steps is the structural reason a six-figure budget project ends, eighteen months later, as a pretty demo parked in a cloud. The real deliverable of the method isn’t the final system: it’s that the client’s team can apply the same sequence without us, six months after we’ve gone.

There’s a question almost nobody asks in a first meeting that changes everything that follows: does this step need to exist?

Not “how do we automate it?” Not “what AI tool fits here?” The question is earlier and more uncomfortable, because it forces an admission most operations have been postponing for years: part of the process exists by habit, not by need.

We work inside mid-sized industrial companies where the order flow has fourteen steps, the monthly close eats two Saturdays from the same person, and the integration between the ERP and the TMS is held together by a spreadsheet only Maria understands. When they call us, the sentence is almost always the same: “we want to put AI into this.” And our answer is almost always the same: AI comes later. Much later.

This isn’t a slogan. It’s an operational order, with five verbs, that we apply the same way every time. We call it The Zero Friction Method.

The five verbs

The order matters more than any specific tool. Skipping a step is the reason a six-figure AI project ends up, eighteen months later, as a polished demo sitting in a cloud no one opens.

One verb at a time.

1. Eliminate what shouldn’t be there

It’s the free step, and that’s why almost nobody does it.

When we walk into an operation, the first thing we ask is to sit with the people who actually run the process, not the people who describe it on a slide. We ask them to walk us through the flow on the real screen, with a real case. In under an hour, without exception, several steps appear that no team member defends when asked directly: “why does this step exist?”

The most common answers are three. “Because that’s how we’ve always done it.” “Because a customer used to ask for it, but they’re not a customer anymore.” “Because the old system needed it and we never took it out.”

Eliminating those steps doesn’t require technology, code, or budget. It requires permission to do it. And that permission is almost always there: the operations director has suspected for months that they’re useless, what was missing was the space to audit them.

Once they’re gone, the flow weighs half before anyone touches anything technical. That’s the foundation everything else sits on. If you skip this, whatever you automate later carries the same operational debt, just running faster. We wrote up the full session, the step-by-step protocol and the three mistakes that wreck it, in how to find the steps in your flow that shouldn’t be there.

2. Standardize what survives

After elimination, what remains is still uneven. Each customer has its exception. Each supplier has its format. Each branch has its little variation that “we’ve always done it that way out of respect for how they work.”

Standardizing isn’t imposing rigidity. It’s defining the canonical version, writing down what the default looks like, and accepting that exceptions are exceptions, not the same rule entered five different ways.

When a catalog has the same brand spelled four different ways, the problem isn’t data. It’s the decision they’ve been postponing for years: accepting that cleanup is part of the work, not a separate project. When one supplier sends invoices as PDFs, another as spreadsheets, and a third in email bodies, the hard part isn’t reading them, the hard part is deciding which canonical format they all need to land in.

Standardization is unglamorous work, doesn’t sell in pitches, and nobody runs case studies on a supplier canonical. But without it, step 4 doesn’t work and step 5 amplifies the chaos instead of fixing it. How it gets done in practice, with the concrete catalog example, we lay out in standardize before you automate.

3. Simplify what’s heavy

What survived elimination and got standardized now gets simplified.

Simplifying means reducing the number of human decisions the flow requires. Not the important ones, the trivial ones, the calls that get made by hand today and that nobody enjoys making. The operational rule is direct: if the criterion fits on a sticky note, it doesn’t need a committee.

In a spend approval flow, simplifying might mean any purchase below a threshold from a recurring supplier gets approved automatically, without an email to three people. In an incident flow, it’s deciding routine incidents have a templated response and only the atypical ones get escalated. In a closing flow, it’s removing the two intermediate spreadsheets that don’t change the result, just move it from one place to another.

After this step, the flow is clean enough that a deterministic system can run it without anyone watching. How to identify the simplifiable decisions and the handoffs between systems, with the concrete protocol and three examples, we lay out in simplify what’s heavy.

4. Automate the deterministic

Here, and not before, the code shows up.

Automation doesn’t mean AI. It means a rule-based system does what a person used to do typing the same thing twenty times a day. A system that pulls fields from an invoice with conventional OCR. An integration between the ERP and the TMS that goes from spreadsheet-as-glue to a real connection. A dashboard that updates when the data changes, not when someone remembers to export it.

Automation at this point works because the process is already clean. If you automate the flow from step 1 without eliminating anything, you end up with a fast system doing things that shouldn’t exist. Apparent efficiency goes up, operational debt does too.

Almost all the value of an operational project gets unlocked at this step, not the next one. AI closes. Deterministic automation carries the load.

5. Augment with AI

AI shows up when it’s earned its place, not before. And when it does, it does what no rule-based system can: make decisions that need judgment at scale.

Catching the anomaly the human eye misses on a tired Friday afternoon. Categorizing variants of the same brand when a new spelling shows up that the rules don’t cover. Answering an ERP question in plain English without anyone writing SQL. Suggesting the most likely account code for a new invoice based on the supplier’s historical pattern.

For all of this, AI is the right tool. For the four steps before, it isn’t.

When the order is followed, what the customer experiences isn’t “we put AI in.” It’s “I stopped having to look at invoices in my day,” “I know last quarter’s sales by region in five seconds,” “the dashboard tells the story without anyone rebuilding it every Monday.” The AI is invisible. What’s visible is the operational result.

Why skipping steps breaks everything

The most expensive mistake we see in the market is exactly this: companies hiring an AI project to automate a process nobody has reviewed. Step 1 gets skipped. Step 2 gets skipped. Step 3 gets skipped. They try to enter directly through step 4 or step 5.

The result is predictable. The AI learns the patterns of the broken process. Exceptions are still exceptions, now more expensive to handle. The five spellings of the same brand are still there, now with a model on top treating them as five different entities. The fourteen steps in the flow are still fourteen, now executed by an agent that confuses the person on the team who was supposed to operate it.

And worst of all: the customer’s team walks away with the feeling that AI “doesn’t work.” When what didn’t work was the order.

We’ve seen this enough times to know the pattern is structural, not accidental.

The real deliverable

The Zero Friction Method has a property that rarely shows up in presentations: the real deliverable isn’t the system we built at the end. It’s that the team operating it, six months after we’ve left, identifies a new problem and solves it with the same five-verb sequence, without us.

That’s what we measure. If the customer’s team has learned to ask “does this step need to exist?” before asking us to automate something, we’ve done the job. If the team only knows how to operate the specific system we delivered, we’ve done something closer to a pilot with a happy ending, which is better than nothing but isn’t what we promised.

We build to leave, not to stay. The method is what makes that possible.

If your operation is thinking about AI

One question before picking a tool or a vendor: has anyone walked your most expensive flow step by step, on the real screen, with a real case, in the last six months?

If the answer is no, that’s the first step. Not the AI. Not the system. The question of whether all those steps in the flow need to exist.

When that question has been asked honestly and someone has acted on the answer, AI fits like a glove. Before that, it doesn’t.

How many steps does your most expensive flow have today, and when was the last time someone looked at them one by one?

---

If your company is thinking about putting AI into an operational process and you want to walk through these five verbs on your real flow before picking a tool, the 2-week operations roadmap is the first door. We come out with the flow mapped, the steps that should go identified, and a plan prioritized by impact.