Build the pipeline once, stop rebuilding the same report every week
How connected systems can turn recurring reporting from a Friday afternoon task into a background process.
Somewhere in your business there is a report that gets rebuilt. Every week, or every month, the same person exports the same three things, pastes them into the same spreadsheet, fixes the same broken column, and sends the same email. It takes two hours and it has taken two hours every week for three years.
The two hours are not the real cost. The real cost is that the report is always describing the past, always arrives too late to act on, and stops entirely whenever that person is on leave.
Why it never gets fixed
Because two hours a week never feels like enough to justify a project. It is exactly the wrong size: too small to schedule, too frequent to ignore. So it survives, quietly, indefinitely.
It also survives because the person who does it has become good at it. They know the column that breaks and they fix it without thinking. From the outside it looks solved. It is not solved — it is absorbed.
What a pipeline actually is
Nothing exotic. A pipeline is the same three steps that person does, written down once so that something else does them.
- Collect. Pull the numbers from wherever they live — the sales system, the website analytics, the spreadsheet, the payment provider — on a schedule, without anybody exporting anything.
- Reshape. Apply the rules that currently live in somebody's head. Which orders are counted. What a refund does. Which customers are excluded. This is the step that takes the longest to build, because it is the step where the rules get said out loud for the first time and turn out to be less settled than everyone assumed.
- Publish. Put the result somewhere people look — a dashboard, a message in the team channel on Monday morning, a document that updates itself. Not an attachment on an email, which is a copy the moment it is sent.
Once those three exist, the report is not produced. It is simply there.
The arguments are the valuable part
The uncomfortable, genuinely useful thing about building one of these is that it forces agreement.
Halfway through, someone will ask whether a sale counts when it is invoiced or when it is paid. Two people will answer differently, and both will be surprised the other thought otherwise. They have been reading the same report for two years believing different things about what it said.
This happens almost every time, and it is worth the exercise on its own. A definition written into a pipeline is a definition the business has actually made — as opposed to a convention that varies by whoever is compiling the numbers that week.
What to be careful about
Do not automate a report nobody reads. Ask first. A surprising number of recurring reports are produced out of momentum for someone who stopped needing them.
Do not hide the workings. A number nobody can trace back is a number nobody will trust the first time it looks wrong. Whatever you build, it should be possible to ask "where did this figure come from?" and get an answer.
Do give it an owner. Something that touches four systems will break when one of them changes, and the failure of an automated report is that it silently reports nothing, or worse, reports something stale as if it were current. Someone has to be told when it breaks, and that someone has to be a person, not a folder.
Do start narrower than feels satisfying. One report, the one that is rebuilt most often. Not a dashboard for the whole business.
A report that assembles itself changes what it is for. When it costs nothing to produce, you can afford to look at it on a Tuesday, when there is still time to do something.
The compounding bit
The first pipeline is mostly plumbing — connecting to systems, agreeing definitions, handling the awkward cases. The second is much faster, because the connections and half the rules already exist. By the third, the work is almost entirely deciding what you want to know.
That is the shift worth aiming at. Not saving two hours a week, though you will. Moving the business from reconstructing what happened to being able to ask a question and get an answer while it still matters.