Should you automate a process before adding AI? Start with the process
AI will not repair an unclear operating process. Make the work visible, simplify it, set control points, then decide where AI adds value.
Written by the Problem Solver Team with AI assistance.
The short answer
Should you automate a process before adding AI? Usually, first make the work visible and remove unnecessary ambiguity. Then decide which stable steps deserve automation and where AI can help with variable inputs, classification, drafting, or escalation without taking uncontrolled actions.
Key takeaways
- Start with the operational problem and workflow, not an AI feature.
- Simplify repeatable handoffs before using AI for variable judgment.
- Define the owner, exceptions, and fallback before automating an action.
- Use AI where context or classification helps—not as a substitute for process design.
01Should you automate a process before adding AI?
Clarify the process first, then decide which steps need conventional automation, AI assistance, or human judgment. You do not need to automate the whole workflow before trying AI. You do need a clear purpose, an accountable owner, and a way to handle exceptions.
A team asking for an “AI inbox” may actually need a consistent intake rule. Another team may already have a reliable process but spend time interpreting free-text requests. Those are different problems. Our proposed method below helps separate them before a tool is chosen.
02What must you understand before choosing a tool?
Follow a real work item from arrival to completion and record where decisions happen. Ask the operator to show an ordinary case and an exception, including work done outside the official system.
A useful map identifies the trigger, trusted inputs, decision owner, handoff, and completion evidence. Capture the difference between the documented process and what people actually do. If someone checks a spreadsheet before approving a request, that dependency belongs on the map.
| Part of the work | Question to answer |
|---|---|
| Trigger | What creates a new case, and how are duplicates recognized? |
| Input | Which record is authoritative when two sources disagree? |
| Decision | What rule applies, and who may approve an exception? |
| Handoff | What information must the next person receive? |
| Completion | Which system confirms that the requested action happened? |
| Recovery | Who takes over if the tool or source is unavailable? |
OMG's BPMN specification provides a formal process-modeling notation. A small team can begin with plain boxes and arrows; the immediate goal is an agreed account of the work, not notation expertise. For choosing the candidate workflow, use our process-selection method.
03Which problems should you simplify first?
Remove avoidable work and resolve ownership before automating the route. Preserve controls that protect a real business requirement, even when they appear inconvenient.
For every repeated step, ask what would break if it disappeared. Duplicate data entry might be removable, but a second review may catch a specific risk. Record that purpose rather than treating all handoffs as waste.
Then distinguish missing rules from variable information. If nobody agrees who approves an urgent request, a classifier cannot settle that policy. If the owner is clear but requests arrive in different wording, interpretation may be a reasonable AI-assisted task.
NIST's MAP guidance calls for understanding purpose, users, context, assumptions, and limitations, including consideration of non-AI alternatives. This is risk-management guidance, not a promise that documenting a process will produce a particular return.
04Where should automation stop and AI begin?
Use fixed logic for stable rules and consider AI where interpretation is genuinely needed. Keep consequential decisions with an authorized reviewer until the proposed action has a suitable control.
| Situation | Sensible first design |
|---|---|
| A required field is empty | A deterministic completeness check |
| The same request arrives twice | A duplicate check using an agreed identifier |
| A message describes a problem in varied language | AI-assisted categorization, with review of uncertain cases |
| Two records contradict each other | Present the conflict to the responsible person |
| A change creates an external commitment | An explicit approval step and completion receipt |
Anthropic's architectural distinction separates predefined workflows from agents that choose their own steps and tools. It is vendor technical guidance, not independent evidence of commercial results. Our AI, RPA, and agent comparison explains the choices in operating terms.
05What does this look like in an ordinary service queue?
A bounded intake improvement can combine simpler rules with AI assistance without giving AI control of the whole case. The following composite example is hypothetical and contains no client results.
Imagine service requests arrive by email. Coordinators copy them into a case system, identify missing information, and decide who should handle them. Different coordinators interpret “urgent” differently, while repeat emails sometimes create duplicate cases.
First, the process owner defines required information, an urgency policy, and a duplicate-handling rule. A structured intake form may solve some missing-field problems. A fixed check can flag an existing case identifier.
AI then has a narrower role: propose a category and extract supporting text from the message. The coordinator sees the original wording beside the suggestion. Ambiguous urgency returns to the owner; the system does not invent a priority or promise a response date.
If the case system is unavailable, the item stays in a visible waiting queue. If submission times out, the operator checks whether a case exists before retrying. This recovery rule matters even if the categorization is accurate.
06How should you test the first version?
Compare the proposed workflow with the current one on representative cases before widening access. Decide what acceptable behavior looks like before reviewing the outputs.
Include complete requests, missing information, duplicates, contradictory records, and unavailable sources. Record whether the correct owner received the case, whether the evidence was sufficient, and whether the final state was verified.
Track review effort alongside speed. A faster draft can still create more work if someone must repeatedly correct it. Separate interpretation errors from process-rule disagreements so the team knows whether to improve the AI step or clarify the operating policy. Our first-90-days guide helps place that test inside a manageable rollout.
07What should you ask your team for next?
Ask for a one-page operating brief and a demonstration of an exception. That is enough to expose many unresolved choices before development expands.
The brief should name the workflow, owner, authoritative source, permitted actions, approval boundary, success evidence, and fallback. Ask the team to explain which steps remain manual and why. A deliberate manual checkpoint can be a sound first release.
If the brief still depends on “the AI will figure it out,” narrow the task. For help turning an agreed workflow into a bounded pilot, use the AI Opportunity Audit: Book a 30-minute call.
08Frequently asked questions
Should every process be automated before adding AI?+
No. Some workflows need human judgment throughout. The useful first step is to clarify the process, its owner, decisions, and exceptions; then choose whether a stable step should be automated or an AI assistant should support a person. The best choice depends on the consequence of the decision.
Where does AI add value after process design?+
AI can help where inputs vary or need interpretation: extracting details, classifying requests, drafting a response, or identifying an exception. Keep the permission boundary and escalation rule explicit, especially when an output can trigger an action. Review outcomes before giving an AI-assisted step more autonomy.
What is a good first artefact for an AI project?+
A one-page workflow map is a strong start. It identifies the trigger, inputs, decisions, handoffs, systems, exception routes, and accountable owner. That shared view makes a small, testable initial scope much easier to choose. It also exposes which assumptions need evidence before a release decision.
Sources and further reading
- Business Process Model and Notation, Version 2.0. Object Management Group, 2010; accessed 2026.
- Map: AI Risk Management Framework Playbook. NIST, Accessed 2026.
- Building effective agents. Anthropic, 2024; accessed 2026.