The agent escalated the case. Can anyone decide from what it sent?

Imagine a distributor receiving a request to split a delivery. The customer wants the available items tomorrow and the remainder next week.

The order screen shows stock on hand, but the allocation view shows some of it reserved for another customer. The account is on credit hold. The salesperson has the customer’s requested dates in an email; dispatch has not confirmed whether the first shipment can make the carrier’s collection.

The assistant sends the operations manager a notification: “Exception detected. Please review.”

The manager now has a second job. Before deciding anything, they must discover what the first job was.

An escalation can be technically successful and operationally useless. The message arrived. The right person may even have received it. Neither fact establishes that they have enough information to act.

Two messages about the same order

Here is the weak version of the handoff:

Customer requests split delivery. There may be a stock or credit issue. Human approval required.

It names a problem without preparing a decision. “May be” covers several possible states. Nothing identifies the proposed change, the source of the uncertainty or the decision the manager is authorised to make.

A more useful handoff might read:

Decision requested:May order 4821 be split into two deliveries?

Customer request:Receive the available items tomorrow and the remainder next week. Original request attached.

Stock to use:The linked allocation view separates unreserved order lines from stock committed elsewhere. Dispatch must confirm the proposed first shipment against that view before release; stock on hand alone is not availability.

What is unresolved:Finance has not cleared the account for release. The second transport charge has not been accepted by the customer.

What has happened:A draft delivery plan exists. No release instruction has been sent.

Next decisions:Finance must decide whether to release the credit hold. The commercial owner must confirm who pays for the second shipment. Dispatch must check the carrier’s collection cut-off and transit time before anyone promises tomorrow’s delivery. Until those answers are recorded, both dates remain requested dates.

This is an illustrative format, not a universal template. Some cases need less. A regulated or safety-critical decision may need considerably more. The point is to stop asking one person to infer several decisions from a vague alert.

Keep the question small enough to answer

“Approve this exception” often bundles together decisions that belong to different people.

Someone may be able to approve a different delivery date but not extend credit. A warehouse manager may allocate stock but not waive a customer charge. Asking either person for one broad yes creates confusion about what their answer means.

Write the decision as an action within that person's authority. If the decision depends on another team's answer, show the dependency. Do not make the recipient discover it by trying to approve the case.

There will be situations where the information cannot yet support a decision. The useful next action is then a request for a specific missing fact, assigned to someone who can obtain it. “Need more context” is not enough. “Confirm whether the reserved stock can be released from the other order” gives the next person something to do.

Make uncertainty visible without making the reader hunt

A fluent summary can conceal how little has been established.

For each consequential fact, distinguish a confirmed record from a customer request, an inference or an unresolved conflict. Attach the relevant source and its timestamp. A stock figure copied before the afternoon picking run should not look identical to a fresh warehouse confirmation.

Keep the source close to the claim. If the manager has to search an entire conversation to find the message behind one sentence, the handoff has transferred reading work rather than reducing it.

Avoid forcing the whole company into a new ticketing system merely to produce this card. The useful destination may be an existing case screen or approval queue. What matters is that the evidence and the decision remain connected, with access appropriate to the recipient.

Say what the agent has already done

A recipient needs to know whether they are reviewing a proposal or recovering from an action.

“Delivery update prepared” could mean a draft on screen, a saved change in the order system or a message already sent to the customer. Use words that match the actual state. If an attempted action has an uncertain result, say that explicitly and identify who will reconcile it.

This also prevents accidental repetition. The manager should not have to guess whether pressing a button will perform the first release or repeat one that may already have happened.

The handoff should preserve the work already done by the customer as well. Do not ask them to repeat their address, order number and explanation simply because the case moved from a bot to a person.

Test the handoff with the intended recipient

Before buying a polished exception dashboard, take one representative case to the person expected to handle it. Use a simulation or sanitised records, not a real order that could be released accidentally.

Ask them to work through the card. Which source do they open first? What question is still missing? Does the decision actually belong to them? Where would they record an answer?

Watch for information they have to reconstruct outside the card. Some of it will be unnecessary detail. Some will be the very fact that makes the decision possible. Revise the handoff around that distinction rather than adding every available document.

Then check the return path. A decision recorded in a comment must reach the system that continues the work. If someone declines, asks a question or leaves the company, the case needs an explicit next state. A notification with no owner after delivery is only a new inbox.

Bring the exception that keeps coming back

Start with a recurring case that passes between teams. Bring the request, the relevant records and the person who normally resolves it. Remove sensitive details where necessary.

A useful Strategy Session can begin with that handoff: what someone needs to decide, what the assistant can assemble and where authority must remain explicit.

For the broader work of defining operating rules, see Your company runs on rules nobody ever wrote down.