The Monday summary that took half a day, already sitting in the inbox
Numbers pulled, commentary written, exceptions flagged, sent. Nothing to log into and no habit to form. For most of our clients this quietly does more work than the dashboard does.
In short: We take the recurring reports your team assembles by hand and generate them instead, with the commentary written, the exceptions called out at the top, and the whole thing delivered to an inbox or a chat channel on a schedule. Push beats pull, and that is the entire argument.
Push beats pull, and it is not close
Anything that depends on a busy person forming a new habit loses to something that simply arrives. That is the least glamorous finding in this whole field and the most reliable one. A dashboard asks three things of a reader: remember it exists, decide to open it, then work out what the charts are saying. A report asks nothing. It is already open on a phone in a car park before a site visit.
We build plenty of dashboards and we stand behind them. But we can see the usage data, and the pattern repeats across clients: the two or three people who asked for the dashboard use it constantly, and almost nobody else logs in twice. The report goes to forty people and gets read by most of them. If you only have budget for one, take the report.
Assembled, not exported
It pulls from the source systems, applies your agreed definitions and does the joins somebody used to do by hand in a spreadsheet on Monday morning.
Commentary written in
Sentences saying what moved and by how much, drafted from the same figures that fill the tables, against rules you set about what deserves a mention.
Exceptions at the top
Anything outside its normal range is raised in the first paragraph rather than left in row 214 for a careful reader to notice.
Delivered where you already are
Email, Slack, Teams, or a formatted PDF dropped into a shared drive for a board pack. The point is that nobody has to go anywhere new.
What the commentary can say, and what it cannot
The written part is where a language model earns its place, and also where it can do the most damage if left unsupervised. So we fence it in. Every figure that appears in a sentence comes from the query that produced the table beside it; the model is never asked to calculate anything. It describes what happened, quantifies it, and attributes the movement where an attribution is actually present in the data.
Where it is not present, the report says the driver is not visible in this data and moves on. That is a deliberately unsatisfying sentence. It is also the reason people still trust the commentary a year later, because it has never once told them something confident and wrong. A report that guesses at causes is worse than a table of numbers, since the guess travels into meetings while the uncertainty stays behind.
Exceptions are the actual point
Most weeks a recurring report says nothing new. Volume was ordinary, margin held, the same three customers accounted for the same third of revenue. The value of the whole arrangement is concentrated in the handful of weeks when that is not true, and the job of the design is to make sure those weeks are impossible to miss.
Some thresholds are fixed because a person has decided on them: any order above a certain value, any account with nothing invoiced for sixty days. Others are learned from the data, comparing this week against the normal range for this week of the year rather than against a flat average that a seasonal business will breach every December. Then we tune the volume down. Deliberately. An alert stream that fires every day is one nobody reads by month six, and a threshold set high enough to be believed is worth more than one set low enough to be complete.
Which report we automate first
We look for the one somebody rebuilds by hand every week. It usually has a named owner, a slightly resentful tone attached to it, and a filename ending in v7 final. We ask how long it takes, how often it runs, and what happens on the weeks that person is on holiday. The report with the highest hours per month goes first, because the payback is measurable and it buys goodwill for the less obvious work that follows.
How quickly it can be built depends almost entirely on where the numbers live. If they sit across four systems that have never been joined, the reporting layer is the easy half and the integration work is the real project. We will tell you which situation you are in during the first conversation, before anyone has signed anything. Once the pipeline exists, adding a second and third report costs a fraction of the first, and adding a forward-looking section becomes a small extension rather than a new engagement.
What we won’t do
We won’t automate a report nobody reads
The first question is who opens it and what they do next. Sometimes the honest answer is that the report should stop existing, and we will say so. Retiring it is a better outcome than paying us to send it faster.
We won’t let the commentary explain a cause the data cannot show
It will state that the driver is not visible rather than offer a plausible story. Clients sometimes ask us to loosen this. We have not, because a report that invents reasons is only useful until the first time somebody checks one.
We won’t send more alerts than a person will actually read
If the thresholds you want would produce something every day, we will argue for raising them and missing the small stuff. Complete coverage that gets ignored catches nothing at all.
Which report does somebody rebuild by hand every week?
Tell us what it contains, where the numbers come from and who reads it. If it is worth automating we will say so, and if it is not we will tell you that too.
Yes, and it is one of the more common uses. Client-facing output sits on a separate template with its own approval step, so a person signs off before anything leaves the building. Internal reports usually send without review once they have settled down and people trust them.
What if the numbers look wrong one week?
Every figure traces back to the query that produced it, and where the source systems allow it we include a link straight into the underlying rows. Most apparent errors resolve in a couple of minutes. If it turns out to be a pipeline fault, finding it in a Monday report is far better than finding it in a board meeting.
Do we need a dashboard as well?
Often not. Reports serve people who need to know what happened. Dashboards serve people who need to poke around and ask why. If your team is mostly the first group, start with reporting and put the money you save into the data work underneath.
What does it cost to run each month?
Running cost is small next to the build, because the pipeline does the heavy lifting and the writing step is short. We size it against how often the report runs and how much data it touches, and we give you that figure before the build rather than on the first invoice.
