“We want a real-time wall screen” often appears in the first sentence of a kickoff. It sounds advanced, and it ties two different problems together: whether numbers are trustworthy, and whether they must jump by the second. Most mid-size companies die first on definitions and master data, not on being twenty-three hours late.
The test is one sentence: if you miss this refresh window, does the decision get worse. A jammed line that needs a reassignment will pile a shift of rework in ten minutes. That is when a shop-floor screen needs a faster refresh; see What a plant and warehouse screen should show and How a shop-floor screen keeps crews out of the office. A weekly meeting on margin, collections, and turns is safer on yesterday’s reconciled numbers than on numbers still jumping ten minutes ago. Real-time eats the reconciliation window, and finance and operations pull out two sheets again.
Real-time also has a price. APIs must be stable, failures must retry, lateness must be marked, and dirty data reaches leadership at the same speed. Going second-level before quality holds only amplifies pollution; see Data quality is poor. Build the dashboard first, or clean first. Mid-size companies do not need a streaming pipeline to match a “platform standard”; see Do mid-size companies have to buy a data platform. Cost follows frequency; see What dashboards or a data platform cost, and how long they take. Before you write “real-time” into a tender, write the latest usable time for each KPI. If you cannot write it, do not buy the most expensive refresh.
Write the decision time before you write refresh in seconds
In the plan, write one sentence for each KPI’s latest usable time: the 8:30 huddle needs yesterday’s output; Wednesday’s meeting needs Monday’s closed margin; stock below safety must reach the warehouse in ten minutes. If that is clear, T+1 is not backward and real-time is not waste. If it is not, vendors can only quote the most expensive real-time, and the project spins on sync delay. When alerts must reach a person, frequency follows responsibility, not wall-screen animation; see Alerts pushed to people, so exceptions rarely sit overnight.
Draw both waveforms on the same leadership screen and leadership will think strategy changes every second, while the floor will call operations numbers “fake real-time.” Split themes and refresh. That is engineering. When DaXi builds a data project, operations subjects default to a daily batch. Floor subjects get their own collection cycle. They can share definitions and master data. They do not have to share refresh. To judge which numbers must jump, send meeting times and shift times to the Data service page. How we schedule from brief to launch, see From brief to launch: how a data project actually runs.
If the screen says “real-time,” the extract has to match that sentence
A screen that says “real-time” and extracts every fifteen minutes hurts trust more than an honest T+1. Refresh policy and page copy must match. Late batches should show a cutoff time.
During a finance close, do not force a match between instantaneous operational sales and margin. Different windows not matching is normal. Write the extract timestamp on the chart instead of letting two departments blame the API.
Device collection can be fast. Operations KPIs should still close daily. Put API delay, the reconciliation window, and the close calendar in an appendix so launch does not get killed with “you said it was real-time” against a definition that should have been T+1.