How to Tell If a Business Process Is Ready for AI Automation

Most automation ideas start with a verb: qualify leads, read invoices, answer questions, schedule work. That wording hides the hard part. A business process is not a verb. It is a chain of inputs, decisions, handoffs, records, exceptions, and consequences.

When I taught product managers to move from writing specifications to building and shipping products, I kept seeing the same failure before the technology choice: nobody could say what done meant. That matters here. If the business cannot describe a finished outcome, an AI system cannot be judged against one.

This guide gives you a practical test for one process. You will leave with a process card, a baseline plan, an evidence pack, and a control decision. Those artifacts let you choose among ordinary automation, an AI-assisted step, a supervised AI pilot, process repair, or no automation.

The four-artifact test for AI automation readiness

A business process is ready for an AI automation pilot only when four artifacts exist: a process contract, a baseline, an evidence pack, and a controlled action path. This is my decision rule for a pilot, not a certification and not a universal industry score.

Artifact	What it proves	Minimum contents	If it is missing
Process contract	The team agrees what work is in scope and what counts as complete	Trigger, inputs, steps, decisions, output, owner, boundary, common exceptions	Map and name the process before selecting a tool
Baseline	The team can tell whether the change creates value or damage	Volume, time, cost, quality, delay, error, or another outcome measure	Observe the current work and record a baseline
Evidence pack	The team can judge AI behavior before trusting it	Normal, edge, and failure cases, expected outcomes, acceptance checks	Collect cases and define what “correct” means
Controlled action path	A wrong result can be seen, stopped, reversed, or contained	Permissions, approval, logs, stop condition, fallback, owner, recovery	Keep the system assistive or redesign the action boundary

All four are required for a process to be ready for an AI pilot. A missing artifact is not a score of one out of four. It is a different diagnosis.

If the process is clear but the output cannot be checked, you have an evidence problem. If the output is checkable but the system would send money, change employment status, or expose sensitive data without a meaningful control, you have a control problem. If the process has no owner, you have an operating problem. Each problem calls for preparation, not a more capable model.

The rule also separates three decisions that teams often mix together:

1. Process readiness: Is this one piece of work clear, valuable, testable, and controllable enough to change?
2. AI fit: Does a language or multimodal model add something that ordinary software cannot add as simply or safely?
3. System readiness: Can the chosen implementation operate with the required security, reliability, evaluation, and maintenance?

The four artifacts answer the first decision. They make the second decision less speculative. They do not prove the third. A pilot still has to earn its way through evaluation, security, integration, and release review.

NIST’s AI Risk Management Framework takes a compatible position from a risk perspective. It asks organizations to establish context, map risks and benefits, measure performance, and manage the resulting trade-offs. Its Playbook also states that an AI system may not be the right solution for a given business task and recommends weighing negative risks against benefits. The useful implication is simple: “AI-ready” is not the same as “AI should be used here.” (NIST AI RMF Core; NIST AI RMF Manage)

The test is deliberately strict at the boundary of action. A process may be ready for a read-only assistant before it is ready for an automated write. It may be ready for drafting before it is ready for sending. It may be ready for triage before it is ready for a final decision. Readiness belongs to a scope and an action, not to the process name alone.

Start with the process, not the AI use case

Write the process in ordinary business language before you name a model, vendor, or agent. “Use AI for sales” is not a process. “After a web form arrives, classify the request, check whether required fields are present, draft a routing recommendation, and place the case in a human-owned queue” is closer.

The difference is not stylistic. A product name encourages a solution-first conversation. A process description exposes the questions that determine whether a solution can work:

• What starts the work?
• What information is available at that moment?
• What does a person do next?
• Which decisions are rules and which require judgment?
• What records change?
• What does the next person need to receive?
• What counts as complete?
• What happens when the normal path fails?

ISO guidance on the process approach makes a similar point without making an AI claim. It emphasizes identifying key processes, understanding inputs and outputs, defining responsibilities, controlling variations and errors, collecting performance data, and improving based on evidence. That is a useful foundation because an AI system enters an existing operating system. It does not replace the need to define one. (ISO 9001 explained)

Use a process sentence

Describe the candidate in this form:

When [trigger] occurs, [owner or role] uses [inputs] to make [decisions] and produce [output] for [next person or system], within [time or policy boundary].

For example:

When a new support request arrives, the support coordinator uses the message, customer record, and current service policy to classify urgency and route the request, producing a recommended queue, reason, and missing-information list for a human reviewer within one business hour.

This sentence does not say that AI should do the work. It gives you something to inspect.

Now try to make the sentence more precise. Replace “support request” with the actual source. Replace “classify urgency” with the decision categories. Replace “route” with the destination. Replace “human reviewer” with a role. Replace “within one business hour” with the service boundary.

If the sentence keeps expanding, that is information. You may be describing a department rather than a process. Narrow the work until one owner can explain its start and end without a meeting.

Distinguish a task from a process

A task is one action, such as extracting a date from a document or writing a reply. A process is a sequence that turns an input into an outcome. AI may help with a task inside a process, but the business value and risk usually sit at the process level.

This distinction prevents a common mistake. A team sees a task that looks easy to automate and ignores the handoff after it. The extraction works, but the value disappears because someone still has to re-enter the data, resolve missing fields, or decide what to do with an ambiguous result.

Use a task-level pilot when the task has a clean input and a checkable output. Use a process-level pilot when the benefit depends on several steps, a handoff, a queue, or a system record. Do not claim to have automated a process because one sentence in the process is now faster.

Distinguish the nominal path from the real path

The written procedure is a hypothesis. The real process is what people and systems actually do.

Microsoft describes process mining as using event data from systems of record to visualize how processes are actually executed, compare variants, find root causes of inefficiency, and monitor key performance indicators. You do not need a process-mining platform for every small process, but the principle matters: inspect real work before deciding what to automate. (Microsoft Power Automate process mining overview)

For a small team, a practical observation set might include:

1. Watch several normal cases from trigger to completion.
2. Ask the operator to narrate decisions without turning the session into a training demo.
3. Record every system touched and every handoff.
4. Mark places where the operator leaves the documented path.
5. Ask what they do when a field is missing, a policy is unclear, or a system is unavailable.
6. Compare the written procedure with the actual sequence.

Do not treat the operator’s workaround as a nuisance. It may be the process. A spreadsheet maintained outside the official system, a private inbox label, or a manual approval may carry the context that the formal diagram omitted.

When I led a ChatGPT workshop at Orange, the useful starting point was the work people already did. The workshop did not start with agents. That choice changes the conversation. Participants can name the inputs, bottlenecks, judgment calls, and consequences of their own work. The technology comes later.

Write the process contract before you choose a tool

The process contract is the smallest shared description of the work that another person could use to challenge the automation proposal. It should be short enough to read in one sitting and specific enough to expose disagreement.

Use these fields:

Field	Question	Example for invoice exception handling
Name	What is this process called?	Resolve invoices that do not match a purchase order
Trigger	What event starts it?	An invoice enters the accounts-payable inbox
Scope	Which cases are included?	Supplier invoices with an existing purchase order
Exclusions	Which cases stay out?	New suppliers, tax disputes, legal holds
Inputs	What information is available?	Invoice PDF, purchase order, receipt, supplier record
Steps	What happens in order?	Extract, match, compare, classify, request missing evidence
Decisions	What choices are made?	Match, mismatch, duplicate, missing receipt, escalate
Output	What is produced?	Review packet and recommended next action
Owner	Who is accountable?	Accounts-payable operations lead
Boundary	What must not happen automatically?	No payment release and no supplier-master change
Exceptions	Which variants matter?	Partial delivery, currency difference, duplicate invoice
Completion	What counts as done?	A reviewer has a complete packet and recorded disposition

The contract should name the output, not only the action. “Review invoice” is an activity. “A reviewer has a complete packet and recorded disposition” is a state that can be checked.

Define done as a state change

Ask what is different in the system or in the customer’s situation when the process is complete. The answer may be:

• a ticket has the correct queue and urgency;
• a request has a complete set of documents;
• a draft has been approved and sent;
• a record has been reconciled against a source of truth;
• a human has made a decision with the relevant evidence attached;
• a follow-up has been created with an owner and deadline.

If “done” means “the AI produced text,” the process is not defined far enough. Text is usually an intermediate artifact. The business result arrives only when someone uses it, approves it, records it, or acts on it.

This is where my experience teaching product managers matters. Teams can describe an interface, a prompt, or a feature while leaving the outcome vague. The fix is not a better prompt. The fix is to define the state that must be true after the work.

Separate rules from judgment

For each decision, write down whether it is:

• Deterministic: the same inputs and rule produce the same answer.
• Interpretive: the system must understand language, images, or context.
• Policy-bound: a policy or regulation determines the permitted result.
• Escalatory: the case must go to a person when a condition is met.
• Unknown: the team has not agreed what to do.

Unknown is a valid category. It is better than pretending that a person’s intuition is a stable rule.

An AI model can help with interpretive work, but that does not mean it should decide a policy-bound outcome. It can summarize evidence for an approver without becoming the approver. It can detect a possible exception without resolving the exception. It can propose a next step without executing it.

OpenAI’s guide describes agents as useful where workflows involve complex decisions, difficult-to-maintain rules, or heavy reliance on unstructured data. It also says to validate those criteria clearly before committing, because a deterministic solution may suffice otherwise. Treat that as an architecture prompt, not as a license to add an agent to every process. (OpenAI practical guide to building agents)

Map the exceptions that change the action

Do not create a long list of every imaginable exception. Find the exceptions that change the next action, the owner, the required evidence, or the acceptable risk.

For each important exception, record:

Exception field	Example question
Trigger	What makes this case different?
Detection	How would the system notice?
Correct route	Where should it go?
Required evidence	What must be attached or checked?
Authority	Who may resolve it?
Deadline	How long can it wait?
Wrong-action cost	What happens if it is treated as normal?
Fallback	What is the safe manual path?

If nobody can agree on the correct route for a common exception, do not hide that ambiguity inside an AI prompt. Make it a design task.

Measure the current process before you promise value

A process is not ready for an AI pilot if the team cannot tell whether the pilot improved it. A baseline does not need perfect data. It does need a defined observation window, a consistent unit of work, and a measure connected to the intended outcome.

The baseline can be small. You might measure one queue for two weeks, sample a set of completed cases, or reconstruct cycle time from timestamps. State what you measured and what you did not.

ISO guidance names monitoring, measurement, performance evaluation, process responsibilities, variation, and evidence-based improvement as parts of a quality management system. Microsoft’s process-mining guidance similarly connects event data with actual process visibility, root-cause analysis, and KPI monitoring. These sources do not tell you how much improvement to expect. They tell you why “before” must be visible. (ISO 9001 explained; Microsoft Power Automate process mining overview)

Choose a unit of work

Pick one unit that can be counted from start to finish. Depending on the process, it might be:

• one invoice exception;
• one support conversation;
• one onboarding request;
• one supplier review;
• one internal question;
• one document packet;
• one scheduling request.

Do not mix units. “The team was busy” is not a baseline. “Thirty-two invoice exceptions entered the queue; twenty-seven reached a recorded disposition; median elapsed time was three business days” is a useful shape, even if the sample is too small for a general claim.

Measure the outcome the business actually cares about

Select one primary measure and a small set of guardrails. The primary measure could be cycle time, completed cases per period, cost per successful outcome, first-pass accuracy, resolution rate, or customer wait. Guardrails might include rework, escalation, complaint, privacy incident, policy violation, or human review time.

Use the following worksheet:

Baseline field	Your value
Observation window
Unit of work
Number of cases observed
Start event
Completion event
Primary outcome
Current value
Variation by case type
Human time
Rework or correction
Escalation
Customer or internal delay
Material failure or risk
Data limitations

The last row is part of the baseline, not an apology. If completion timestamps are missing, say so. If review time was estimated, label it. A rough baseline that identifies uncertainty is more useful than a polished number that hides it.

Separate capacity from cash savings

If automation saves an employee time, ask what happens to that time. It may become more customer work, faster response, better documentation, or simply less overtime. Those outcomes can matter, but they are not all the same as cash savings.

This distinction is especially important when deciding whether a process is worth automating. A low-volume process might still be worthwhile if it releases scarce expert attention. A high-volume process might not be worthwhile if every case needs nearly the same amount of human verification afterward.

Do not use a generic hourly rate and declare ROI. Connect the baseline to a plausible change in the business. The existing guide on how to calculate ROI for an AI agent covers the economics once you have a defined candidate and baseline.

Baseline variants, not just averages

An average can hide the part of the process that matters. Segment the baseline by the variables that change the action or cost:

• simple versus complex cases;
• new versus returning customer;
• complete versus incomplete input;
• domestic versus international request;
• normal versus urgent service level;
• one system versus several systems;
• known policy versus policy exception.

If the easy cases dominate the average, the automation may look successful while failing where the risk lives. If the difficult cases are rare but expensive, make that visible before you choose the pilot scope.

What if you have no data?

No data does not mean no opportunity. It means the first deliverable is observation.

You can start with:

1. A short time-boxed sample of real cases.
2. A manual count of trigger and completion events.
3. A structured operator log.
4. A review of existing inbox, ticket, spreadsheet, or system records.
5. A small set of representative cases selected with the process owner.

Do not fill a missing baseline with a market statistic about automation. The relevant question is what this process costs, delays, or risks in this business.

Build an evidence pack before you trust an AI output

The evidence pack answers a practical question: if the AI produces a result, how will a person or a program decide whether it is good enough?

A demo case is not an evidence pack. A happy-path example proves that one input produced one plausible output. It says nothing about missing information, contradictory records, uncommon language, malformed files, policy boundaries, or tool failure.

Create cases in at least three groups:

Case group	Purpose	Example
Normal	Test the common path	Complete invoice with matching purchase order
Edge	Test variation that should still be handled	Partial delivery or unusual but valid wording
Failure	Test when the system must stop, escalate, or refuse	No purchase order, conflicting totals, suspected duplicate

The group names are simple, but the content must come from the real process. Ask the owner which cases cause rework, which cases are passed between people, and which cases are embarrassing when missed.

Define an expected result for each case

For each case, write:

• the input available to the system;
• the expected classification or extracted fields;
• the required evidence or citation;
• the permitted next action;
• the action that must not happen;
• the human review requirement;
• the acceptable uncertainty or refusal behavior.

This is not necessarily a single “correct answer.” Many business processes have several acceptable outputs. In that case, define a rubric or a set of invariants.

For a support-routing task, acceptable outputs might include the right queue, a correct urgency band, a reason that cites the relevant message, and a list of missing details. A polished paragraph is not enough.

For document extraction, acceptable outputs might require every required field, a source location for each field, a confidence or review flag, and a refusal when the document is unreadable.

For an internal research step, acceptable output might be a bounded summary with links to the source records, explicit unknowns, and no invented policy.

Test the handoff, not only the model answer

Most business value appears after the output. Test whether the next role can use it without reconstructing the work.

Ask:

• Can the reviewer find the original input?
• Can the reviewer see what the system changed or inferred?
• Can the reviewer understand why the result was produced?
• Can the reviewer correct the result without starting over?
• Is the correction recorded?
• Does the corrected state reach the right system or queue?
• Does the process end in the defined completion state?

The handoff is part of the process contract. If the AI result is accurate but the next person cannot trust or use it, the process has not improved.

Use ground truth from the environment

Anthropic’s guidance distinguishes workflows with predefined code paths from agents that dynamically direct their own process and tool use. It also says agents need ground truth from the environment at each step, such as tool results or code execution, and should have checkpoints or stopping conditions. That gives you a strong evidence principle: prefer signals from the system of record over a model’s claim that it is finished. (Anthropic Building Effective AI Agents)

For a process, ground truth might be:

• a record was actually created;
• the destination queue changed;
• a required field passed validation;
• the payment status remained unchanged;
• a reviewer approved the packet;
• a customer received the correct message;
• the downstream system returned a success state.

If the only evidence is “the model said it completed the task,” the evidence pack is incomplete.

Decide what quality means before the demo

Quality can have multiple dimensions:

Dimension	Question
Accuracy	Did the result match the intended outcome?
Completeness	Did it include the required fields or evidence?
Calibration	Did it signal uncertainty when the case was difficult?
Timeliness	Did it arrive within the service boundary?
Usability	Could the next person act on it?
Safety	Did it avoid prohibited actions and data exposure?
Recoverability	Could the process continue after an error?

Not every process needs a numerical threshold for every dimension on day one. Every pilot needs a clear statement of which dimensions are non-negotiable.

A draft-email assistant might tolerate a minor style problem but not an invented price or an unauthorized promise. An invoice classifier might tolerate a human review on more cases but not a payment release based on an unverified match. An internal summarizer might allow a partial answer but must expose missing source material.

What if no one can agree on correctness?

That is not a model problem yet. It is a process-design problem.

Bring the disagreement into the open. Ask the process owner to name:

1. The business outcome the decision protects.
2. The evidence a competent operator uses.
3. The conditions that require escalation.
4. The error that is worse than delay.
5. The minimum information required to proceed.

If two experts disagree, record the disagreement as an allowed outcome or as a human-review boundary. Do not force a false label to make an evaluation set look tidy.

Make the action path smaller than the ambition

A process can be clear, valuable, and testable yet still be unsafe to automate. The final artifact is the controlled action path: what the system may read, propose, change, send, or refuse, and who remains accountable.

Start with the smallest action that creates useful evidence. Common boundaries are:

• read-only retrieval;
• classification without routing;
• draft without sending;
• recommendation without commitment;
• update to a staging record rather than the system of record;
• one reversible write with an approval gate;
• automatic handling only for a narrow, low-consequence subset.

Do not grant write access just because the model can produce a plausible answer. Ability is not authorization.

Write an action inventory

For each step, record:

Action	Read or write	System	Data involved	Allowed automatically?	Review or approval	Recovery
Retrieve customer record	Read	CRM	Identity and account status	Maybe	Scope check	None or retry
Draft response	Write to draft	Helpdesk	Message and policy	Yes in draft area	Human approval	Edit or discard
Send response	External side effect	Email	Customer communication	Usually no at first	Named reviewer	Resend or correction
Change account status	System write	CRM	Entitlement or access	Depends on consequence	Policy-specific	Revert or manual correction
Release payment	High-consequence write	Finance system	Bank and invoice data	No for initial pilot	Authorized human	Financial recovery process

The table often reveals that the best first pilot is not the one the original request named. “Automate invoice processing” may become “extract fields and prepare an exception packet.” “Automate customer support” may become “suggest a queue and identify missing information.” The narrower slice produces evidence without pretending that every downstream decision is safe.

Make human review meaningful

A person clicking approve is not automatically meaningful oversight. The reviewer needs enough information, time, authority, and independence to challenge the output.

UK government guidance distinguishes solely automated decision-making from automated assisted decision-making and says data quality, intended use, human oversight, and intervention matter. It also identifies process owners and risk owners as relevant participants. The practical lesson is to document what the human sees, what they can change, what happens when they disagree, and who owns the outcome. (Ethics, Transparency and Accountability Framework for Automated Decision-Making)

Use a review gate with four explicit states:

1. Approve: the reviewer accepts the proposed result and the system records the decision.
2. Edit: the reviewer changes the result and the correction is retained for later analysis.
3. Escalate: the case moves to a person with more authority or subject expertise.
4. Reject: the system stops and follows the manual fallback.

If the reviewer cannot tell what the system saw or why it proposed the action, the gate is decorative.

Define stop conditions before launch

Stop conditions are not only technical errors. They include business conditions:

• required input is missing;
• source records disagree;
• confidence is below the agreed boundary;
• the request falls into a restricted category;
• the task exceeds a time or cost limit;
• a tool returns stale or unexpected data;
• the system attempts an action outside its permission scope;
• the process has reached its maximum retry or review count;
• the model cannot cite the evidence needed for the decision.

The stop path must produce a useful state. “Agent failed” is not a recovery plan. It might create a human queue item, attach the original input, record the reason, notify the owner, and preserve the partial work.

Define fallback and recovery separately

Fallback is what happens when the system cannot proceed. Recovery is what happens after an incorrect or partial action has already occurred.

For a draft assistant, fallback may be manual drafting. Recovery may be editing or discarding the draft. For a record-update tool, fallback may be a human queue. Recovery may require an audit entry and an authorized reversal. For a customer message, recovery may include a correction message and a review of related cases.

If a proposed action is irreversible or difficult to reverse, raise the approval requirement. The process might still be suitable for AI assistance, but not for autonomous execution.

Use logs that explain the outcome

At minimum, keep:

• process version;
• input reference;
• model and prompt or instruction version where relevant;
• retrieved sources or records;
• proposed output;
• tool calls and results;
• approval or rejection;
• final state;
• exception reason;
• operator or system identity;
• timestamps.

The exact fields depend on the process and its obligations. The purpose is not to produce a giant trace for its own sake. It is to answer, after the fact, what the system saw, what it proposed, what it did, who approved it, and what state resulted.

When I work on TryUncle, the AI agent watches a screen and annotates it live. That kind of product makes latency and human approval concrete operating constraints. A technically plausible result that arrives after the user has moved on is not useful. A helpful annotation that takes an unsafe action without a review boundary is not acceptable.

Choose ordinary automation, AI assistance, or an agent

Readiness does not answer the technology question by itself. Once the four artifacts exist, ask what kind of system is justified. The default should be the simplest system that can meet the outcome and controls.

Process characteristic	Best first choice	Why
Fixed inputs, fixed rules, predictable exceptions	Deterministic software or workflow	It is easier to test, explain, and operate
One step needs language, image, or document interpretation	AI-assisted step inside a fixed workflow	The path stays controlled while AI handles interpretation
Several known stages with an AI step in one or two places	Fixed LLM workflow	The sequence remains explicit and the model has a bounded role
Required steps change as the system discovers information	Bounded agent, usually with approval gates	Model-directed path selection may add value, but needs stronger controls
Outcome cannot be checked or action cannot be contained	Assistive research only, or no automation	More autonomy would make uncertainty operational

OpenAI’s practical guide uses a similar distinction: agents are a fit for complex decision-making, brittle or difficult-to-maintain rules, and heavy reliance on unstructured data. Anthropic recommends starting with the simplest solution and adding complexity only when it improves the outcome. Anthropic describes workflows as predefined code paths and agents as systems that dynamically direct process and tool use. (OpenAI practical guide to building agents; Anthropic Building Effective AI Agents)

When ordinary automation wins

Use ordinary automation when the process already has stable rules and structured inputs. Examples include:

• checking that a required field exists;
• moving a record when a status changes;
• calculating a value from a defined formula;
• sending a reminder at a known time;
• matching two identifiers with an exact rule;
• creating a task from a fixed event;
• enforcing a known approval sequence.

Adding AI to these steps can make them harder to test and more expensive to explain. “AI automation” is not a maturity upgrade. It is a different failure surface.

When AI assistance earns its place

AI assistance can make sense when the process contains a bounded interpretation step. The model might read a free-form message, extract fields from a document, classify a request, summarize evidence, or draft a response. The surrounding workflow remains deterministic.

This pattern is often the right first move because it limits the model’s authority. The process owner can evaluate the output before a downstream action. The team can compare the AI step with the existing manual step. The pilot can improve one bottleneck without making the entire process open-ended.

The evidence pack must still include refusals and exceptions. A document extractor that fills fields on clear invoices but flags unreadable pages may be more useful than one that guesses on every page.

When an agent is justified

An agent is justified only when the path cannot be specified in advance without losing the value of the work. The system may need to choose which record to inspect next, ask for missing information, use different tools based on findings, or stop when it reaches a policy boundary.

That flexibility comes with a larger evaluation and control burden. You need ground truth from tools or systems, a clear completion state, a maximum step or time boundary, and a path back to a person. If the path is predictable, keep it in code.

You can read the existing guide on when to use an AI agent for the architecture decision. The present question comes first: can the business process be made clear, measurable, testable, and controllable enough to support any of those choices?

Do not confuse unstructured input with an unstructured process

A process can accept emails, PDFs, images, or natural language while still having a stable sequence and a checkable output. That may call for one AI step, not an agent.

Conversely, a process can have clean database fields while the decisions and ownership are unclear. Structured data does not make a process ready. It only makes one part of it easier to observe.

The question is not “does this use unstructured data?” The question is “where does interpretation happen, and what must be true before the next action?”

Run the readiness procedure in one working session

You can use the following procedure for one candidate process. It is designed to produce a decision and a next action, not a scorecard that leaves the team with the same ambiguity.

1. Name one process and one outcome

Write the process sentence and the completion state. If the name includes a department, product, or broad ambition, narrow it.

Bad:

Automate operations with AI.

Better:

When a qualified inbound request arrives, prepare a complete handoff packet for the sales coordinator, including the source message, account context, missing fields, and recommended next step.

The better version gives you a trigger, an output, a role, and a boundary. It does not assume that AI should contact the prospect or update the CRM.

2. Draw the actual path

List the current steps from trigger to completion. Add systems, people, queues, and handoffs. Mark workarounds in a different color if you are using a diagram tool.

Then ask the operator to walk through three cases:

1. A normal case.
2. A case that required judgment.
3. A case that went wrong or became delayed.

Do not let a process owner describe only the ideal route. A pilot that works on the ideal route but fails on the common exception is not ready.

3. Create the process contract

Fill in trigger, scope, exclusions, inputs, decisions, outputs, owner, boundary, exceptions, and completion. For each decision, label it deterministic, interpretive, policy-bound, escalatory, or unknown.

If the owner, boundary, or completion field is blank, stop the readiness assessment. Those are not optional metadata fields. They define accountability.

4. Record the baseline

Choose a unit, window, primary outcome, and guardrails. Use existing timestamps where possible. If you must sample manually, record how.

The baseline should make a counterfactual possible. The question is not “did people like the demo?” It is “compared with the current process, did the defined outcome improve without breaking the guardrails?”

5. Assemble the evidence pack

Collect normal, edge, and failure cases. For each, write expected output, required evidence, permitted action, prohibited action, and review state.

Include cases where the safest result is a question, a refusal, or a handoff. A system that never refuses is often a system that has not been given a safe failure definition.

6. Draw the controlled action path

List every read, write, message, approval, and external side effect. Start with read-only or draft-only scope. Define stop conditions, fallback, recovery, log fields, and the accountable owner.

If the process touches personal data, financial records, employment decisions, access rights, health information, legal commitments, or essential services, add the relevant legal, security, and domain reviewers before a pilot. Do not treat this paragraph as legal advice or as a substitute for jurisdiction-specific review.

7. Select the simplest technology

Choose ordinary automation if rules are enough. Put AI inside the workflow if one step needs interpretation. Consider an agent only when the path genuinely changes with findings and the evidence and control artifacts support that autonomy.

The architecture decision should be a consequence of the process card. If the proposed technology appears in the process definition before the trigger and output, you are still solution-first.

8. State the pilot boundary

Write one sentence:

For [scope], the system may [allowed action], must not [prohibited action], and must send the case to [owner] when [stop condition].

Example:

For invoices with an existing purchase order, the system may extract fields and prepare a match recommendation, must not release payment or modify supplier data, and must send the case to accounts-payable review when totals conflict, the document is unreadable, or the match is below the agreed evidence threshold.

9. Choose a decision and a next action

Use one of these outcomes:

Outcome	Conditions	Next action
Ready for supervised AI pilot	Four artifacts exist, value is real, and the action boundary is acceptable	Run a narrow, review-gated pilot
Ready for ordinary automation	Rules and path are predictable; AI adds no necessary capability	Build the deterministic path
Process repair first	Owner, scope, steps, decisions, or exceptions are unclear	Document and redesign the process
Evidence first	Output or success cannot be judged	Collect cases and define acceptance checks
Control review first	Risk, permissions, or reversibility are unresolved	Add domain, legal, security, or accountable review
Reject or redesign	Value is weak or the downside cannot be contained	Keep human control and choose another candidate

The decision is useful only if it names the next action and owner. “Not ready” without a preparation task becomes a postponement.

Worked example: customer request routing

Suppose a small service business receives requests through a website form and a shared inbox. The proposed idea is “use AI to automate lead qualification.” That is too broad to assess.

Rewrite the process

A narrower process might be:

When an inbound request arrives, prepare a routing recommendation and a missing-information list for the sales coordinator.

The completion state is not “the lead is qualified.” It is “the sales coordinator has a traceable recommendation and can decide what happens next.”

Inspect the current work

The process owner discovers that requests arrive from two sources. The form contains service type and budget range, but the inbox messages do not. The coordinator checks an existing customer record, looks for a service-area match, and sometimes asks a colleague whether the request belongs to a specialist.

The written process said “route qualified requests.” The actual process includes missing fields, a system lookup, geographic constraints, and a human specialist decision.

Fill the contract

Contract field	Decision
Trigger	New form submission or inbox message
Scope	Requests for the three standard services
Exclusions	Complaints, existing disputes, and requests involving a regulated decision
Inputs	Message, form fields, customer record, service-area table
Interpretation	Identify intent, summarize need, detect missing information
Rules	Service area and required-field checks
Output	Recommendation, evidence, missing fields, and suggested queue
Owner	Sales coordinator
Boundary	No pricing promise, no external reply, no CRM stage change
Completion	Coordinator accepts, edits, or rejects the recommendation

The AI has a plausible role in interpreting the message and preparing a packet. It does not need authority to qualify the lead or change the record.

Build the baseline

The team chooses one observation window and records request volume, time from arrival to first human action, time spent gathering context, routing corrections, and requests returned for missing information. The team does not assume that all time saved becomes sales revenue. It records capacity and quality separately.

Build the evidence pack

The cases include:

• a complete form submission that should route normally;
• a free-form inbox message with missing budget information;
• a returning customer whose existing record changes the route;
• a request outside the service area;
• a complaint that must bypass qualification;
• an ambiguous request that should ask for clarification or go to a human.

Each expected result includes a queue, reason, source evidence, missing information, and prohibited claims. The system is judged on the handoff packet, not on whether its summary sounds professional.

Choose the first automation

The process is ready for a supervised AI pilot if the owner agrees that recommendations can be reviewed, the cases are representative, and the action boundary is respected. The first version should produce a draft packet. A later version might create a task in the sales queue after approval. Automatic outreach is a separate decision with a separate evidence and control boundary.

Worked example: invoice exception handling

Now consider “automate accounts payable.” That phrase hides several processes, including intake, extraction, matching, exception resolution, approval, payment, and supplier maintenance.

Separate the slices

One useful slice is:

When an invoice with an existing purchase order enters the accounts-payable inbox, extract the fields and prepare a match packet for a reviewer.

This slice excludes payment release, supplier-master changes, new suppliers, legal holds, tax disputes, and unclear ownership.

Why the process may be a good candidate

Invoices often contain documents that need interpretation. A model may help extract fields or describe a mismatch. But the output can be checked against a purchase order, receipt, or supplier record. That creates ground truth.

The candidate still needs a baseline. Measure time to prepare a review packet, fields that need correction, cases returned for missing evidence, and the time reviewers spend verifying the result.

Define the refusal path

The system should stop or escalate when:

• the invoice is unreadable;
• the supplier cannot be matched;
• totals conflict with the purchase order;
• currency or tax treatment needs expert review;
• the document appears duplicated;
• a payment or supplier change would be required;
• the source records disagree.

The pilot is not “AI processes invoices.” It is “AI prepares a review packet for a defined invoice subset while preserving human authority over payment and supplier changes.” That sentence can be evaluated.

What success looks like

The primary measure might be time to a complete review packet. Guardrails might include field correction, missing evidence, incorrect exception classification, unauthorized writes, and human review time. A result that reduces extraction time while increasing verification time may not improve the process.

This example shows why a high-volume process is not automatically ready. Volume helps justify effort. It does not establish a safe outcome.

The failure modes that make a process look ready when it is not

Readiness mistakes repeat because they sound reasonable in a meeting. Name them before they become project assumptions.

“It is repetitive, so AI should do it”

Repetition is evidence that automation may be worth considering. It is not evidence that AI is needed or that the process is well defined.

A fixed rule, scheduled job, form validation, or ordinary integration may be safer and cheaper. If the work is repetitive but the output is not checkable, AI adds uncertainty to a task that already lacks a reliable completion state.

Ask: what part of the repetition requires interpretation? If the answer is “none,” start with deterministic automation.

“The team already has a standard operating procedure”

A document proves that someone wrote a procedure. It does not prove that the procedure matches real work, covers common exceptions, or defines ownership.

Observe cases. Compare the written steps with the actual path. Ask which steps operators skip, repeat, or perform in another system. Treat the difference as process evidence.

“The model handled our example”

One example demonstrates possibility. It does not establish quality, consistency, or safe failure.

Add edge and failure cases. Include the cases that the process owner wishes had been easier to handle. Test missing inputs, contradictory evidence, ambiguous language, stale records, and downstream tool failure.

“A human will review it”

Human review can be meaningful, but only if the person can inspect evidence, challenge the output, change the result, and carry accountability. A reviewer who sees only a green button and a polished sentence is approving a conclusion, not reviewing a process.

Define the review contract. What must the reviewer check? What can they override? How is disagreement recorded? What happens when the queue is busy? What is the escalation route?

“We can measure success later”

Later measurement turns into opinion about whether the demo felt useful. Set the baseline and primary outcome before the pilot. It can be revised, but not invented after the result is known.

“We can clean the data after launch”

Some pilots can tolerate messy inputs if the system is designed to flag uncertainty and the action is reversible. That is different from assuming that bad data does not matter.

List the input conditions that are acceptable, reviewable, or disqualifying. A data-cleaning task may be the best first automation. It may also be the prerequisite for everything else.

“The process is high volume, so errors will average out”

They may not. Rare errors can be concentrated in the most consequential cases. Segment the baseline and define guardrails for the tails, not just the average.

“The agent can fix itself”

An agent may retry or choose another step, but self-correction is not a substitute for an external completion signal, bounded permissions, or an operator path. Anthropic’s guidance emphasizes environmental ground truth and stopping conditions for agent operation. If the system cannot tell whether the business state changed, it cannot reliably declare completion. (Anthropic Building Effective AI Agents)

“We can give it access now and tighten it later”

Access is an action boundary. Start with the least powerful permission that lets you test the intended outcome. An unrestricted pilot creates a larger incident surface before the team knows whether the process works.

“Not ready means no”

Not ready is often the most useful answer. It tells you whether to document, baseline, collect cases, clarify ownership, or design a fallback. The process can become ready through preparation. The mistake is calling it ready because the team wants the project to start.

High-impact processes need a separate gate

The four artifacts are necessary for an AI pilot, but they are not sufficient for every domain. If the process affects a person’s rights, livelihood, access, safety, health, finances, or essential services, treat the risk boundary as the first question.

The EU AI Act identifies high-risk areas that include employment and worker management, access to essential private and public services, creditworthiness, certain insurance uses, and emergency response, subject to its classification rules and exceptions. The regulation is legally binding and its implementation is time-sensitive. This article is not legal advice. Use the official text and qualified counsel for a real deployment. (Regulation (EU) 2024/1689)

The correct result in such a process may be:

• AI can assist with search, summarization, or administrative preparation;
• a qualified human must make the decision;
• the system may not infer a sensitive attribute or use an unapproved proxy;
• the case needs an appeal or contest path;
• the process requires additional impact assessment and documentation;
• autonomous execution is rejected even if the process is repetitive.

Do not let the phrase “human in the loop” close the discussion. Ask what the person can actually see, question, change, and stop. Public guidance on automated decision-making distinguishes fully automated decisions from systems that assist human judgment and emphasizes responsible data, oversight, and intervention. (UK Ethics, Transparency and Accountability Framework)

The higher the consequence, the more the pilot should begin with evidence gathering and human assistance rather than automatic action. The process may be ready for an AI assistant while remaining unsuitable for an AI decision maker.

What you still do not know after the readiness test

Passing the four-artifact test does not answer every question. It creates the conditions for a good pilot.

You still do not know:

• how a selected model performs on representative cases;
• how behavior changes when inputs or policies change;
• whether users adopt the new process;
• whether review time cancels the expected benefit;
• whether model, tool, or data costs fit the business case;
• how often an edge case appears after launch;
• whether the system remains reliable under load or provider limits;
• whether the integration preserves the system of record;
• whether the process owner can operate and improve it;
• how long the chosen design will remain maintainable.

That uncertainty is not a flaw in the readiness rule. It is the reason the rule ends at a supervised pilot rather than declaring production readiness.

NIST describes risk management as iterative across the AI lifecycle and says measurement and management should continue as context, capabilities, risks, and benefits change. Anthropic’s guidance similarly treats stopping conditions and environmental feedback as part of agent operation. A process can pass discovery and fail evaluation. That is a useful result if the pilot is bounded and reversible. (NIST AI RMF Core; Anthropic Building Effective AI Agents)

Treat the process card as a living contract

Update the card when:

• the trigger changes;
• a new system becomes authoritative;
• a policy changes;
• an exception becomes common;
• the owner changes;
• the action scope expands;
• the evaluation set reveals a new failure;
• the fallback no longer works;
• the process serves a new group of people.

Do not make the process card a document that exists only for the kickoff. It should be the reference used by the operator, builder, reviewer, and owner.

Use failed cases to improve the process

When a pilot fails, classify the failure:

Failure type	What it means	Likely next move
Wrong interpretation	The AI step needs better cases, instructions, model choice, or a narrower input	Improve the evidence pack or keep a human review
Missing business rule	The process contract was incomplete	Clarify policy or ownership
Bad source data	The system cannot trust an input or record	Repair data or add validation
Wrong handoff	The output does not create a usable next state	Redesign the process boundary
Unsafe permission	The action is too powerful for current confidence	Reduce scope and add approval
Weak value	The change does not improve the primary outcome	Stop, redesign, or choose another process
Unclear outcome	The team cannot agree what success means	Return to the completion state and rubric

This classification keeps the project from becoming a model-tuning tunnel. Sometimes the correct fix is a prompt. Often it is an input rule, a queue, a policy, a human role, or a smaller scope.

A one-page worksheet you can copy

Use this worksheet with a process owner. Fill it in before choosing a product.

Process contract

• Process name:
• Trigger:
• Scope:
• Exclusions:
• Inputs and source systems:
• Current steps:
• Decision points:
• Rules:
• Interpretation:
• Escalation conditions:
• Output:
• Accountable owner:
• Completion state:
• Common exceptions:
• Actions the system must not take:

Baseline

• Observation window:
• Unit of work:
• Volume:
• Primary outcome:
• Current value:
• Cycle time:
• Human effort:
• Rework or correction:
• Escalation:
• Customer or internal delay:
• Risk or incident signal:
• Data limitations:

Evidence pack

• Normal cases:
• Edge cases:
• Failure cases:
• Expected result for each case:
• Required evidence:
• Acceptable uncertainty:
• Refusal conditions:
• Ground-truth signal:
• Reviewer:
• Acceptance checks:

Controlled action path

• Read permissions:
• Write permissions:
• Draft-only actions:
• Approval gate:
• Stop conditions:
• Fallback:
• Recovery:
• Audit fields:
• Operating owner:
• Review cadence:

Decision

Choose one:

• Ready for supervised AI pilot
• Ready for deterministic automation
• Process repair first
• Evidence first
• Control or legal review first
• Reject or redesign

Next action:

Owner:

Decision date:

The worksheet is intentionally plain. A useful artifact should survive outside the article, in a meeting, a ticket, or a project document.

How readiness changes by process shape

The four artifacts apply to every process, but the weak artifact changes with the shape of the work. Use the following as a quick diagnostic after you complete the worksheet.

Process shape	Usually strongest first move	Artifact that deserves extra attention
Document-heavy intake	AI extraction or classification inside a fixed workflow	Evidence pack, especially unreadable and conflicting documents
Conversation-heavy support	Drafting, summarization, or routing with review	Process contract, especially escalation and completion
Cross-system investigation	Read-only retrieval and a review packet	Controlled action path, especially source authority and logging
Repetitive back-office transaction	Deterministic rules or a narrow AI interpretation step	Baseline, especially review time and exception cost
Creative or judgment-heavy work	Assistive drafting, research, or comparison	Evidence pack, because several outputs may be acceptable
High-impact decision	Assistance only until legal and domain controls are settled	Controlled action path and accountable human decision

Document-heavy intake

The temptation is to count the number of documents and call the process suitable. The better question is whether each important field has a source and whether the system knows when not to guess. For these processes, the evidence pack should include scans, missing pages, conflicting values, unusual layouts, and documents from new sources. The baseline should include reviewer correction time, not just extraction time.

Conversation-heavy support

Conversation work often looks open-ended, but the business process around it may be narrow. Define the queue, urgency, service promise, escalation conditions, and completion state. A draft reply can be useful even when automatic sending is not. A routing recommendation can be useful even when final priority remains with a human.

Cross-system investigation

The hard part is usually not the language. It is deciding which record is authoritative and preserving the link between evidence and action. Start read-only. Require the output to name the records it used. If systems disagree, stop. Do not let a model silently choose the most convenient source.

Repetitive back-office work

These processes deserve a deterministic baseline. Before adding AI, ask whether an integration, validation rule, or scheduled workflow solves the problem. If documents or messages create a bounded interpretation step, place AI there and keep the rest of the path explicit. Measure exception rate and human verification, because a faster first step can move work downstream rather than remove it.

Creative or judgment-heavy work

Judgment-heavy work does not mean anything goes. Define the dimensions that matter, the sources that may be used, the audience, and the unacceptable errors. If several outputs could be good, use a rubric, comparison, or human selection rather than pretending that one reference answer exists.

High-impact decision work

High impact changes the default. The process may be ready for search, summarization, evidence organization, or administrative preparation while remaining unsuitable for automatic decisions. The action boundary is the decision. Do not let a generic readiness checklist erase that distinction.

The shape of the process helps you choose the first experiment. It does not let you skip the four artifacts. A document extractor still needs an owner and fallback. A support assistant still needs a measurable outcome. A cross-system agent still needs a stop condition. A creative assistant still needs a quality rubric.

What a good readiness conversation sounds like

You can often detect readiness in the language a team uses. Ready teams talk about states, cases, owners, and evidence. Unready teams talk mostly about tools and aspirations.

Unready phrase	Better question
“Can AI handle our onboarding?”	Which onboarding slice, from what trigger to what completed state?
“We need an agent for research.”	Which sources may it inspect, what must it produce, and how will a person verify it?
“The model is accurate.”	Accurate on which cases, against which expected result, with what failure behavior?
“Someone will approve it.”	Who reviews, what do they see, what can they change, and what happens when they reject it?
“We will save a lot of time.”	Which unit of work, compared with what baseline, and where does the released time go?
“The process is standard.”	What happens on the last difficult case, and who owns that exception?

The better questions slow down the pitch and speed up the decision. They also make it easier for a team to build the system itself because the work has been made explicit.

When the answers become concrete, you can make a smaller promise. Smaller promises are easier to test. They also produce better information about whether the process should expand, change architecture, or stop.

The practical answer

You can tell that a business process is ready for AI automation when the business can describe its boundary, measure its current outcome, test representative cases, and contain a wrong action. Those conditions are more informative than repetition, data volume, or an impressive demo.

The four-artifact rule gives you a short decision:

1. Process contract: do we agree what starts, ends, and falls outside the work?
2. Baseline: can we see the current outcome and the cost of changing it?
3. Evidence pack: can we tell correct, incorrect, uncertain, and incomplete outputs apart?
4. Controlled action path: can we limit, review, stop, log, and recover from the system’s actions?

If all four exist, run the narrowest supervised pilot that can produce evidence. If the path is predictable, use ordinary automation. If one interpretation step needs AI, keep the workflow fixed. If the process needs model-directed path selection, add agent autonomy only after the evidence and control boundaries are explicit.

If a box is blank, do not call the process ready. Call the blank what it is. Document the process. Establish the baseline. Gather the cases. Clarify the approval boundary. That preparation is not a detour from AI automation. It is the work that makes the decision honest.

If you have a real process card and want help turning it into a capability your own team can build and operate, learn about Marius Manolachi’s AI consulting and tutoring work. The article is complete without that next step. The process card is the next step that matters.