Beyond the Dashboard: Building Real-Time Decision Intelligence

The distinction between a reporting system and a decision intelligence system is not the quality of the charts. It is whether the system surfaces information in time and in a form that enables a decision to be made.

A dashboard that shows last week's sales by region is a reporting system. A system that detects that a specific sales rep's pipeline has stalled, identifies which deals have been without activity for more than seven days, and sends the rep's manager a list of those deals with one-click actions is a decision intelligence system.

The first records history. The second changes outcomes.

Why Dashboards Often Fail to Change Behaviour

Dashboards fail to produce decisions for predictable structural reasons:

The signal-to-noise problem: A dashboard with thirty metrics requires the viewer to determine which metric is actionable today. Most of the time, most metrics are within normal range. The signal — the metric that is out of range and requires action — is buried in a grid of green. Humans are not efficient anomaly detectors across thirty simultaneous streams.

The timeliness problem: A daily-refresh dashboard showing yesterday's data is always behind the action window for fast-moving operational situations. A logistics exception that appeared yesterday may already have shipped incorrectly or been resolved by someone who noticed manually. The dashboard confirmation is stale intelligence.

The ownership problem: Who owns the action implied by a dashboard metric? If a dashboard shows customer churn rate increasing by two percentage points, who is responsible for the decision about what to do? If it is not clear, the information propagates and the decision does not.

The context problem: A number without context does not enable a decision. Monthly revenue of ₦45M is ambiguous without knowing the target, the trend, and the pipeline. A metric paired with its compared-to values, trend direction, and the specific records driving the change enables a decision. A standalone number requires investigation before a decision is possible.

The Architecture of Decision Intelligence

Decision intelligence requires three layers beyond what a standard BI stack provides:

Layer 1: Event Streaming Rather Than Batch Reporting

Batch reporting processes: data warehouse refreshes on a schedule (hourly, daily) → BI tool queries the warehouse → dashboard reflects data as of the last refresh.

Event streaming processes: business events are emitted in real time as they occur → stream processor evaluates events against decision rules → alerts and actions are triggered within seconds to minutes.

The practical implementation: business events (order placed, payment received, customer support ticket created, inventory level changed) emit to a message bus — Cloudflare Queues, AWS SQS, Kafka, or Pub/Sub depending on the infrastructure context. A stream processor evaluates rule sets against the incoming event stream. When a rule triggers, an action fires.

For a Nigerian distribution company:

Event: warehouse records goods receipt
Rule: if received quantity is more than 10% different from purchase order quantity
Action: alert procurement team with PO number, expected quantity, received quantity, and variance

This alert fires within thirty seconds of the goods receipt. In a daily-refresh dashboard, the same information appears in tomorrow morning's exception report.

Layer 2: Anomaly Detection Against Baselines

Not every actionable signal has a pre-written rule. Decision intelligence systems maintain per-metric baselines from historical data and surface events that deviate significantly from expected patterns.

Statistical approach: For each metric tracked (daily sales by rep, daily support ticket volume, daily payment processing success rate, etc.), maintain a rolling mean and standard deviation over the last ninety days. Flag observations beyond two standard deviations as anomalies requiring attention.

Business calendar awareness: Anomaly detection needs to compare the right reference data. A Monday's sales should be compared to other Mondays, not to the seven-day rolling average that weights mid-week more heavily. Public holiday effects, month-end patterns, and seasonal variations must factor into the baseline or they generate noise.

Implementation: a scheduled job running every hour (or every event batch) computes current values, retrieves the appropriate historical baseline, computes z-scores, and routes high-z items to the alert queue.

Layer 3: Contextualised Action Routing

Alerts that go to everyone are ignored by everyone. Decision intelligence alerts must:

Reach the specific person responsible for the decision — not the whole team, not CC'd to management
Include the context needed to decide — not just the metric value, but the comparison, the trend, the specific records involved, and the suggested action
Provide the action mechanism in the alert — not a link that requires the recipient to log into a system, navigate to the relevant record, and figure out what to do

A practical example in a B2B SaaS customer success context:

The alert: "Acme Corporation's product usage has dropped 42% in the past fourteen days (daily active users: 3 now vs 5.2 fourteen-day average). Last support contact was eighteen days ago. Their renewal is in sixty-seven days. Suggested action: schedule a check-in call."

Beneath the alert description: [Log a call] [Schedule a meeting] [Snooze for 7 days] [Dismiss — not at risk]

Each action button executes the appropriate operation in the CRM via API. The customer success manager reads the alert, taps one button, and the action is recorded. The entire interaction takes thirty seconds.

Without this structure, the same information would require the CS manager to: notice the anomaly in a dashboard (if they look), remember the renewal date (or look it up), open the CRM, create a task, and assign it. Some fraction of at-risk customers go unnoticed; those that are noticed require several minutes of process work per alert.

Practical Implementation for Nigerian Businesses

Operations Intelligence

The most impactful operational alerts for Nigerian businesses:

Inventory below reorder point: fires at the moment available-to-promise crosses the minimum threshold, with the recommended order quantity and the lead time estimate from the supplier record. Reaches the procurement team, not the warehouse manager.

Delivery exception: logistics event shows a shipment is delayed beyond expected arrival window. Customer service team alerted immediately with customer contact details and order information, enabling proactive outreach before the customer calls.

Cash conversion cycle anomaly: accounts receivable aging shows a collection cycle extending beyond the norm for a specific customer segment. Finance manager alerted with the specific invoices and customer contacts, enabling proactive collection activity.

Finance Intelligence

Payment failure spike: payment gateway failure rate exceeds threshold (indicates a gateway issue, a bank system outage, or a fraud spike). Finance and engineering alerted simultaneously — one for customer impact, one for technical response.

Budget variance by cost centre: monthly spend is tracking to exceed budget before the month end. Budget holder alerted with current run rate, projected month-end spend, and the specific cost items driving the variance.

Payroll approval approaching deadline: payroll processing requires multi-step approval. If approval has not been completed three days before the processing date, escalation alert fires to the approver's manager.

Customer Success Intelligence

Churn risk scoring: usage drop, support ticket frequency increase, and lack of recent champion contact are leading indicators of churn. A churn risk model scoring each customer weekly, with alerts for customers crossing a risk threshold, routes proactively to the CS team before the customer submits a cancellation.

Upsell opportunity detection: customer usage approaching their plan limits is an upsell trigger. Automated alert to account manager with current usage, next plan tier details, and draft upgrade email.

The Tool Stack

For most Nigerian businesses, decision intelligence does not require enterprise BI software. The practical stack:

Metabase (open source, free): handles dashboards, scheduled reports, and alerting on metric thresholds. Runs as a self-hosted Docker container or on Metabase Cloud (~$1,020/year, or ~$85/month, for small teams).
Application-layer event hooks: every meaningful business event emits a domain event that the alerting system can process. This is an architecture decision, not a tool purchase.
Slack or WhatsApp as the delivery channel: alerts that reach people where they already are get seen. Alerts that require logging into a monitoring portal get ignored. Route high-priority operational alerts to WhatsApp (for Nigerian business context) or Slack for engineering and product teams.

The investment is not in tools — it is in clarity about which signals require action and designing the system to surface those signals rather than recording everything and hoping someone notices the important things.

Database Choices for Nigerian Business Applications — Selecting the right data layer
Measuring Software ROI — Quantifying the value of better data
Beyond Efficiency: Measuring Human Impact of Software — Beyond dashboards to real impact