Automated reporting and dashboards: pipelines that replace the weekly report

The weekly report that one person assembles every Monday from three exports and a spreadsheet is late when they are on holiday, wrong when a column shifts, and unverifiable by everyone who reads it. This is for operations and finance leads who want numbers that arrive on schedule, from queries anyone can rerun, with a summary that does not need a meeting to interpret.

Why the hand-built report is a liability

The problem is not the report but how it is made: a CRM export, a query someone saved two years ago, a Sheets tab with a pivot, forty minutes of copying figures into an email. Each step is a place where a number can change unnoticed, and only the person who builds it knows which step matters.

The automated version is the same report, produced by a pipeline that runs the same queries every week, keeps the results and tells someone when a number looks wrong. The gain is not speed but reproducible numbers and an owner other than a calendar reminder.

The pipeline from sources to summary

1. Pull from the systems of record

Postgres for transactional data, the CRM through its API, Google Sheets or Excel in Microsoft 365 for the numbers that live nowhere else. Each source is one n8n node and one versioned query or endpoint. A spreadsheet is read as a named range with a fixed header row, and the workflow fails loudly when the header changes.

2. Check before you compute

Freshness: is the latest row from this week. Completeness: is the row count within the range of the last eight weeks. Reconciliation: does the revenue total from Postgres agree with the CRM within tolerance. A failed check stops the report and alerts the owner; stale data does more damage than a late report, because people act on it. This is also where data readiness problems surface and get fixed at the source instead of in the spreadsheet.

3. Store the snapshot

Every run writes its metrics to a reporting table with a run ID and timestamp. The dashboard reads that table, not live sources, so last week's number is still last week's number in March, and week-over-week comparison is a query rather than a memory.

4. Deliver where people already look

A dashboard for people who want to explore, an email for people who want the headline, a chat message for people who will open neither: same snapshot, three renderings, one schedule.

The rule about numbers: the model never calculates

The LLM receives a JSON object — this week's metrics, last week's, the eight-week average and the anomaly flags — and writes three paragraphs of plain prose about it: what moved, what did not, what needs a decision. Every figure in the output must appear verbatim in the input; the workflow extracts every number from the draft and looks for it in the metrics object. A draft that fails is regenerated, and if it fails twice the report goes out with the table and no narrative.

That sounds paranoid until a model rounds 18.4% to "nearly 20%" in an email to the board. Models are good at explaining a change, unreliable at arithmetic, and unable to tell a number they were given from one they produced. Calculation in SQL, language in the model: that split makes the narrative trustworthy, and it is the same principle as the output validation layer in any AI workflow.

Scheduling and alerting on anomalies

A schedule has two parts: when the report is due and what must be true before it runs. A Monday 07:00 report that depends on a Sunday night warehouse sync waits for the sync, not the clock. In n8n that is a trigger, a freshness check and a retry with a deadline; if the deadline passes, the owner is told the report is delayed and why.

Anomaly alerts are separate from the report: the report is context, an alert is a number that moved outside its expected range today. Keep the rules explicit — two standard deviations from the trailing eight-week mean, or a threshold the business set — and post the metric, the value, the expected range and a link to the query. Over-alerting kills the channel within a month, so start with three metrics.

A worked example: a regional logistics company

Consider a carrier with three depots, around 9,000 shipments a week, a Postgres-backed dispatch system, a CRM and a Sheets file where depot managers log damage claims. The operations manager spent three hours every Monday on a report covering volume, on-time rate, cost per shipment and claims by depot. When she was away it was skipped, and two archived versions showed different on-time rates for the same week because a filter had changed.

An n8n workflow runs Monday at 06:30 once the weekend dispatch sync confirms: four Postgres queries, one CRM call, one read of the claims sheet's named range. Checks confirm the shipment count is within range and the claims sheet has this week's rows. Metrics go to a reporting table; a dashboard reads it, an email goes to the depot managers and the director, and a chat message posts the narrative. The number check rejects roughly one draft in fifteen, usually for a rounded percentage.

After a month the report arrives at 07:00 every Monday, holidays included, the on-time rate has one definition, and the operations manager spends the three hours on the depot whose claims rate was flagged on Wednesday. Build effort: about a week and a half, most of it agreeing on what "on time" means.

Ownership and the switch-off checklist

An automated report without an owner is a manual report with extra steps: it will break and nobody will notice. Ownership is three named people — one for the queries and definitions, one for the schedule and infrastructure, one who reads it and says when it stops being useful. Hilluter's automations ship with that list in the runbook, alongside retries, logging and the alert route, the same discipline as any back-office workflow.

• Every metric has a written definition and a query a second person has read.
• Freshness and completeness checks exist for every source, and a failed check stops the report.
• Each run stores a snapshot with a run ID, and the narrative is generated from that snapshot only, with the number check enforced.
• The schedule waits on upstream data, not just the clock, and delays are announced.
• Anomaly rules are written down, with thresholds the business agreed to.
• Three owners are named, and the manual report runs in parallel for two cycles first.

If you have a report that depends on one person and a spreadsheet, describe what it contains and where the numbers come from and we will reply with the pipeline sketch and the checks we would put in front of it.