Something is down. Within ten minutes you have two incidents. The first is technical: a group chat with four engineers and a screenshot nobody can read. The second is the client asking by email what is happening, answered by whoever can best be spared from the first. The second one is what damages the relationship, and nobody is assigned to it.
A war room is one place for both. You open it from the incident, people join and pick a role, and the room holds a board to draw on, a message thread and a timeline of events. You can also bring named people from the client into the room, and they see it from their own portal. That part took us the longest to build.
Why the client update is a second incident
Client updates rarely go badly because nobody cares. They go badly because the person who knows what is happening cannot stop to write it down. So someone else writes the update, retelling a chat log they are reading for the first time. Every retelling loses something, and the client can tell.
Any update that has to be re-typed by a second person will be late, and will be wrong in a way you cannot predict.
So the room does not write a client update for you. It lets the client in to watch the shared board being drawn and read a timeline of what has actually happened, while the people fixing the problem carry on from the team’s side.
Two boards and two threads, on purpose
The obvious way to build this is one room that the client can see. We did not do that, because a room during an incident contains things a client should not read: the guess that turned out to be wrong, the name of the engineer who pushed the change, the half-hour spent on a theory that went nowhere. Remove them and the room stops being useful to the team.
Instead, a room has two boards and two threads. The internal board and thread are for staff only, and always will be: the internal board is created with no client attached, and no setting can change that. The client-facing board and thread are separate, and they only exist once you have actually let someone in.
The timeline row is the subtle one. The number of engineers pulled in tells the client how bad things are, and you do not want to reveal that by accident at four in the morning. So the client timeline is built from a list of event types that are allowed through, instead of a list of the ones to hide. If that list is wrong, the client sees too little, never too much.
A seat is not a permission
The board was the easy part. The hard part was deciding exactly who is in the room, because a room needs a narrower membership than anything else in the product.
Our staff rule is broad: you see a project if you are on it or senior to someone who is. Our client rule is broader still: portal rights cover everything that belongs to that client. A war room needs the opposite. It admits one named person from that client, to this room only, until the room closes.
Roles, so the room knows who is doing what
A room comes with the four roles an incident usually needs (Incident Commander, Comms, Scribe and Subject matter expert), and people pick one when they join. A role is only a label. Taking Incident Commander grants no extra access; it tells everyone else in the room who to ask. Each room has its own list of roles, so a room that needs a fifth can add it without changing anybody’s access.
Roles that grant access end up needing access reviews. Roles that only describe the work cost nothing, so people actually pick one, and that habit is what we wanted.
What it deliberately does not do
- Rooms do not open themselves. Not even for a P1. An automatic room is an empty room with a notification, and once people learn to ignore those, the feature is dead.
- The client thread is not the normal chat. The portal’s chat is shared by everyone at the client; a war-room thread belongs to one person. Keeping them apart has a cost: no edits, no reactions, no attachments, no read receipts. We accepted it rather than put a second rule about who may read a thread into the most sensitive code in the system.
- You cannot seat an outsider. Only an existing contact of that client can join. The product has no guest links or share tokens anywhere. Adding them for this would have been the biggest security change in the release, made in a hurry, for the rarest case.
- No extra charge. War rooms are part of the support feature your plan already includes. The client you bring in costs nothing, because they do not take a paid seat.
Where it sits
A war room belongs to the record it is about, an incident or a change request, so there is no separate place to remember. Open the record, then open the room. Everything the room collects stays attached to the record afterwards, which makes the post-mortem easy: the timeline is already in order and the board is still there.
The board uses the same engine as the project whiteboard, which is why it worked from the first day. That drawing code already runs in the desktop app, the web app and the portal; here it simply points at a different record.
What the client does at three in the morning
Ideally, nothing. You do not seat someone to give them a job. You seat them so that when they wake up and ask, you can answer with a link. They open the room and see what has happened. If they have something to add, such as when their own alerts fired or which customer called them, they can put it on the board where the people fixing the problem will see it.
We do not judge the room by how good it looks during an incident. We judge it by whether anyone had to write the same sentence twice: once for the people fixing the problem and once for the person waiting. That repeated sentence is the whole cost of the second incident, and it is what we set out to remove.