When a team asks for AI, the first instinct may be to select a model, build a chatbot, or connect an agent to existing tools. A better starting point is the work itself.
What is the person trying to accomplish? Which steps repeat? Where do they wait, copy information, or make a judgment? What happens when an input is incomplete or the answer is wrong? These questions reveal whether the best solution is ordinary automation, a better interface, a model-assisted step, or no new software at all.
Map the process people actually follow
Choose one workflow and follow it from trigger to outcome. Talk to the people who perform it and review the real artifacts involved: forms, messages, spreadsheets, systems, and handoffs. Document exceptions as well as the happy path.
Look for a specific friction point:
- Repeated entry of the same data across systems
- Finding relevant information across a large, changing knowledge base
- Preparing a first draft that a person reviews
- Routing work based on a small set of clear signals
- Summarizing a long record into a structured handoff
Do not describe an entire department’s work as one automation. A narrow task is easier to prototype, evaluate, and improve.
Match the method to the uncertainty
Use deterministic code for rules that are stable and explicit. A model may help when the input is unstructured—such as classifying a message, extracting fields, or drafting a response—but its output should be validated and bounded.
Ask whether the task needs a language model at all. A database query, search index, workflow rule, or clearer form may be more predictable, cheaper to maintain, and easier to explain. AI is useful when it improves a real step, not simply because it can be added.
Define success before the prototype
Pick a baseline from the current workflow. Measure the outcomes that matter to users and operators, such as time spent on the task, number of handoffs, correction rate, completion rate, or frequency of escalation. The right measure depends on the process; do not substitute a model benchmark for a product outcome.
Write down what a correct result looks like and what the system should do when it is uncertain. Include a route to correct mistakes and a way to compare the new workflow with the old one. A successful demo is not the same as a dependable operating process.
Decide where people stay in control
Some outputs can be suggested and edited. Others change records, affect customers, or trigger financial or operational consequences. Make the boundary visible: which actions are automatic, which require approval, and who is accountable for the decision?
For human review to work, show the evidence behind a recommendation and make the next action clear. “Approve” should mean the reviewer understands what will happen, not merely that the interface has a button.
Plan for exceptions and ownership
Map how the workflow behaves when the model is unavailable, data is missing, a source is stale, or a downstream service rejects the action. Decide whether the system retries, queues work, asks a person, or stops. Assign an owner for the workflow and for its evaluation set.
Start with one narrow pilot, compare it with the baseline, and review mistakes with the people affected. Expand only when the workflow is useful and its failure modes are understood.
The strongest AI opportunity is often not “automate everything.” It is a specific step where the system can reduce friction while leaving judgment, accountability, and recovery in the right hands.
