Reporting and Decision Systems

A dashboard is not a decision system merely because it contains current-looking numbers. We start by listing the recurring decisions the organisation must make: where to allocate capacity, which pipeline risk needs intervention, when margin has moved outside tolerance, which delivery commitment is at risk or whether an experiment should continue. Each decision has an owner, a review rhythm, an evidence threshold and a possible action. If nobody is expected to act, the proposed metric is probably information rather than an operating signal.

The written scope names the decision domains, intended users, source systems, history to be loaded, refresh expectation, security model, output surfaces, alerts, acceptance tests, training, handover and support window. It also identifies dependencies controlled by the client or a provider. A request for an executive view across finance, CRM, operations and marketing is materially different from a single-source departmental report; a live operational alert is different from a monthly board pack.

Pricing is supplied after that boundary is understood. Data discovery, source repair, historical backfill, identity resolution, warehouse or semantic-model work, custom connectors, embedded analytics, mobile views, export layouts and continuous operation can change the commission substantially. Power BI, Fabric, Looker, Tableau, database, connector, cloud, model and other third-party charges are not hidden inside an unspecified build fee. Where continuing refresh, monitoring or change work is required, the proposal states its cadence and term.

The service does not promise faster decisions, better margin or earlier detection merely because a dashboard is delivered. Those are outcomes that require a usable source, timely adoption, agreed decision rights and action. We can verify calculations, refreshes, permissions, rendered views, alerts and recorded decisions. Business impact remains unproven until an agreed baseline and subsequent evidence show a change.

Terms that look obvious often hide different calculations. Revenue may mean booked, invoiced, recognised, collected, gross or net revenue. A customer may mean an account, billing entity, buyer, location or active subscription. Conversion rate changes with its numerator, denominator, attribution window and excluded traffic. Before designing a visual, we write a metric contract that states the business meaning, formula, grain, filters, time zone, currency, entity rules, owner, source and valid comparison.

A governed semantic layer turns those agreements into reusable dimensions and measures rather than copying formulae into each chart. Calendar logic, fiscal periods, currency conversion, status mapping, deduplication and slowly changing categories are resolved once and tested. A dashboard may still show several legitimate views of a measure, but the difference is named. It should never present two incompatible definitions under the same label.

Every signal carries freshness and quality context. The user needs to know when a source last completed, what period the number covers, whether records are delayed and which checks passed. Missing data is not automatically zero; an incomplete refresh is not the same as no activity. Where an estimate, forecast or manually supplied figure appears, the interface distinguishes it from observed data and records who supplied or approved it.

Metric ownership is operational, not ceremonial. The owner resolves definition disputes, approves material changes and decides what happens when the signal breaches a threshold. Data engineering may own the pipeline and finance may own a revenue definition, while a commercial director owns the decision made from it. Those responsibilities are recorded separately so a technical maintainer is not silently made responsible for a business judgement.

The integration design records how data enters the system, how often it can change and what happens when it arrives late. APIs, files, databases and manual inputs have different failure modes. Incremental loads need stable keys and checkpoints; snapshots need retention rules; backfills must not silently rewrite previously reported periods. Identity matching across CRM, finance and product systems is treated as a business rule with exceptions, not as a convenient join that happens to run.

Control totals and reconciliations are placed at meaningful boundaries. A source count, monetary total or status distribution can be compared before and after transformation. Thresholds reflect the decision risk: a rounding difference and a missing business unit do not deserve the same response. Failed refreshes, schema changes, unexpected nulls, duplicates and delayed feeds create visible incidents with an owner and recovery action.

Provenance should survive the final chart. A user may not need to see every technical step, but an authorised reviewer must be able to trace a figure to the relevant source, transformation, version and time. Changes to metric logic are versioned and release notes state which historical numbers may move. If a source cannot support the precision or frequency requested, the limitation is stated rather than masked by a more polished interface.

Access follows the least privilege needed for the role. Executive summaries, operational details, personal data, financial information and row-level records may require different audiences. Service accounts, credentials, exports and shared links are governed; development, test and production are separated where the risk warrants it. The client retains control of its data and accounts, and deletion, revocation and handover paths are defined in writing.

An executive surface should answer a small number of questions quickly. Current state, movement against a meaningful comparison, material exception and the route to detail take priority over decorative density. The interface distinguishes target, forecast and actual; exposes units and time periods; and keeps filters visible. Colour is never the only carrier of meaning, and a mobile or exported view must not alter the interpretation of the data.

Drill-down is designed around diagnosis. When a measure crosses a threshold, the next view should reveal the dimensions that can explain or route the issue—region, product, customer segment, owner, stage or time—without exposing data the user is not authorised to see. Annotations record known events, definition changes and interventions. This prevents a normal campaign launch, source outage or accounting adjustment from being misread as an unexplained trend.

Alerts are part of a decision contract, not a stream of notifications. A threshold has an audience, schedule, suppression rule, escalation path and recovery condition. Repeated alerts for the same unresolved event create fatigue; a missing feed should not trigger a misleading commercial alarm. The system records delivery and acknowledgement where required, but it does not claim that a notification caused action unless the action is separately captured.

The review routine closes the loop. A daily operational review, weekly pipeline meeting and monthly executive review need different views and decisions. The meeting record links observation, interpretation, decision, owner and due date. The next review can then distinguish an unresolved action from a new signal. A report that is viewed but never changes a decision may need to be simplified, reassigned or retired.

Validation combines technical and business checks. Source samples, transformation tests, reconciliation totals, permission tests, refresh behaviour, responsive layout, export output and accessibility are examined before release. Business owners complete scenario-based acceptance using decisions they genuinely make. A screenshot approval is not enough if the measure cannot be reproduced or the person expected to act cannot use the view.

Production ownership covers refresh failures, credential expiry, provider incidents, schema changes, stale data, slow queries, broken exports and access requests. The support model names who monitors each class of failure, the hours covered, the escalation route and the restoration or fallback expected. No 24/7 monitoring, fixed response time, unlimited change capacity or availability commitment is implied unless the written proposal includes it.

Adoption is measured with care. Page views, exports and subscriptions can show use, but not necessarily effective use. We pair usage with interviews, decision records, retired manual reports, recurring questions and unresolved actions. A lightly used monthly board report may be valuable; a heavily viewed report may be misunderstood or used only as a route to Excel. The review asks whether the intended people can make the intended decision with less ambiguity.

AI-generated summaries or anomaly suggestions are treated as an additional interpretation layer. They receive bounded data, cite the underlying measure or record where practical, disclose uncertainty and never replace the authorised decision maker. Prompt, model, retrieval source and output version may need to be logged for sensitive use. A fluent explanation is not accepted as evidence. AI features are tested before release and monitored for changing behaviour, access and cost.

The operating review chooses what to keep, change, test or retire. It considers data quality, refresh reliability, access, use, decision records, recurring support demand and third-party change. Material changes return through definition, test and approval rather than being edited directly in production. The result is a maintained decision surface with accountable ownership—not a growing museum of dashboards.