Operational alerts instead of dashboards: how to find out in 10 minutes, not at Monday's meeting

The problem is not a lack of reports

Almost every company with 50-300 employees already has reports. Many also have dashboards — typically 5 to 15 of them, built in Power BI, Metabase or straight inside the ERP. When we look at access logs, the picture is almost always the same: 2-4 dashboards get opened weekly, the rest 2-3 times a month, usually by the person who built them.

This is not a discipline problem. A dashboard requires somebody to wonder, unprompted, whether something happened — on the exact day it happened. Nobody does that 40 times a month across 12 screens.

What that latency actually costs:

• A stockout on a top-50 item gets noticed Monday morning, after 4 days of lost sales
• A 22,000 EUR purchase order sits stuck in approval for 6 days, with nobody notified
• A supplier raises prices by 9%; the increase lands on ~300 order lines before anyone sees it in the monthly margin report
• An integration flow dies on Thursday evening; it is discovered Tuesday, by the customer who calls
• A customer who used to order 14,000 EUR/month drops to 3,000; it comes up in the quarterly review, by which point they are gone

In every one of these cases the data was in the system at the right time. What was missing was somebody being told.

What an operational alerting system actually is

This is not infrastructure monitoring — that watches whether servers and APIs are alive. Here we are talking about business metrics drifting away from normal. Six components:

1. One trustworthy data layer. Alerts are computed from a warehouse that pulls ERP, CRM, WMS and the invoicing platform together. If each alert queries its source system directly, you will end up with alerts that contradict each other.

2. Deterministic rules with thresholds. Most of the value sits here, not in models: stock coverage under 7 days on class-A items, line margin below 8%, order unconfirmed after 48 hours, delivery note issued but not invoiced after 5 days.

3. Anomaly detection for what cannot be thresholded. A customer's order volume, return counts, average delivery time — these are seasonal. Compare against an 8-week rolling average on the same weekday, and flag deviations beyond 2.5 standard deviations.

4. Routing to a person, with context. An alert in a general channel has no owner. Every rule has one, and the message carries the item, the customer, the figure, the variance and a direct link into the system — not "check the report".

5. Acknowledgement, escalation, history. An alert closes with a reason: resolved, false positive, accepted. Without that, you cannot calibrate anything three months in.

6. A calibration loop. Monthly: how many alerts were false positives, which rule generates noise, which incident slipped through and now needs a rule.

Why "let's add another dashboard" does not fix it

• Pull versus push. A dashboard assumes the person comes to the data. An alert takes the data to the person. For incidents that cost money within 24-48 hours, that difference decides the outcome.
• No threshold. A chart shows a line going down. It does not tell you whether that is normal for October. A threshold forces the judgement a dashboard leaves open.
• Nobody is accountable. A dashboard belongs to everyone, therefore to no one. An alert has a name attached.

Dashboards stay useful — for investigation, once the alert arrives. Their job is context, not detection.

Case study: FMCG distributor, 7 warehouses, 4,200 SKUs

A distributor with 190 employees and 31M EUR in turnover had 9 Power BI reports and a controller who manually emailed a summary every Friday. Problems kept happening between two reports.

What we built together with the team at NEXVA SYSTEM:

• A warehouse fed from ERP and WMS every 15 minutes, plus a nightly load for accounting data
• 23 deterministic rules at launch, only 11 of them high priority: stock coverage, line margin below threshold, stalled orders, uninvoiced delivery notes, supplier price deviations from contract
• Anomaly detection on the top 200 customers' order volume and on delivery time per warehouse
• Routing into Slack across three channels (purchasing, sales, finance), with SMS reserved for two critical rules
• An acknowledge button on every alert with a closing reason, plus a monthly calibration report

Results after 6 months:

• Median time from problem occurring to somebody seeing it: from ~3.5 days to 22 minutes
• Stockouts on class-A items: -34% (from 61 to 40 events/month)
• Supplier price discrepancies caught before invoicing: 18,400 EUR recovered in the first 5 months
• Uninvoiced delivery notes at month-end: from 46 to 3 on average
• False positive rate: 31% in month one, 9% after two calibration rounds
• Alert volume: down from 140/week to 48/week after removing 6 redundant rules — while catching more incidents, not fewer

The finding nobody planned for: two warehouses ran delivery times consistently 1.8 days above the rest. It never showed in the national average. The per-warehouse anomaly rule surfaced it in week three.

How to avoid alert fatigue

This is where most of these projects die. Rules that hold up in practice:

• Five alerts per person per day, maximum. Above that, people start ignoring all of them, including the real ones.
• Three severity levels on different channels: critical (SMS, response within the hour), important (Slack, same day), informational (daily digest, not a notification).
• A deduplication window. Same item, same rule: one alert per 24 hours, not one per run.
• Every alert must have an available action. If the honest response is "fine, but what do I do now?", the rule does not belong in the system.
• Calibrate on historical data before launch. Run the rule across the last 6 months and count how many alerts it would have fired. If the answer is 400, the threshold is wrong.

What it costs and when it pays back

| Component | Cost |

|-----------|------|

| Analysis: which incidents cost money, what data exists, who responds | 2,000-3,500 EUR |

| Unified data layer from ERP, CRM, WMS | 4,000-9,000 EUR |

| Rule engine, thresholds, routing and acknowledgement | 3,500-6,500 EUR |

| Anomaly detection on seasonal series | 2,500-5,000 EUR |

| Hosting, maintenance and monthly calibration | 200-450 EUR/month |

Payback has two components. The direct one: time freed in controlling and manual reporting — 15-25 hours a month, worth 3,000-6,000 EUR/year.

The second one is what matters. On 30M EUR of turnover at an 18% gross margin, cutting stockouts on fast-moving items by 30% is comfortably 60,000-120,000 EUR/year in sales not lost. Add price discrepancies caught before payment and delivery notes invoiced on time, and the project typically pays for itself in 4-7 months.

The mistakes that ruin it

• Launching with 60 rules. Noise in week one and lost trust. Start with the 8-12 rules covering the incidents that actually cost you money last year.
• Alerting on poor-quality data. If ERP stock figures are unreliable, your stockout alert will be a permanent false positive. Fix the data first, not after.
• Email notifications. They land in the folder with the automated reports and die there. The channel has to be where the team already works.
• No owner per rule. An alert with no name behind it produces no action.
• AI where a threshold would do. Anomaly detection earns its place on seasonal series, not on "stock below 10 units".
• No baseline. Write it down now: how many days until you learn about a problem, how many stockouts a month, how many uninvoiced delivery notes. Without that, you can prove nothing later.

How to start

1. List the incidents from the last 12 months that cost more than 1,000 EUR each. Group them. You will find that 6-8 types account for 80% of the losses.

2. Check, for each one, whether the data existed in the system 24 hours earlier. If it did not, your problem is collection, not alerting.

3. Write 8-12 rules with a threshold, an owner and an expected action. On paper, before any code.

4. Replay them against historical data and tune the thresholds until you land under 5 alerts per person per day.

5. Launch with one channel and one department for 4 weeks. Only then expand to the rest and add anomaly detection.

The difference between a company that reacts in 20 minutes and one that finds out on Monday morning is not the quality of its analysts. It is that one of them turned 10 recurring questions into 10 rules that ask themselves, around the clock.

Want to see which of the incidents that cost you money last year could have been caught automatically with the data you already have? Book a free consultation.