Escalation must say which step is stuck and what is needed; a failure report alone cannot be handled

What it is

An escalation that only says “task failed” hands a person a state name, not material they can act on. Escalation states step and need: which beat of the plan it is stuck on, whether the gap is permission, object, judgement or an external system, and what the person should do first after taking it.

“Failed, please handle” hands archaeology to the taker. Handoff wants cause; escalation is that cause in a failure scene.

Why it happens

Handling a failure is a miniature takeover. Takeover wants state and “do not do this again.” If the failure report is only an error code, the person rummages the process view, guesses the gap, and retries a call that already failed. Time is spent rebuilding, not on the gap. Written as an actionable item (“need customer B’s address field,” “need write permission,” “need a person to decide whether to send outward”), rebuild collapses to a check.

A failure-only report also encourages “run it again” as the response, because the material does not support another act. Retrying without escalating is an agent-side problem; a person forced to retry by an empty report is the mirror of the same gap.

Studying it

Hold the same failure, compare: failed only, an error code, step plus gap plus a suggested first act. Dependent variables: time from escalation to a correct handling, whether the failed call is repeated, whether a probe can recast the gap. Independent variables: gap type (permission / missing / judgement), whether the process view is open at the same time.

Correct handling means filling the gap, not marking the task read. Repeating an already-failed call counts as the ask being unhandleable.

Where it stops holding

If the step record itself was thrown away, even a well-written ask cannot point at the beat — process has to leave a trace. Cleanup items for a partial are a different packet; do not mix them into one sentence with “what is needed to continue.” Escalate late and history lengthens; the material has to compress into the gap, not pad with the long history.

Applying it

• Fix three columns on the escalation template: which step, what is missing, suggested first human act. Missing a column, the task must not enter a person’s queue.
• The suggested first act must be something a person can do (grant, fill a field, veto), not “please check the system.”
• Check: send the escalation to someone who did not watch the process. If the first act is re-run or rummage the log, the material is still unhandleable. With three columns present, the first act should be filling that gap.

Related

• Same group: L4.13.1 When an agent cannot finish, it should escalate rather than cover with an approximation · L4.13.3 Retrying without escalating consumes resources and delays human intervention · L4.13.4 A partially completed task must say how far it got and whether cleanup is needed · L4.13.5 The later the escalation, the longer the execution history a person must reconstruct
• Nearby: L4.04 Takeover and Handoff Design · L4.08 Visibility of Task Progress · L4.14 Plan Visibility and Revision for Multi-step Tasks
• Search terms: actionable escalation · handoff · failure reporting