Can we have one dashboard with everything on it?

You can, and you will open it once. A page with twenty-two charts on it does not tell anyone what to look at, so people go back to the spreadsheet they trust. The rule we work to is that no chart goes on a page unless it answers a question someone has written down, and every chart carries a one-line note above it saying what you are meant to notice. Everything else that is genuinely useful goes on a second page.

What happens when someone says the number is wrong?

That is the most useful conversation in the project, not a crisis. It almost always turns out to be a definition rather than a fault — their figure excludes tax or shipping, or counts refunds when the refund was issued rather than when the order was placed, or their month ends on a different day from the calendar month. We find the difference, write it down, and put a note on the page. Two numbers differing is not a problem. Two numbers differing without an explanation is.

Which tool should we be on?

It depends on who is reading it and what the data sits in. Looker Studio is free, shares by link so nobody has to install anything, and emails itself on a schedule, which suits small and mid-sized teams — it slows down on large datasets. Power BI is the default inside most corporates, is considerably more powerful, and is per-user licensed and slower to build in. Metabase is common where there is an engineering team and a database to point at. We will recommend one and tell you what you give up by choosing it.

How current will the data be?

That is a decision, not a default, and it has a cost. We agree a refresh schedule per source based on how often each one actually changes and how quickly you need to act, then we put a visible last-updated timestamp on every page. A dashboard that silently shows yesterday's figures is more dangerous than one that admits it.

What if our data is not clean enough for this?

We find that out in the second week, not the seventh, and we tell you immediately. Sometimes the honest answer is that a cleaning or migration job has to happen before a dashboard is worth building, because a beautiful chart of unreliable data is a faster route to a wrong decision than no chart at all. If that is the situation, we scope it separately rather than quietly absorbing it.

Can different people see different things?

Yes, and it should be planned rather than retrofitted. The simplest version is a matter of who gets which page. Where sales staff should only see their own accounts, or franchise managers only their own sites, that is row-level filtering and it needs to be designed into the data model from the start, because bolting it on afterwards usually means rebuilding.

Data & Analytics

Dashboards people actually reopen

Looker Studio, Power BI or Metabase built around a written list of questions — with every metric defined before a single chart is drawn.

From: $800–$10,000
Typical time: 2–8 weeks
Usually bought by: Management teams

What this actually solves

There is data. That is not the problem. The problem is that it lives in three systems, and somebody spends the first two days of every week exporting, pasting and reconciling it into a report that is out of date by the time it is circulated. That person is expensive, they hate the work, and when they take leave the report simply does not happen.

The second version is worse. Every meeting starts with an argument about whose number is right, because four people arrive with four spreadsheets built from four different assumptions. The meeting is spent establishing what happened rather than deciding what to do next. Nobody is wrong, exactly — one of them is including shipping in revenue, one is counting refunds in the month they were issued, one has a financial month that ends on the twenty-sixth — but nobody can prove it in the room.

The value of a dashboard is not that it looks good. It is that it ends both of those. The report builds itself, and the definitions are settled in writing before anyone sees a chart, so the meeting can be about the decision. That is why the most important part of this work happens before anything is built, and why a project that starts with chart types usually ends with something nobody opens.

What we do, and in what order

Write down the questions, in your words. Five to eight of them — the ones actually asked on a Monday morning. This is the step new suppliers skip and it is the one that determines whether the result gets used. Anything that is not answering one of these questions does not make the first page. Half a day to a day.
Get to the sources. Listing them takes an hour; getting working access with the right permissions is where projects lose time, because it depends on other people's calendars and someone's admin login. We start it early for that reason. Two days to two weeks, mostly outside our control.
Check the condition of the data before modelling it. Volumes, gaps, duplicates, inconsistent currencies and time zones, and whether the identifiers actually join. If a cleaning job is needed first you hear it here, in week two. One to two days.
Write the metric definitions. One page, agreed by you, that says what revenue means — with or without refunds, with or without tax, shipping included or not — and the same for every other headline figure. This single page prevents most of the disputes that would otherwise arrive in month three. One day.
Build the model, then the pages. Which tables, which joins, which calculated fields, and then no more than two or three pages on top of it. Charts chosen for what they have to show rather than for variety, each with its explanatory line. One to three weeks.
Refresh, access and handover. Schedules set, last-updated stamps visible, permissions configured per group, then a short training call and a recorded walkthrough so the knowledge does not leave with one person. Two to three days.

What moves the price

How many sources have to be joined. One source is a straightforward build. Four is roughly three times the work, because the effort is not in connecting them — it is in reconciling identifiers, currencies, time zones and definitions between them so a single figure can be trusted across all four.

Whether the data is usable as it stands. Cleaning is a separate discipline and a separate cost. Where the source data is inconsistent, that work has to happen first and it can be a larger job than the dashboard.

Which tool, and how many people use it. Building in Power BI takes meaningfully longer than Looker Studio for the same output and carries per-user licensing. Add differentiated access — row-level filtering so people see only their own accounts — and both the model and the testing expand.

What usually goes wrong

Every chart that could be built, gets built. Twenty-two visuals on one page because the data supported all of them. You are impressed at handover and never open it again, because there is no way to tell what deserves attention. The discipline is subtractive — if a chart does not answer a written question, it does not go on the page, and if it survives that test it still needs a sentence above it telling the reader what to look for.

Metrics that were never defined get argued about instead. Without the definitions page, revenue means whatever each department assumes it means, and the first time the dashboard disagrees with someone's spreadsheet the dashboard loses. The definition has to be agreed in writing before the build, because after the build it looks like an excuse.

Partial periods compared against complete ones. A tile showing this month against last month makes the business look like it is collapsing every day until the twenty-eighth, and then recovering. The same trap catches refunds landing in a different month from the order that generated them. Every period comparison needs to state what it is comparing, and month-to-date figures need to be labelled as such on the page rather than left to be misread in a board meeting.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Can we have one dashboard with everything on it?: You can, and you will open it once. A page with twenty-two charts on it does not tell anyone what to look at, so people go back to the spreadsheet they trust. The rule we work to is that no chart goes on a page unless it answers a question someone has written down, and every chart carries a one-line note above it saying what you are meant to notice. Everything else that is genuinely useful goes on a second page.
What happens when someone says the number is wrong?: That is the most useful conversation in the project, not a crisis. It almost always turns out to be a definition rather than a fault — their figure excludes tax or shipping, or counts refunds when the refund was issued rather than when the order was placed, or their month ends on a different day from the calendar month. We find the difference, write it down, and put a note on the page. Two numbers differing is not a problem. Two numbers differing without an explanation is.
Which tool should we be on?: It depends on who is reading it and what the data sits in. Looker Studio is free, shares by link so nobody has to install anything, and emails itself on a schedule, which suits small and mid-sized teams — it slows down on large datasets. Power BI is the default inside most corporates, is considerably more powerful, and is per-user licensed and slower to build in. Metabase is common where there is an engineering team and a database to point at. We will recommend one and tell you what you give up by choosing it.
How current will the data be?: That is a decision, not a default, and it has a cost. We agree a refresh schedule per source based on how often each one actually changes and how quickly you need to act, then we put a visible last-updated timestamp on every page. A dashboard that silently shows yesterday's figures is more dangerous than one that admits it.
What if our data is not clean enough for this?: We find that out in the second week, not the seventh, and we tell you immediately. Sometimes the honest answer is that a cleaning or migration job has to happen before a dashboard is worth building, because a beautiful chart of unreliable data is a faster route to a wrong decision than no chart at all. If that is the situation, we scope it separately rather than quietly absorbing it.
Can different people see different things?: Yes, and it should be planned rather than retrofitted. The simplest version is a matter of who gets which page. Where sales staff should only see their own accounts, or franchise managers only their own sites, that is row-level filtering and it needs to be designed into the data model from the start, because bolting it on afterwards usually means rebuilding.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about BI dashboards All Data & Analytics services