Redesigning Work Around People and Agents

The business remains responsible for the delegated work. To manage it, someone needs to understand the actual sequence of work, not the tidy version in a process diagram that says “handle inquiry” and draws one arrow to “customer satisfied.”

Start with one real request and follow it from arrival to outcome. Imagine the small company that sells commercial coffee equipment, now handling a replacement-parts inquiry: “The replacement pump arrived, but it doesn’t fit our unit. Can you send the right one before Friday?” The message is short. The work behind a good answer is not.

Someone must identify the customer and product, understand what “doesn’t fit” means, check the order and product records, determine whether the customer has the wrong part or the wrong expectation, confirm stock and delivery timing, decide whether an exchange is allowed, communicate clearly, and make sure the promised follow-up actually happens. If the company needs a photograph or serial number, someone must ask for it and remember to resume the case when it arrives.

A useful map follows the request through four kinds of events: inputs, decisions, handoffs, and outcomes. It also records the tools involved and the places where work tends to stall or go wrong. This need not become a grand flowchart. A page of notes assembled with the people who do the work is often more revealing than a polished diagram assembled without them.

Follow the work, not the ideal

Ask the person handling inquiries to walk through a recent case, including the inconvenient bits. Where did the request arrive? What information was missing? Which system did they open? What did they check before replying? Who had to approve an exception? What happened after the email was sent?

That last question matters. The customer may still need a return label; the warehouse may need an instruction; the case may need a reminder if the requested details do not arrive. A process map that ends at “reply sent” can quietly misplace the very work that makes the reply useful. An action is not an outcome: sending a response is a step, while resolving the customer’s problem is the result to check.

For the replacement-pump inquiry, the map might look like this in plain language:

• Request arrives: The email enters the shared inbox. A person or system identifies it as a fit or replacement question.
• Case is understood: The handler finds the order, customer, product, and relevant policy. If the description is unclear, they ask for a photo or serial number.
• A decision is made: Is this a straightforward exchange, a product-compatibility question, or a complaint requiring a specialist? Is the proposed remedy within policy?
• Actions are taken: The customer receives an answer; an exchange may be recorded; the warehouse may be notified; a follow-up may be scheduled.
• Outcome is checked: The case is closed only when the needed action is confirmed—or kept open with an owner and next step.

The map should include the forks, not just the main road. “If the replacement is in stock” and “if the customer’s equipment is outside the supported range” are different paths. So are “customer sends the requested photo” and “customer never replies.” A process that works only when every request is clear, every record is correct, and every colleague is available is not a process; it is a hopeful anecdote.

Mark the judgment and the handoffs

As you trace the route, distinguish steps that follow a stable rule from those that call for interpretation. Looking up an order number is usually a defined task. Deciding whether a frustrated customer’s case deserves an exception may require judgment, authority, and context. The distinction is not that one is easy and the other difficult. It is that the cost of getting them wrong differs, and the right answer may depend on factors not captured in the record.

Handoffs deserve special attention. When the service representative asks the warehouse to check stock, who owns the case while they wait? When a specialist replies, does the representative see it? If the customer provides a photo in a new email thread, will it be connected to the original inquiry? Many delays blamed on “people” are really gaps between systems, roles, and expectations.

Record the tools used at each step: inbox, order database, inventory system, policy document, customer relationship system, or a colleague’s memory. Then note what can go wrong. Product descriptions may be outdated. Stock counts may lag. A policy may have an exception nobody has written down. A customer may use a model name that resembles another. These are not footnotes. They determine whether delegation is safe and useful.

Match each step to the right kind of help

Only after the work is visible should you decide what kind of technology belongs in it. The choices need not be all-or-nothing.

For this inquiry, an assistant could summarize the email, identify missing details, retrieve relevant policy passages, and draft a response for a representative to review. That may suit steps where interpretation matters but a person should make the decision.

Fixed automation could acknowledge receipt, create a case, assign it to the service queue, or send a reminder after a set number of days. These steps are predictable and governed by clear rules.

A supervised agent might gather the order record, check approved product guidance and current inventory, classify the inquiry, and prepare a proposed next step. It could send a routine request for a serial number if that action is explicitly allowed. But if the records conflict, the customer asks for an exception, or the suggested replacement is expensive or uncertain, it should stop and hand the case to a person.

The same inquiry can therefore contain several kinds of work. The goal is not to appoint one tool to run the whole process. It is to place help where it suits each step and keep consequential decisions with an accountable owner.

A map makes the next question sharper: not “Could an agent handle customer service?” but “Could it safely perform these particular steps, with these sources, permissions, checks, and handoffs?” Start with the work, not the job title. That is a question a business can actually investigate—and answer from evidence rather than enthusiasm.

What changes in the team

If an agent gathers the facts faster, the next constraint may become the person who approves exceptions. Maya might spend less time searching records but more of her day on difficult cases. The company needs to plan for that concentration of judgment: who covers the queue, how quickly they can respond, and how they retain enough contact with routine cases to notice a changing pattern.

A faster first step improves the service only if the rest of the workflow can absorb it. Preparing twice as many quotes does little for customers if installation capacity is already full. The business opportunity is to shorten the whole journey to a useful result. Time released from routine work becomes valuable when the team can use it—for better service, additional capacity, or work that previously went undone.

Once the work is mapped, resist the temptation to begin with the most impressive-looking task. A good first opportunity is not necessarily the one that sounds most like a digital employee. It is the one where a modest delegation can create visible value, while keeping mistakes contained and learnable.

Consider the replacement-parts inquiry at the commercial coffee-equipment company. Asking an agent to handle every incoming message from greeting to resolution would bundle together routine questions, unclear requests, exceptions, and decisions with financial consequences. A narrower first experiment might be to review new inquiries, identify likely order-status or parts questions, find the relevant order record, and draft a response for staff approval. The task is useful, bounded, and easy to inspect before anything reaches a customer.

The questions below are a practical decision aid, not a validated scoring system or a guarantee of safety. Use them to surface trade-offs and decide what to test; they do not replace evidence from a carefully monitored trial.

1. Is the value real and visible?

Start with the business problem, not the novelty of the tool. Does the task consume meaningful staff time? Does delay frustrate customers? Does work pile up at predictable times? Could faster handling free people to solve harder cases?

Estimate the current cost in ordinary terms: minutes per case, number of cases, time spent searching or copying information, and the consequences of delay. A small improvement repeated hundreds of times may matter more than a spectacular demonstration used once a month. Also count the work created by oversight. If every agent-produced draft takes longer to check than it would take to write, the apparent saving is an illusion.

2. Does the task repeat, without being identical every time?

Look for a recognizable pattern with enough variation to make rigid rules cumbersome, but not so much ambiguity that the work depends almost entirely on tacit judgment. Customer inquiries often share a broad shape—understand the request, consult records, respond, update a case—while differing in wording and relevant details.

If the task is almost perfectly repetitive, conventional automation may be simpler. If every case is unique and highly ambiguous, a person or an assistant that prepares information for a person may be a better fit. Look for manageable variation.

3. Is the information good enough?

An agent cannot make a sound decision from records that are missing, outdated, contradictory, or scattered beyond its authorized reach. Ask where the necessary facts live and whether staff can identify the authoritative source. For an order-status reply, that might be the current order record—not an old email, a customer’s recollection, or a spreadsheet that is updated “when someone gets a chance.”

Information quality is not a technical footnote. It is part of the task. If employees routinely reconcile conflicting records by asking colleagues who remember the history, the process may not yet be ready for delegation.

4. What happens if it is wrong?

Mistakes have different weights. A slightly awkward draft is inconvenient; an incorrect refund, a misleading promise, or exposure of private information can be costly. Consider the likely harm, how many people could be affected, and whether an error can be reversed before it matters.

A useful first task has a limited downside. The agent might prepare a response but not send it, or gather facts but not change an account. That lets the business learn about its performance without making customers bear the cost of every early mistake.

5. Can someone check the result easily?

A task is easier to delegate when a person can verify the answer against clear evidence. A draft that cites the customer’s order status can be checked against the order record. A recommendation based on several vague sources may be much harder to judge.

Ask what “done correctly” means. Is there a factual match, a completed field, a response within policy, or a clear record of what changed? If reviewers cannot agree on the standard, neither the agent nor its supervisor has a dependable target.

6. Can the boundary be drawn clearly?

Specify what the agent may do, what it must not do, and when it should stop. “Handle customer inquiries” is a wish, not a boundary. “Find tracking information and draft a reply; do not promise a delivery date that is absent from the record; escalate conflicting records or requests for compensation” is much closer to an inspectable assignment.

These questions expose trade-offs; they do not certify a task as safe. A task may have high value but poor information, or excellent repeatability but serious consequences if mishandled. Begin where the combination is favorable: worthwhile enough to matter, patterned enough to learn, supported by usable information, low-risk enough to contain, and simple enough to check.

Then keep the first trial small. Limit the kinds of cases, the people or records involved, and the actions permitted. Review what it gets right, where it hesitates, and what failure looks like in practice. The point is not to prove that the agent can do everything. It is to discover, under controlled conditions, which slice of the work it can do reliably—and what human judgment still needs to surround it. Capability in a trial is a starting observation, not yet proof that the work creates sustained value.

A small trial shows what an agent did under the conditions tested. Measurement tells you whether handing it that work is actually helping—and whether it continues to help under ordinary working conditions.

That distinction matters because activity is easy to count and easy to mistake for progress. An agent may process a hundred inquiries, draft a hundred replies, or close a hundred tickets. Those numbers say little if customers still need to write back, employees must repair errors, or the fastest responses are the wrong ones.

For the commercial coffee-equipment company’s inquiry workflow, start with the outcome it wants: customers receive accurate, useful answers promptly, and the team spends less effort on routine handling without losing control of consequential cases. Choose a few measures that reveal whether the work is improving from the customer’s and the business’s point of view.

Measure the work, not the motion

Resolution quality is more telling than response volume. Did the reply answer the customer’s actual question? Was it accurate, complete, and consistent with company policy? A message can be polished and still fail to resolve anything. Review a sample of completed cases, including ones the agent marked as successful, and judge the result against clear standards. Where appropriate, look for signs of resolution in the workflow itself: did the customer need to contact the company again about the same issue?

Time saved should mean time genuinely returned to people, not just time shifted elsewhere. If an agent drafts a reply in seconds but an employee spends several minutes checking every sentence, the apparent speed may be an illusion. Compare the total human effort per case—including review, corrections, follow-up, and exception handling—with the effort required before the trial. The relevant question is not “How quickly did the agent respond?” but “How much work did it remove without creating more work downstream?”

Consider a hypothetical trial of 100 inquiries. At eight minutes of staff effort per case, the baseline is 800 minutes. If review and correction take three minutes per case and monitoring takes another 100 minutes, the trial uses 400 minutes of staff time and releases 400 minutes—six hours and forty minutes. These are illustrative numbers, not a forecast. Compare similar cases and check that accuracy and customer outcomes have held up.

That is capacity released, not automatically cash saved. Include software charges, usage fees, setup, integration, and ongoing maintenance when judging value. A team may use the released time well without reducing payroll; a low-volume task may never repay an expensive setup. Ask where the benefit will actually appear in the business.

Rework makes hidden costs visible. Track how often staff correct a reply, reopen a case, undo an action, or ask the customer for information that was already available. A low correction rate is encouraging, but examine the corrections themselves. A misplaced greeting is not the same as a wrong refund promise. Counting errors without weighing their consequences can make a risky system look respectable.

Customer impact belongs beside internal efficiency. Watch for complaints, repeat contacts, delays, or feedback that suggests customers feel passed around or misunderstood. These signals need context—a busy week or a policy change can affect them too—but they help answer the question that matters: did the experience get better, or merely cheaper to produce?

Finally, track escalation frequency: how often the agent hands a case to a person, and why. More escalations are not automatically bad. A cautious agent that flags unusual or sensitive cases may be behaving well. But a high rate on ordinary inquiries may mean its scope is too broad, its information is poor, or its instructions are unclear. Look at the reasons, not just the percentage.

Treat these indicators as evidence to interpret, not as self-explanatory proof. Compare them with a suitable baseline and account for context such as changes in demand, policy, case mix, or staffing. A shift in a measure does not by itself show that the agent caused it, and good results on one set of cases do not establish general reliability. Together, outcome quality, time saved, rework, customer impact, and escalation patterns can inform a decision; none independently proves sustained value or causation.

Let evidence set the boundary

Suppose the agent handles routine questions about opening hours and order status accurately, but repeatedly struggles when a delayed delivery involves a promised refund. The answer is not to celebrate its overall success rate and grant it wider authority. Nor is it necessarily to shut the whole trial down. Keep the low-risk, well-understood cases within its remit; require approval before it promises money or changes an order; route ambiguous complaints to staff.

This is how boundaries should move: one observed capability at a time. Widen permission when the agent has repeatedly handled a clearly defined class of cases to an acceptable standard, and when errors are detectable and recoverable. Tighten it when failures cluster, information proves unreliable, or the cost of a mistake rises. A strong record on routine inquiries does not establish competence in exceptional ones.

Keep a human review in the loop while learning, but make the review useful. Record what was approved, changed, or escalated and why. That gives the team evidence about both the agent and the process: perhaps the model misread a policy, or perhaps the policy itself is vague enough to confuse employees too. The point is to improve the boundary, not merely to collect a pile of approvals.

Set review intervals rather than treating a successful launch as a permanent verdict. New products, policy changes, unusual demand, or shifts in the quality of source information can alter performance. A permission that was sensible last month may need reconsideration today.

Good results are evidence that an agent is reliable within a defined boundary, under conditions you have actually observed—not proof that it is trustworthy in every situation. Keep measuring outcomes, and let the permission follow the evidence, interpreted in context—not the excitement of seeing the work happen automatically.

The most useful question about an agent is not “What can it do?” A system may be capable of sending messages, updating records, or searching documents; that does not mean those are sensible things to hand over. Start instead with the work itself, and ask a handful of questions in order. Together, they make the Delegation Check: a way to define the task, its limits, and the evidence and ownership needed before relying on the result.

What outcome are we trying to achieve? Name the result in terms a colleague or customer would recognize. “Handle inquiries” is too broad. “Give customers a prompt, accurate answer to routine delivery questions, and route unusual cases to the right person” is a workable objective. A clear goal helps reveal when a process is succeeding—and when it is merely producing activity.

Where does judgment enter? Trace the work from beginning to end. Which steps follow a stable rule? Which depend on interpreting incomplete information, weighing competing interests, or understanding a relationship? In the coffee-equipment inquiry workflow, an agent might sort a request, find the relevant order details, draft a reply, and record what it did. A complaint involving a damaged product and a customer facing a deadline may call for a person’s judgment, even if the agent can gather the facts first.

What information and tools does the work require? Give the agent the context required for the task, not a key to the whole business. It may need order status and the current delivery policy, but not unrelated customer records or permission to alter prices. Check whether the sources are authoritative and current, and decide what gaps or conflicts should make the agent pause or ask for help.

What may the agent do, and what must it not do? “Help with replies” leaves too much room for interpretation. Define actions and boundaries: draft without sending; send routine answers drawn from approved information; offer a refund only up to a stated limit; never change an account or promise an exception without approval. The useful question is how far the system may proceed before a human must decide. Give the agent a smaller key: match its access and actions to the objective and the consequences of error.

How will we know the work was done correctly, and who owns the result? Decide what evidence counts before judging performance. Was the answer accurate and timely? Did the agent use the right policy, update the record, and route exceptions properly? Check outcomes, not just speed or volume. Include a way to catch errors and a path for customers or employees to reach a person. Assign someone to review consequential results, handle exceptions, monitor performance, and correct problems. Capability does not confer accountability.

As part of that ownership, identify where a human must remain in control. Identify the decisions with meaningful consequences: unusual promises, sensitive complaints, financial exceptions, or cases where the facts do not fit the rules. Human oversight should be placed where it can change the outcome, not added as a ceremonial click after the important decision has already been made.

These questions form a compact sequence: define the outcome; map the judgment and route; check information and tools; set action boundaries; verify results and retain human ownership. Delegate a bounded objective, not a blank check. Then ask whether an agent is actually needed. A clear, repetitive step may suit fixed automation; a difficult answer may call for an assistant that prepares options for a person. Use an agent when the work benefits from a system that can pursue a bounded goal through several steps and respond to what it finds.

The boundary should be earned and revisited. Evidence can justify more freedom in a narrow, well-understood task—or show that the agent needs tighter limits. The organization remains responsible for setting those limits and managing the work. The practical promise is not that people can stop paying attention. It is that they can spend their attention where it matters most, while routine work moves forward under clear, tested rules.