Automation projects often begin in the wrong place. Someone sees a repetitive task, finds an AI tool that appears capable of doing it, and starts building. The harder questions arrive later: Is the process actually stable? Who owns it? What happens when the input is incomplete? Which decisions are too important to delegate?
A better starting point is readiness. Before choosing technology, understand the work well enough to know whether automation would make it better or simply make a messy process move faster.
Start with the process as it exists today
Write down what really happens, not what the procedure manual says should happen. Identify the trigger, the people involved, the systems touched, the information required, the decisions made, the exceptions, and the final outcome. If two experienced employees perform the same task in completely different ways, that is a warning that the process may need standardization before automation.
Look at volume and frequency too. A task performed twice a year may be irritating without being worth automating. A ten-minute task repeated hundreds of times a week is a different proposition.
Separate rules from judgment
Some work follows clear rules: validate a required field, route a request by category, send a reminder after a deadline, or copy approved information between systems. Other work depends on context, professional judgment, negotiation, safety, or interpretation. Most real processes contain both.
The useful question is not “Can AI do this?” It is “Which parts should technology handle, and which parts should remain under human control?” That distinction becomes more important as the consequence of an error increases.
Check the information the process depends on
An automation cannot reliably compensate for consistently poor inputs. Before deployment, examine whether the required data is available, current, permitted for the intended use, and understandable enough to support the workflow. If the process relies on employees knowing unwritten exceptions, capture those exceptions first.
Security and privacy belong in this assessment, not at the end. Determine what information the system would receive, where it would travel, who could access it, how long it should be retained, and what third parties would become involved.
Define failure before defining success
Teams naturally discuss the happy path. Readiness depends just as much on the unhappy path. What if the model produces an unsupported answer? What if an API is unavailable? What if a document is unreadable? What if a customer disputes an automated action?
Design an escalation route before launch. A person should know when they are expected to intervene, what evidence they can inspect, and how to correct the process without improvising under pressure.
Decide what evidence would justify expansion
A pilot needs measurable outcomes. Depending on the process, useful measures might include cycle time, error rate, exception volume, staff handling time, customer wait time, rework, or the percentage of cases that require human intervention. Cost matters, but it should not be the only measure.
NIST’s AI Risk Management Framework encourages organizations to manage AI risk throughout design, development, deployment, use, and evaluation rather than treating governance as a one-time approval. That is a useful mindset even for modest automation projects.
A simple readiness test
A process is a stronger candidate when it has a clear owner, a repeatable workflow, sufficiently reliable inputs, meaningful volume, defined exceptions, measurable outcomes, and an agreed human escalation path. If several of those are missing, fix the process first.
Good automation begins with operational clarity. The technology comes second.