Every MSP has a dashboard somewhere. A BrightGauge board nobody's opened since the QBR. A Power BI report that broke when someone renamed a column. A wall-mounted TV that's been stuck on the same week-old numbers for a month. The dashboard exists. The problem is that nobody uses it.

We've built the same dead dashboard ourselves more than once. So when we built the home screen for Morton Command Center, the design goal wasn't "show every metric we can pull." It was narrower and harder: make a board a tech opens at the start of their shift and a manager opens before standup — without being told to. Here's what we learned about what makes that happen.

Why most MSP dashboards die

The dashboards that get abandoned almost always share the same three failure modes, and they compound.

Notice that none of these are about which charts you picked. They're about ownership, trust, and friction. That's where we spent our effort.

Make it per-role, then per-person

The single biggest change was letting the layout differ by who's looking at it. In Morton Command Center, the dashboard is a tile grid that each agent can arrange for themselves. You drag tiles to reorder them, drag a corner to resize them on the grid, and the arrangement is saved as a per-agent layout override — so your board stays yours between sessions and across devices.

In practice that means a technician can pull their assigned-tickets and SLA tiles up top and shrink everything financial down to nothing, while a manager keeps the ticket-volume and revenue widgets front and center. Same underlying data, two completely different boards, no second tool. Role-based access control does the rest of the work here: finance-flavored numbers are stripped for roles that shouldn't see them, so a sales rep or a read-only tech simply never has those tiles to add in the first place.

The lesson we'd pass on to any MSP, regardless of what tool you use: stop trying to design the one dashboard. Design the data layer well, then let each role shape the surface. People keep what they shape.

Add tiles from a library, don't author charts from scratch

There's a tempting middle path that we deliberately avoided: turning the dashboard into a full BI builder where anyone can author arbitrary charts. It sounds empowering and it's a trap. The moment a board can show anything, every number on it becomes a question — is this filtered the way I think it is? does "open tickets" here mean the same thing as on the tickets page? You trade trust for flexibility, and trust is the whole point.

So we landed on a curated middle. Morton Command Center ships a Widget Library — a fixed catalog of tiles we've already built and validated — and agents add or remove tiles from that catalog into their own layout. You can't draw a brand-new visualization from nothing, and that's on purpose. Every tile in the library is a metric we've defined once, sourced from one place, and tested. When two people add the "open tickets" tile, they get the same number, computed the same way.

The catalog covers the things an MSP actually watches: a four-up security overview, per-KPI counters, ticket and revenue widgets, recent activity, and the live call tiles. You arrange and add from that set. The freedom is in the composition, not in the math — which is exactly the balance that keeps a board both personal and trustworthy.

Morton Command Center dashboard showing a customizable tile grid of MSP KPIs including tickets, revenue, and security overview

One metric, one definition, one source

If there's a single principle that does the heavy lifting, it's this one. A dashboard only earns daily use if every tile agrees with the page behind it. The open-ticket count on your home screen has to match what you see when you click into the tickets console, or people quietly stop believing both.

We get that for free because of how the platform is built. Morton Command Center doesn't keep its own parallel copy of your data — it reads through normalized adapters straight from the tools you already run. Tickets come from your ticketing system or PSA, device health from your RMM, call activity from your phone system, invoicing and A/R from your accounting system. Each of those adapters is built custom to your stack as part of your engagement, and because the platform is API-driven, the same pattern connects whatever you actually run: your ticketing system or PSA (Freshdesk, ConnectWise, HaloPSA, or anything with an API), your RMM (NinjaOne, Datto, or similar), your phone system (3CX, RingCentral), and your accounting system (QuickBooks, Xero, Sage). If your tool has an API, we build the integration for it, fit to your exact workflows. That's the advantage over a rigid all-in-one suite that forces you onto its pre-built connectors: your board reads from the tools you chose, wired the way you work. The dashboard tile and the detail page are reading the same cached pull, so they can't disagree. There's no second database to fall out of sync, because there's no second database — caching runs on Cloudflare KV, warmed on a schedule.

One caveat we're careful about, and you should be too: this is near-real-time, not real-time. The caches refresh on cron cycles — security incidents from your EDR (any EDR with an API connects — Huntress, SentinelOne, or your stack) every couple of minutes, most other feeds hourly or nightly — with a manual refresh when you need it now. A dashboard that promises "live" and then shows a number five minutes behind erodes trust just as fast as a wrong number. We say "within minutes" and we mean it, and the board itself doesn't pretend otherwise.

Tie tiles to action, not just observation

A KPI you can only stare at is a KPI you'll eventually stop checking. The tiles that get used are the ones that are a doorway, not a billboard. An assigned-tickets tile that clicks straight into the filtered queue. A security tile that drops you into the incident you need to triage in your EDR. A call-activity tile that's one hop from the queue you're about to reorder. When the number is the start of a workflow instead of the end of a report, opening the dashboard becomes the natural first move of the day rather than a chore someone reminds you to do.

This is also why we didn't bolt the dashboard onto a standalone analytics product. It lives in the same app as the work — the tickets, the devices, the invoices, the phones — so every tile is one click from the thing it's measuring. The shortest path from "noticed a number" to "did something about it" is what turns a dashboard from decoration into a habit.

What we'd tell an MSP starting from scratch

You don't need our product to apply most of this. If you're building a KPI board on whatever you've got, the order of operations that worked for us was: nail one trustworthy source for each metric first, give each role its own view second, keep the catalog of tiles small and validated third, and make every tile clickable into the underlying work last. Adoption follows trust, trust follows consistency, and consistency follows having exactly one definition of "open tickets" in the whole building.

If you'd rather not assemble that yourself, that's the gap we built for. The same architecture shows up in our customizable MSP dashboard and, for the money side specifically, our revenue dashboard — both reading from the tools you already pay for rather than asking you to migrate anything. And if the per-seat cost of your current dashboard layer is part of what's pushing you to consolidate, we wrote about that math in why MSPs end up paying 4× their headcount in platform fees.

The dashboard you actually use isn't the one with the most metrics. It's the one each person trusts, shapes, and clicks into a dozen times a day without thinking about it. That's a much harder thing to build than a pretty board — and it's the only kind worth building.