Business intelligence
Reporting nobody has to argue with
You get metrics with one agreed definition, and numbers you can trace back to source. When the data stops arriving, you hear about it.
The short version
4 things that decide this
- 01Most business intelligence projects fail on definitions rather than on tools, because two teams counting revenue differently will disagree in any dashboard you buy them.
- 02A number nobody can trace back to a source record gets quietly distrusted, and a distrusted dashboard is worse than none because people build private spreadsheets instead.
- 03The silent failure mode in reporting is a pipeline that stops without complaining, so every dashboard we build says when its data last arrived.
- 04Buying a bigger BI licence rarely fixes a reporting problem, and we will tell you when the tool you already own is enough.
Two dashboards, two revenue figures, one very awkward meeting
Everybody in the room has a number and none of them match. Finance counts revenue when the invoice is paid. Sales counts it when the deal closes. Both are defensible, and the meeting is now about arithmetic instead of the business.
Technically nothing is broken. Both pipelines ran, both queries are correct. The disagreement is upstream of every tool you could buy, and no BI platform will resolve it for you.
What happens next is the real damage. People stop trusting the dashboard and rebuild their own view in a spreadsheet. Six months on you are paying for a platform leadership does not open. The numbers in the board pack came from somebody's laptop.
What is running now
Counted, not estimated
22
production systems we have shipped and can name
5
permission tiers in TankAware's multi-site reporting
4
distinct roles reporting through TrialTriage's platform
38+
countries Broollie reports across
What a reporting build actually needs
The chart is the last thing we make. These come first.
A written definition for every metric that matters, agreed by the people who disagree about it today, stored where anyone can look it up.
A traceable path from any figure on screen back to the records that produced it, so a challenge takes minutes instead of a week.
Freshness on the face of the dashboard, showing when the data last landed, because a stale number looks identical to a current one.
Alerting on the pipeline itself, so a failed load pages somebody rather than waiting for a director to notice a flat line.
Access rules that match your organisation, so a site manager sees their site and a group director sees all of them.
A handover written for your team, or an agreed service level where we keep running it.
What we will talk you out of
- A warehouse, where three well-modelled tables and your existing database would answer every question you actually asked.
- A dashboard for a decision nobody makes on a repeating basis.
- Migrating BI tools before the definitions are agreed, which moves the argument rather than settling it.
- Agree the definitionWritten down, owned by a person.
- Land the dataFrom the systems of record, on a schedule.
- Model it onceOne table everyone reads from.
- Check it arrivedFreshness and row counts, alerted.
- Show itIn the screen where the decision happens.
- Trace it backAny figure, back to source records.
The first station is the one that gets skipped, and it is the only one that cannot be fixed later with engineering. Definitions are a management decision wearing a technical costume.
Getting two directors to agree what a customer is
Ask five people in your business what counts as an active customer and you will get four answers and one argument. Is a paused account active? A trial? A parent company with six branches, or six customers?
There is no technically correct answer. There is only the answer your business picks and then applies consistently. We run that session, write the decision down, and build to it. Where two teams genuinely need different views, we name both metrics separately rather than letting one word carry two meanings.
- Each metric has one owner, by name, who decides when the definition changes.
- Two legitimate definitions get two names, never one contested name.
- A definition change is dated, so last quarter's board pack still reconciles.
- The definition sits next to the number on screen, not in a document nobody opens.
What we build on
Data
Pipelines
Presentation
Run
Systems where leadership had to trust the number
WAIQ
Business operations and execution platform for multi-site organizations.
Read the case study →
TankAware
AI + IoT petroleum site management for Sutherland Excavating Ltd.
Read the case study →
ExtraaJe
Gamified employee rewards platform for a European workforce.
Read the case study →
PremiumAudit.io
AI automation for smarter insurance premium audits.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual BI project against ours
Both deliver dashboards. They separate the first time somebody challenges a figure in a meeting.
| Criterion | The usual approach | How we build |
|---|---|---|
| Where it starts | Choosing a BI tool. | Agreeing definitions, with the people who disagree in the room. |
| When a number is challenged | An analyst spends a week reconstructing it. | Trace it to the source records while the meeting is still running. |
| When a pipeline fails | The chart flattens and nobody notices. | An alert fires, and the dashboard shows its own staleness. |
| Two teams, two definitions | One wins, the other keeps a spreadsheet. | Two named metrics, both correct, neither hidden. |
| Who it is built for | Whoever commissioned it. | The person making the decision, in the screen they already use. |
| After launch | The contract ends at go-live. | An agreed service level, or a documented handover to your team. |
01Our two systems report different revenue. Where do we actually start?
Start with the definition, not the data. In almost every case both systems are computing correctly and measuring different events, so no amount of pipeline work will reconcile them. We get the owners in one session, write down which definition the business uses, and only then decide what to build.
02Do we need a data warehouse for this?
Less often than vendors suggest. Plenty of companies get everything they need from a few well-modelled tables in the database they already run. A warehouse earns its keep when you have many source systems, real volume, or history you cannot query from production without hurting it.
03Can you work with the BI tool we already pay for?
Yes, and that is usually the cheaper answer. The value we add sits underneath the tool: agreed definitions, reliable pipelines, and a model your reports can share. Swapping tools before that work is done tends to reproduce the same disagreements in a new interface.
04How do we find out a report has stopped updating?
The dashboard tells you, and an alert reaches a person. Every build shows when its data last arrived. The pipeline raises an alarm when a load fails or the row count falls off a cliff. Silent staleness is the failure mode that quietly destroys trust in reporting.
05Who can see what once the data is in one place?
Access is designed with the reporting, not bolted on afterwards. TankAware runs five permission tiers so a contractor, a site manager and a company admin each see their own scope. Consolidating data without deciding who may read it is how a reporting project becomes a security problem.
06How long before we can trust the numbers?
Trust arrives when the first challenged figure gets traced to source in front of the person challenging it. That moment does more than any amount of documentation. We aim the first slice of work at the metric your leadership argues about most, for exactly that reason.
07Is this worth doing for a startup, or only at enterprise scale?
A startup usually needs three trustworthy numbers rather than a platform, and that is a small, honest project. The cost of getting it wrong is the same at both sizes: decisions made on a figure nobody checked. Enterprise buyers get the same definitions work plus access control and audit expectations.
08What does a BI engagement cost?
The drivers are how many source systems must agree, how bad the definition disagreements are, and whether anyone owns the result afterwards. Scoping conversations cost nothing. Where we have to go inside an existing codebase to answer honestly, a paid two-week diagnostic comes first. The number it produces is one we can hold.
Related
- Data engineering →The pipelines underneath the reporting.
- Predictive analytics →When you need an estimate rather than a report.
- Machine learning development →Where a model beats a rule, and where it does not.
- Postgres vs MongoDB →The storage decision underneath most reporting builds.
- Custom software development →When the reporting has to live inside a product.
