Services / Data / Automated reporting

The Monday report, already written before you ask for it

The pack somebody rebuilds by hand every week (same exports, same pivot tables, same formatting), produced automatically, checked before it sends, and delivered in whatever format each audience actually reads.

Start the conversation →See the technology

Why it matters

The cost is the wait

Somewhere in your business a capable person spends half a day a week producing a report. They export from three systems, paste into a workbook that has been passed down for years, fix the formatting, write two paragraphs of commentary and email it out. It is careful work, it is completely repeatable, and it is a poor use of someone who understands the business well enough to be trusted with it.

The risk is not only the wasted time. A hand-built report is a report where a filter can be left on, a range can miss the last row of a new month, and a formula can be dragged one cell too far, and nobody downstream can tell. When the numbers in the board pack disagree with the numbers in the CRM, the credibility damage lands on whoever presented them, not on the spreadsheet.

Automating it means the same figures, produced the same way every time, from definitions everyone has agreed, with checks that run before anything is sent and a record of exactly how each number was calculated. The half-day comes back, and the person gets to spend it on the interpretation, which was always the part that needed them.

What you actually get

Built to be trusted

An automated report has to be at least as trustworthy as the handmade one it replaces, or nobody will stop making the handmade one.

In the format each audience will actually open

A board pack as a PDF, a working file as a spreadsheet with the underlying rows intact, a short summary into a Slack or Teams channel, a link to a live dashboard for the people who want to dig. Same numbers, delivered where each group already looks.

Comparisons built in, not bolted on

Every headline figure shown against last week, last year and budget, with the variance calculated for you. Reports that show a number with nothing to compare it to leave the reader doing arithmetic in their head, and they generally get it wrong.

Commentary where it can be automated honestly

Plain-language notes on what moved and by how much, generated from the actual figures ("north region down 12% on last week, driven by two sites") so the human writing the interpretation starts from the facts rather than hunting for them.

Checked before anyone sees it

Freshness, completeness and sanity checks run before the report goes out. If a source did not deliver or a total moved implausibly, the report is held and a person is told, far better than a board discovering it in the meeting.

Reproducible, months later

Every issued report is kept exactly as sent, and can be regenerated for any past period with the same result. When somebody queries a figure from April, you can show them precisely what was reported and how it was calculated.

The right people, the right rows

Distribution lists tied to your existing user accounts, with each recipient's version containing only what they are entitled to see. Nobody gets the whole company's payroll because they were on the wrong mailing list.

Where it earns its keep

Same pattern, different desks

Look for the recurring calendar entry called something like "pack prep". That is where this pays for itself first.

01 · Finance teams & CFO offices

Four days of month end that were never accounting

The problem: Management accounts mean exporting from the accounting package, reconciling against the sales and operations systems, rebuilding the same workbook, and reformatting the board pack: every month, under time pressure, with the qualified accountant doing data entry.
What we build: Ledger, sales and operational data joined automatically, the pack generated from agreed definitions with variance against budget and prior year, and a checking step that flags anything unusual before the file is produced.
What changes: The pack is ready on day two rather than day six, the arithmetic is identical every month, and the finance team spends its time explaining the numbers instead of assembling them.

02 · Marketing agencies

Client reporting that eats the last week of every month

The problem: Every client needs a report pulling from ad platforms, analytics and the CRM, each in the client's own template. Account managers spend the final week of the month copying screenshots into slides instead of doing the work clients are paying for.
What we build: One reporting engine reading each client's connected accounts and producing their branded report on their schedule, with results tied through to the leads and revenue in the CRM rather than stopping at impressions and clicks.
What changes: Reports go out on time without anyone assembling them, and they show contribution to actual revenue, which is a considerably better renewal conversation than a chart of clicks.

03 · Charities & grant-funded organisations

Funder returns rebuilt from scratch every quarter

The problem: Each funder wants different figures over different periods in a different format, drawn from a case management system, a fundraising database and volunteer spreadsheets. It is assembled by hand, and a mistake risks a funding relationship.
What we build: One agreed set of definitions feeding per-funder report templates, generated on each funder's own reporting cycle, with the personal data aggregated at source so returns contain only what they are meant to contain.
What changes: Returns produced in minutes rather than days, consistent between funders, and defensible under audit because every figure traces back to its source records.

The technology

The tools behind it, named

Reporting is mostly plumbing plus typesetting. We use boring, well-supported tools so the thing still runs in three years without anyone tending it.

5 layers · 28 technologies

Producing the report

Where the numbers become a document: charts, tables and text laid out properly, in PDF, spreadsheet or slides, to a template that matches your brand.

Python
pandas
Quarto
Jupyter
Plotly
Microsoft Excel

Getting it to people

Delivery decides whether a report is read. Most organisations need two or three channels at once, because different people genuinely will not use the same one.

Slack
Microsoft Teams
Resend
Gmail
Google Sheets
Notion

Running it on schedule

The scheduler that produces the report on time, retries if a source is late, and tells a human when it has to hold the send rather than issuing something wrong.

Apache Airflow
Prefect
n8n
Cloudflare
Docker

The numbers underneath

Reports read from the same modelled, tested tables as your dashboards, which is the only way a report and a dashboard ever agree with each other.

Google BigQuery
PostgreSQL
Snowflake
dbt
Metabase

Where the figures come from

The operational systems that hold the source data: read on a schedule, never edited, and reconciled against your own accounts before anything is issued.

Xero
QuickBooks
Salesforce
HubSpot
Stripe
Google Analytics

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Three to six weeks for a report pack, and we deliberately automate one report properly before touching the rest.

We take the spreadsheet apart

We sit with whoever builds the report today and go through it cell by cell: every export, every lookup, every manual adjustment and every rule that only exists in their head. That last category is always bigger than expected.

We ask who reads it and why

Half the pages in most recurring reports are read by nobody. Finding that out early makes the automation cheaper and the report better, and it is a conversation the person building it by hand has usually wanted to have for years.

We rebuild the calculations properly

Each figure is defined once, tested, and documented in plain English. Where the manual version had a genuine error, and there is usually one, we show you the difference before switching over, so nobody is blindsided by a number moving.

We run both versions side by side

For a few cycles the automated report is produced alongside the handmade one and the two are compared line by line. It replaces the manual version when it matches, not when the build is finished.

We add the checks and the alerts

Freshness and sanity checks that hold the send and notify a person when something is off, plus a clear log of what ran, when, and against which data, so a late report is explainable rather than mysterious.

We hand it over and stay reachable

Documentation, ownership and access with your team, plus training on how to change a threshold or add a recipient. Most clients then need us only when something structural changes: a new system, a new entity, a new funder.

Before you commit

The questions worth asking

Will the automated version match our current numbers?

Usually not exactly, and that is worth knowing before we start. When we rebuild a report from the source data we almost always find a small error in the manual one: a filter left on, a range that stopped updating, a formula dragged a row short. We show you every difference and explain its cause, then you decide which version is right. It is an uncomfortable fortnight and it is the single most valuable part of the exercise.

Can it write the commentary too?

It can write the factual part reliably: what moved, by how much, and which segments drove it, all computed from the actual figures. What it should not do unsupervised is explain why, because the reason is usually context that exists only in your team's heads: a lost tender, a supplier problem, a competitor's promotion. We automate the description and leave the interpretation to a person, with a draft to start from.

Is automating a report worth it if the report itself is wrong?

No, automating a bad report just delivers the wrong number faster and more confidently. If the underlying definitions are not agreed or the source data is unreliable, we will say so and propose fixing that first. That is often a smaller job than people fear, but it does have to come first.

What happens if a source system is late?

The report is held, not sent with a gap in it, and the responsible person gets an alert saying which source is missing and how late it is. A report that quietly omits a region is far more damaging than one that arrives two hours late with an explanation.

Can different recipients get different versions?

Yes, and they usually should. The same run can produce a full pack for the board, a regional cut for each manager containing only their own rows, and a one-line summary into a channel, all from one set of definitions, so the versions cannot disagree with one another.

What if we change accounting or CRM systems next year?

The connection to the source is a separate layer from the report itself, so a migration means rebuilding the feed rather than the pack. It is real work and we will not pretend otherwise, but it is contained, and your history stays in your warehouse regardless of what the old vendor does with your account.

Send us the report someone rebuilds by hand

Attach last month's version and tell us who receives it. We will tell you what can be automated, what should be cut, and how long it would take.

Start the conversation →

Explore more

The rest of Data & Dashboards

Live dashboards Connecting systems Forecasting & alerts ← All of Data