Build it with AI
Create an operations dashboard around the signals that actually run the business.
Build a live operating view for workload, throughput, exceptions, service levels, and next actions.
Introduction
What an operations dashboard has to hold.
Most teams end up with an operations dashboard the same way: a weekly operations meeting where each function brings its own numbers. Weekly reporting is adequate while the response to a problem is also weekly. It becomes the constraint the moment the cost of an exception compounds daily, which is true of nearly every operational failure and almost never reflected in the reporting cadence.
Each function measures itself, so the handoffs between them — where the delays actually accumulate — are measured by nobody. There is no threshold defined for what counts as an exception, no owner attached to one when it occurs, and no record of how long it took to notice as distinct from how long it took to fix.
What follows covers building an operations dashboard: the records it holds (throughput, backlog, exceptions, owners, and cycle time across the operating processes), the systems it reads (Slack and Google Sheets), and what it does not fix.
The problem
The exception is visible on Friday and happened on Tuesday.
Operational systems each report on their own domain, so the view of the business is an assembly job performed weekly by whoever owns the spreadsheet. BI tools chart it beautifully at whatever cadence the extract runs, which is the cadence that was the problem.
The records are throughput, backlog, exceptions, owners, and cycle time across the operating processes, and the authoritative copy of most of them already lives in Slack or Google Sheets. The operations sheet is updated Thursday afternoon for the Friday meeting, so every number in the meeting is between one and seven days old and nobody says which.
The cost is not the inconvenience: effort goes into the step that is already fast.
You're likely here because
- Problems are discovered at the weekly meeting rather than when they happen
- Each function measures itself, so the handoffs between them — where the delays actually accumulate — are measured by nobody.
- When it is wrong, effort goes into the step that is already fast
What gets built
Launch builds it, Grow operates it.
Built in Launch
- • Operations KPIs
- • Exception queues
- • Workload views
Operated through Grow
- • Action routing
- • Notifications
- • Follow-up
Systems it reads
- • Slack
- • Google Sheets
- • Airtable
The record model
What an operations view has to hold.
- Exception threshold with its owner
- Numeric, and agreed by whoever is accountable. An undefended threshold produces an alert that is muted within a month and stays muted.
- Time to notice
- Recorded separately from time to resolve. Most operational improvement is available in the first number and almost all attention goes to the second.
- Queue depth and its rate of change
- Because a queue of forty that is falling is a different situation from a queue of thirty that is rising, and depth alone cannot tell them apart.
- Service level target
- Per work type, so an exception is defined against a commitment rather than against a feeling about what is normal.
- Alert precision history
- Whether each alert produced an action. Alerts are added continuously and removed almost never, which is why alerting degrades predictably.
- Workload by team
- So the answer to a persistent exception can be a capacity decision rather than another escalation.
- Normal band per metric
- Derived from history, so live data does not invite intervention in ordinary variation that a weekly average was usefully hiding.
How it runs
From weekly reporting to a live operating view.
Step 01
Describe what an operations dashboard has to do
Define what an exception is, numerically, before building any chart. An operations dashboard without thresholds is a wall of numbers that everyone learns to stop reading.
Step 02
Connect the systems of record
The operational systems supply throughput and state, chat is where the response happens. Reading both is what lets time-to-notice be measured separately from time-to-fix.
Step 03
Build the operating surface
Throughput and service-level views, exception queues with owners, and workload by team — with thresholds visible on the view rather than held in policy.
Step 04
Start narrow
One exception queue for the failure that costs most, with a threshold and a named owner. A single queue that changes a response time beats twelve charts that change nothing.
Step 05
Route the exceptions
An exception past its threshold goes to the named owner with context attached and the clock running, rather than waiting to be noticed.
Step 06
Measure time a work item spends waiting versus being worked
Measure time to notice separately from time to resolve. Most operational improvement is in the first number and most attention goes to the second.
Implementation path
Building an operations view that changes a decision.
- 01
Define exception thresholds numerically and get the owner of each to agree them. Undefended thresholds produce alerts that are turned off within a month.
- 02
Baseline time to notice and time to resolve separately for the last quarter’s incidents. The split is usually surprising and determines where the work should go.
- 03
Build one exception queue before any charts. Charts inform; queues change what happens, and only one of those is worth the first two weeks.
- 04
Review alert precision after a month and remove anything that fired without a resulting action. An alert nobody acts on trains people to ignore the ones that matter.
- 05
Build the narrowest useful version first: cycle time across one end-to-end process that crosses at least two teams.
- 06
Agreeing thresholds with the accountable owner is a session per area and is the part that determines whether anyone acts on the result. One exception queue is a week of build. The monthly alert precision review is a standing commitment rather than a one-off, and skipping it is what turns a working system into background noise within two quarters.
- 07
Once one queue has changed a response time, add the second-highest-cost exception and the workload view that lets a persistent queue be answered with capacity. Trend charts come after the queues, not before.
Controls
Controls that matter.
Control 01
Numeric thresholds agreed with the owner accountable for each, so an alert has a recipient who accepted it
Control 02
Time to notice recorded separately from time to resolve, since they respond to entirely different interventions
Control 03
Alert precision reviewed on a schedule, with anything that consistently fires without action removed rather than tolerated
Examples
Three things that surface earlier.
The backlog that built for four days
A threshold on queue depth with a named owner turns a Friday discovery into a Tuesday intervention, which is usually the difference between an adjustment and a recovery effort.
The dashboard nobody opened
Exceptions that come to a person, rather than waiting on a screen for someone to look, is the design difference between an operations dashboard that changes behaviour and one that is admired at launch.
The weekly operations meeting
When exceptions are already handled, the meeting shifts from finding out what happened to deciding what to change, which is the only version worth an hour of several people’s time.
How it goes wrong
Three ways operations dashboards stop working.
Charts ship first, the dashboard is opened for a fortnight, and then nobody looks.
Build a queue before a chart. A queue has an owner and a chart has an audience, and essentially all measurable improvement comes from exceptions reaching a named person faster.
Thresholds are set tight, alerts fire constantly, and the team learns to ignore them.
Review precision monthly and delete anything that fires without producing an action. Alert fatigue is worse than no alerting because it degrades response to the alerts that are real.
Live data arrives and managers start intervening in daily variation on a metric that only means something weekly.
Show the normal band and match refresh to the decision cycle. Some of what a live view exposes is noise the weekly average was usefully suppressing.
Limitations and considerations
What visibility alone does not achieve.
- Visibility does not add capacity. A dashboard showing a team is over capacity produces a decision about priorities or headcount, and can create the impression that something has been done when nothing has.
- Thresholds set too tight produce alert fatigue, which is worse than no alerting because it degrades response to the alerts that are real.
- Live operational data invites intervention in normal variation. Some of what a live view exposes is noise that a weekly average was usefully hiding, and reacting to it costs more than it saves.
- If the response to a problem is weekly regardless, live data buys anxiety rather than improvement. If the constraint is capacity rather than visibility, a dashboard makes the shortfall legible and can create the impression that something has been done.
- Connector coverage varies: Slack, Google Sheets, Airtable are representative rather than guaranteed, and the fields exposed depend on your workspace permissions.
FAQ
Build an operations dashboard with AI: common questions.
How live does an operations view need to be?
As live as the cost of a delayed response. If an exception compounds hourly, hourly; if the response is weekly regardless, live data buys anxiety rather than improvement.
Why start with a queue rather than charts?
Because a queue has an owner and a chart has an audience. Almost all of the measurable improvement from an operations build comes from exceptions reaching a named person faster, and none of it comes from more visualisation.
How do we avoid alert fatigue?
Review precision monthly and delete anything that has fired more than a few times without producing an action. Teams add alerts continuously and remove them almost never, which is why alerting degrades predictably.
Who should own it?
The person accountable for the operational outcome, not the person who built it. A dashboard owned by whoever assembled it drifts out of agreement with the process within a quarter of any change.
What should the first version contain?
Cycle time across one end-to-end process that crosses at least two teams. Everything else waits until that one is genuinely used.
How will we know whether it worked?
Measure time a work item spends waiting versus being worked against the baseline taken before anything changed.
Related pages
Keep exploring
Start with ARIA
Ask ARIA to build it.
Describe the website, application, workflow, or operating surface you need. ARIA plans, connects, builds, tests, and keeps refining it — inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Start here
Build an operations dashboard around the process you actually run.
Define the thresholds first, build one exception queue with a named owner, and measure time to notice separately from time to fix.