Where real-time most often goes wrong
Motion isn’t progress
Real-time management is the function most prone to confusing motion with progress. The analyst who’s busy — pulling agents, authorising overtime, re-routing contacts, sending alerts — looks effective and often isn’t. The analyst who’s quiet, watching the right signals, declining most interventions, and acting decisively on the few that matter, looks less effective and often is. Most bad days don’t happen because the real-time team lacked information. They happen because the team acted on the wrong information.
This series walks through the six failure modes that recur across real-time functions. Each is the subject of one of the next five pieces; this opening article names them so the diagnostic landscape is visible from the start.
The six failure modes
1. Reacting to noise. The most common failure. A 30-minute spike triggers an action that lands twenty minutes later, by which time the spike has reverted to mean and the action persists. The cumulative cost of these over-corrections across a year is large and almost invisible. See reacting to noise.
2. The dashboard-only view. The analyst who never leaves the screen misses everything the dashboard can’t show — the system fault being whispered about, the TL pulled into an escalation, the queue building on a skill that isn’t on the primary screen. See the dashboard you can’t see the floor through.
3. No lever menu. Decisions made under pressure without a pre-written playbook get worse over time, look inconsistent across analysts, and quietly drift toward expensive defaults. See the lever menu nobody wrote down.
4. Poor communication. Real-time sees the operation in detail nobody else does, and most of that detail never reaches anyone outside the team. The information advantage is wasted. See communicating real-time to the rest of the operation.
5. No post-event review. The cheapest improvement discipline in operations and the most consistently neglected. Without it, the same lessons go unlearned week after week. See the post-event review that nobody runs.
6. Reactive, not anticipatory. The operation that finds out about the marketing campaign on the day it launches, the system release in the middle of it, the regulatory deadline as the calls start. All preventable; almost never prevented. The relationship layer that fixes this is covered in the BI-layer piece of the where-forecasts-go-wrong series and applies equally to real-time.
Why this order matters
Operations that try to improve real-time by adding more dashboards or hiring more analysts usually find the improvements don’t materialise. The bottleneck is rarely information volume or headcount; it’s in the disciplines around how the existing information is used. Operations that adopt the noise/signal discipline, the floor-walk rhythm, the lever menu, the standing comms, the post-event review, and the upstream relationships find their real-time function becomes measurably more effective within a quarter, without adding any tools or people.
The series ahead
The next five pieces each take one failure mode and walk through what it looks like in practice, why it’s persistent, and what the operations that catch it early do differently. The series complements rather than replaces the existing real-time articles (top tips, the case for doing nothing, playbooks) by treating the failures explicitly rather than the successes.
Next in the series: Reacting to noise — the real-time over-correction trap.
Pair this with top tips for real-time, sometimes the best thing to do is nothing, and real-time reporting in 2026.