10 Questions to Ask Before Adding AI to a Business Process

Teams rarely fail to consider AI for a process. They fail to ask hard enough questions about it before committing time and budget. The questions below are not exotic. Most of them are the same questions a good operations manager should ask about any proposed change, with a few added because AI raises specific risks around error handling and judgment. Working through all ten, honestly, takes an hour or two and saves considerably more time than that later.

1. Do we actually know how this process runs today?

A good answer describes the process step by step, including the exceptions, the rework loops, and the workarounds people use when the official path does not fit. It usually comes with a map or a written description that more than one person has reviewed and agreed matches reality. A weak answer describes the process the way it appears in a policy document, with no mention of what actually happens when a case does not fit the standard path. If the honest answer is that nobody has looked closely at the process in years, that is the first problem to fix, not a reason to add AI on top of an unclear process.

2. Do we know how this process performs today, with numbers?

A strong answer includes current cycle time, volume, and some sense of variation, such as how a claims process behaves in a slow week versus a busy one. A weak answer is a general impression, such as claims processing feels slow, with nobody able to say how slow, for which cases, or how consistently. Without a measured baseline, there is no way to know afterward whether an AI change made things better, worse, or no different at all. This is the same discipline that should apply to any process change, and it applies just as strongly here.

3. Where is the actual constraint in this process?

A good answer names the specific step or resource that limits how fast cases move through, for example a single reviewer who approves every vendor onboarding file regardless of risk level. A weak answer treats the whole process as equally slow everywhere. Adding AI to a step that already runs quickly does nothing for overall speed if a different step downstream is where cases actually queue up. Identifying the constraint first tells you where an AI step, or any other change, would matter and where it would be wasted effort.

4. Is there a simpler fix that gets most of the benefit?

A strong answer has already considered whether reordering steps, removing an unnecessary approval, or writing a clearer set of rules for existing staff would solve most of the problem. A weak answer jumps straight to AI because it is the newest option under discussion, without checking whether the same complaint, such as slow invoice approval, would improve just as much from combining two redundant sign-offs into one. Conventional process improvement is often cheaper, faster to implement, and easier to explain to the people who have to live with the change.

5. Is there enough volume and variation to justify this?

A good answer has a sense of how often this task happens and how much it varies case to case. High-volume, moderately varied work, like reading incoming complaint emails that arrive in inconsistent formats, is where AI's ability to handle unstructured input earns its cost. A weak answer proposes AI for a task that happens a handful of times a month, where the setup and ongoing oversight cost more attention than the manual task ever did.

6. How much judgment does this task actually require?

A strong answer distinguishes between tasks that follow a clear rule, tasks that require pattern recognition within a bounded set of options, and tasks that require weighing context nobody wrote down, such as deciding whether a customer's complaint history changes how a new complaint should be handled. A weak answer treats all three the same and assumes AI can substitute for judgment in every case, when in reality some decisions need a person who can be held accountable for them.

7. What happens when this goes wrong, and what controls catch it?

A good answer describes specific failure modes, such as an AI agent misreading a scanned invoice and what review step would catch that before payment goes out. It names who reviews outputs, how often, and what happens if error rates turn out higher than expected. A weak answer assumes the AI step will simply work and has not thought through what a wrong answer looks like or who is accountable for catching it. Every AI step in a regulated or financially sensitive process, like claims processing, needs a stated control, not an assumption of accuracy.

8. Which decisions stay with a person, explicitly?

A strong answer draws a clear line: AI can summarize, draft, flag, or triage, but a named role makes the final call on anything above a defined threshold of risk or value. A weak answer leaves this vague, assuming it will sort itself out once the tool is in use. Ambiguity here is where accountability quietly disappears and where trust in the process erodes once something goes wrong and nobody can say who should have caught it.

9. What is the expected value, and is it worth the effort?

A good answer has a rough estimate, built from the process baseline, of how AI might change cycle time, cost, or error rates, along with an honest acknowledgment that the estimate depends on assumptions still to be tested. A weak answer either has no estimate at all or treats a vague sense of efficiency as sufficient justification. Estimates do not need to be precise to be useful, but they do need to exist and be based on the actual process rather than a hopeful guess.

10. What will it actually take to implement, and who owns that?

A strong answer acknowledges that data access, system integration, security review, and ongoing maintenance are real costs that belong to IT and engineering, and that these have not yet been assessed. A weak answer assumes implementation will be straightforward because the process case looks good on paper. The process case and the technical feasibility case are different pieces of work, done by different people, and both need to be favorable before the project proceeds.

Running these questions as a workshop

These ten questions work best worked through together, in a room, with the people who actually run the process, not just the people proposing the change. A useful format is ninety minutes: twenty minutes mapping the current process on a wall or shared screen, thirty minutes working through the questions in order with the map in view, twenty minutes debating the constraint and the simpler alternatives specifically, and the remaining time capturing a rough estimate and a list of open items for the technical team. The goal is not consensus on every point. It is a written record of where the group agrees, where it does not, and what still needs to be checked before anyone commits budget.

It is worth treating a weak answer as useful information rather than a failure. A workshop that concludes the process is too low-volume for AI, or that a simpler fix solves most of the complaint, has done its job. The point of the exercise is a better decision, not a predetermined yes.