The dashboard nobody has opened since the launch demo, and the one screen a shift cannot run without
A command centre is not a reporting surface with bigger numbers on it. It shows exceptions and breaches rather than totals, every tile answers who does what by when, the action is taken on the same screen the signal appeared on, and there is a named escalation path when nothing gets done. Reporting tells you how the quarter went. This tells you what to do before lunch.
- Companies delivered for
- 20+
- Median to first production-grade artefact
- 6 weeks
- Software the floor can open
- By week 3
- Team on a build
- Pod of three, no bench
- Published case study for this pillar
- None yet
Signs the screen on the wall is not a command centre
Each of these starts as a good dashboard. What goes wrong is not the chart, it is that nothing on the screen tells anybody what to do next.
Nobody has opened it since the launch demo
The link still works and the data still refreshes. Look at the access logs and the last real visit was the week it went live, which was the week everyone was told to look at it.
It shows yesterday to people deciding today
The load lands at six in the morning and the decisions that matter get taken at eleven. A number that is correct and late is worth the same as a number that is wrong.
Forty tiles where four would do
Every request from every stakeholder got its own chart, because adding one was easier than saying no. The tiles that matter are now somewhere in the middle of the third row.
The floor has muted the alerting
An alert that fires on an ordinary Tuesday teaches people to ignore it. By the time a real breach fires, ignoring it is the habit rather than the exception.
The real command centre is a WhatsApp group
A supervisor who knows everything, a phone and a group chat. It works, it is faster than the dashboard, and it walks out of the building when that person takes leave.
Nothing on the screen has a name against it
Every tile reports how things are going. None of them says who will do something about it, by when, or what happens if they do not.
What we have actually delivered
We have not published a named command centre case yet, so these are firm-wide delivery figures and we will say on the call which of them came from work like yours.
What the floor says, and the tile it turns into
Nobody asks for a command centre. They describe a shift that went wrong and a phone call that should have come two hours sooner.
- We only found out at the end of the shiftException queue with owners
- Three people chased the same exceptionOne claim, one owner
- Nobody knew it had breached until the client rangThreshold with a named escalation
- The night shift left no record of what they decidedHandover state carried on the screen
- Every decision waits for one supervisor to be awakeThe action taken where the signal appeared
Five surfaces, one discipline
Different floors and different breaches, held to the same rule: a tile earns its place by changing what somebody does in the next hour.
The screen a supervisor runs the day from
Open exceptions, who holds each one, how long it has been open and what is about to breach. Totals live somewhere else. This screen is about the things that are not going to plan while there is still time to change them.
Legible from across the room, to somebody walking past
A different design problem from a desk screen. Large type, few states, no hover, and nothing that needs a click before it means anything. It should be boring on a good day, which is the only way it is unmistakable on a bad one.
A queue you claim from, not a list you scroll
Work arrives as items with an owner and a clock. Claiming one takes a single action and takes it off everybody else's screen, so two people stop working the same problem without knowing it.
The action taken where the signal appeared
Reassign, hold, release, override, call. The control sits beside the number that caused it. Every system you have to open in a second tab is a place where the response stops and the exception ages.
The state one shift hands to the next
What is open, what is claimed, what breached and what was decided about it, carried across the change of shift by the screen instead of by a conversation that nobody wrote down.
What comes off the screen
The hard part of this work is subtraction, and it is the part that gets skipped, because adding a chart is easier to invoice for than taking one away.
- 01
Watch a shift before drawing anything
Time on the floor, standing behind the person who will use the screen. What they open, what they ignore, and what they pick up the phone about instead.
- 02
Write the decision, not the metric
Each candidate tile gets one sentence: who looks at this, what they do when it moves, and by when. A tile that cannot finish that sentence does not go on the screen.
- 03
Set the threshold with the people who breach it
The line that turns a reading into an exception is an operational decision, not a statistical one. It gets agreed with the supervisor and written down where they can find it and change it.
- 04
Give every exception one owner and a clock
Not a team and not a distribution list. A person, or a named role on the roster. The clock starts when the exception appears, not when somebody happens to notice it.
- 05
Cut everything that survived on politeness
The tiles that exist because a stakeholder asked come off, move to the reporting surface where they belong, and the person who asked is told where to find them.
- 06
Run it for a fortnight and count what nobody touched
Any tile nobody acted on in two weeks is either wrong or unnecessary. We fix it or we take it off.
From breach to record
The path one exception takes, from the moment a threshold is crossed to the moment somebody can prove what was done about it.
- Signal
Something crosses a line
A threshold agreed in advance, on data fresh enough that the decision it serves is still open. Not a daily average, and not a total.
- Claim
One person takes it
The exception lands in a queue with an owner and a clock. Claiming it is one action, and it disappears from everybody else's screen the moment it is claimed.
- Act
The response happens here
The response is available on the screen the exception appeared on, so nobody has to log into a second system to answer a question the first one raised.
- Escalate
Silence is an event
If the clock runs out with nothing done, it moves to a named person on the roster. Nothing is allowed to expire quietly and nothing is closed by being scrolled past.
- Record
What was done, and by whom
Every claim, action and escalation is written down as it happens. That record is what makes the handover short and the argument about last Tuesday shorter.
What happens overnight, when nobody is watching
Most floors are not staffed round the clock, and most alerting behaves as though they are. Three levels, agreed in daylight, so the night is not one long judgement call.
- Level 1
Hold it for the morning
Recorded, queued and waiting on the first screen the early shift opens. Most things belong here, and putting them here honestly is what makes the other two levels credible.
- Level 2
Wake a named person
One name on a rota, not a group address that everybody assumes somebody else is reading. Agreed with the people who will be woken, before the first night it happens.
- Level 3
Stop, automatically
The small set of cases where continuing is worse than halting. The system takes the safe action itself and tells somebody it did, rather than waiting to be told.
The wall, and the ten minutes at shift change
Two parts of this work get designed last and decide whether the rest of it holds.
A wall display is a different design problem
Read from across the room, understood at a glance, by somebody carrying something and walking past. That rules out most of what makes a good desk dashboard: small type, dense tables, hover states, colour carrying meaning on its own, and anything that needs a click before it means something.
A wall display should be boring on a good day and unmistakable on a bad one. If people stop to squint at it, it is a desk screen that has been hung on a wall.
The handover is the hardest ten minutes of the day
Two shifts, a few minutes, and everything the outgoing team knows has to reach the incoming one. When that knowledge lives in a supervisor's head the handover is a conversation, and what gets lost is invisible until it costs something.
When it lives on the screen the handover is a screen: what is open, what is claimed, what breached and what was decided. The test is whether a competent person who was not there can pick up the shift without making a phone call.
Where reporting still belongs
None of this replaces reporting. The weekly pack, the board view and the trend that only makes sense across a quarter all matter, and they belong on a surface somebody can sit down with. Mixing the two is exactly how a screen ends up with forty tiles on it.
The command centre answers what to do before lunch. Reporting answers how the quarter went. Keeping those two questions on two different surfaces is most of the discipline.
Where this ends and the neighbouring work begins
Three things get confused with each other on most first calls, so it is worth being plain about which one you are actually buying.
Antvia is the product you report from
A lakehouse and the BI layer over it: dashboards, exploration and the pack that goes to the board. If what you need is a reporting layer over governed data, that is the product, and this page is not it.
See Antvia →Not this pageAgentsData agents watch a metric and explain the movement
An agent notices that something moved, works out what is driving it and writes the explanation. That is a producer of signals. A command centre is where a signal becomes somebody doing something about it.
Read about data agents →The human surface the shift acts on
One screen, exceptions rather than totals, an owner and a clock against each one, and the action available in the same place. Built for the person on shift, not for the person writing the monthly.
You usually need more than one, in a particular order
The signal often comes from an agent, the history usually lives in the reporting layer, and the acting happens here. Week one says which of the three you need first, and it is not always this one.
What the first six weeks look like
Three phases, always, and the interesting part is what has to be true by week three.
- Week 1
The audit, fixed fee
Two calls, and a shift followed end to end: what the floor looks at, what it ignores, and where the decisions actually get made. You get a one-pager, yours whether or not we go further.
- Week 2
The first tiles are chosen
Not forty. The handful of exceptions that change what somebody does in the next hour, each with an owner, a threshold and an escalation written against it before anything is built.
- Week 3
The floor can open it
Software a real supervisor can run a real shift from, with your own data in it. This is the week we find out which of our tiles was wrong, which is precisely why it is not week eight.
- Weeks 4 to 6
It becomes the screen they work from
The actions move onto the surface, the escalation path goes live, and the handover starts running off the screen instead of off a conversation. Our median time to a first production-grade artefact is six weeks.
- Week 7 onwards
Operate
Quarterly reviews and on-call governance. Thresholds drift as the operation changes, and a threshold nobody revisits is how a floor ends up muting its alerting all over again.
Where week three falls in the six
The point of week three is that a busy person disagrees with us while disagreeing is still cheap.
Questions operations leaders ask us
The ones that come up on almost every first call.
Is this just a dashboard with a different name?
No. A dashboard answers how things are going. A command centre says who does what, by when, and what happens if they do not. If nothing on the screen can be acted on where it appears, it is a report, and we will tell you that rather than rebuild it at a higher price.
We already have dashboards nobody uses. Why would this be different?
Because we start by removing rather than adding. The audit week looks at what the floor actually opens and what it rings somebody about instead. Most of what is on screen today moves to the reporting surface, and a small number of tiles stay.
How fresh does the data have to be?
Fresh enough that the decision it serves is still open. On a dispatch floor that is minutes. For a weekly stock call a day is fine. We set it per tile from the decision, because paying for streaming everywhere is a reliable way to get the whole project cancelled.
Our alerting is already ignored. How do you fix that?
By making far fewer alerts and putting an owner and a clock on each one. An alert with no name against it is a notification. Once silence itself escalates to a named person, muting stops working as a strategy.
What happens overnight when nobody is watching?
Three levels agreed in advance: hold it for the morning, wake a named person on the rota, or stop automatically. Most things belong in the first, and being honest about that is what keeps the other two believable.
Do you build the data underneath as well?
Often, yes. Where the data is not fit to act on we will say so before putting a screen over it, because a fast wrong number on a wall is worse than no wall. That work is data engineering and it sits underneath this rather than inside it.
Is this not what an agent does?
An agent notices and explains. A person decides and acts. Data agents are a separate discipline of ours and they feed this surface, they do not replace the person on shift or the escalation path behind them.
You have no case study for this. Why should we believe you?
Because we said so, rather than putting a result from another discipline on this page and hoping you did not check. What we offer instead is week one: two calls, a shift watched end to end, and a one-pager you keep either way.
Who owns it, and can our team change a threshold without you?
You own it from the first commit. Thresholds, owners and escalation rules are configuration your supervisors edit, not a code change you raise a ticket for. If we have built something only we can retune, we have failed at the part that matters.
Our real command centre is one supervisor who knows everything. Is that a problem?
It is, from the moment they take leave. What that person carries is a set of thresholds and escalation rules nobody ever wrote down. The work is getting those onto the screen without pretending the screen is as clever as they are.
The rest of the practice
These are genuinely different jobs with different ways of failing. Most engagements start in one of them.
- Data engineeringJobs that finish, migrations that reconcile, and storage that stops paying for cold data.
- Data integration and governanceOne set of records the finance team and the operations team both accept.
- Data platforms and modernisationOff the platform you outgrew, without a twelve-month freeze on new reporting.
- Apache SupersetSuperset built and run by people who commit to the project, including embedding and Kubernetes.
- AI evaluationA graded eval set, because an AI system cannot simply pass or fail a test suite.
- AI governanceGovernance you can defend in a board meeting and audit on demand.
- AI agentsOne reasoning agent on Claude, on your live data, with evidence and a kill switch.
- Data agentsAgents that watch the data, flag what moved, and explain what is driving it.
- AI use case, guaranteedOne production agent in eight weeks, or you do not pay for the build.
- Applications and automationThe system your team works in all day, built or replaced in slices.
- Application modernisationThe system nobody wants to touch, replaced a slice at a time rather than rewritten.
- System integrationSystems that stop disagreeing about the same customer, order and item.
- Process digitisationThe process that still runs on paper, WhatsApp and one shared spreadsheet.
Start with the Week 1 audit
Two calls, a shift watched end to end, and a one-pager naming what should be on the screen, who owns each of those things and what happens when one of them breaches. You keep it either way. NDA-friendly, fixed scope. Write to hello@woodfrog.tech.