How to automate client reports (without a template).

You produce the monthly client reports. The job description is clear: each month, the same objective, N reports out the door. The plan to automate client reports is always the same, and it sounds reasonable: one template, some numbers, company branding, done. Built once, you tell the data team to plug the data in and the manager to validate the output. Next month, push the button and you're free.

Well, that's not really what happened.

At a high level it looks simple. Every engineer familiar with this environment sees the complexity it reveals. The data is never ready on time. Part of it is missing. Misshaped data breaks the template. One custom element breaks the whole thing. Last-minute demands arrive after the numbers are frozen. And there is too much data to narrow down by hand, so one break takes the rest with it.

Why monthly client reporting takes so long

It depends on how many reports you produce, and the segments behave differently: small is 1 to 10, medium is 10 to 100, large is 100 and beyond, often with the volume spread across different templates.

Small stays manageable: about a day to produce, about 30 minutes per change. Medium becomes serious: about a week to produce, 1 to 3 hours per change. Large is a real scale issue: about a month to produce, 2 to 3 days per change.

Read that last line with a monthly cycle in mind. When production takes a month, the current report production drifts into the next one. You are never finished, you are always late on the month that already started.

One honesty note on those numbers: we never really timed this with discipline. They come from experience and industry tendencies, and they vary a lot depending on the complexity of the reports and how the organisation is set up. The same imbalance shows up inside a single report, where producing the document takes about as long as the analysis it presents.

The question nobody owns: is the batch correct?

Then the batch goes out and the regular question arrives: did the huge mass of reports we just produced come out correct? So many edge cases we might not spot. It looks good, but how can we prove it? Is anything missing?

In most teams the honest answer is a hope: hope that no formatting or wording issue reaches the client.

And the shape of the problem is not technical. Data producer and consumer ask each other the same question, is the data ok, and both think the other is actually responsible for it. Nobody is. There is nothing in the middle.

Build the report first, then the pipeline

They automate the data, nobody automates the document. That is what the tools in this category sell: connectors, refresh, scheduling, delivery. The document itself is treated as already solved.

Look at how these systems get built. Classically:

data -> pipe -> (some kind of validation) -> report

which is weird, because the expected result is actually the report, and it is not the part where we put the maximum effort. (Pipe here is whatever moves the data: a data platform, a data warehouse, a CSV in an email.)

So maybe:

report <- (some kind of validation) <- pipe <- data

Same four pieces, opposite order of decision. Start at the report: what it must say, what it must show, how it is laid out. Then define what correct means for it, the checks that answer "is this batch right", the thing nobody owns today. Then the pipe, which now has a shape to hit, so misshaped data gets caught instead of rendered. Then the source, where late or partial data becomes a named failure instead of something the client finds.

What Pressentable does today, and what it doesn't

Pressentable is still alpha and a much bigger version is under development. Of the four steps above it does the first two: the report is defined first, as a config rather than a template, and that config is validated before anything renders.

The re-render already works: I changed the numbers, saved the report as new, and it came out almost instantly.

One report is not a batch, though. At small volume this is convenience. The medium and large cases, the ones where a month of production eats the next month, are where this has to land, and it hasn't yet.

Step 2 is not automated either. The checks that would answer "is this batch correct" are the next thing we build, under the codename skeletor, which might change. To be honest about where it stands: it is a design, not code. None of it ships in the alpha today. It is the part I am committing to, because it is the half nobody else is building.

The same report, two months

Here are two editions of the same client report: July and August. Same structure, same layout, new numbers.

Pressentable is in alpha and priced like it: twenty founding seats at $15 a month, at a price that never rises.