Dashboards built around decisions, not around available metrics
An admin dashboard gives your team a view across systems and the ability to act on what it shows. The design question is which decisions it supports: dashboards built from available data rather than from decisions become wallpaper nobody opens.
Dashboards fail more quietly than most software. Nobody complains about them. They are simply not opened. Six months after launch the team is still asking for the same figures by email, because the dashboard shows twenty numbers and none of them is the one that prompts an action.
The usual construction is backwards: someone lists what data is available and displays it. The result is comprehensive and undirected, charts of everything measurable, where nobody can see what requires attention. There is no way to act on anything shown, so noticing a problem means leaving the dashboard to do something about it elsewhere. And the numbers are pulled live from production systems, so it becomes slow enough to discourage opening.
When this work makes sense
Questions worth asking any supplier
Which decisions should this support? A dashboard with no decisions attached becomes wallpaper.
Who opens it, how often, and what do they do next?
Can they act from the dashboard, or only observe?
Where does the data come from, and how fresh must it genuinely be?
What already gets requested by email? That is the real requirements list.
Deliverables
A decision inventory. What each user needs to determine and what they do about it
Dashboard design organised around those decisions rather than around available data
Data pipeline aggregating from source systems without overloading them
Actions available in context, so noticing something and doing something are one step
Alerting for conditions that need attention, so nobody has to watch a screen
Role-based views, since a manager and an operator need different things
Scheduled exports for people who will always prefer a spreadsheet
Performance work so it opens quickly enough to be used
Built with
Process
We start by collecting what people currently request by email or rebuild by hand each month. That list is the real requirement, and it is consistently shorter and more specific than what a stakeholder workshop produces. Asking people what they want on a dashboard produces everything; looking at what they actually ask for produces the handful of figures that drive decisions.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
BI tool, custom dashboard, or scheduled reports
BI tool (Looker Studio, Power BI)
Fits: Analytical exploration by people comfortable building their own views
Limits: Read-only; no actions; licensing costs per user
Custom dashboard
Fits: Operational monitoring where users need to act on what they see
Limits: Build cost; must be maintained as source systems change
Scheduled reports
Fits: Periodic review where live data adds nothing
Limits: No exploration; arrives whether or not anything needs attention
Case studies
No published dashboard case study. Internal tooling is client-confidential by nature.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Why does nobody use our dashboard?
Usually because it shows data rather than answers. If someone has to interpret twenty charts to work out whether anything needs attention, they will go back to asking a colleague. Dashboards that get used answer a specific question quickly and make the next action available.
Should we use a BI tool instead?
If the need is analytical exploration by people who will build their own views, yes. It is cheaper and faster. If the need is operational monitoring with actions attached, a BI tool leaves you observing problems you then have to go elsewhere to fix.
How fresh does the data need to be?
Less fresh than people request, usually. Real-time is expensive and rarely changes a decision, if nobody acts within the hour, hourly refresh is sufficient. Asking what decision the freshness supports usually reduces the requirement substantially.
Can it pull from several systems?
Yes, and that is frequently the main reason to build one. The work is in reconciling systems that disagree, different customer identifiers, different date handling, different definitions of the same metric. That reconciliation is usually the bulk of the project.
Will it slow down our production systems?
Not if built properly. Aggregating into a separate store rather than querying production live is the standard approach. Dashboards that hammer the operational database are how a reporting tool becomes an outage.
What about alerts instead of a dashboard?
Often better for anything needing a response. A dashboard requires someone to look; an alert finds them. The best arrangement is usually alerts for conditions needing action and a dashboard for periodic review.
Our team prefers spreadsheets.
Then include a scheduled export. Fighting that preference rarely works, and a dashboard that also feeds the spreadsheet people already use gets adopted, where one that insists on replacing it does not.
Who maintains it when our source systems change?
Someone must, and it should be agreed before launch. Dashboards break silently: a field is renamed in your CRM, an API version is deprecated, and a chart shows zero rather than an error. Nobody notices for weeks because a number that looks plausible is not questioned. We build validation that flags when a source stops returning sensible data, and the maintenance arrangement should be explicit rather than assumed.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.