Stop Building Dashboards Nobody Opens: Design Exception Routing Instead

Originally published on penningtonj.com as "Nobody Opens the Dashboard." This is a rewritten version for builders.

Here's a pattern I've watched repeat across a lot of operations software: the team asks for a dashboard, we ship it, usage spikes for about two weeks, and by week five the analytics show it's mostly opened by the person who asked for it.

The charts weren't wrong. The design question was wrong. "What should this screen show?" is a reporting question. The question that keeps a business on track is an engineering one: when a specific condition goes bad, which human gets notified, where, and with what attached?

I'm Justin Pennington, founder of Infraxio, a product studio in Ponte Vedra, Florida. We build the business hub, growth, bid, and dock-and-yard software that operators across St. Johns County, Jacksonville, and further out use every day. Below is how we've started to think about exceptions instead of tiles.

Why pull-based reporting decays

A dashboard is a pull interface. It only works if someone remembers to come and pull. In the first month, novelty does that job. After that, three things kill it:

1. Calm is the default. Most days most tiles look fine, so checking becomes optional. That's exactly when the one bad day gets missed.
2. It's a second place. The people who can change an outcome already live somewhere else: the task board, the CRM record, the dock schedule, their phone. Asking them to leave that to read a picture is friction they'll eventually skip.
3. Shared visibility has no owner. Five people can see a red tile and each assume someone else has it.

If you've seen a CRM become a place only leadership visits, you've seen this already. I wrote about that in nobody lives in the CRM.

The three-field exception spec

Before anyone designs a tile, we write each exception down as a tiny spec with three fields:

exception: lead_without_first_touch
condition: inquiry.created_at older than 15 min AND no outbound contact logged
owner: assigned_rep
backup: sales_lead_on_shift
next_action: "Call the lead; log the outcome on the record"
deliver_to: the owner's task board, with the lead record attached

The numbers above are an example, not a recommendation. The point is the shape:

• Condition has to be specific enough that an operator can name the miss. "Pipeline health" isn't a condition. "A bid section with no owner five days before the due date" is.
• Owner is one named person plus a backup. A channel isn't an owner. A shared inbox isn't an owner.
• Next action is something a person can actually do: a call, a decision, a task with a date, a hold, a no-bid.

If you can't fill in all three, another chart wasn't going to save you either.

Where AI fits (and where it doesn't)

The tempting move is to have a model summarize the dashboard every morning. It feels like the dashboard finally has a reader. But a summary of everything still makes a human scan for the one line that needed a decision. It's the same chart, just in prose.

The better use is narrower and more boring: let the model watch the thresholds you named, and route the trips. When a condition fires, create owned work for the owner, attach the record, and stay quiet the rest of the time. Calm doesn't need narrating.

The agent doesn't replace the owner. We treat agent output the same way we treat anyone's work. It lands on the task board and a person reviews it, which I covered in put AI on the task board.

Deliver the exception where the work already happens

This rule shapes how we build our own products:

• IFX Hub: a stalled follow-up or a delivery that stopped moving lands as an owned task on the board, not as a red number somewhere else.
• Growth7: a new inquiry nobody has touched, or a reply that needs a person, turns into a next action for a named rep, with the context attached.
• IFX Bid: what goes wrong is usually internal. A section with no owner, a price that's still an open question, a pursuit that should have been declined. Those come up as owned work long before the submission date.
• DockOps: the supervisor needs the break, not the overview. A door that slipped, a blocked yard, an appointment that doesn't match the truck that showed up.

Custom builds get the same test. If the daily job is a price, a dispatch, a pick, or a client update, the exception belongs on the screen where that job is done.

A retro you can run this week

If your dashboard has turned into furniture, skip the redesign and run this instead:

1. List the last five misses you can still name: the lead that went cold, the invoice that sat, the bid that went out thin, the dock that backed up.
2. For each one, write the condition that would have caught it, who should have heard, and what they should have done next.
3. Wire just those into the tools your people already have open, with a backup owner for every one.

You'll end up with fewer screens and more caught problems. If the only way to find out something is wrong is to open a dashboard, you'll find out late.

Justin Pennington is the founder of Infraxio, based in Ponte Vedra, Florida. More essays at penningtonj.com.