A real-time dashboard for a sales team: what real means

"Real-time" is the most expensive word in a dashboard brief, and it is usually the wrong one. What a sales team almost always means is that the numbers should be current when they look, not stale from last week. That is a solved, cheap problem. Genuinely live, updating-as-you-watch data is a different system with a different cost, and paying for it by accident is the most common way these projects overspend.

So the first job is not to build anything. It is to find out which of the two the team is actually asking for, because the honest answer changes the budget by an order of magnitude.

Current versus live

A current dashboard refreshes on an interval. You open it and the numbers reflect the last few minutes, which for a sales team watching a day unfold is indistinguishable from live. A live dashboard pushes changes the instant they happen, so a number ticks over while you are looking at it. The second is genuinely useful in a few settings and pure cost in most.

The open-source tools make the cheap path concrete. Metabase's own documentation offers dashboard auto-refresh at 1, 5, 10, 15, 30 and 60 minute intervals, and warns that each refresh re-runs every query on the dashboard. That warning is the whole cost model in one sentence: refresh is not free, it is a query bill you choose the size of.

What the refresh interval actually costs

The interval you pick is a direct trade against database load. A dashboard set to refresh every minute runs all of its queries every minute, whether or not anyone is looking and whether or not anything changed. On a busy database that is a real load, and it competes with the application the sales team uses to do the work.

For most sales teams a five-minute refresh is the right default. It is current enough that nobody notices the gap, and it cuts the query load to a fraction of what a one-minute interval demands. Metabase's documentation makes the same point from the other direction, suggesting that a dashboard past about ten cards should probably be split in two, because every card is another query on every refresh.

The numbers a sales dashboard should carry

A dashboard is only as useful as its restraint. The failure mode is putting every available metric on one screen, at which point nobody reads any of them. A sales dashboard that gets looked at usually holds a small set:

• Pipeline value by stage, so the shape is visible at a glance.
• Activity against target for the current period, not all of history.
• Deals that changed stage today, which is the closest thing to genuine live value.
• A small number of leading indicators, chosen because they predict the lagging ones.

Notice that only one of those needs anything near real-time, and even it works on a five-minute refresh. The rest are current-enough by nature. This is the same discipline as any reporting build: the point is the decision the number drives, which is the argument in automating manual reporting without buying a BI platform.

When live is genuinely worth it

The pattern is clear: live pays when a human acts on the number within seconds and the seconds matter. A rep deciding which inbound lead to grab, a floor during a launch where minutes change the plan. For the daily and weekly rhythm that is most of selling, current is not a compromise, it is the correct engineering choice.

How to build the cheap version well

The current-dashboard path is short: point a tool like Metabase or Grafana at the database the CRM already writes to, build the handful of cards above, set a sensible refresh, and stop. There is no pipeline, no streaming layer, no second copy of the data to keep in sync. Most of the value in a sales dashboard is available for the cost of configuration, not construction.

Reach for the live architecture only when the table above puts you in the right-hand column, and when you do, scope it as its own project rather than a checkbox on the dashboard brief, using the same small-and-reversible discipline as scoping any software project before code. The most common good outcome here is the one where the team asks for real-time, gets current, and never notices the difference except in the bill they did not pay.