Redesigning Work Before Automating It with AI

A fictional building-supplies distributor receives about 2,400 customer credit requests a month: damaged pallets, short deliveries, wrong items. The vice president of customer operations has a proposal on her desk to buy an AI assistant that reads each request email, fills in the credit form, and drafts the credit memo. The vendor’s pilot shows the assistant cutting six minutes from a fourteen-minute clerk task. Before she signs, the operations analyst asks for one more number: how long does a request take from arrival to posted credit? The answer is three business days for a clean request and, across all requests, a little over six. The six minutes the assistant saves sit inside a process that spends almost all of its time somewhere else.

The distributor and its figures are invented for this example, and every number below is hypothetical. The question is general. Fourteen Pilots and Nothing in Production argued that an AI use case should map the existing decisions, handoffs, and responsibilities before deciding what must change. This article carries that step out: how to analyze tasks and exceptions, separate decisions from execution, find what handoffs cost, simplify without AI, and then decide what a person must still answer for. The UK government’s AI Playbook makes the same point at the level of principle, describing AI as a means to an end and not an objective, and noting that it is not always the best solution to a problem.

Start with the tasks and the exceptions

The first piece of work is a process map built from real cases, not from the policy document. The analyst pulls a month of requests, walks a sample of each kind through the process with the clerks who handle them, and records for every case the steps taken, the time people spent on it, the elapsed calendar time, and the loops where the case went back. The aim is a description of how the work actually runs, including the path that does not finish cleanly.

Grouping requests by how they behave gives three segments. Standard requests arrive complete, the delivery record confirms the problem, and the amount is small. Missing-information requests need at least one exchange with the customer or the warehouse before anyone can decide. Complex requests involve partial deliveries, carrier claims, or pricing disputes and usually need several people. The table shows volume and effort, where effort is the minutes of hands-on work per case multiplied by the number of cases.

Segment	Requests per month	Share of requests	Hands-on minutes per case	Hours per month	Share of effort
Standard	1,440	60%	14	336	26.8%
Missing information	600	25%	35	350	27.9%
Complex	360	15%	95	570	45.4%
All requests	2,400	100%	31.4 on average	1,256	100%

The pilot measured the assistant on the typical request, which is standard, and 60 percent of the requests account for under 27 percent of the effort. The exceptions, meaning everything that does not follow the clean path, are 40 percent of the requests and 73 percent of the effort. That changes what automation is worth: a tool that handles the clean path well attacks the cheapest part of the work.

An exception also has a cause, and the cause is often upstream. The analyst reads a sample of 100 missing-information requests and finds that 58 lack a delivery receipt reference, 27 have no photos of the damage, and 15 name the wrong customer account. Those are failures of the intake step, not of the people who later chase the information. An assistant that drafts better follow-up emails would make the chasing faster and leave the cause untouched. Exception analysis therefore asks two questions of each category: how much effort does it consume, and what earlier step creates it?

Hands-on time is not elapsed time

A standard request takes 14 minutes of hands-on work and three business days to complete. A business day is 480 minutes, so three days is 1,440 minutes, and the work itself is about 1 percent of the elapsed time. The rest is waiting. The request waits in the shared inbox for a clerk, waits for the warehouse to confirm the delivery, waits in a manager’s approval queue, and waits for finance to post the memo. Each of those transfers is a handoff, and each handoff adds a queue, a chance for information to be lost, and often a loop back to the previous step. DORA’s guidance on value stream mapping makes the same observation about software delivery: pay close attention to handoffs between teams, which are often sources of miscommunication and delay.

Queues also show up as inventory. Little’s law says that for a stable system, the average number of items in the system equals the average arrival rate multiplied by the average time each item spends there. With 2,400 requests over about 21 business days, arrivals average 114.3 a day. Weighting the elapsed times of three, eight, and fifteen business days by segment gives (1,440 × 3 + 600 × 8 + 360 × 15) ÷ 2,400 = 6.05 business days on average. The distributor therefore carries about 114.3 × 6.05 ≈ 691 open requests at any moment, each one a customer waiting for money or an unresolved invoice.

Now apply the proposal. Six minutes saved on each of the 1,440 standard requests and, assume, four on each of the 600 missing-information requests is 11,040 minutes, or 184 hours a month. That is a real saving, about 15 percent of the 1,256 hours of effort. But for a standard request, six minutes is 6 ÷ 480 = 0.0125 of a business day. The three days become 2.9875. Customers see no difference, and the queue of 691 requests does not shrink in any way a customer would notice. The assistant improves the cost of the work while leaving the time to complete it almost unchanged, because the time is in the handoffs. If the business case promised faster credits, this tool does not deliver them. If it promised capacity, the saving is 184 hours that must still be converted into something.

Separate the decisions from the execution

Process steps fall into two kinds. Execution steps carry out something that has already been decided: keying the order number, attaching the delivery receipt, posting the memo. Decision steps apply judgment to settle a question: is this damage claim valid, is the amount right, is this customer’s pattern of claims unusual? Mixed steps hide both. When a clerk “processes” a request, the clerk is executing most of the time and deciding some of the time, and the proposal to automate the step treats the two as one.

A decision inventory pulls them apart. For each decision in the process, record the question it answers, who makes it, which decision right that person holds, what information they use, whether the rule is written or tacit, how often the decision is changed or overturned downstream, and what an error costs. The distributor’s inventory shows five decisions. Four are made by clerks on written rules. The fifth, manager approval of every credit memo, is the largest source of waiting, and the analyst asks what it accomplishes.

A month of approvals gives the answer: the managers changed the amount or rejected 96 of 2,400 requests, 4 percent. Of those 96, 78 came from the missing-information and complex segments, and 18 from the 1,440 standard requests, a rate of 1.25 percent. The average correction on a standard request is \$140, so approval of standard requests recovers 18 × \$140 = \$2,520 a month. It costs a manager three minutes per request, 1,440 × 3 = 4,320 minutes, or 72 hours. At an assumed loaded cost of \$60 an hour that is \$4,320, more than the money recovered, before counting the average 1.5 business days of queue time that approval adds to a clean request. For this segment, the check costs more than the errors it catches, and the standard cases wait 2,160 case-days a month for it (1,440 × 1.5), which is the delay a customer feels.

That arithmetic does not by itself justify removing the approval. Credits move money out of the company, and a control can matter for reasons other than the average correction: deterrence, a pattern of one clerk’s errors, or a rare large mistake. The finding is narrower. Approval was applied uniformly because the rule was written after an incident years earlier and never revisited, and its price, in decision latency, was never counted. The redesign question is whether a cheaper control can serve the same purpose for the segment where the loss per case is small, such as a clerk’s authority to approve standard credits up to a stated amount, finance’s own limits on posting, and a periodic audit of a sample. A 10 percent monthly sample of the standard cases is 144 requests, which would contain about two corrected cases at the observed rate. That is too few to watch the rate month by month, so the audit is read over a quarter, where 432 sampled cases would contain about five. Who may change the rule, and what the exposure limit is, are decisions for the process owner and finance, not for the analyst.

The same split tells you how an AI system could enter. It can execute a step, such as extracting fields from an email. It can prepare a decision, assembling the order history and a draft assessment for a person to judge. It can make a decision itself. Each carries different consequences for who is responsible when it is wrong, and the choice should follow from what the decision inventory shows about the rule, the error cost, and the volume. For the distributor, extraction on a form that will soon be structured is low in value, and preparing the evidence for complex cases looks far more promising.

Remove work before automating it

Michael Hammer argued in his 1990 Harvard Business Review article “Don’t Automate, Obliterate” that firms had used technology to speed up old processes where they should have redesigned them. The practical sequence that follows from it is to ask what can be eliminated, combined, or standardized, and only then ask what remains to be automated. Google’s SRE book states the same test for toil: if the need for a task could be designed away, the task is toil. The toil entry explains why repeated judgment caused by avoidable complexity belongs in that category.

The analysis already points to three simplifications. First, a structured intake form that will not submit without the order number, a delivery receipt reference, and a photo addresses all three causes found in the missing-information sample. Second, the delegated approval described above removes the largest queue. Third, a customer-facing status page removes the “where is my credit?” contacts that interrupt clerks, although the analysis has no data on their volume and the distributor would need to measure it before counting a saving. Suppose the form lowers the missing-information share from 25 percent to 10 percent, and the 360 requests that no longer need follow-up behave like standard requests. The case mix becomes 1,800 standard, 240 missing-information, and 360 complex. Effort falls from 1,256 to 67,800 ÷ 60 = 1,130 hours, a reduction of 126 hours (360 × 21 minutes), and with approval removed from standard cases their elapsed time drops from three business days to 1.5.

The average elapsed time becomes (1,800 × 1.5 + 240 × 8 + 360 × 15) ÷ 2,400 = 4.175 business days, and by Little’s law the open requests fall from about 691 to 114.3 × 4.175 ≈ 477. Compare this with the AI proposal: 126 hours saved, plus a third fewer days of waiting for the typical customer, without buying a model. These results are projections from assumed behavior, so the distributor should run the form and the delegated approval for a defined period and measure the actual mix and elapsed times. What the simplification buys the AI decision is a new baseline. An AI tool should be evaluated against the simplified process, not the original one; otherwise it receives credit for improvements a form would have delivered. This is the same discipline Live for a Year, Used by a Third applied to benefit claims: write the value hypothesis against a baseline that is measured and agreed in advance.

Where AI belongs after the redesign

After the simplification, the standard path is short and cheap, and the 360 complex requests are 50.4 percent of the remaining effort: 34,200 of 67,800 minutes. This is where clerks spend their long hours, and the work has a shape that suits an assistant. A complex case begins with a clerk reading a long email thread, pulling the order and delivery records, checking the carrier’s terms, and assembling a file for the decision. The reading, retrieving, and summarizing steps are execution in service of a human judgment. An assistant that prepares that file, with each statement linked to its source record, leaves the judgment where it was and removes part of the effort.

Suppose a pilot on complex cases shows a net saving of 20 minutes per case, after the time a clerk spends checking the assistant’s file against its sources. That is 360 × 20 = 7,200 minutes, or 120 hours, about 10.6 percent of the 1,130 hours that remain. The saving is smaller than the 184 hours in the first proposal, but it is aimed at the cases where time is spent and where elapsed time is longest. The pilot also needs a measure that counts the checking. The assistant’s cost belongs per successfully resolved case, with failed drafts, rework, and review included, not per draft. The related entry on cost per successful task works through the arithmetic.

AI is not the only tool for this remaining work. A checklist, a better search across the order and delivery systems, or a shared case template might deliver part of the saving at lower cost and with less operating burden. Testing those alternatives on the same cases keeps the comparison honest. The assistant earns its place if it beats the best non-AI option on the measures that matter, including the cost of operating it.

Who answers for the redesigned work

A redesign changes who does what, and the new arrangement needs someone who can answer for it. Responsibility and accountability are different assignments: responsibility belongs to whoever performs the work, while accountability belongs to whoever must answer for the outcome and has the authority to change it. In the distributor, the director of customer operations is accountable for the credit process end to end: the intake form, the delegated limits, the exception queue, and the assistant’s use within them. The clerks are responsible for the cases they decide. Finance holds the exposure limits. The AI vendor supplies a component; buying it does not transfer accountability for the process.

The redesign also changes the clerks’ jobs. In the new process the clerks handle fewer routine cases and more of the hard ones, and for the standard path they become auditors of a lightweight process. Lisanne Bainbridge’s 1983 paper “Ironies of Automation” describes the consequence: when automation takes the routine work, the operator is left with the abnormal cases and less practice at them. The distributor can plan for this. Clerks keep handling a share of standard cases themselves so that the skill stays current. Training moves to the complex categories. Reviewers of the assistant’s files are given the source records, time to check, and clear authority to reject a file, because human oversight is only as strong as what the reviewer can see and change. The risk of review turning into reflexive acceptance, called automation bias, rises with volume and with a good track record, so the process measures override rates and has an independent sample audit.

Capacity is the last operating question. Effort of 1,256 hours a month is 7.85 full-time equivalents at 160 productive hours each. After the form and delegated approval it is 7.06, and after the complex-case assistant 6.31. Whether that frees people for other work, absorbs growth in volume, or reduces headcount is a decision for the operations director with finance, and it should be made explicitly. Without that decision, saved hours dissolve into slack and no budget moves. The process also needs a fallback. If the assistant is unavailable or its quality drops, clerks must be able to prepare complex files by hand, at the old 95 minutes, and the staffing plan should say how long the team can absorb that. A process that cannot run without its AI component has traded a cost problem for a continuity problem.

What a reviewer should ask

1. Which segments of the work exist, how much of the effort does each consume, and what upstream cause produces each exception category?
2. What are the hands-on time and the elapsed time for each segment, and where does the waiting occur?
3. Which steps are decisions and which are execution, who holds each decision right, and how often is each decision changed downstream?
4. What could be eliminated, combined, or standardized without AI, and what baseline does that create for judging the AI proposal?
5. Does the AI tool execute, prepare, or make a decision, and what are the net savings after checking its output?
6. Who is accountable for the redesigned process, which skills must the remaining human work keep, and what happens when the AI component fails?
7. What will be done with released capacity, and who decides?

The vice president declines the original purchase. She funds the intake form and the delegated approval limits first, with a ninety-day measurement of mix, elapsed time, and sampled corrections, and asks the vendor to run a second pilot on complex cases against a checklist-and-search alternative. The director of customer operations owns the redesigned process and the capacity decision. The assistant is approved for complex cases only if its net saving holds against the simplified baseline.

References:

• UK Government Digital Service, Artificial Intelligence Playbook for the UK Government, 2025 (Open Government Licence v3.0).
• DORA, How to use value stream mapping to improve software delivery.
• DORA, Capabilities: Streamlining change approval.
• Google, Site Reliability Engineering: Eliminating Toil.
• Lisanne Bainbridge, Ironies of Automation, Automatica 19(6), 1983.
• Michael Hammer, Reengineering Work: Don’t Automate, Obliterate, Harvard Business Review, July-August 1990.