How to know if a custom dashboard is right for you

Most discovery calls we run start the same way: an ops or finance lead has been thinking about fixing their reporting for six to twelve months and is not sure whether the problem is big enough to solve, or whether what we do is what they need. This guide is for them.

It will not answer the question for you, that is what the call is for, but it will tell you whether a call is worth your 30 minutes.

Four signals that say you're ready

You know exactly what question you need answered. Not "better visibility into the business", something specific. "I need to know by 9am every Monday whether we have enough pipeline to hit the quarter." "I need to see whether we are on track for month-end close without spending three days preparing." "I need to know the moment a shipment is more than two hours late, before the customer calls."

The more specific the question, the better. The best dashboards answer one question very well. If you cannot name the question yet, the discovery call is still useful, we help you find it, but the build will take longer and the result will be less precise.

The data already exists somewhere. You have a CRM, an ERP, a warehouse system, a project management tool, a finance platform. The problem is not that the data does not exist, it is that it lives in three separate systems and nobody has wired them together. If the data does not exist yet (for example, you are tracking something entirely in spreadsheets with no source system), a dashboard will not create it. It can only surface what is already there.

You are currently spending hours assembling a view manually. The classic signal: every Monday morning, or every month-end, or every Friday afternoon, someone on your team exports data from one system, pastes it into another, runs some calculations, and produces a summary that everyone reads once and forgets. If you can name that person and that ritual, you have a problem a dashboard solves.

The decision that depends on this data is recurring. A dashboard pays off when the same question is asked every week or every month. If you need a one-time analysis, how did this campaign perform, what was our total revenue in 2023, a dashboard is not the right tool. You want a report, not a board. If the question is asked regularly and the manual preparation time adds up over the year, the economics of a build make sense.

Three signals that say you're not ready yet

You do not know what you want to see. "We want better data visibility" is not a brief. Neither is "a dashboard for the leadership team." If you cannot describe the specific tile that would change a decision you are currently making in the dark, the build will either take much longer (because the discovery process has to do the strategic work first) or produce something that nobody uses because it answered a question nobody was really asking.

This does not mean you should not call us, a discovery conversation can help clarify what you actually need. It means you should expect the conversation to focus on your operations first and the dashboard second.

Your data sources are unstable or undocumented. If your CRM is in the process of being migrated, your ERP was just upgraded and the API changed, or the data quality in your source systems is known to be unreliable, a dashboard built on top of them will reflect those problems. A dashboard does not fix bad data, it makes bad data more visible, which is often worse than not having it at all.

The right order is: clean and stable data first, then a view of it. If you are in the middle of a system migration, wait until the dust settles. If you know the data quality is poor, that is a separate project before this one.

You need analytics flexibility across multiple users with different questions. If what you actually want is for five different people to be able to explore data themselves, run ad hoc queries, and build their own visualisations, a self-serve BI platform is probably the better fit, and you should also read our article on why self-serve BI tools often do not stick before committing to one. A custom dashboard is purpose-built for one use case. That specificity is what makes it work for the person who uses it every day and what makes it the wrong fit if the goal is general-purpose data exploration.

What happens on the discovery call

The call is 30 minutes. We ask three questions.

What does your current reporting process look like? We want to understand what you are doing manually today, which systems it touches, how long it takes, and what decision it is meant to support. Most people can answer this in five minutes. Sometimes the answer surprises them, when they put a time estimate on the routine they have been running for two years, the annual cost becomes visible.

What would you need to see to trust the board? This is the tile question. If we built you a dashboard tomorrow and you opened it at 8am, what would you need to see on it to feel confident you knew the state of the business? We are listening for specifics: a number, a threshold, a comparison, a trend. Specifics mean the build will be fast. Vague answers mean we spend more time on the discovery and less time building.

What are the data sources? We want the names of the systems: HubSpot, Salesforce, Exact, SAP, Shopify, a specific warehouse system, a bespoke internal tool. We will ask whether they have an API or export. We will ask how frequently the data updates. By the end of the call, we will have a clear picture of whether the build is straightforward (API-connected, documented, stable) or whether there are complications worth discussing.

You leave the call knowing three things: whether your problem is the kind we solve, roughly what the dashboard would show, and what it would cost. If we are not the right fit, we will say so.

The honest version

Not every problem needs a custom dashboard. Some problems need a better spreadsheet. Some need a BI tool. Some need cleaner source data before anything else. Some need a different internal process, not a technical solution.

We have ended discovery calls by telling a prospect that what they described was not a dashboard problem. We would rather do that than build something that does not solve the actual issue.

If you have read this far and recognised your situation in the "ready" signals, the 30-minute call is a reasonable next step. If you recognised yourself in the "not ready yet" section, the call can still help you figure out what to fix first.