The L3 Activation Test: the day your team solves a new problem without calling us

Most automation projects are declared done the day the system works. We declare them done the day the client team modifies one without calling us. The distance between those two days is the whole point.

When a project ends, almost nobody measures what happens next. The consultancy delivers, the client pays the last invoice, and everyone assumes it worked. Nobody comes back three months later to ask the only question that matters. Does your team use what we built? Can they touch it? Can they extend it to a problem that was never in the original scope?

We call that question the L3 Activation Test. It is our canonical metric for success. We do not measure by billed hours or by slides delivered. We measure by what happens after we leave.

The problem: delivery gets mistaken for success

The traditional way to measure a consulting project mixes up two different things. Delivering a system and having the client adopt it are separate outcomes. The first is controlled by the consultancy. The second depends on whether the internal team can operate it, adapt it, and actually want to use it when nobody is around.

A lot of automation projects die from success. The system works while the people who built it are nearby. One changed requirement, one new supplier, one new business rule, and the flow stops. If responding to that change means calling the builder again, the project did not activate anything. It created a new dependency, usually with better technology than the old one.

That is the trap we avoid with the Zero Friction Method. First you remove work that adds no value, then you standardize what remains, and only at the end do you automate. The goal is not more systems. The goal is a system that lives without us. The best system is the one your team can change on a random Tuesday without asking permission.

The three levels of activation

We use three levels to measure that transfer. They are the ladder from the minimum to what actually matters.

L1. Operative. The team uses the system day to day without help. They start it, feed it, handle the expected incidents. That is the functional minimum. If a team does not reach L1, the project never closed. You delivered one more dependency.

L2. Adaptive. The team modifies the system on their own. They change configurations, adjust rules, rewrite a prompt, add a small integration. They understand the reasoning behind the design, not just the manual. That is real progress, but the territory is still the one we defined.

L3. Generative. The team spots a problem that was never in the original scope and starts solving it with the transferred approach. They do not call us. They do not wait for permission. They apply the same logic we use. Map before moving, observe before prescribing, remove before automating, measure before deciding. That is the day activation happened.

Only L3 justifies using the word activation in a proposal. L1 and L2 are necessary steps. L3 is the proof.

Why this test makes consultancies uncomfortable

Because you cannot pass it in the presentation room. You cannot even pass it on the last day of the project. You have to wait. You have to come back months later and ask what happened when nobody was watching.

Most automation proposals do not include a test like this. That is why they promise deliverables and bill hours. Activation cannot be billed by the hour. It is demonstrated over time.

We put the test up front. We know the outcome we are after, the independence of the client, can only be demonstrated by a test that happens after we are gone.

What this looks like in practice

It is not theory. We run every engagement through this ladder. The standard we set for ourselves is real production. Today that means five live systems in industrial production and zero failed implementations. The number does not replace the context of each workflow, but it sets the bar. Production, evidence, transfer. In that order.

The test is not passed on its own. The system is handed over with documentation, clear operating rules, and a team trained to handle the expected cases. Then comes the part that actually decides. Whether the team dares to touch what we built when we are no longer there.

What you can take away in fifteen minutes

If you are evaluating an automation proposal, ask these three questions.

1. What test measures whether the project worked, and when is it run?
2. What level of autonomy is the internal team expected to reach, and how is it demonstrated?
3. What happens when a new requirement appears? Does the team solve it, or do they call the builder?

If the answer to the third one is calling the consultancy again, the project did not end. A dependency relationship started.

If you want to try it

If you have an operational flow that depends on specific people and you want to know what can actually be automated, that is a good place to start: complete the AI checklist and we review it together, or get in touch for a short operational diagnostic. We put the activation test up front, in the proposal too.

Keep reading: the Zero Friction Method and why AI projects fail.