Threshold Alerts and Escalation (generic process)

Threshold Alerts and Escalation (generic process) is the generic process card, GP-304, for the process by which the real-time function of a workforce operation turns a metric crossing a boundary into an acknowledged alert, routes it to the seat with authority to respond, escalates it when the response does not recover the metric, and steps it down when recovery has held. The method, the alert classes, the configuration principles and the three-branch decision tree, is documented on Real Time Threshold Alerts and Escalation Protocols and is not restated here; this card carries what a function needs in addition in order to catalog, localize, certify and automate the process: its L0 profile, the mapping of the method's branches onto the tiers of Decision Authority Tiers in Workforce Operations, its variant classes, the L3 job aids a localizing team must write, and the sub-steps flagged as automation candidates. It is part of Process Standardization and sits under the real-time section of the function catalog in Anatomy of a ROC Standard.

An alert is the front door of the real-time day: the trigger of GP-302, the entry criterion of Incident Management for Contact Centers when sustained and wide, and a signal the rotation of GP-301 reads between alerts. The oldest finding in the alarm literature governs its design: an alarm set is only as useful as the attention it directs, and an operation that fires more alarms than its analysts can act on has trained them to ignore the set.

Process profile

Field	Generic value
Card	GP-304 · local card id assigned by the standards committee at deployment
Class	real-time
Trigger	a monitored metric crossing its boundary and staying there for the confirmation window (a sustained breach, never an instantaneous one); a recovery crossing triggers the step-down check
Cadence	continuous; the alert catalogue is reviewed for false positives on a cadence the function sets (SET LOCALLY)
Scope in	generation, acknowledgement, routing to the tier, escalation up the tiers, the step-down, the alert log, the catalogue review
Scope out	the lever (GP-302); the incident once declared (Incident Management for Contact Centers); the severity matrix; the staffing-state codes, which classify what the operation has become rather than what crossed a line
Inputs	the metric feeds; thresholds per class and interval group (SET LOCALLY); the confirmation window; the recipient map per class and tier; the staffing position; exogenous signals (Operational Volatility Index (OVIX))
Outputs	the alert record (class, metric, value, time, recipient, acknowledgement, response, outcome); the escalation record; the step-down record; the false-positive register; catalogue change requests
Upstream	the monitoring surface; the intraday reforecast (GP-104) for predicted alerts; the metric rows of The Definitions Register
Downstream	GP-302 (the confirmed variance); incident management (the declaration); GP-303 (the adherence class); Variance Harvesting (the log); GP-602; post-mortem
Resources	an alerting layer; one notification channel per tier; an alert log. Platforms are named at L3, never here
Decision points	is the breach sustained? which tier does the class map to? has the autonomous response recovered the metric inside the step-up window? is this an incident? has recovery held for the step-down window?
Authority tier	by class, per the mapping below; the catalogue and its thresholds change only through GP-601 at tier 4
Risk and compliance flags	alert fatigue; thresholds not calibrated by interval group; a class with no documented owner; the alert log is audit evidence, comparable to the incident record that service-management standards require to be kept; notification wording sent to a partner supply node crosses a contract boundary
Variant-prone steps	the thresholds; the recipient map at partner supply nodes; the overnight tier map; predecessor alert sets
Automation candidates	five sub-steps of the method page's response sequence, every one ranked below

L1 and L2

The L1 flow is the response sequence on Real Time Threshold Alerts and Escalation Protocols: the alert fires on a sustained breach, the recipient acknowledges inside the class's window, the decision tree sends it down one of three branches (autonomous response, supervised response, incident declaration), escalation follows when the response has not recovered the metric or the class is above the recipient's authority by definition, and every acknowledgement, action and escalation is logged. That page also carries the alert classes and configuration principles a deploying function copies into its L2 through Wiki:Packs/Process Decomposition, filling the owning seat, acknowledgement window, notification text and join key per row. Two things the method page states in its own vocabulary are fixed here in the catalog's. First, the branches map onto the authority tiers as follows.

Branch on the method page	Tier	Generic examples	What the tier must produce
Autonomous response	tier 1, the real-time analyst inside guardrails	a warning-level service or queue alert; a team adherence alert; a low-occupancy alert answered by a time-off offer inside the budget	the lever chosen and the checkpoint set (GP-302)
Supervised response	tier 2, the supervisor or team lead	an alert whose answer is overtime, off-phone deferral beyond the budget, or a non-standard schedule change	a decision per lever, recorded
Incident declaration	tier 3, the operations manager or ROC duty lead	a sustained breach across queues, skills or supply nodes; a platform or facility cause; the ladder exhausted	the severity row and the incident record
Catalogue change	tier 4, the function head, through change control	a new class, a threshold change, a recipient change	the signed change record
Continuity trigger	executive sponsor, by exception	the row of the severity matrix that hands to business continuity	the activation decision

Second, the step-down is an L2 row of its own, owned by the real-time analyst, not a footnote to recovery. A metric that has recovered because a lever is still in place has not recovered, and the step-down check asks three questions in order: has the metric held inside its boundary for the step-down window (SET LOCALLY); is the cause understood or the matched event closed; have the levers deployed against it been returned or written back? Only then does the state step down. The analyst runs the check and writes the row; where the state had been escalated, the row carries the escalating tier's confirmation before it closes.

Variants

Recorded per Standard and Variant in Process Documentation:

• Statutory. Alert classes that name individual agents (the adherence class) inherit the statutory variants of GP-303 and carry the agent identifier only where that card's row permits: a parameter at most supply nodes, a variant row where the recipient changes.
• Contractual. A partner contract naming the seat the center may notify and the wording it may use parameterizes the recipient map and the verbiage (SET LOCALLY). One under which the partner runs its own alerting and reports breaches through an interface replaces generation with receipt for that supply node and takes a variant row, reviewed at renewal.
• Structural. An overnight watch with no tier-2 seat on duty maps the supervised branch to the duty lead directly: a standing variant row, reviewed when the watch structure changes. A channel without a queue alerts on backlog age rather than waiting count; its class list differs and takes a row.
• Transitional. A predecessor organization's alert set is mapped class by class onto the catalogue under a row with an expiry at cut-over, so that a breach counted on the old set counts on the new one, the rule the severity matrix page applies to merged matrices.

L3 register

Job aid	Anchored to	Form
The alert catalogue: class, metric, threshold (SET LOCALLY), confirmation window, interval group, owner	generation	work instruction
The notification verbiage per class and per tier, with the partner-supply-node version	routing	work instruction
The acknowledgement and step-up windows per tier	routing, escalation	work instruction
The escalation path per branch	escalation	runbook
The step-down check: the three questions and the window	step-down	runbook
The false-positive review and the catalogue change request	catalogue review	playbook
The overnight recipient map	routing	work instruction
The manual rotation when the alerting layer is down	generation	runbook; the watch is GP-301's

Automation candidates

Flagged at L2 per Process Decomposition (L0–L3); released per class of action on a published catch rate per Human Gates and Number Grades, never on a maturity label. The classes are those of Expanding Intraday Automation: trigger, notify, offer, action. The list is ordered by how easy that catch rate is to publish. Alert generation is the oldest automated step in real-time operations; the human-factors warning about it is not that it fires but that its output is trusted or ignored without a measured basis for either.

1. Alert generation on a sustained, correlated breach: trigger class; first, since a seeded breach is either raised or missed and the false-positive register is the catch rate's denominator.
2. Notification and routing to the tier recipient with the class's verbiage: notify class; ranks after 1 because a seeded error in the recipient map can only be observed once an alert has been generated to route, so its test depends on the first.
3. The predicted service-level alert from the reforecast: trigger class; ranks after 2 because a prediction can be wrong in two directions, so the seeded set must hold misses and false alarms in known proportion.
4. The escalation case draft (what, by how much, for how long, what was tried): offer class; the detector of Real-Time Agents writes it with the evidence attached and the analyst sends it; ranks after 3 because its verifier is the analyst at the action gate, so the catch rate needs an outcome record rather than a seeded input.
5. The step-down proposal: offer class; ranks last because its known failure, stepping down a state that recovered only because a lever is still holding it, can be seeded only by running a lever and withholding its write-back, the most expensive test on this list. The step-down decision itself is not a candidate until that catch rate is published.

Two steps are never candidates. Incident declaration is a tier-3 decision and the severity matrix's trigger. A change to the catalogue is change control, a versioned and reviewed act.

Maturity Model Position

Four scales on this wiki use the word level; the launch page states which is which. On the WFM Labs Maturity Model™ a function with a published catalogue, documented owners per class and a logged escalation path is at Level 2; one that has released candidates 1 and 2 on a published catch rate and reviews its false positives on a cadence is at Level 3; one whose alerts are predicted rather than observed and whose escalation cases arrive with the evidence attached is at Level 4.

See Also

• Process Standardization — the hub and the inventory this card belongs to
• Real Time Threshold Alerts and Escalation Protocols — the method: alert classes, configuration principles and the decision tree
• Decision Authority Tiers in Workforce Operations — the tiers the branches map onto
• Contact-Center Incident Severity Matrix — what takes over at the declaration branch
• Incident Management for Contact Centers — the incident process and the staffing-state codes
• Intraday Management — the cycle an alert triggers
• Real Time Staffing Visualization and Wallboards — the surface the alerts sit on
• Standard and Variant in Process Documentation — how the variants above are recorded
• Runbooks, Playbooks and Work Instructions — the three L3 forms in the register
• Wiki:Packs/Process Decomposition — the pack that localizes this card (CP-OPS-001)