Work Output: Alerts
Objective. Read alerts as threshold-driven signals to investigate, and triage them by scope and context - the count of alerts is not the count of real problems.
Alerts answers 'what changed enough to deserve a look?' It watches output, quality, backlog and cost against thresholds and surfaces the exceptions, so attention goes to movement rather than to reading every screen daily.
See it in the demo
What this screen answers
A CSM uses alerts to run a daily or weekly triage without opening every screen; Sales uses it to show the platform points managers at the right exception. The customer question is 'where should a manager look today?' An alert is a prompt to investigate, bought cheaply, not a confirmed incident.
The task
Scan the alerts in your scope, read each with its context - what fired, over what period, against what threshold - and triage: which are real signals worth drilling and which are noise from a threshold set too tight. Carry a real one to the matching screen (root cause, quality, backlog, cost). For a CSM, tune thresholds with the customer so alert volume stays meaningful, and fold the triage into an agreed manager routine.
How to read it
An alert is a threshold crossing, not a confirmed problem - the classic misread is treating the alert count as a problem count or acting on an alert before checking its context. Thresholds that are too tight flood the screen and train people to ignore it; too loose and real movement is missed. A single alert may also reflect a legitimate mix change rather than a fault. Read each alert as 'go look here', then let the underlying screen decide whether there is anything to act on.
Honest limits
This screen does not prove a problem exists or its cause; it only flags a threshold crossing on seeded data. Alert quality depends entirely on how thresholds are set, which must be agreed with the customer. Confirm with product how alerts are generated and tuned, and never report an alert as an incident until the drill-down confirms it.
Interpretation check
An alert is a threshold-crossing signal to investigate, not a confirmed problem; the number of alerts is not the number of problems, and context plus a drill-down - not the alert itself - decides whether to act.
Practical task
Triage the alerts in one scope, pick one real signal and one likely-noise alert, and write a one-line finding for each explaining why - and which screen you would open to confirm the real one.
Self-check
There are 40 alerts this week. Are there 40 problems?
No - alerts are threshold crossings, not confirmed problems, and a tight threshold floods the list. Each one is 'go look', and the drill-down decides if there is anything real.
An alert fired on a team's output drop. Do you raise it with the manager?
Only after checking context - it could be a legitimate mix change. Confirm with the underlying screen before treating an alert as an incident.
Why tune thresholds with the customer?
Too tight and the screen is ignored as noise; too loose and real movement is missed. Meaningful alert volume is what keeps the routine useful.
Verified vs demo. Screen is live in the demo at https://work-output.demo.timechamp.io/#/alerts; exact controls, labels and on-screen figures are SME-validation-pending.