You're deciding by gut because the numbers live in 6 tools: what it costs (and how to get ONE dashboard you actually open)

The Monday morning when nobody can answer

It’s 9:10 on Monday. You walk in, put down the keys, and before coffee you ask the most normal question in the world: “how did last week go?”. Silence. Then the carousel starts. Someone opens the ERP/gestionale, someone else downloads the extract from the e-commerce, the admin lead says “wait, I’ll send you the file”, and meanwhile someone is looking at the banking app “to get a sense of it”. After twenty minutes you have three different numbers and nobody willing to put their name on any of them.

This is not a people-being-lazy problem. It’s that a real business dashboard — the one the owner opens alone, in ten seconds, without asking anyone for anything — you don’t have. You have data in too many tools that don’t talk to each other, and every question becomes a small investigation. This piece is for you if you’re an owner or a director who decides with last month’s numbers because yesterday’s don’t exist yet in one place.

I’ll tell you right away where I want to land: you don’t need “another piece of software”. You don’t need a Power BI course. You need a product: one screen, built on your data, that answers the three or four questions that actually matter. And you need someone who builds both the data underneath and the interface on top, because if those are two different vendors the project dies. Let’s start from the pain, because the pain has a price in euro and it’s worth knowing it.

Where the numbers ended up

Let’s do the inventory, the real one, the one nobody ever writes down. In a company with a few million in revenue, the numbers you need to decide usually live here:

The gestionale / ERP — revenue, orders, warehouse, often with definitions all its own.
The e-commerce (Shopify, WooCommerce, a custom B2B) — online orders, returns, carts.
One or more Excel sheets — the “real” ones, where the bookkeeper manually patches what the ERP/gestionale gets wrong.
The ads platform (Meta, Google) — how much you spend to bring in traffic.
The current account / home banking — the actual collections, which never match the invoices.
The sales reps’ heads — the pipeline, the promises, “that one will sign by month-end”.

Six sources. Six truths. And the problem is not that one of them is wrong: it’s that each one has a different definition of the same words. What is a “sale”? The order received, the invoice issued, or the payment that arrived? Do you take the return off the day it was sold or the day it comes back? Do you count IVA/VAT or not when you say “we did 40,000”? As long as these definitions live in people’s heads and not written down somewhere, every meeting starts from zero.

That’s why searching “small business intelligence” on Google leads to dozens of tools that solve nothing: the tool assumes the data is already clean and agreed. It isn’t. The real work is under the dashboard, not in the dashboard.

The cost of inertia: what it really costs you not to have a dashboard

“Fine, we’ll make do”. Sure. But inertia isn’t free — it only looks free. Let’s put some numbers on it — declared as estimates, not as absolute truth, but honest estimates you can check in your own company.

First line: the hours. How many people, how many times a week, “pull the numbers” by hand? Let’s do the minimum count for a small company:

Recurring manual activity	Who	Frequency	Time/instance	Hours/month
“Give me the sales summary”	Admin	2 times/week	90 min	~13
Reconcile Excel vs ERP/gestionale	Admin	weekly	120 min	~9
Report for the owner	Controller/external	monthly	1 day	~8
Numbers for the sales meeting	Sales	weekly	60 min	~4
Total				~34 hours/month

Thirty-four hours a month of qualified work spent copy-pasting and arguing over totals. At a fully loaded cost of 25–35 €/hour, that’s 850–1,200 € a month, meaning 10,000–14,000 € a year, just to produce numbers that are already old when they arrive. And you haven’t decided anything yet: you’ve only compiled them.

Second line: the wrong decisions. You don’t measure this in hours, you measure it in mistakes. A warehouse reorder done on last month’s numbers, while a product has already stopped selling. A discount granted “because they seemed like a good customer” when the data would say the opposite. A hire decided by gut on a trend that later turns out to be seasonal. One of these a year is enough to burn far more than the 14,000 € in hours.

Third line: speed. Deciding well into the month is deciding on the past. The competitor who sees yesterday’s numbers course-corrects in three days; you notice at month-end, when the damage is done. This advantage never shows up on the P&L as its own line, but it’s the most expensive of all.

If you add up only the first line, a dashboard that pays for itself in twelve–eighteen months is not a luxury: it’s ordinary maintenance for a company that wants to stay on its feet. And if this sounds abstract, there’s a twin article that starts from the owner’s literal question — “how much did we sell yesterday?” — and shows why even ten minutes of waiting is already too much.

One wrong decision is worth more than a year of hours

We’ve counted the hours. But the most expensive line is invisible: the decision taken on the wrong number. A concrete example, with sums you can redo on your own company.

Take a product that sells well, 30% margin. The “official” data you look at is two weeks old, when the product was still moving. Meanwhile the pace has dropped 40%, but you don’t see it. Here are the three typical forks where old data makes you get it wrong:

Scenario	What you “see” with old data	What actually happens	Typical cost
Overstock	“it’s flying, reorder”	capital tied up, then clearance at zero margin	thousands of € per single reorder
Missed sale	“everything stable”	you reorder late on what is accelerating, sales lost	margin lost + customer who goes elsewhere
Useless discount	“important customer”	discount given to someone who would have bought anyway	margin given away on every order

One of these episodes a quarter is enough, on its own, to exceed the 10,000–14,000 € of hours per year. And here’s the point the spreadsheets hide: the mistake doesn’t leave a trace in accounting labelled “decided on old data”. It disappears into the noise, and next year you do it again. A dashboard with an anomaly alarm — “this product is at −40% for three days” — lets you see the fork before you take the wrong road. It doesn’t guarantee the right decision: it guarantees you take it on the present and not on last month.

“But we already have Power BI” (and nobody opens it)

Here comes objection number one. “Look, we already have the dashboard. The consultant built us Power BI two years ago.” Perfect. Open it now. When did you last update it? Who looks at it every morning? In most cases the answer is: nobody, for months.

It’s not Power BI’s fault — it’s a solid tool. It’s that they delivered you a tool, not a product. The difference is all here:

A tool is powerful and generic: it can do a thousand things, but someone has to configure it, update it, and above all keep the data connections alive. When a field changes in the ERP/gestionale, it breaks in silence. Nobody notices until the number is blatantly absurd.
A product does a few things, always, reliably. It opens by itself, the data is already there, and if something doesn’t add up it tells you with an alarm instead of showing you a wrong chart with a straight face.

The dashboard nobody opens almost always has three defects: it’s too full (twenty charts, zero decisions), it’s stuck (the data is from when the consultant built it), and it’s fragile (one source changes and everything breaks without warning). A business dashboard built as a product is born with the opposite obsession: few metrics, always fresh, and they shout when something is broken.

“We already have Excel”: why the sheet beats ugly software (and where it collapses)

The other honest objection is: “I get on just fine with Excel”. I believe you, and I’ll tell you something few vendors admit: Excel is often right. It’s immediate, it doesn’t force you to learn anything, and it does exactly what you want. ERP/gestionale software “with a dashboard” loses to Excel and to WhatsApp because it’s slower and uglier to use. If your new product is worse than the sheet, people go back to the sheet, period.

Excel collapses at three precise points, and those are the three points where you actually need a product:

When the data comes from more than one source. A sheet someone has to fill by hand every week is a time bomb: sooner or later a week gets skipped, then the meaning gets skipped.
When the same truth is needed for more than one person. Three sales reps with three “their” files are not a dashboard, they’re three opinions.
When you need a reliable history. “How was this month a year ago?” — with monster-sheets copied every time, the answer is a lottery.

The healthy rule is: if your problem is one person, one source, one moment, keep Excel and don’t let anyone sell you anything. If your problem is multiple sources, multiple people, every day, then the sheet has become the bottleneck and a product pays for itself.

What the owner must see in twenty seconds (the screen)

Now the concrete part: what a business dashboard the owner actually opens looks like. I’ll describe it in words, because the value isn’t in the technology but in what you see the moment you open it.

Imagine opening it from your phone, in the car, at 8 in the morning. The first screen doesn’t have twenty charts. It has four big numbers, at the top, each with a comparison arrow:

Sold yesterday — next to it “yesterday of last week” and the variation in percentage. One colour: green if on track, yellow if below, red if well below.
Sold this month vs the same period last month — not the finished month, the month up to yesterday compared with the same number of days.
Collected vs invoiced — the gap that tells you whether you’re selling or just issuing paper.
One alarm — “attention: sales of product X are at −40% for three days” or “a regular customer hasn’t ordered in two weeks”.

Below, scrolling, you find the detail: sales by channel (store, web, agents), the top ten products, the top ten customers, and the cash expected in the coming weeks. But the point is the first screen: in twenty seconds you know whether to sleep easy or pick up the phone. That’s the product. Not “the data”. The decision.

Notice something that looks trivial and isn’t: nothing to fill in. There’s no file to open, no sheet to update, no person to call. The dashboard is already ready when you open it, because overnight it already did the work. That’s the difference between something you use every day and something you “should look at more often” and never look at. And the colours aren’t decoration: they’re a language. Green means “don’t think about it”; yellow means “keep an eye on it”; red means “today someone has to deal with this”. An owner shouldn’t read the dashboard, they should look at it and understand at a glance where their attention is needed.

And there’s one thing a screen like this does that a file will never do: it alerts you without you asking. The inertia of spreadsheets is that you have to remember to look at them. A real dashboard sends you the notification when yesterday was anomalous, so you see the problem on Tuesday and not at month-end. If you want to see what work done this way actually looks like, take a look at the projects in the portfolio: they’re not slides, they’re things that run.

The four questions a dashboard must be able to answer

Before filling a screen with charts, there’s a question upstream: which decisions does this dashboard take? A dashboard that doesn’t change any decision is a poster. In 90% of SMEs the questions that actually matter are four, and every single metric should hook onto one of these:

Are we selling enough? — yesterday’s sold and the current month, compared with the same period before. Not annual revenue: the pace now.
Are we collecting what we sell? — cash. Selling and not collecting is the most elegant way to go under with a full calendar.
What is changing right now? — trends and anomalies. A product dropping for three days, a regular customer disappearing, a channel slowing down.
Where is the problem or the opportunity? — the detail: which channel, which product, which customer. The big number tells you that something is there; the detail tells you where to look.

Everything else — the twenty metrics the template stuffs in — is noise until it answers one of these four. It’s the same mistake as whoever optimises the wrong metric: the dashboard is all green and the bank account is red, because you’re looking at visits instead of margin. Better four numbers you decide on than forty charts you just look at.

The sources, one by one: what connects (and what makes you sweat)

“But can my data actually be connected?” Almost always yes, but with very different degrees of difficulty. It’s worth knowing in advance where it will be easy and where you sweat through your shirts, because that’s where the time (and the budget) goes.

Gestionale / ERP — usually the central piece. If it has an API or a queryable database, great; otherwise you work with a nightly export. The real difficulty isn’t technical, it’s semantic: understanding how that ERP/gestionale names things, where returns end up, how it treats giveaways and credit notes.
E-commerce — normally the gentlest: Shopify, WooCommerce and serious B2B setups have clean APIs. The attention goes to duplicates (the online order that also lands in the ERP/gestionale) so you don’t count the same sale twice.
Bank / collections — often the most stubborn. Between statements in different formats, PSD2 and reconciliations, connecting real cash takes patience. But it’s also the source that tells you the most uncomfortable truth: how much of what you invoice you’ve actually collected.
Ads platforms — APIs available, but with definitions all their own (a “conversion” for Meta is not a sale for you). They have to be hooked up with judgement, otherwise you mix apples and oranges.
Excel sheets — they connect, provided they stop being the place where numbers get patched and become a controlled source, with a fixed structure. A free-form sheet that changes columns every month is not a source: it’s a problem that comes back.

The message for you is simple: before you fall in love with the screen, the right question to the vendor is “how do you connect my sources and what do you do when one of them changes?”. If the answer is vague, the project will be vague.

The single number: why definitions get signed

I’ll come back for a moment to the most boring piece, because it’s the one that makes the difference between a dashboard and an endless argument. Take the word “revenue” (fatturato). Admin means the taxable amount. Sales means the value of signed orders, IVA/VAT included, returns excluded. The warehouse thinks in the value of what went out. Three different numbers for the same word, and as long as they stay in people’s heads, every meeting is a small trial.

The solution is not software: it’s a decision, put in writing and signed. “In our dashboard, sale = invoice issued, IVA/VAT excluded, return deducted on the order date.” Done. From that moment there is one number, and whoever disagrees argues the definition, not the chart. That’s why a serious dashboard starts from the definitions and not from the colours: without the single number, the most beautiful dashboard in the world becomes just a more expensive way to argue. It’s the same principle that leads so many companies to discover they’re optimising the wrong metric — green on the screen, red at the bank — because they never decided what they were actually measuring.

Who builds the data underneath and who designs the interface (if they’re two vendors, it fails)

Here’s the point almost nobody tells you, and it’s the reason so many SME sales dashboard projects end up in a drawer. A real dashboard is made of two layers:

The data layer — taking the numbers from six sources, cleaning them, agreeing the definitions (“sale = invoice issued, IVA/VAT excluded, return deducted on the order date”), keeping them updated every night, and noticing when a source changes.
The interface layer — the screen that opens in twenty seconds, the alarms, the right colour, the thing that works from the phone too.

When these two layers are done by two different vendors, the worst thing in the world of projects happens: they blame each other. “The number is wrong” → “no, the data they pass me is wrong” → “no, it’s the dashboard that displays it badly”. And you, in the middle, pay two invoices for a dashboard you don’t use. The data vendor says you’re right, the interface one does too, and meanwhile months go by: each one has fixed “their part”, but their part is not your product. The product is the entire chain — from the raw number in the ERP/gestionale to the coloured arrow on your phone — and a chain only makes sense if someone is accountable for the whole chain.

The reason I insist on someone who does data + backend + interface together is not a commercial tic: it’s that the data definitions and the way you show them are the same decision. Whoever designs the screen must know what a sale is; whoever cleans the data must know what the owner will see at 8 in the morning. If you split them, you split the product. It’s the exact same reason why hiring a data analyst alone doesn’t fix the sources: the capable person drowns in data cleaning and never gets to building something that gets used.

A typical case, no names and no fairy tales

I’ll describe a typical profile — architectural, no names and no invented revenues, because fairy tales with the famous-client logo we leave to others.

Distribution, three channels: a physical store, an e-commerce and a network of agents. Before: the owner asked for the numbers on Monday, admin spent half a day putting them together, and anyway the agents channel arrived a week late because it went through spreadsheets sent by email. Stock was the real disaster: the site was selling what the store had already sold, with returns, apologies and angry customers.

What was done, in layers. First the definitions: a sale is the invoice, IVA/VAT excluded, with the return deducted on the order date; a stock level is the real remainder minus what’s committed. Then the pipeline: every night the three channels flow into one place, with an alarm if a source doesn’t arrive. Then the screen: four numbers, a traffic light on critical stock, the detail by channel.

After: the owner opens the dashboard from the phone at 8, admin no longer compiles the Monday summary, and above all the site stops selling what isn’t there. It isn’t magic: it’s having agreed the definitions and having kept data and interface together. The value wasn’t “the dashboard”: it was stopping paying the inertia week after week.

And a note that matters: the first two weeks of bedding-in were “hate”, because the dashboard showed that two “historic” products were actually losing margin — an uncomfortable truth the spreadsheet was hiding. That’s exactly the sign that it works. A real dashboard, every now and then, proves you wrong: and that’s where it earns its money.

What is NOT included (because it isn’t magic on dirty data)

Now the honest part, the one that tells you whether you have a serious vendor in front of you or a dream-seller. A real dashboard does not do these things:

It doesn’t fix dirty data by magic. If in the ERP/gestionale the same items are entered in five different ways, someone has to decide the rules. The software can help, but the decision is yours.
It doesn’t guess the definitions. “Sale”, “active customer”, “margin”: we put these in writing together, at the start, before writing a line. It’s the most boring piece of work and the most important.
It isn’t real-time to the second (and you almost never need that). Updated every night, or every hour, is fine for deciding. True “real time” costs ten times as much and is useful to very few.
It doesn’t maintain itself. Sources change, the business changes, the questions change. A dashboard is a living product, not a deliver-and-run.

If someone promises you “we load your data and in a week you have everything”, they’re describing a demo, not a product. The demo works on fake data. The product works on yours, which is dirty, and that’s where the work is.

What a serious project includes (and what is fluff)

When you sign a dashboard, what are you actually buying? Here’s the list of what a serious project includes — and what isn’t in the three-thousand-euro quotes:

The definitions analysis put in writing, not “verbally”.
The connection to the sources with error handling: what happens when a source doesn’t respond.
The history rebuilt, not only “from today onwards”.
The alarms on data breaks: a silent source generates a notification, not a wrong number with a straight face.
The mobile screen, not only desktop.
The ownership of the code, the credentials and the data: all yours, no lock-in.
The living documentation and a handover done for real.
A bedding-in period and a declared maintenance.

And here’s what is fluff, the signals that you’re buying a demo dressed up as a product:

“We load the data and in a week it’s ready” (they’ve just skipped the analysis).
A beautiful dashboard built on the vendor’s sample data.
Not a word about what happens when a source changes.
The code “stays ours” or only runs on their account.
Accuracy promised “at 99%” without explaining on what.

The rule: if the quote doesn’t name the definitions and the maintenance, it isn’t a quote for a product. It’s for a poster with numbers on it.

Honest timeline: what happens and when

No magic number, but honest ranges for a small-to-medium company with the sources I listed above.

Phase	What happens	Indicative time
1. Definitions & sources	We put in writing what counts as a sale, which sources, which accesses	1–2 weeks
2. Data pipeline	We connect the sources, clean, build the history, put alarms on the breaks	3–5 weeks
3. The screen	We build the dashboard that opens in 20 seconds, first on desktop then on mobile	2–4 weeks
4. Bedding-in	You actually use it, we adjust definitions and views to what you really need	3–4 weeks

In practice: from a useful dashboard in 6–8 weeks, to a bedded-in product in three–four months. Whoever tells you “two weeks” is selling you phase 3 skipping 1 and 2 — and that’s exactly why that dashboard will end up in a drawer.

The after counts as much as the during: a dashboard lives if someone owns it. Budget for maintenance (typically 15–25% of the project per year) to keep the connections alive, add a view when a new question appears, and fix things when a source changes. A product without maintenance is a product that dies in instalments.

How you actually start: the first 30 days

If we decided to start on Monday, the first thirty days are not “development”. They’re the part that saves the project:

Week 1 — map of the sources and the accesses, and the list of questions the dashboard must answer (the four above, dropped onto your business).
Week 2 — the definitions in writing, signed: what is a sale, an active customer, a stock level. Here you argue a bit, and that’s healthy.
Week 3–4 — the first connection to one or two sources and a raw but real screen, on your data, not on sample data. Better an ugly dashboard with the right numbers than a beautiful one with fake numbers.

At the end of the first month you don’t have the finished product, but you have the thing that matters: the certainty that the numbers are right and shared. From there on it’s almost all downhill, because the hard piece — agreeing on reality — is done.

It’s for you if / it isn’t for you if

I’ll spare you the sales pitch and give you the honest filter.

It’s for you if:

You take decisions on numbers, but the numbers arrive late, from different sources, and they disagree.
You’ve already tried with a dashboard that nobody opens anymore.
You (or your team) spend hours every week compiling summaries by hand.
You have more than one sales channel and no place to see them together.
You want the advantage of yesterday’s numbers to be yours and not the competitor’s.

It isn’t for you if:

You have a single, simple source, and Excel really is enough (good, keep it).
You’re looking for a one-off report for the bank, not a daily steering tool.
Your data doesn’t exist yet: if you’ve been selling for three months without an ERP/gestionale, we fix that first.
You want “the AI that decides in my place”. AI here cleans and flags; the decisions, luckily, stay yours.

The two objections that remain

Two honest objections remain, and I hear them practically always.

“The accountant (commercialista) gives me the numbers.” Yes, at month-end or quarter-end, and they’re tax numbers, not management numbers. The commercialista tells you how it went; a dashboard tells you how it’s going, while you can still change something. They’re two different jobs: one looks backwards for the tax office, the other looks at yesterday to decide today. They don’t exclude each other — but don’t confuse them, because deciding the reorder on the commercialista’s numbers is like driving looking in the rear-view mirror.

“Let’s wait until we’re bigger.” It’s the most expensive mistake, because data confusion grows with you. The longer you wait, the more sources you add, the more dirty history you accumulate, the more the day you put things in order costs. The right moment for the first dashboard isn’t when you’re big: it’s when you stop being able to answer in your head the question “how are we doing?”. If you’re asking yourself that while you read, the moment is now — and you start small, with the four metrics that matter, not with the multinational-scale project.

Questions owners ask me before starting

How much does a business dashboard cost, in order of magnitude? It depends on the number of sources and how dirty they are, but for an SME with the typical sources we’re in the order of a project from a few thousand to a few tens of thousands of euro, plus annual maintenance. The real variable isn’t the screen: it’s the data cleaning. The less dirty they are, the less it costs.

Do I have to change the ERP/gestionale? Almost never. A good dashboard reads from the gestionale you have, it doesn’t replace it. If someone proposes rebuilding the ERP to give you a dashboard, run.

How long until I see it working? A first useful dashboard in 6–8 weeks, bedded-in in three–four months. The longest and most valuable phase is agreeing the definitions at the start.

And if my data is a disaster? That’s the norm, not the exception. Part of the work is precisely deciding the rules to clean it. But nobody can invent data that doesn’t exist: if a piece of information isn’t collected anywhere, it has to be collected first.

Why don’t I just do it with Power BI / Looker / a tool? Because the tool is the upper layer. You need someone who also builds the lower layer (clean data, updated, with the alarms) and who holds the two things together. The tool on its own is the dashboard nobody opens.

Do I need to hire someone? No, and often it’s counterproductive. Hiring a junior analyst doesn’t fix the sources: they spend the first month cleaning data and never get to the product. First you build the system, then eventually someone watches over it.

Do the data stay mine? Yes, and they must. Code, pipeline, definitions and infrastructure stay yours. No vendor lock-in: if tomorrow you want to change vendor, you take everything with you.

Does it work from the phone? It has to. The moment you look at the dashboard is often the morning in the car or the evening after dinner. If it doesn’t work well from the phone, you won’t open it.

How often does the data update? To decide, the night before is enough, sometimes every hour. “Real time to the second” costs a lot more and is useful to very few: if they propose it as standard without explaining why, that’s a warning bell.

Who uses it in the company besides me? Ideally a few roles with different views: you see the overall picture, the sales lead sees theirs, admin sees cash and overdue. Same definitions, different views. A dashboard that everyone sees identically often nobody opens, because it doesn’t speak to anyone in particular.

And if I change ERP/gestionale or e-commerce in a year? You update the connection to that source, you don’t throw away the dashboard. That’s another reason why ownership of the code and the definitions must be yours: you’re the one who decides when and how to change the pieces, without starting from zero.

The point, in one line

You’re not missing another piece of software. You’re missing a business dashboard built as a product: few metrics that matter, always fresh, on your data finally agreed, with someone who holds together the data layer and the interface layer. It’s the difference between deciding on the past and deciding on yesterday.

If you want to go deeper on a specific piece of this thread — the reports that arrive late, the KPIs that don’t match between departments, the consolidation of multiple sites — I’ve collected them in the guide to dashboards and data products. And if you recognised yourself in that opening Monday morning — the simple question, the twenty minutes, the three different numbers — you’re already paying that cost, only it isn’t on any invoice: it’s in the hours, the mistakes and the decisions taken in the dark. If you want to understand what solving it for real would look like, look at the projects I’ve built or drop me a couple of lines: we start from your numbers, not from a demo.