The request is almost never for a dashboard
Why does nobody use the dashboard you paid for?
Because a dashboard answers a question, and what you actually wanted was for something to happen without you. Those are different products, and only one of them gets used on a Tuesday afternoon when everyone is busy.
Nearly every dashboard request I have received, in-house and since, decomposed into something else once I asked what the person would do with the number. Not because the requester was wrong about their problem — they were describing the symptom accurately. They were just proposing the first solution that came to mind, which is the one they had seen before.
What are people actually asking for when they ask for a dashboard?
Almost always one of four things. Each has a cheaper and more effective answer than a dashboard
- "I want to know when something goes wrong." That is an alert, not a dashboard. A dashboard requires someone to remember to look; an alert finds them. If the value of the number depends on noticing it quickly, a chart is the wrong container.
- "I want to stop asking three people for an update." That is a status field that updates itself. The pain is the chasing, not the absence of a graph — and chasing is solved by making the system record state as work happens, not by displaying state after the fact.
- "I want to trust the number." That is a data quality problem, and a dashboard will faithfully render bad data in an expensive typeface. Fix the source, or you have bought a more confident version of the same doubt.
- "I need to show the board / the client something." That is a reporting deliverable on a fixed cadence — a generated document, monthly, in their inbox. Nobody needs live tiles for a number they will look at twelve times a year.
Only the fifth case is a genuine dashboard: someone whose actual job is to explore data, looking for patterns they cannot specify in advance. That person exists in some businesses. In a 20-person SMB, usually they do not.
How do you tell the difference before you commit budget?
Ask one question, and keep asking it until the answer stops being a number: "What will you do differently the moment you see it?"
Follow that thread and it terminates in one of three places, each pointing at a different build:
- I'd chase someone. Build the chase. The system should be issuing the reminder, not you reading a tile and then typing an email.
- "I'd move the work to someone else." Build the routing rule. The condition you are watching for is a trigger, and triggers belong in code, not in a human's morning routine.
- "Nothing — I'd just know." That is real, and it is fine, but it is a monthly report, not a dashboard. Price it accordingly.
This costs nothing to run and routinely removes the most expensive item from a scope. I would rather lose the line item than build something that gets opened enthusiastically for two weeks and then never again.
Isn't a dashboard still useful for visibility?
Visibility is only valuable if it changes a decision, and most SMB dashboards are consulted after the decision has already been forced by events.
The honest test is whether anyone opened it last week without being reminded to. If a dashboard is not part of a routine that already exists — a Monday meeting, a weekly review someone genuinely runs — it will not create that routine by existing. Software does not manufacture discipline.
The exception worth respecting: dashboards are good at revealing problems you could not have named in advance. If you are in a genuinely unfamiliar situation — new market, new service line, unexplained churn — exploration has real value. That is a specific, temporary need, not a default.
Frequently asked questions
Should a small business build a dashboard?
Usually not first. If the underlying need is to know when something goes wrong, or to stop chasing colleagues for updates, an alert or an automated status field delivers the outcome faster and cheaper. Build the dashboard once you have a named person whose job includes exploring the data.
What is the difference between reporting and automation?
Reporting tells a person that something happened so they can act. Automation performs the action. Reporting leaves the work with you; automation removes it. Most requests framed as reporting are really requests for automation with the last step missing.
How do I know if a proposed build will actually get used?
Ask what the user will do differently within five minutes of seeing the output. If the answer is a concrete action, build the action. If the answer is vague, the build will be too.