You Cannot Automate What You Haven’t Defined

You Cannot Automate What You Haven’t Defined

The Situation

A common request in AI conversations goes like this: ‘We want to automate our customer service’ or ‘We want to use AI for our HR processes’ or ‘Can AI help with our invoice processing?’

These sound like reasonable requests. But they all share a hidden assumption — that the process being discussed is defined well enough to automate.

In many organisations, it is not.

Ask five customer service representatives how they handle a complaint, and you will get five different answers. Ask the HR team how performance reviews work, and you will discover variations that no one has reconciled. Ask finance how invoices are processed, and you will find workarounds built on workarounds.

These processes exist. They happen every day. But they exist in practice, not on paper. They live in the habits of the people who do them, adjusted over time through trial and error, shaped by individual preferences and informal agreements.

AI does not understand habits. AI understands instructions. And when the instructions do not exist, AI cannot help.

What process clarity means

A process is a sequence of steps that transforms inputs into outputs. Process clarity means being able to answer five questions:

What triggers the process? What event or condition starts things moving? A customer request? A calendar date? An approval? If you cannot define the trigger, you cannot automate the beginning.

What are the steps? In what sequence? Who does each one? What tools do they use? How long does each step take? If different people do it differently, you do not have a process — you have multiple processes wearing the same name.

What are the inputs and outputs? What information or materials go in? What comes out? What format? What quality standards? If these are undefined, AI cannot check whether it is doing the job correctly.

What are the decision points? Where does someone need to make a judgment call? What criteria do they use? What happens in edge cases? These are often where processes break down — and where AI needs the most guidance.

What are the exceptions? What happens when something goes wrong? Who handles unusual cases? What is the escalation path? Every process has exceptions. If you have not documented them, you have not documented the process.

Process clarity is not the same as process perfection. You do not need elegant, optimised workflows. You need honest documentation of what actually happens, including the messy parts.

The Nigerian context

Many Nigerian organisations operate with high tolerance for ambiguity. This is not a weakness — it is an adaptation to an environment where formal systems often fail and relationships fill the gaps.

The accountant knows which invoices to prioritise because she knows which clients are reliable. The operations manager knows which suppliers to call for urgent orders because he has built those relationships over years. The customer service team knows which complaints require escalation because they have learned from experience.

This institutional knowledge is valuable. But it is also fragile. When key people leave, the knowledge leaves with them. When the organisation grows, the informal systems do not scale. When AI is introduced, it cannot access knowledge that lives only in people’s heads.

There is also the workaround culture. When official processes do not work, people invent alternatives. These workarounds become embedded. Everyone knows that you do not actually follow the official procedure — you do this other thing instead. Over time, the official process and the actual process diverge completely.

AI will follow the instructions you give it. If those instructions describe the official process rather than the actual process, AI will produce official-process outputs that do not match how things really work. This creates confusion, rework, and a perception that ‘AI doesn’t understand our business.’

Why this matters for AI

AI tools, particularly the automation and augmentation kind, work by learning patterns and applying rules. This works brilliantly when the patterns are consistent and the rules are clear.

When the process varies by person, AI learns a confused mix of different approaches. When the rules are unwritten, AI cannot apply them. When exceptions are handled through judgment and relationships, AI has no framework for handling them.

The result is predictable: AI produces outputs that are wrong in ways that are difficult to diagnose. The technology is working correctly, but it is working from flawed instructions.

There is a deeper issue. Automating a broken process does not fix it. It scales the brokenness. Every error, inconsistency, and workaround now happens faster and more consistently. The organisation has not solved its process problems — it has amplified them.

This is why process clarity must come before AI, not after.

Practical takeaway

Before automating any process, document it honestly:

• Map the current state.
• Identify the decision points.
• Document the exceptions.
• Test
• Standardise

This documentation has value even if you never implement AI. It reduces key-person dependency. It enables training. It supports process improvement. The AI use case forces the discipline, but the benefits are broader.

Risks or limitations

There is a risk of over-documentation. Not every process needs detailed mapping. Focus on processes that are candidates for automation or that have significant business impact.

There is also the reality that some processes are inherently judgment-based and should remain so. Not everything should be automated. The goal is to understand your processes well enough to make informed decisions about which ones are suitable for AI assistance.

Finally, process documentation is a snapshot. Processes evolve. Documentation must be maintained, or it becomes another artifact that describes how things used to work rather than how they work now.

But these are implementation challenges, not reasons to skip the work. You cannot automate what you have not defined. This is not a recommendation — it is a constraint. The question is whether you confront it now, when you can do it thoughtfully, or later, when a failed AI project forces your hand.

Now we have the three foundations: data visibility, role clarity, and process definition. The final question is how these work together — and what AI readiness actually looks like when you put it all in place. Part 4: Putting it Together – How Data, Roles and Processes Enable AI.