When your leadership team's weekly decisions run on a PDF assembled manually on Monday morning, the data is already five days old.

Metric definition workshop with representatives from each department with a stake in the numbers -- finance, operations, sales, product -- to agree the definition of every KPI before a line of SQL is written. Common disagreements surfaced and resolved in this workshop: is revenue invoiced revenue, order value, or cash received? Is a customer counted when they sign up or when they pay? Is churn measured by count or by revenue? Is ARR calculated from current MRR or from the signed contract value? Each disagreement represents a structural difference in how departments have been tracking the same business event, and the workshop forces the resolution that the data layer then encodes. Metric dictionary document delivered before dashboard build begins: each KPI listed with its business name, definition in plain language, SQL formula or business rule, source system, update frequency, responsible owner, and the edge cases explicitly excluded from the calculation. Metric sign-off process: each department head reviews and approves the metrics in their domain before development begins -- preventing the scenario where the dashboard is built on a definition that finance recognises but sales disputes. Typically 8--12 KPIs for an executive dashboard; the constraint that produces a useful dashboard rather than an overwhelming one.

Data layer connecting the dashboard to source systems and applying agreed metric definitions consistently regardless of how the underlying systems store raw data. Source connectors: ERP (SAP, Oracle, NetSuite, Sage via API or database connection), CRM (Salesforce, HubSpot via API), finance system (Xero, QuickBooks), product database (PostgreSQL, MySQL via read replica), and marketing platforms (Google Ads, Meta Ads via official API connectors). Transformation layer built in dbt (data build tool) for organisations that want version-controlled, testable SQL transformations: metric calculations defined as dbt models that are reviewed like code, tested for null values and referential integrity, and versioned in Git. Power BI semantic model or LookML (Looker) for organisations that want a governed semantic layer where metric definitions are centralised and reused across reports rather than defined per-report by individual analysts. Refresh schedule per metric tier: financial metrics refreshed daily after ERP posting closes; CRM pipeline metrics refreshed every 4 hours; operational product metrics refreshed every 15 minutes via incremental extraction from the product database. Data quality gate: before metrics are surfaced on the dashboard, a validation query checks for expected row counts, value ranges, and null rates; a metric that fails validation displays a "data quality alert" indicator rather than a potentially wrong number that leadership acts on.

Summary dashboard view presenting the KPIs that determine whether the business is on track: revenue (MTD actual vs budget, YTD run rate vs annual target), gross margin (current period vs target), customer count (current vs prior period with net change), NRR or retention rate, pipeline value and pipeline coverage ratio, and operational throughput metrics specific to the business model. Period comparison built into every metric card: current period value, prior period value, delta (absolute and percentage), and target -- the four numbers that answer "are we ahead or behind, and by how much." Traffic light indicators (green, amber, red) based on configurable thresholds per metric: a single-glance visual language that surfaces the metrics requiring attention without requiring each number to be mentally evaluated against a memorised target. Power BI: DAX measures used for all calculations so metrics remain consistent when users slice by time period or dimension; row-level security configured so each leadership team member sees only their business unit's metrics where appropriate. Tableau: LOD (Level of Detail) expressions for complex aggregation that must ignore filter context; cross-datasource joins for metrics spanning multiple source systems. Metabase: metrics defined in the Metabase semantic layer so the same calculation is reused across questions without copy-paste SQL maintenance. Configurable date range selector for ad-hoc period analysis when leadership needs to investigate a specific quarter or week that differs from the standard reporting view.

Drill-down from summary KPI to the breakdown behind it: revenue total → revenue by product line → revenue by product line and region → revenue by product line, region, and customer segment -- each level of decomposition revealing where the aggregate number is coming from and which dimensions are driving the variance from target. Star schema data model designed to support multi-dimensional slicing: a central fact table (orders, transactions, events) connected to dimension tables (product, customer, region, date) enables any combination of group-by without a schema change. Drill-through to detail records: clicking through a churned customer count metric shows the list of churned customers with the churn date, previous MRR, and last activity -- the records the executive needs to understand a trend, not just confirm it exists. Power BI drill-through reports: configured as a separate report page that receives context from the source visual via page filters, showing a pre-built detail view without requiring the user to apply manual filters. Cross-filtering behaviour: selecting a dimension in one visual filters all other visuals on the page simultaneously -- clicking "Q3 2025" in a bar chart filters all other metrics to Q3 without additional clicks. Bookmark and personal bookmark capability: a specific filter state (YTD, product line X, region EMEA) can be saved and returned to without reconfiguring the filters each session -- valuable for executives who review the same slice every week.

Dashboard accessible on mobile and tablet without a separate mobile build or a second development cycle. Power BI mobile layout: a mobile-specific view built within the same Power BI report using the Mobile Layout Editor -- the most critical 4--6 KPIs arranged vertically in a card format that fits a phone screen without horizontal scrolling, designed for the 2-minute morning check before a leadership meeting rather than a full analytical session. The mobile view and the desktop view are the same data source; filter state applied on mobile persists when the user opens the desktop version. Power BI Mobile app (iOS/Android): native app with biometric authentication (Face ID, Touch ID, fingerprint), push notification delivery for data alerts, and offline tile access for recently viewed dashboards when connectivity is unavailable (common in transit or at client sites). Tableau Mobile: responsive dashboard published to Tableau Server or Tableau Cloud, accessible in-browser on mobile without installing the native app. Metabase: all dashboards are responsive by default; the Slack integration delivers a dashboard image to a configured channel on a schedule so executives see the morning metrics in their existing communication tool without opening a separate BI tool. Email delivery via scheduled PDF: for executives who prefer inbox delivery over dashboard login, a scheduled PDF snapshot sent at the start of the business day.

Configurable threshold monitoring for each KPI with alert delivery via email, Slack, or Teams -- eliminating the need for a human to check the dashboard to find out something went wrong. Threshold types: absolute threshold (revenue below £X), percentage-of-target threshold (revenue below 80% of monthly target), week-over-week change threshold (churn rate increased by more than 20% compared to the prior week), and consecutive-period breach (alert escalation when a metric has been below threshold for two or more consecutive reporting periods without improvement). Power BI data alerts: native alert functionality on dashboard tiles displaying cards or KPIs -- the alert fires on the next data refresh after the threshold is crossed. Custom alerting for more complex conditions: a Python or dbt job running after each data refresh evaluates multi-condition alert rules (e.g., alert when both pipeline coverage AND deal velocity drop simultaneously, indicating a systemic sales motion problem rather than a single data point anomaly) and posts to Slack via Incoming Webhook with a message that includes the current value, the threshold, the percentage deviation, and a direct link to the relevant dashboard section. Alert history log: every alert fired, the metric value at the time, the configured threshold, and whether the alert was acknowledged -- providing an audit trail for post-incident review and for evaluating whether alert thresholds are calibrated correctly or generating noise. Alert fatigue management: threshold calibration review included at the 30-day mark to ensure alerts are firing on genuine anomalies rather than triggering in every reporting cycle on a threshold that was set too tightly.