Escalation and exceptions
What happens when work gets missed
Most tools send a reminder when a task is missed. Reminders are not escalation. A reminder is a notification asking someone to do the thing they were supposed to do. An escalation moves the work to a different person who can act on it now. The difference is what closes the loop instead of leaving it open.
Quick answer
What happens when work is missed?
When work is missed, an escalation chain moves the task to the next person who can act on it: original owner, named backup, role-based fallback, then the owner only as the last resort. A reminder is a notification asking the same person again. An escalation moves the work; the difference is what closes the loop instead of leaving it open.
Each step fires from the system, not from a person noticing. See missed work falls to the owner for what happens when the chain has no defined steps, or take the scan.
Why missed work has nowhere to go in most setups
Missed work has nowhere to go because the default chain is one step long. A notification fires, asking the same person to do the thing they already missed. If they respond, the task continues. If they do not, the task becomes the owner's problem.
That is not a chain. That is a notification followed by silence followed by the owner picking it up by hand. Every missed task eventually reaches the owner because the chain has no other steps. This is the same pattern that drives owner dependency across the rest of the business.
A real escalation chain has named steps, a system actor that moves the work, and the owner only as the last resort.
How a real escalation chain works
- 01
Reminder
The system surfaces the task to the original owner just before it is due. This is the only step that looks like a notification.
- 02
Fallback
If the original owner does not act, the task moves to a defined backup. The backup is a named person, not "the team."
- 03
Reassign
If the backup does not act, the task moves to a role-based fallback or another named person.
- 04
Owner
The owner becomes the call only after the previous steps have been tried and the work still has not been done.
- 05
Chain exhausted
When even the owner cannot act, the task is logged as chain-exhausted. This is rare and gets surfaced as a structural finding, not as another notification.
Each step fires from the system, not from a person noticing. Nobody has to ask. (The chain itself is rules-based and deterministic; the same situation produces the same chain every time.) For the broader picture of what drives missed work in the first place, see why recurring work fails.
What an exception is, and why it stays open
An exception is an unresolved operational reality. It is not a notification. It is a record of something the system could not finish on its own, with an owner attached and a path to resolution.
Exceptions do not disappear. They stay open until a person resolves them with a useful note, or the underlying work completes through another path. Empty notes, “done,” “fixed,” and “handled” are rejected by the system because they break the loop the next time the same problem comes up. See the exception trail for what a useful resolution note actually carries.
For the broader pattern of how missed work connects to owner involvement, see owner dependency.
Three places escalation breaks
Pick the one most familiar.
- 01
Missed work falls to the owner
When the chain has no defined steps, every miss eventually reaches the owner.
- 02
No backup for the backup
When the only backup is one specific person, the second miss has nowhere to go.
- 03
The exception trail
Why a record of how missed work was resolved is what closes the loop, not just a record that it happened.
Try one of your own processes
Pick a recurring task where missed runs land on you. fullyOS turns it into an owner, steps, a cadence, a backup chain, and what proof of completion looks like.