Check the impact behind an urgent label
Original fictional triage policy: Priority A means the next opening cannot proceed and no approved fallback works; B means one task is blocked but an approved fallback covers its deadline; C means the task has recovered and impact still needs confirmation. All three cases are included incidents, not scope-classification questions. Operations lead Mei assigns priority; no response-time commitment is defined.
| Incident | Affected task/deadline | Approved fallback evidence | Priority/decision owner |
|---|---|---|---|
| I-1: booking desk unavailable | All two desks blocked before 09:00 opening | Paper fallback unavailable; no approved replacement | A; Mei |
| I-2: one admin export unavailable | Jo needs daily total by 17:00 | Approved read-only report supplies same total by 16:00 | B; Mei |
| I-3: search recovered | Two staff can now finish search; earlier missed work unknown | Current task succeeds; confirm backlog before closure | C; Mei confirms remaining impact |
A fallback changes the impact assessment
I-2 is labelled urgent, but the agreed read-only report supplies the required daily total at 16:00 before its 17:00 deadline. Under this fixture, is it Priority A?
Show the worked answer
No. It meets B: the export task is blocked but an approved fallback covers the stated deadline. Mei records B and reviews again if the fallback fails, its definition differs or the deadline changes.
These invented A/B/C rules are not an industry severity standard or response promise. Prioritisation does not classify maintenance scope, approve access or declare recovery complete.