MELLORCATalk to Mellorca
Patterns

Data, Reporting & Management Visibility

Why Real-Time Operations Still Depend on Friday Reports

Live capture does not make a business responsive if nothing turns events into action. Learn which few events should bypass the weekly report and how to route them to the right person.

Mellorca Patterns2026-10-10

Observable condition

The business has live systems. Orders are captured as they are placed, vehicles report their positions, tills post sales within seconds and the warehouse scans stock in and out through the day. Yet the operation is steered by a report that is prepared on Thursday night and read on Friday morning. Anything that cannot wait until then is handled by phone calls, WhatsApp messages and walking to someone's desk. Anything that can wait is left until the report says it matters.

An illustrative example: a Gauteng cold-chain logistics company with a fleet of delivery vehicles and a small control room. Temperatures, locations and delivery confirmations all arrive from the vehicles as they happen. The weekly operations meeting, however, runs from a spreadsheet of exceptions compiled on Thursday evening: late deliveries, temperature excursions, missed windows. The control room sees each event as it occurs. Management sees it a week later, in aggregate, when it can no longer be linked to the route, driver or customer conversation that would explain it.

The data is current. The management routine is not.

Realisation

This is easily mistaken for a technology gap, and the natural remedy is to buy something faster. The more useful realisation is that the speed of the information and the speed of the organisation are separate things. A business can hold second-by-second data and still make its weekly decisions weekly, because the meetings, responsibilities and habits were built around the old rhythm and nobody has revisited them.

The Friday report persists for good reasons. It is trusted, because everyone knows how it is made. It has an owner. It fits the meeting. The live data has none of these qualities: it is scattered across screens, nobody is accountable for watching it, and it is not obvious which events deserve a reaction. So the organisation falls back on the one artefact it understands, and the investment in live capture produces a very expensive input to a weekly summary.

Identification

This is a capture-to-action gap. The business has solved data capture but not event routing: the point at which a recorded event becomes a task, a message or a decision for a named person. It is different from disconnected systems acting on old information, because here the information is fresh and sitting in a system. It is also different from a dashboard that is secretly a spreadsheet, because the live feed is real. What is missing is the link between the feed and the people who must respond.

The visible symptom is a reliance on one weekly report despite modern systems. The common assumption is that the systems are not "real-time" enough or that staff resist change. The structural cause is that nobody has defined which events should trigger action immediately, who receives them and what they are expected to do.

Diagnosis

  • Batch is the default. IBM's overview of streaming data contrasts the two models plainly. Batch processing groups records and runs them on set schedules, and suits jobs such as a daily sales report. Streaming handles events as they arrive, and suits cases where the response must be immediate. Most business reporting was built as batch because that was simpler, and it stays batch unless someone makes a deliberate choice.
  • Events are recorded but not routed. IBM's description of event-driven architecture explains the alternative: components emit events, and other components react to the ones they care about, which allows automation and a proactive response. In many small and mid-sized businesses nothing is listening. The temperature excursion is stored, but nobody is told.
  • No agreed thresholds. Without a definition of "needs attention now", the choice is between watching every screen all day or not watching at all. Staff default to the second option.
  • Alert fatigue, or fear of it. Microsoft's data-alert feature notes that alerts apply to numeric values and fire when thresholds are crossed on refreshed data, and Google's site reliability guidance warns that frequent, unnecessary pages lead to fatigue and missed real incidents. People who have been burned by noisy notifications are reluctant to switch more on.
  • Accountability sits in the weekly meeting. If the only place where problems are formally reviewed is the Friday meeting, the rational choice for a busy manager is to hold the issue until then.

Commercial impact

The commercial value at stake is speed, customer experience, risk and margin.

Speed is lost wherever a recoverable problem is left to become an unrecoverable one. A late delivery that is noticed in the control room can be re-routed; the same delivery noticed in a weekly summary becomes a credit note. Customer experience follows, since customers feel the difference between a call that says "we have spotted a problem and are fixing it" and an explanation a week later. Risk includes spoiled stock, safety incidents and contract penalties that depend on how fast a response is made. Margin is eroded by repeated small losses that never look important enough individually to appear in a summary. The related cost of finding things out late is examined in Why Management Finds Out Too Late.

Common misidentification

The common mistake is to demand that everything be real-time. Streaming is more complex and more costly to run, and IBM itself points out that batch remains well suited to jobs like daily reporting. For most measures, a weekly view is exactly right, since trends and totals are what management needs.

The right question is not "can we make the report live?" but "which few events must never wait for the report?" A business may need real-time handling for five or six situations and a weekly rhythm for everything else. The Friday report is not the problem. Its monopoly on attention is.

A second misidentification is to put a live screen on the wall. It looks modern, but unless someone owns it and knows what to do when a number changes, it becomes wallpaper. The same point is made in How to Decide What Should Be on an Operations Dashboard.

Possibility

In a better arrangement, the live data the business already holds is used for a small number of defined triggers. Each trigger names an event, a threshold, a recipient and a first action. A temperature excursion goes to the shift controller with the vehicle, the load and the customer attached. A missed delivery window creates a task for the account manager and a proactive message to the customer. The Friday report is then free to do what reports do best: show patterns, repeat offenders and trends, because the individual incidents have already been dealt with.

The weekly meeting changes character. Instead of discovering that something went wrong, it reviews how quickly it was handled and what to change so it happens less often.

Intervention

  1. Inventory what you already capture. List the systems that produce events as they happen: orders, payments, scans, positions, tickets, sensor readings.
  2. Choose the few events that cannot wait. Ask which situations, if found a week later, would have cost money or a customer. Keep this list short.
  3. Define the response. For each event, state the threshold, who is told, through which channel and what they are expected to do within what time.
  4. Connect the event to the person. This is usually an integration task: a rule that turns a recorded event into a task, message or alert in the tool people already use. Avoid creating yet another screen to monitor.
  5. Tune before you extend. Review the volume of alerts after a few weeks. Remove those that are routinely ignored, so the ones that remain are trusted.
  6. Re-purpose the weekly report. Move incident handling out of it and use it for patterns and decisions.

Diagnostic questions

  • Which events in your systems are recorded immediately but only reviewed weekly?
  • If a problem appears at ten o'clock on Tuesday, whose job is it to notice, and how do they find out?
  • How many of your alerts or notifications are routinely ignored?
  • What does your weekly meeting mostly do: discover problems or learn from them?
  • Which two or three situations would you want to hear about within minutes?

Bottom line

Having fast data does not make an organisation fast. The gain comes from choosing the small set of events that deserve an immediate response, wiring them to the right person, and leaving the rest to the weekly rhythm that suits them.

Sources and further reading

Related Mellorca reading

Article summaryLive capture does not make a business responsive if nothing turns events into action. Learn which few events should bypass the weekly report and how to route them to the right person.
Explore our solutionsStart a conversation