Roles covered: operations leader, process owner, exception-queue lead, master-data owner. Functions: operations, with interfaces to finance, engineering, sales, and procurement. Linked workflows: order intake, inventory forecasting, catalog enrichment.
Operations leaders should begin with the complete process: what arrives, what must leave, where work waits, and what happens when something is wrong. AI is useful when it improves that flow under real constraints. This guide covers the decisions that belong to you rather than to engineering, finance, or a vendor, and points to the workflow chapters for worked cases, arithmetic, and evaluation designs.
The planning example below is fictional and labeled as such. Recommended controls are proposed practices, not observed results. Where this guide relies on an external source, it says so and states the source's limits.
The decisions you own
Where the constraint is. You decide which step limits throughput, quality, or cost, and therefore where a change can matter. Engineering can make a step faster; only the process owner can say whether faster matters.
What happens to exceptions. You decide what counts as an exception, who resolves it, how long it may wait, and what the customer experiences while it waits. In the workflow designs in this guide, the economics sit here: routine cases get cheaper, and the remaining cases define the staffing, the cycle time, and the error cost.
What a system may do on its own. You decide the arrangement for each step, in the terms of the authority chapter: assistance that only informs a person, approval before action, where a person approves a proposal before anything is written to a system of record, or, once evidence supports it, monitored execution. You also decide what counts as a duplicate, a valid correction, or an unauthorized substitution. These are business rules, not implementation details to leave to a vendor.
The outcome you answer for is dependable completed work: correct orders shipped, accurate catalog records published, replenishment decisions that hold the agreed service level. A measure that looks like progress but is not: faster processing at one step. Suppose an assistant makes order entry faster but the warehouse cannot fulfill additional orders. The team may gain administrative capacity without increasing shipments. Alternatively, better product matching may reduce returns even if entry time changes little. Choose the measure that reflects the actual problem.
Map the work you manage
Walk several cases through the whole process with the people who do the work. Include ordinary cases, amendments, incomplete inputs, and failures. Write down each handoff and the person who can resolve it. The workflow-change chapter describes how to define the unit of completed work and look for work that moves elsewhere rather than disappearing. Use the exercise to find opportunities for clearer forms, better mappings, or ordinary automation alongside AI.
The table below is a proposed starting inventory for a distribution operation. The starting authority column is a recommendation for a first trial, not a ceiling.
Capability verbs in the table follow the capabilities chapter; starting authority uses the arrangements in assistance, approval, and autonomy.
| Task | Consequence of an error | Candidate capability | Proposed starting authority | Canonical chapter or first fix |
|---|---|---|---|---|
| Key customer purchase orders into the order system | Wrong item, quantity, or unit ships; credits and freight | Extract, then deterministic validation | Approval before action; specialist approves the staged order | Order intake |
| Detect duplicate or revised orders | Double shipment or missed amendment | Rules on business identity; generation not required | Unchanged; rules flag duplicates, a person resolves exceptions | Order intake, duplicate and retry sections |
| Map customer part numbers to SKUs | Substitution the customer did not accept | Retrieve and classify against the mapping table | Approval before action; unmapped items held | Maintain the mapping table first |
| Enrich supplier product data into the catalog | Wrong pack size or unsupported safety claim published | Extract with source spans; generate limited copy | Approval before action; steward approves, compliance attributes owner-approved | Catalog enrichment |
| Forecast demand for replenishment | Stockout or excess inventory weeks later | Predict | Approval before action; planner approves orders | Forecasting |
| Set reorder policy (lead times, buffers, pack multiples) | Systematic over- or under-ordering | None needed | Unchanged; fix the policy data | Forecasting, "compare against simpler methods" |
| Answer "where is my order" questions | Wrong promise to a customer | Retrieve from order and shipment records | Assistance; no new commitments | Existing status lookup may suffice |
| Post receipts and adjust inventory | Book stock diverges from physical stock | Not a first candidate | Unchanged | Cycle counts and scanning discipline |
Three tasks in this table need no model to start, and one depends on data that has to be fixed first. That is a legitimate outcome of mapping. Separate the work you perform from the work you supervise: you may approve reorder policy yourself, while a team of order-entry staff performs intake. The skills and review burden differ.
Who decides what
A proposed division of responsibility for an assisted operations workflow:
| Decision or activity | Operations leader | Process staff | Master-data or knowledge owner | Engineering or IT | Finance | Sales or customer service |
|---|---|---|---|---|---|---|
| Unit of work and acceptance criteria | Owns | Contribute cases | Contribute definitions | Advise on feasibility | Reviews value basis | Contribute customer impact |
| Exception definitions and routing | Owns | Resolve exceptions | Resolve data gaps | Implements routing | — | Handles customer contact |
| Authority to write into systems of record | Approves scope | Approve individual records | — | Enforces permissions and retry protection | — | — |
| Master data (SKUs, units, mappings, lead times) | Sets quality expectations | Report errors | Owns accuracy and change control | Maintains integrations | — | Reports customer part numbers |
| Service-level target | Owns jointly with sales | — | — | — | Reviews inventory cost | Owns jointly |
| Fallback and manual operation | Owns and rehearses | Perform | — | Provides the switch-off | — | Informed |
| Value and cash realization | Provides volumes and effort | — | — | Provides running costs | Owns | — |
Distinguish owning the outcome from operating the system. Engineering can operate the extraction service without owning order accuracy. Staff who approve a record own that approval; the leader who defined the review contract owns whether that contract was adequate.
Design the exception path first
For each proposed step, specify what must be known, what counts as an exception, where the exception goes, and how long it can wait. Allocate staff to that queue. A system that processes easy cases quickly can leave a smaller but harder queue requiring more expertise.
Do not use the model's confidence as the sole control. Prefer observable conditions: missing required data, conflicting sources, an unrecognized item, a request outside scope, or a failed validation rule. The human-review playbook sets out routing by consequence and uncertainty. Escalation needs an owner and a clear record of the unresolved question.
Size the queue before the trial
The order-intake chapter's illustrative mixture is useful for a role-level staffing decision. With 2,100 assisted orders a month and 20% of them exceptions handled in seven minutes each, the exception queue receives 420 orders and needs 420 × 7 = 2,940 minutes, or 49 hours of skilled handling a month. If exceptions rise to 40%, the queue receives 840 orders and needs 98 hours. These hours are already inside the order-intake chapter's assisted averages; they are shown here to decide who staffs the queue, not to be subtracted again from the economics.
Queue length matters as much as hours. Little's Law states that the average number of items in a queuing system equals the average arrival rate multiplied by the average time an item spends in the system. Little, Operations Research, 2011 Over 20 working days, 420 exceptions arrive at 21 per day. If each waits two working days on average, about 21 × 2 = 42 orders sit unresolved at any time; at the 40% exception share, about 84. Every one of those is a customer waiting. Decide before the trial what age is acceptable, and what happens when the queue exceeds it.
Every dot is an order waiting for a person
20% exceptions: 21 a day × 2 days’ wait = 42 orders open, 49 handling hours a month
40% exceptions: 42 a day × 2 days’ wait = 84 orders open, 98 handling hours a month
Show the data
| Exception share | Exceptions a month | Handling hours a month | Arrivals a day | Open at any time |
|---|---|---|---|---|
| 20% | 420 | 49 | 21 | 42 |
| 40% | 840 | 98 | 42 | 84 |
These figures are illustrative arithmetic from invented inputs, not measured exception rates. The relationship is an average over a stable period; bursts, month-end peaks, and a few very hard cases can make the experienced wait much worse.
Match authority to reversibility
Drafting an internal summary, proposing an inventory order, and sending that order to a supplier require different permissions. Begin with a reversible step and retain explicit approval for consequential actions. A proposed progression:
- Read-only. The system prepares information; a person does everything else.
- Proposal. The system stages a record; a person approves a specific version before anything is written.
- Approved write. An approved payload is submitted with a stable operation identifier and reconciled against the destination record.
- Monitored action within limits. Only for low-consequence, reversible actions with an evaluated error record, and never as a first step.
Define how records are reconciled if a write fails after partial completion. Caller-provided request identifiers can make retries safe, and a timeout can leave completion uncertain; whether your order or purchasing system honors such identifiers must be tested. The order-intake chapter cites the engineering source and proposes explicit states such as "outcome unknown" so an uncertain submission is reconciled rather than resent.
Plan fallback as an operating mode, not a disaster procedure. If the extraction service, forecast, or enrichment tool is unavailable, the team should know which manual process resumes, who decides to switch, and how work already in flight is reconciled. A rollback path that nobody has practiced is an assumption.
Protect the service level
When AI changes one step, the service commitment can move without anyone deciding to move it. A forecast that lowers inventory by accepting more stockouts is a policy change, as the forecasting chapter explains. A faster intake step that sends more orders to an understaffed exception queue can lengthen order-to-ship time. A catalog tool that publishes faster but holds fewer records for missing supplier data can put incomplete records in front of customers.
Before any trial, write down the service measures that must not deteriorate: fill rate or availability, order accuracy, order-to-ship time, published-record accuracy. Agree how each is measured and who can declare a breach. Report them next to the efficiency gain, not in an appendix.
Plan a first quarter
The following example is fictional. Harrowmint Supply is an invented industrial distributor with one warehouse, about 3,000 customer orders a month arriving mostly as emailed PDFs, a catalog of roughly 12,000 active SKUs, and planners who reorder from ERP suggestions. Its operations leader has budget for one AI trial this quarter and three candidates: order intake, catalog enrichment, and forecasting.
Weeks 1–3: measure before choosing. The leader samples two weeks of orders and records keying time, correction rate, credits caused by entry errors, and the age of unresolved orders. Planners log how often they override ERP suggestions and why. The product-data team records how long new items wait for complete records. No tool is selected yet. The choosing-a-workflow chapter gates apply: an owner, a defined outcome, permitted inputs, a baseline, bounded authority, and review capacity.
Week 4: choose. In this invented scenario, the measurements show that intake errors concentrate in unmapped customer part numbers, and that catalog records for new items are missing pack quantities. Forecasting has a data problem: stockouts were not recorded, so sales history understates demand. The leader chooses order intake, with a condition: first spend two weeks cleaning the customer part-number mapping table, because the extraction step cannot fix a mapping that does not exist. Catalog enrichment is next: Harrowmint's missing pack quantities are confined to new items, which make up little of its order volume, so they do not hold intake back. The wholesale distribution guide puts enrichment first for a distributor whose orders lean on new items; the order follows where intake exceptions actually come from. Forecasting waits until stockout periods are recorded.
Weeks 5–8: offline test. The team replays a held-out sample of past orders through the staging process, with no writes to the order system. The exception queue is sized from the replay's exception share, and one experienced order-entry specialist is named its owner.
Weeks 9–12: supervised trial and decision. One customer segment moves to staged intake with human approval. The team measures total effort including exceptions, order accuracy, queue age, and credits, and the fallback is rehearsed once. At week 12 the leader expands, revises, or stops against criteria written in week 4.
Counterexample. Suppose the week 1–3 measurements had shown that the real delay was credit holds and picking capacity, with orders waiting two days for release after being keyed in minutes. Faster intake would then add orders to a queue that cannot absorb them. The right call would be not to run the AI trial, and to fix credit release and pick scheduling first. Likewise, a forecasting trial on stock data the team does not trust would measure data errors, not forecasting.
Measure the right things
For whoever runs the pilot
| Measure | Why it matters | How it can mislead |
|---|---|---|
| Throughput | Completed acceptable units over a stated period | Counting processed but uncorrected units inflates it |
| Cycle time | Elapsed time from valid input to finished output | Excluding time in the exception queue hides the slowest cases |
| Human effort | Total work across all affected teams, including review and exceptions | Measuring only the assisted step moves work out of view |
| Rework | Corrections after the output was treated as complete | Late-discovered errors fall outside a short pilot window |
| Exception load | Volume, age, and skill required to resolve exceptions | An average age hides a tail of very old items |
| Critical failures | Errors by consequence, reported separately from averages | Small samples can show zero without proving zero risk |
| Service measures | Availability, order accuracy, order-to-ship time | A quiet pilot period says little about peak weeks |
| Continuing work | Hours for mapping, schema, evaluation, and monitoring upkeep | May sit in another team's budget and go uncounted |
Inspect results by case type and volume. A pilot using clean inputs during a quiet week is not evidence about peak operations. Released hours become money only through specific mechanisms such as avoided overtime or temporary labor; the economics chapter and finance leaders guide explain the distinction.
Your team: work, judgment, and skills
In the proposed designs, work shifts from keying and searching toward checking, resolving exceptions, and maintaining the data the systems depend on. Judgment remains with people: whether an ambiguous line is a substitution the customer would accept, whether a supplier document governs this packaging level, whether a forecast-driven order makes sense given a customer event the data does not show.
| Group | What they need to learn |
|---|---|
| Order-entry and customer-service staff | Checking a staged record against its source; recognizing when to hold rather than approve; recording why a correction was made |
| Exception-queue owners | Resolving harder cases; spotting recurring causes and routing them to data owners |
| Master-data and product-data stewards | Change control for mappings, units, and attribute schemas; approving compliance attributes only from evidence |
| Planners | Reading forecast ranges and exception lists; logging overrides with reasons |
| Supervisors | Reading queue age and error measures by case type rather than averages |
Review can degrade into approval; the authority chapter lists the signs. A proposed safeguard is to keep people practicing the underlying task: rotate staff through some unassisted work, and include known-wrong records in periodic checks.
Whether the team's size or roles change is a decision to plan and measure, not a forecast this guide makes. If released time will be redirected, name where: a backlog, supplier follow-up, cycle counts, or avoided temporary labor. Each has a different measure.
Who to bring in. A first intake pilot can bring in a builder for extraction and staging, integration work on the order system's write permissions, retry protection, and switch-off, and an independent evaluator to run the offline replay and size the exception queue from it. Keep in-house what outsiders cannot supply: the unit of work and acceptance criteria, exception definitions, master-data ownership, approval of each record, and the rehearsed fallback. The part-number mapping cleanup in the first-quarter plan is work for your own master-data stewards, not a build task. See Staffing an AI pilot and Choosing and working with an AI partner.
Change management and governance
Involve the people doing the work in mapping and in building evaluation cases; they know which inputs are hard. Explain what the trial measures and what it does not, and say plainly how released time will be used. Adjust targets so they do not reward unsafe reliance: a quota of records approved per hour invites approval without checking. Measure reviewers on accuracy and appropriate holds as well as speed.
Make failure reporting cheap. A one-step way to flag a bad proposal, with the investigation owned by a named person rather than absorbed invisibly by the reporter, keeps the error record honest. Budget for maintaining rules, source data, and evaluations as continuing work, not as a launch task.
Warning signs
| Signal | What it may indicate | Proposed response |
|---|---|---|
| Exception queue age rising while throughput holds | Easy cases automated; hard cases understaffed | Re-staff the queue or narrow scope before expanding |
| Approval rate near 100% with falling review time | Rubber-stamp review | Seed known-wrong cases; revisit targets |
| Corrections appearing after shipment or publication | Review checks the wrong things or the window is too short | Extend the observation window; revise the review contract |
| Frequent manual workarounds outside the system | Scope or interface does not fit real cases | Map the workaround and decide whether it belongs in scope |
| Master-data fixes requested repeatedly for the same fields | The model is compensating for missing data | Fund data ownership instead of more prompting |
| Service measure slipping while cost falls | A policy change presented as efficiency | Report both together; revert if the breach is confirmed |
These are signals to monitor, not reported frequencies.
Questions to ask vendors and internal teams
- What happens to an item the system cannot process: which queue, with what information attached?
- Can we see the source evidence for every proposed value, and the reason for every hold?
- How are retries protected against creating a second order or record, and how is an unknown outcome reconciled?
- Which parts of the behavior can our staff change, such as mappings, rules, and schemas, without a vendor release?
- What must we maintain continuously, and how many hours did your estimate assume?
- How do we switch it off, and what state is work in progress left in?
- Which of your performance figures come from data like ours, and which are vendor-reported from other settings?
When to wait
Defer if the baseline process is undocumented, if no one can authorize corrections to master data, if the destination system cannot safely accept retried writes and no reconciliation queue is staffed, or if the real constraint lies downstream. Defer forecasting until stockouts, lead times, and promotions are recorded; defer catalog enrichment until an attribute schema has an owner.
The simpler investment may also serve the later AI work: a maintained mapping table, a documented reorder policy, a clean attribute schema, and a staffed exception queue. Your role is to make the operating system dependable; the model is one component of it.
What external research establishes
For your analyst
This chapter cites one external source directly; the retry principle it relies on is cited in the order-intake chapter and says nothing about any particular order system. Little's 2011 paper states the relationship between arrival rate, time in system, and number in system that the queue example uses; it is a queuing result, not evidence about AI-assisted operations.
We found no attributable evidence on how AI-assisted order intake, catalog enrichment, or forecasting changes operations staffing, exception rates, or service levels in distribution, and this guide asserts none. The workflow chapters list the operator records and measurements still needed.
Related reading
Wholesale distribution, order intake, inventory forecasting, catalog enrichment, human review and escalation, pilot design, and economics. For planning templates, see the pilot kit.