Before You Automate a Process, Measure Where It Breaks

The first process worth automating is not the one that makes the most noise. It is the one you can describe, measure and hand back to the team without hiding its exceptions. Before talking about models, answer three questions: which decision repeats, what input triggers it and which error you cannot accept.

This checklist helps you decide before building anything. It is not a full audit or an ROI promise. It is a filter so an AI conversation ends in a workflow that is measurable, maintainable and useful to the team.

1. What repeated decision is someone making today?

Write the decision in one sentence, with a subject and a verb: “the purchasing team decides whether this invoice needs review”. If you cannot name the decision, you still have a broad problem, not a use case.

Also write down who makes it, what information they check and what happens next. AI should not replace a vague decision; it should support a decision that already exists.

2. What concrete input starts the workflow?

Choose an observable input: an invoice, a delivery note, an ERP row, a tender or an internal request. Keep a representative sample and separate normal cases from exceptions.

If each person receives a different input or interprets it by a different rule, the first job is not adding AI. It is defining what counts as an input and which fields matter.

3. Which part is a rule, and which part needs judgement?

Mark every step as rule, retrieval or judgement. Rules should be automated without a model. Retrieval can be solved with data and links. AI belongs where variation is real and the team can review the result.

This separation stops us calling a script, a chatbot or deterministic automation an “agent”. It also makes clear where the system must escalate when it is uncertain.

4. What does good look like, and which error is unacceptable?

Define one simple measure before the pilot: time per case, percentage of complete cases, number of reviews or time to decision. Define the boundary too: which errors stop the flow, who reviews them and how the data is corrected.

Without this pair — expected result and unacceptable error — you can only say the demo “seems to work”.

5. Where is the evidence for each decision?

Every output should retain the input, the decision, the evidence consulted, the confidence and the person who intervened. Traceability is not a compliance extra: it is how you improve the workflow without arguing from opinions.

At Zero Ops we use systems in production and leave the capability inside the team. The current operational proof point is 5 systems in production, not a collection of demos. The number does not replace workflow context, but it sets the standard: production, evidence and transfer.

6. What can the team maintain when we leave?

List the maintenance tasks: correcting a rule, reviewing an exception, updating a source and measuring the result. If all of them depend on the provider, you have bought dependency, not activated a capability.

The right first workflow is one the team can understand, review and operate with a clear guide.

7. What would you remove before automating?

Before building, remove steps nobody can defend, standardise the data and simplify the handoffs. Only then automate the deterministic work and reserve AI for the judgement that remains.

That order complements the Zero Friction Method and avoids repeating the problem described in why AI projects fail, without turning this checklist into another general explanation of the method.

The decision at the bottom of the page

By the end, you should be able to write one line:

“We will improve this workflow, with this input, this decision, this measure, this boundary and this owner.”

If you cannot write it, the next action is not building. Observe the process for a week and measure again.