Choosing the first enterprise workflow to automate
Find a bounded process with an owner, observable inputs, and a useful way to judge the result.
The best first AI workflow is often a modest one. It has a recognizable beginning, a defined destination, and a person who can explain what happens when the usual path breaks. Choosing that process well gives a pilot something useful to prove.
Start with a process people can describe from recent experience. “Improve operations” is an ambition. “Prepare incoming supplier requests for an operations reviewer” is a workflow. The second version lets you inspect inputs, exceptions, decisions, and the final handoff.
Follow a real item through the process
Ask the team to walk through one ordinary item and one difficult item. Record where each arrives, what information gets copied, which systems are opened, and who decides it can move forward. Include the quiet work: finding a missing reference, asking a colleague for context, or checking whether the request is a duplicate.
This is also where you separate the available tools. A stable rule may handle a known category. A database lookup may resolve an identifier. AI may be useful for interpreting unstructured text or preparing a draft. The process does not improve simply because every step uses a model.
Look for four useful boundaries
- An input boundary: Specify accepted formats, sources, and the information needed to begin. Keep unsupported inputs out of the normal path.
- An action boundary: Describe what the system may prepare and what it may actually change. A suggested routing category is different from sending a customer response.
- A review boundary: Name the person or team responsible for exceptions, corrections, and approval.
- An outcome boundary: Define the destination and the evidence that the handoff completed correctly.
A workflow with no identifiable owner is a poor first candidate. So is one where the team cannot inspect the result until much later. Those problems may be solvable, but they make it harder to learn from a narrow pilot.
Define evaluation before celebrating the demo
Build a representative sample set that includes messy inputs and meaningful exceptions. For a request-routing pilot, include ambiguous requests, missing account references, unfamiliar wording, and requests that should stay with a person. Agree which outcomes are acceptable before reviewing the model’s output.
Evaluate the complete process. A correct classification is not enough if it reaches the wrong queue, exposes information to the wrong team, or creates a duplicate task. Compare the proposed process with the current one, including reviewer effort and recovery from failures.
NIST’s AI Risk Management Framework organizes risk work around governance, context, measurement, and management. It is a useful reference for treating the pilot as an operating decision. Our suggested selection method here is a practical starting point, not a certification or a substitute for your organization’s risk review.
Write a one-page pilot brief
Before building, capture the trigger, input sources, permitted actions, review owner, destination, evaluation cases, and stop conditions. Add the system dependencies and the person authorized to grant access. State what remains outside the pilot.
A supplier-request pilot can prepare a structured record and highlight missing fields. It would stop before approving the supplier or updating payment details. That boundary lets the team inspect preparation quality without bundling several consequential decisions into the first experiment.
End the pilot with a decision: proceed, revise, or stop. A useful pilot can reveal that better source data or a simpler rule will solve the problem. The point is to improve how work moves, with enough evidence to choose the next step.