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

  1. 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.

  2. 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."

  3. 03

    Reassign

    If the backup does not act, the task moves to a role-based fallback or another named person.

  4. 04

    Owner

    The owner becomes the call only after the previous steps have been tried and the work still has not been done.

  5. 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.

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.

Escalation questions answered

What is the difference between an alert and an escalation?
An alert tells you something happened. An escalation moves the work to a different person who can act on it. Most software sends alerts. Few send escalations. The difference is the difference between a notification feed and a system that closes the loop.
What is an exception in fullyOS?
An exception is an unresolved operational reality the system surfaces because the work could not be resolved on its own. Exceptions stay open until a human resolves them with a useful note, or the underlying work completes through another path.
Does the owner get notified for every missed task?
No. The owner is the last resort, not the first response. The system tries every other path first: backup owner, role-based fallback, escalation target. The owner becomes the call only after every other path has been tried.
What does "without anyone asking" mean?
It means the escalation fires from the system, not from a person noticing and pinging. When a task is not done at the right time, the system moves it to the next person automatically. Nobody has to email, text, or message to start the next step.
How does a useful resolution note work?
When a person resolves an exception, they leave a short note on what happened. The system rejects empty notes, single-word notes, and the obvious fillers (done, fixed, ok, n/a, handled). The note is not optional, because the next person who runs into the same problem reads it.
What if the same exception keeps happening?
When the same exception type recurs on the same process repeatedly, the system flags it as a pattern. The summary reads: this process keeps breaking, X of the last Y fixes did not hold. The pattern lands on the SYSTEM surface, not as a flood of individual exceptions.

fullyOS makes sure work actually gets done, not just assigned.