One number per question, and everyone gets the same one.
Dashboards and reports built on a modelled, tested data layer — so the revenue figure finance sees is the one sales sees, the board pack builds itself, and the questions nobody could answer get answered.
- Questions first
- Model and test
- Dashboards
- Operate and extend
The test of a dashboard is whether a meeting ends sooner because of it.
Most companies do not lack dashboards. They lack dashboards that agree. Sales reports one revenue, finance another, the board pack a third, and the meeting that was meant to decide something spends its time deciding which number is right. The cause is never the chart; it is the absence of a modelled layer underneath where each metric is defined once, tested, and owned.
We build that layer first and the dashboards second. Metrics are defined in code with their business rules written next to them, tested on every change, and served to whichever tool your people already use — Power BI, Looker, Metabase, a spreadsheet, an API. The dashboards on top are deliberately few and deliberately simple: the numbers decision-makers look at every week, with the drill-down that explains a change.
That is what we build for.
Four layers between raw data and a decision.
Each layer is tested and documented, so the number on the screen can be traced back to the rows it came from.
Pipelines and warehouse
Data from your systems — ERP, CRM, platforms, spreadsheets that will not die — landed reliably in a warehouse with lineage, freshness checks and alerts. Built with our data engineering practice.
The metrics layer
Every KPI defined once, in code, with its rules and its owner: what counts as revenue, when a customer is active, how a shipment is late. Tested on every change, versioned, and served to every tool from one place.
Dashboards and reports
Executive, operational and self-service views designed around the decisions they serve, in Power BI or the tool you already own. The board pack generated, not assembled.
Embedded and operational analytics
Analytics inside the applications where decisions are made — a dispatcher's screen, a programme owner's console — and the alerting that tells someone when a number moves before the weekly meeting.
How the work runs, day to day.
Define each metric once, test it, show its lineage.
A metric is code: its SQL, its business rules, its owner and its tests live together, and every dashboard reads it from the same place. When finance asks why revenue changed, the answer is a lineage graph from the chart back to the source rows, not a meeting. When a rule changes, the change is reviewed like code, and every dashboard updates at once.
- One definition per metric, versioned and reviewed
- Tests on freshness, volume and business rules, run on every change
- Lineage from any number on any dashboard back to the source
- 01Source
- 02Pipeline
- 03Model
- 04Metric
- 05Dashboard
The number is defined once, at the metric layer
How the work runs.
Questions first
The decisions and the questions behind them, collected from the people who make them. The metrics list and their owners come out of it, with the sources mapped.
Model and test
Pipelines, the metrics layer and its tests. The first metrics reconciled against the numbers finance already trusts.
Dashboards
The views that serve the decisions, in your tool, reviewed with their users. Self-service enabled on the certified models.
Operate and extend
Monitoring, new metrics by request, regular review, at a rhythm agreed with you, of what is used and what is not — unused dashboards are retired.
What you keep.
- A tested metrics layer with definitions, owners and lineage
- Pipelines with freshness and volume monitoring
- Dashboards in your tool, designed around decisions
- A generated board pack
- Documentation and training for analysts and owners
When this is the right call.
Choose this when meetings argue about numbers, when the board pack takes a week to assemble, or when a question the business keeps asking still has no reliable answer.
Look elsewhere if the data does not exist yet — the first job is capturing it in the systems — or if you need a data platform rebuilt from the ground up: start with data engineering.
Frequently asked questions
Services that pair with this.
Which number does your team argue about?
Tell us the metric and who uses it. An engineer reads it and replies in writing with a view of what it would take to make everyone see the same one.