Before You Automate Anything, Ask These Five Questions

Most organisations approaching AI deployment in their workflows have already decided to automate. The question they are asking is how, not whether. And that instinct to move forward is understandable. The business case looks clean, the technology has matured, and the pressure to show progress is real.

The problem is that most workflows are not ready to be automated. Not because the technology cannot handle them, but because the organisations deploying into them have not yet understood what those workflows actually contain.

What follows is not a checklist for slowing things down. It is a set of questions that make the work go better. Five dimensions that, taken together, tell you whether a workflow is genuinely ready for AI, and what kind of AI involvement it actually needs.

1. Intent: what is this workflow trying to achieve?

This sounds obvious. It rarely is.

Most workflows were not designed with a clear purpose statement. They evolved. Someone built a process to solve an immediate problem, it worked well enough, and over time it became the way things are done. The intent got embedded in the practice and stopped being visible.

When you introduce AI into a workflow without surfacing its intent, you risk optimising the wrong thing. You can make a process faster without making it better. You can reduce the number of human touchpoints without reducing the number of errors. You can automate a step that was only there because of a constraint that no longer exists.

Before you touch the technology, ask what this workflow is supposed to produce. Not the output, the documents filed or the cases closed, but the outcome. What changes for the client, the team, or the organisation when this workflow runs well? And how would you know if it was running badly?

If you cannot answer those questions clearly, you are not ready to automate. You are ready to do some design work first.

2. Experience: whose judgment is currently inside this workflow?

Every workflow that involves humans involves judgment. Some of that judgment is visible: a credit analyst assessing a borderline application, a compliance officer deciding whether a pattern warrants escalation. Most of it is invisible: the experienced processor who knows that a particular type of document from a particular jurisdiction always needs a second look, even when the rules do not require it.

This invisible judgment is the hardest thing to account for in AI deployment. It does not appear in process maps. It is not written in procedure manuals. It lives in the heads of the people doing the work, often without them being fully conscious of it.

When you automate a workflow without surfacing that judgment, one of two things tends to happen. Either you lose it entirely, and exceptions start falling through the gaps. Or you try to encode it in rules, and the rules are never quite right, because judgment by definition resists being made fully explicit.

The question to ask here is: who is actually making decisions in this workflow, and what are they drawing on when they make them? Talking to those people, watching them work, understanding where they pause and what makes them hesitate, is not optional groundwork. It is the work.

3. Flow: where does the work actually break?

Process maps show the ideal path. They rarely show what the workflow looks like on a difficult day.

Understanding flow means understanding failure modes. Where do things slow down? Where do items get stuck in queues? Where does work get escalated not because the rules require it but because the person doing it is not sure what to do? Where are the informal workarounds that everyone uses but nobody has documented?

These are the points where AI can genuinely help, or where it can make things significantly worse.

A workflow that breaks because of missing information at intake will not be fixed by automating the downstream steps. A workflow that slows down because of ambiguous decision criteria will not be improved by an AI system that has to make those same ambiguous decisions at scale. The technology surfaces the problem rather than solving it.

Mapping flow properly means following a piece of work from start to finish, not as it is described in a procedure guide but as it actually moves. It means understanding the handoffs, the queues, the exceptions, and the human interventions that are currently keeping things moving. Only then can you make a considered decision about where AI genuinely helps.

4. Trust: what level of human oversight does this workflow require?

Not all workflows carry the same stakes. Automating the routing of internal communications is a different proposition to automating any part of a credit decision or a sanctions screening process. The consequences of errors differ. The regulatory expectations differ. The tolerance for variability differs.

Trust is not just about whether the AI will get it right most of the time. It is about what happens when it does not, and whether the people using the system and the people affected by it can place reasonable confidence in it.

This question has two dimensions. The first is external: what do regulators, auditors, and clients expect in terms of human accountability for decisions in this workflow? The second is internal: do your own people trust the system enough to act on what it tells them, or will they spend their time second-guessing it, which is the worst of both worlds?

Building appropriate trust takes time and evidence. It is one of the reasons that starting with AI in an assist capacity, where a human reviews and acts on the AI’s output, is almost always the right first step. You generate a track record before you reduce oversight, rather than reducing oversight and hoping the track record holds.

Read more about our approach and method here.

5. Learning: how will this workflow get better over time?

Most AI deployment projects treat the go-live as the finish line. It is not. It is the point at which the real work starts.

Workflows change. Regulations change. Client expectations change. The edge cases you did not anticipate at the start will surface in the first six months of live operation. The AI system that was well-calibrated at launch will drift if nobody is actively monitoring its performance and feeding that learning back into how it operates.

The question to ask before you deploy is: who owns this workflow once it goes live? Who is responsible for monitoring its outputs, identifying where it is performing well and where it is not, and making decisions about when and how to adjust it? What mechanism exists for the people working inside the workflow to flag problems and have those concerns acted on?

This is not a technology question. It is an organisational design question. And organisations that answer it before they deploy are far better placed than those who try to retrofit governance structures after something has gone wrong.

The Intelligent Workflow Design framework

These five questions, taken together, form what we call the Intelligent Workflow Design framework. They are not a gate designed to slow AI adoption. They are a way of ensuring that when you deploy, you are deploying into something you understand, with the right level of human involvement at each stage, and a clear sense of how you will know whether it is working.

The firms that are getting AI deployment right in financial services are not necessarily moving fastest. They are moving with the most clarity about what they are building and why.

If you are at the point of making decisions about where and how to deploy AI in your workflows, and you want a structured way to work through these questions, we would welcome the conversation.