Something is down. Within ten minutes there are two incidents running: the technical one, in a group chat with four engineers and a screenshot nobody can read, and the second one — the client asking what is happening, in an email thread, answered by whoever is least useful in the first. The second incident is the one that damages the relationship, and it is the one nobody is assigned to.
A war room is one room for both. You open it on the incident, people join it and take a role, and there is a board, a thread and a timeline in the same place. Then — and this is the part that took the longest to build — you can bring one named person from the client into it, and they see the room from their own portal.
Why the client update is a second incident
The reason the client thread goes badly is not that nobody cares. It is that the person who knows what is happening is the person who cannot stop to write it down, so the update is written by someone translating a chat log they are also reading for the first time. Every translation 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 generate a client update. It lets the client stand in the room, see the board being drawn, and read a timeline of what has actually happened — while the people fixing it carry on in the same place they were already working.
Two boards, two threads, and the split is the point
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. Take those away and the room stops being useful to the people it is for.
So a room has two boards and two threads. The internal board and thread are staff-only and stay that way — the internal board is created with no client attached and it is not a setting anyone can toggle. The client-facing board and thread are separate objects that only exist once you have actually let someone in.
That last row is worth dwelling on. “How many engineers got pulled in” is information about how bad it is, and it is not yours to leak by accident at four in the morning. So the client timeline is built from a list of event types that are allowed to cross, rather than by hiding the ones that are not — a list that can only ever be too short, never too revealing.
A seat is not a permission
The hard part of this feature was not the canvas. It was answering, precisely, who is in the room — because a room needs a membership narrower than anything the rest of the product can express.
Our staff rule widens: you see a project if you are on it or above someone who is. Our client rule widens further: any portal login belonging to a client sees everything that client can see. A war room needs the opposite of both. Not “the client” — one named person at that client, for this room, until it closes.
Roles, so the room knows who is doing what
A room ships with the four roles an incident usually needs — Incident Commander, Comms, Scribe, Subject matter expert — and people take one when they join. It is a label, not a permission: taking Incident Commander does not grant anything, it tells the other nine people in the room who to ask. The catalogue is per-room, so a room that needs a fifth role can have one without touching anybody’s access.
The distinction matters more than it sounds. Roles that grant power turn into an access review; roles that only describe turn into a habit. We wanted the habit.
What it deliberately does not do
- Rooms do not open themselves. No auto-open on a P1. An automatic room is an empty room with a notification attached, and the second one nobody joins, the feature is over.
- The client thread is not the normal chat. It is a separate thing, on purpose — the portal’s chat is scoped to the whole client, and a war-room thread is scoped to one person. The cost is real: no edits, no reactions, no attachments, no read receipts. We took it rather than teach the riskiest code in the system a second idea of who may read a thread.
- You cannot seat an outsider. Only an existing contact of that client. There is no guest link and no share token anywhere in the product, and adding one for this would have been the largest security change in the release, made under time pressure, for the rarest case.
- Nothing is billed for it. War rooms ride the support feature the plan already includes. There is no seat cost for the client you bring in, because there is no seat.
Where it sits
A war room hangs off the record it is about — an incident or a change request — so it is never a separate place you have to remember to look. Open the record, open the room. Everything the room collects stays attached to that record afterwards, which is how the post-mortem writes itself: the timeline is already in order and the board is still there.
The board is the same engine as the project whiteboard, which is why it arrived working — one drawing engine, vendored identically into the desktop app, the web app and the portal, and pointed at a different subject.
What the client does at three in the morning
Nothing, ideally. The point of seating someone is not to give them a job; it is that when they wake up and ask, the answer is a link rather than a paragraph. They open the room, they see what has happened, and if they have something to add — the time their own alerting fired, the customer who called them — they can put it on the board where the people fixing it will actually see it.
The measure we care about is not how good the room looks during the incident. It is whether anyone had to write the same sentence twice — once for the people fixing it and once for the person waiting. That sentence is the whole cost of the second incident, and it is the one we were trying to delete.