Intraday Management: Control tower
Objective. Open the control tower and read today's live position - what has drifted, how urgent it is, and where to look next - without treating the single headline status as the whole story.
The control tower is the duty manager's one-screen 'how is today going right now' view. It answers whether the plan built earlier still holds and flags where the day has started to pull away from it.
See it in the demo
What this screen answers
'Is today's plan still on track right now, and if not, where?' A duty manager opens the control tower first thing and keeps it up through the day. It is the starting point of the detect - decide - act - review loop: the tower is the detect step, surfacing drift early so the manager can move to the deeper screens (forecast vs actual, staffing, backlog) before a small gap compounds.
The task
Set the scope to the operation and day you are managing - the team or skill group and the current date - so the live position reflects the right queues. Scan the summary for intervals or skill groups already running off plan, note which are getting worse rather than just currently behind, and use the tower as the jump-off point into the detail screens. The job here is triage: decide what deserves a closer look, not to fix anything yet.
How to read it
The tower is a same-day control view, not a verdict. A green or 'on plan' summary at a point in time means the day is tracking so far; it does not guarantee the end-of-day service result, because arrivals and absence can still move. Equally, a red flag is a prompt to investigate, not proof that intervention is needed - confirm the drift is real and sustained on forecast vs actual before acting. The headline status compresses many intervals into one signal; always open the interval-level detail before drawing a conclusion.
Honest limits
The tower only reflects the data feeding it. If the arrival/actuals feed or the staffing picture is stale, the live position is wrong in a way the screen cannot show you - confirm feed freshness with product and the customer's own setup. The tower detects and points; it does not reforecast, simulate or execute. And exact tile labels, colour thresholds and refresh cadence shown in the demo are SME-validation-pending.
Interpretation check
'On plan' on the tower at noon is a same-day tracking signal, not a guarantee of the end-of-day service number - and a red flag is a prompt to investigate, not an instruction to act.
In the field
OVO (contact centre): a duty manager keeps the tower up through the morning peak so an arrival spike on one queue is seen as it starts, not discovered at end of day.
Practical task
Open the control tower, set the scope to one team and today, and write a three-line triage note: which one interval or skill group you would investigate first, why (currently behind vs getting worse), and which detail screen you would open next.
Self-check
The tower shows the whole day green at 11am. Can you tell the customer today's SLA is safe?
No. It means the day is tracking to plan so far. Arrivals, absence and backlog can still move the end-of-day result. It is a live tracking signal, not an outcome guarantee.
A skill group flashes red on the tower. What is the correct next move?
Treat it as a prompt to investigate, not a verdict. Open forecast vs actual and staffing to confirm the drift is real and sustained before deciding on any action.
What makes the tower's live position untrustworthy regardless of what it shows?
A stale actuals or staffing feed. If the inputs are not fresh the position is wrong in a way the screen cannot reveal. Confirm feed freshness before relying on it.
Where does the tower sit in the intraday decision loop?
It is the detect step - it surfaces drift and triages where to look. Deciding and acting happen on the deeper screens and the what-if; the tower itself does not fix anything.
Verified vs demo. Screen is live in the demo at /#/tower; exact tile labels, status thresholds, refresh cadence and figures are SME-validation-pending.