Intraday Management: Alerts and events
Objective. Read the day's alerts and events as early-warning prompts to investigate, and distinguish an alert firing from a problem confirmed.
Alerts and events surface drift, thresholds crossed and notable occurrences as they happen, so a duty manager is pulled to the right screen early rather than discovering a problem at end of day.
See it in the demo
What this screen answers
'What should I look at right now, before it becomes a bigger problem?' This screen compresses the day's notable signals - a threshold crossed, a queue spiking, an absence event - into a running list, so the manager's attention is directed to emerging issues rather than relying on them to notice a trend by eye.
The task
Scope to the operation and today, scan the active alerts, and triage: which are rising or service-critical versus which are informational or already recovering. Treat each alert as a pointer into the detail screens - forecast vs actual, staffing or backlog - where you confirm whether the signal reflects a real, sustained problem. The task is prioritised investigation, not reacting to every alert.
How to read it
An alert is a prompt, not a verdict. It fires when a rule's condition is met, which is not the same as a confirmed problem that needs action - a brief spike can trip a threshold and recover on its own. The classic misread is acting on the alert alone; always confirm the underlying drift on the detail screen first. Alert behaviour also depends entirely on how thresholds and rules are configured, so the same day looks noisier or quieter depending on setup.
Honest limits
This screen notifies; it does not diagnose or fix. Which alerts exist, their thresholds and whether they are entitled for a given customer are configuration and packaging dependent - confirm alerting specifics with product. Exact alert types, severity labels and the demo figures are SME-validation-pending.
Interpretation check
An alert firing means a rule condition was met, not that a problem is confirmed - always verify the drift on the detail screen before acting, and remember alert noise depends on how thresholds are configured.
In the field
OVO (contact centre): an arrival-spike alert mid-morning is the cue to open forecast vs actual before the queue compounds - but the alert itself is the prompt, not the decision.
Practical task
On the demo, pick the highest-priority active alert, open the matching detail screen to confirm whether it reflects a sustained problem, and write one line stating whether you would act, watch or dismiss and why.
Self-check
An alert fires that a queue has crossed its threshold. Should the manager act on it immediately?
Not on the alert alone. It is a prompt to investigate. Confirm on forecast vs actual or backlog whether the drift is real and sustained before deciding on an action.
Two operations see very different alert volumes on a similar day. What most likely explains it?
Threshold and rule configuration. Alerts fire on configured conditions, so setup determines how noisy the screen is - not necessarily how differently the two days actually went.
Why is an alert that recovers before you look at it not a failure of the system?
Alerts flag conditions early, including brief spikes that self-correct. Firing then recovering is expected behaviour - it is a prompt, and the correct response was to check, not to assume a lasting problem.
A prospect asks if alerting comes standard. How do you answer?
Confirm with product - alerting specifics and entitlement are packaging-dependent. The demo shows the model end to end on seeded data, which is not a statement of what a given customer's plan includes.
Verified vs demo. Screen is live in the demo at /#/alerts; exact alert types, thresholds, severity labels, entitlement and figures are SME-validation-pending.