When starting an AI project, many teams ask what percentage of work a tool can automate. The question can lead to a rushed path: choose a process, connect data, and then try to minimise human involvement. Yet in most service, sales, operations, or people work, value and risk sit in situations that are not completely alike. A seemingly simple request can contain different contract conditions, missing data, an unusual customer history, or a decision beyond the authority of the person handling it.
A more practical starting point is therefore to design how the system handles exceptions. Once a business knows which work can follow a standard path, which work must pause for clarification, and which work must go to an authorised person, it has a basis for deciding how far AI should act. This approach does not slow implementation. It helps a team avoid spending months automating a process that has not yet been described clearly enough to operate safely.
The standard path is only part of the work
Consider responding to a quotation request. The standard path may involve receiving need information, checking the service catalogue, applying the price list, and preparing a response draft. A request may nevertheless exceed the standard scope, require a discount, have an urgent deadline, or involve special payment terms. If the design focuses only on generating quotations quickly, the system may produce a plausible response that commits the business to something it cannot deliver.
The implementation team should map work into three zones before writing any automation rule. The standard zone contains cases with clear inputs, approved information sources, and an output that can be checked. The clarification zone contains cases with missing data or conflicting signals. The human-handoff zone covers decisions about price, legal exposure, safety, reputation, or authority to commit to a customer. These zones create an operating boundary for AI rather than forcing the tool to act certain in every situation.
| Handling zone | What AI can do | What should be recorded |
|---|---|---|
| Standard path | Find approved sources, check conditions, and prepare a draft. | Sources used, input data, and review criteria. |
| Clarification needed | Identify missing data, state questions, and suggest the next step. | Information still missing, who must provide it, and the waiting period. |
| Human handoff required | Stop at the defined point, summarise context, and route to the right owner. | Reason for the handoff, approver, and final decision. |
Design stopping points before designing actions
Many processes are described through steps to take but omit the conditions that require a stop. This gap easily leads AI to act beyond what was intended. A useful stopping point does not merely say, “escalate to a manager when necessary.” It names a signal: an order value above a threshold, a term not found in the approved library, a missing data field, or a type of complaint that must not receive an automated response.
A stopping point should also lead to an action useful to the person receiving the handoff. Rather than placing a request in a general inbox, AI can summarise the information received, identify sources checked, state open questions, and explain which option is blocked. The authorised person does not then need to begin again and can still assess why the system did not proceed. Handoff quality is as important a design concern as the quality of an automated answer.
Example: an assistant for return requests
A retailer wants AI to guide employees who handle return requests. The team does not let the tool decide every case on its own. For an order within the return period, with a receipt, and with an ordinary product, the assistant finds the current policy and prepares guidance for the employee. If the order number is missing, the product has been used, or the customer reports a safety incident, the assistant moves to clarification questions or routes directly to the responsible team. In the handoff note, it records product type, purchase date, the customer’s statement, and the relevant policy term. After one month, the team reviews the most common handoff reasons to see where policy needs clarification or training needs reinforcement.
Put exceptions where an owner exists
An exception list is useful only when each exception has an accountable person and an update mechanism. If employees repeatedly encounter a situation and do not know whom to ask, they will create private rules or find ways around the system. Feedback data then becomes fragmented, while AI learns from ways of working that have not been controlled.
A business can begin with a simple table: exception type, identifying signal, decision owner, expected response time, and the authoritative source to consult. When an exception occurs often, the team should not assume it must immediately enter the automated path. First, it should determine whether it is a valid process variant, an ambiguity in policy, or a problem that should be removed at the input stage. Each answer leads to a different change: updated guidance, a redesigned form, a new delegation rule, or a retained human checkpoint.
Measure work completed correctly, not automation alone
An automation-rate metric can create the wrong incentive when it makes every human handoff appear to be a failure. In a risk-sensitive process, a handoff at the right time is more valuable than a fast but incorrect response. Alongside the number of tasks handled automatically, track correct exception recognition, processing time after handoff, rework, feedback from frontline employees, and repeating exception types.
These signals help a team distinguish two choices. One is to expand the standard zone because data and rules are mature enough. The other is to keep or strengthen a checkpoint because real-world variation remains high. AI may support more work over time, but the degree of automation should follow operating evidence rather than become a goal separate from service quality and accountability.
Start small, but leave a learning trail
A narrow use case is often the right place to test this approach. Choose a request type with adequate frequency, an identifiable policy source, and an owner willing to review results. During the first weeks, record standard cases, stopped cases, stopping reasons, and final decisions. There is no need to turn every record into a large report; a short weekly review can already reveal which rules are missing and where users are getting stuck.
Introducing AI into a workflow is not a contest to remove people from every step. It is the work of making the part that can be standardised more consistent, while routing the part that needs judgement to the right place with enough context. When exceptions are designed as a source of learning rather than an error to hide, a business gains a stronger foundation for controlled automation.
