Six numbers that change a decision beat forty that nobody reads
One screen per role, built around the choices that role actually makes. Every figure clicks through to the rows behind it. And each week, a short note in plain English saying what moved.
In short: We build one dashboard per role, not one for everybody. Every number on it traces back to the records underneath, so nobody has to take a figure on faith. A written weekly summary says what changed. A month after launch we look at what people actually opened, and remove the rest.
We start with the decision, not the data
Before anyone opens a charting tool, we ask a narrow question. What does this person decide, how often, and what would make them decide differently? An operations manager choosing tomorrow’s shift cover needs almost nothing in common with a finance director signing off next quarter’s spend. Answer that properly and the screen more or less designs itself. Skip it and you get a wall of charts that describe the business accurately and change nothing about how it runs.
That interview takes an afternoon. It is the highest-value afternoon in the whole build.
One screen per role
A dashboard for everyone is a dashboard for nobody. Each role gets its own view, its own default filters, and its own definition of what counts as urgent.
Every figure clicks through
Tap a total and you land on the rows that produced it. Order numbers, invoice lines, ticket IDs. There is no point in the chain where you have to trust us instead of looking.
A note on what changed
A few sentences each week, written in words rather than tiles. What moved, by how much, and what appears to sit behind it.
Pruned after a month
We look at which views people opened and which they never touched, then delete the dead weight. There is always something to delete. Usually it is something we were proud of.
Traceability is what makes people trust a number
Sooner or later a dashboard shows someone a figure they disagree with. That moment decides whether the thing survives. Either they can click into the number and see the eleven orders that made it up, or they send an email asking where it came from and wait two days for an answer. The first version of that conversation is over in ninety seconds and ends with the dashboard slightly more trusted than before. The second ends with a spreadsheet being rebuilt by hand, quietly, in parallel.
So we treat drill-through as a requirement rather than a refinement. Every aggregate on the screen keeps a path back to the records beneath it. That constrains how we model the data, because summary tables that discard their own detail are cheaper to build and impossible to interrogate. We accept the extra work. It is the difference between a reporting tool and a decoration.
The same principle applies to definitions. Next to each metric sits a plain sentence explaining what it counts and what it excludes, written so that someone outside the team can read it. Half the disputes about numbers turn out to be disputes about definitions that nobody had written down.
What changed since last week, in sentences
Charts are good at showing shape and bad at telling you what to do. A line went up. Fine. Was that one large customer, a pricing change, or the same week last year looking unusually weak? A reader who knows the business can work it out. A reader who has been in back-to-back meetings since Tuesday will not.
That is what the written summary is for. A language model drafts it, but the rules about what counts as notable are set by us with you, and every number in the text comes from the same query that fills the chart rather than from the model doing arithmetic. Where the cause of a movement is visible in the data, the note names it. Where it is not, the note says the driver is not visible here. That sounds like a weaker sentence. It is the reason people keep reading it in month nine. The same machinery drives our automated reporting, which is often the better home for it.
The forty-tile problem
Executive dashboards grow by accretion. Someone asks for a tile in a steering meeting, nobody ever removes one, and eighteen months later the front page has forty. This is not really a design failure. It is a decision that never got made. If everything is on the screen, then nobody had to say out loud which three things the company is being run on, and no one has to defend that choice later.
We would rather ship six numbers that change behavior. Six is not a rule and we have built screens with more. It is a posture: every tile has to earn its place by answering what someone would do differently, and the ones that cannot are written on a list instead of added to the page. Attention is the scarce resource in this entire exercise, not storage and not compute.
The prune after a month is the same argument, applied with evidence instead of opinion. We look at what got opened. Then we say, out loud, that three of the views we built are not being used and should go. Clients occasionally find this uncomfortable. It is much cheaper than the alternative, which is a screen that everyone has learned to scroll past.
What it takes to get there
The visual layer is rarely the hard part. Most of the effort in a dashboard project goes into getting your systems talking to each other and settling what the words mean, which is why data integration usually comes first and takes longer than people expect. We work with the tools you already pay for when that makes sense, and build a custom interface when the interaction you need does not fit one. Once the model underneath is sound, adding forecasting or a trained model on top is a much smaller step than starting one from scratch.
What we won’t do
We won’t build a dashboard on data that is not joined yet
If your CRM and your accounts still disagree about revenue, a dashboard publishes that disagreement faster and in color. We will push for the pipeline work first, even when it means the part you can show people arrives weeks later than you hoped.
We won’t add a tile because someone might want it one day
Every tile spends attention belonging to everyone who opens that screen, forever. We will ask which decision it changes. If there is no answer, we write it on a list and revisit it later rather than putting it on the page to be polite.
We won’t build live refresh for a weekly decision
Real-time pipelines cost more to run and give you more ways to fail. If nobody acts on a number before Thursday, refreshing it every minute does not give you more information. It gives you more chances to worry.
What decision should the screen change?
Tell us who will open it and what they are choosing between. We will say honestly whether a dashboard is the right thing to build, or whether something arriving in an inbox would serve you better.
The visual part is rarely the slow bit. If your data already sits in one place with agreed definitions, a first working version can be in front of people within a couple of weeks. If it does not, most of the elapsed time goes into the pipework underneath, and we will tell you that before you commit rather than halfway through.
Which tools do you build in?
We use what you already pay for where that is sensible, including Power BI, Looker Studio and Metabase, and we build a custom web dashboard when the interaction you need does not fit a standard tool. The decision usually comes down to who needs access and where the data is stored.
What does the AI part actually do?
Two things, mostly. It drafts the plain-English summary of what changed, and it flags figures sitting outside their usual range so a person looks at them sooner. It does not decide what your metrics mean and it does not do the arithmetic. Every sentence it writes points back to rows you can open.
Can our team edit the dashboard afterwards?
Yes. We hand over the data model and the metric definitions in writing and set things up so your team can add views without calling us. Many clients keep us on for the pipeline work and take over the visual layer themselves within a few months.
