Most ERP dashboards are built, admired once, and never opened again. The ones that survive have a specific property: someone opens them before a recurring meeting, and what they see changes what they do.
We have built a lot of dashboards. The ones still in daily use two years later have very little in common visually, but they share a design principle — they were built backwards from a decision rather than forwards from available data.
Start from the decision
The wrong question is "what data do we have?" The right one is "what decision does someone make every week, and what would they need to see to make it faster or better?"
A finance director deciding which overdue accounts to chase this week needs four things: who owes, how much, how long overdue, and whether they have paid late before. That is a dashboard. A screen showing every receivables metric available is a report, and reports get exported to Excel and then ignored.
What belongs on an executive dashboard
In our experience, four things. More than that and it stops being scanned.
- Cash position — actual, plus committed outflows for the next thirty days
- Receivables ageing — with the five largest overdue accounts named, not just bucketed
- Margin by line — product, service or project, whichever your business actually manages
- Pipeline — weighted, by stage, with movement since last week
Everything else belongs on an operational dashboard for the person who owns that function. The warehouse manager needs stock accuracy and pick times; the finance director does not.
A test worth applying. For each metric, ask: if this number moved sharply, would someone do something differently tomorrow? If not, it is context rather than a dashboard item. Context belongs in the monthly pack.
Trust is the whole game
A dashboard nobody trusts is worse than no dashboard, because it generates arguments about the numbers instead of decisions based on them.
Trust comes from three things. The data is live rather than synchronised overnight. The definitions are documented, so "revenue" means the same thing to sales and finance. And the figures tie to the statutory accounts — if the dashboard says one thing and the P&L says another, the dashboard loses.
This is why we build reporting inside the ERP itself rather than in a separate BI tool wherever possible. One database, one version of the truth, no synchronisation to explain.
Do you need a separate BI tool?
Usually not. Odoo's own reporting handles pivot analysis, filtering, grouping and graphing without another licence, another login, and another system whose numbers you have to reconcile.
A dedicated BI platform earns its place when you genuinely need to blend Odoo data with substantial external sources — a warehouse management system, a manufacturing execution system, years of historical data from a system you no longer run. That is a real requirement and we will tell you when you have it. It is less common than the vendors of BI platforms suggest.
Build it so the team can change it
The most reliable predictor of a dashboard surviving is whether the people using it can modify it. If every change needs a support ticket, reporting stops evolving the moment the project ends — and the business does not stop evolving.
We train finance and operations teams to build and adjust their own views. It reduces our support revenue and it is the right thing to do.
What this looks like in practice
Our dashboards and BI work typically sits alongside an implementation rather than as a separate project — the reporting is designed while the processes are being configured, because that is when you learn what people actually need to see.
Where a client already runs Odoo, it is often the fastest way to get more value from what they have.
Have data but not visibility?
Thirty minutes to look at what decisions your team makes weekly and what would make them faster.
Book a discovery call