The command centre: running a crisis day when routine real-time isn’t enough

Real-time management · Leadership · ~7 minute read

Most days the real-time desk runs the operation with routine levers. A few days break that routine entirely, and the right response is not to try harder with the same tools but to change the structure: declare an incident, name the roles, and run the day from one picture on a fixed rhythm.

When a bad day becomes an incident

Most days the real-time desk runs the operation with its routine levers: move a break, flex a skill, ask for an hour of overtime. A few days break the routine entirely — a CRM outage across every queue, a site evacuation, a viral event flooding the lines, a storm that takes a third of the workforce off the schedule. On those days the desk’s normal tempo is not enough, and the operation needs something the desk cannot provide alone: a command centre, sometimes called a war room.

The trigger is not drama; it is four plain conditions. The problem affects the whole operation rather than one queue. It will run for hours rather than minutes. It needs decisions or resource beyond what the desk is allowed to commit. And it needs several parties working together — IT, operational leadership, communications, sites. When all four are true, the wrong response is to keep firefighting with routine tools; the right one is to declare an incident out loud and convene the room.

Declare early. Standing a war room down because the problem turned out to be small costs twenty minutes of several people’s time. Convening it three hours in, after a long period of uncoordinated scrambling, costs far more. This is a judgement call and it improves with practice: do not cry wolf on every bad Monday, but do not hesitate when the conditions are genuinely met. Write the four conditions into the escalation design so the desk has the authority to declare without waiting for permission.

Roles: who sits in the room

A war room without roles is a crowded room of anxious people. The minimum cast is an incident lead, who owns the response and every decision; the real-time desk, who owns the live operational picture and the levers; a representative of each party who owns a lever — IT for systems, operations for people and priorities, communications for what customers are told; and a scribe, who logs decisions, actions and timings as they happen. The scribe feels like a luxury until the review, when the log is the only reliable account of what was decided, by whom, and when.

Note who is not the incident lead: usually not the planner. The desk is the operational engine, not the commander. Its value is in being the one person in the room who always knows what the queues are doing, and who can say, calmly, what each proposed action is likely to do to them.

One picture, one rhythm

Two disciplines turn a gathering into a response. The first is a single source of truth: one shared dashboard and one running log that everyone works from. A crisis where five people act on five different versions of the facts is not coordinated, however many of them are in the room. The second is a rhythm: short situation reviews on a fixed beat, fifteen minutes is typical, each answering the same four questions — what is happening, what have we done, what is next, who owns it. Between reviews people work; they do not chatter. The rhythm is what lets everyone get on with their own job instead of constantly asking for updates.

What the desk does inside the room

The desk’s mindset does not change — plan-relative, trajectory-focused, proportionate, as in knowing when to do nothing — but the stakes and the audience do. It provides the live picture: service, volume, availability and backlog across the whole operation. It projects: where is the backlog heading in an hour if nothing changes, and when does a recovery surge arrive? It reforecasts under crisis conditions, which means saying plainly how wide the range is rather than offering false precision. It executes the levers the incident lead chooses — offline holds, all-hands to phones, a message of the day — and it reports back what each action actually did. That feedback loop is the desk’s most important contribution: it stops the room confusing activity with effect.

Take a CRM that goes fully down at 9:40, tripling handle times on every queue and site. The desk does not try to solve it with break flexes. It declares the incident, the room convenes within ten minutes with an operations director as lead, IT on the system, communications drafting customer messaging and a scribe logging. Fifteen-minute reviews run off one dashboard. The desk shows the backlog building, projects the recovery tail for when the system returns, and executes what the lead directs. The outage playbook supplies the degraded modes and the pre-written messages; the command centre supplies the coordination that makes them work together.

Afterwards

Crisis days are rare and defining, which makes the review afterwards more valuable, not less. The desk usually leads it: what happened, when did we notice, when did we declare, how did the response go, and what do we change? The output is changes with owners and dates — to the plan, to the playbook, to the escalation matrix — and the demand displaced by the incident fed back into the forecast so the recovery tail is expected next time. The post-event review format works at this scale too; it just needs a longer slot and the scribe’s log on the table.

The closing principle

You cannot choose your crisis days, only how structured you are when they arrive. Four conditions to declare, a handful of named roles, one picture, one rhythm, and a review that actually changes something. That is the difference between a day that is managed and a day that is merely survived.