The client reporting cycle that eats your first week

Two or more people losing the first week of each month is the common shape. It never appears as a line item because it is absorbed by salaried time, which is exactly why it persists.

Put a number on it before you argue about tooling. Count the people, the days, and your own blended rate, then multiply by twelve. That figure is the budget for fixing it, and it is usually larger than anyone expected because nobody had ever added the months together.

There is a second-order effect worth naming. When reporting is expensive to produce, it gets produced as rarely as the contract allows. Clients see performance late, and interventions happen late.

Cheap reporting is faster reporting, and faster reporting is better account management. The argument for automation is not primarily labour cost; it is the shortened feedback loop.

The third effect is the one that shows up in retention. A client who receives numbers six weeks after the month they describe cannot act on them, so the report becomes a compliance artifact rather than a service. Nobody cancels over a report, and plenty of people cancel over the feeling that nothing is being managed.

The screenshots are what the client keeps, so they must be right. The commentary is what the client reads, so it must be human.

Automating the first frees time for the second. Automating the second is how reporting becomes noise: generated commentary is recognisable within two months, and it teaches clients the report is not worth opening.

The right split: a system that produces every number and page automatically, and a person who writes the two paragraphs saying what happened and what changes next month.

Give the person a fixed shape so the paragraphs are quick to write and hard to pad. Three sentences: what moved, why it moved, and what we are doing differently. A fourth sentence naming what we tried that did not work buys more credibility than any chart on the page, and it takes a minute.

A franchisee wants their own site, this month against last month, and the phone number. A corporate marketing lead wants the ranking across sites and the outliers. A CFO wants spend against booked revenue and nothing else.

One report serving all three serves none of them, which is why most reporting suites go unread.

Start by naming the audiences and the decision each makes with the report. Pages follow from that, and it usually reduces the number of charts substantially. Fewer charts that answer a question beat a dashboard that displays everything.

The test for whether a chart earns its place is whether any decision changes based on what it shows. If the answer is no, it is decoration, and decoration is the thing that makes the useful pages harder to find.

The viewer cost row is not a slight against Tableau, it is how the product is licensed. Tableau maps site roles to licence types, with even the Viewer role requiring at least a Viewer licence. That is correct for an enterprise with an analyst audience and wrong for an agency that wants forty franchisees to look at something once a month.

The third row is uncomfortable and worth taking seriously. Dashboards are better tools and worse deliverables. A link requires the client to decide to go and look; a designed PDF arrives.

The answer is usually both: a dashboard for the people who explore, and a generated PDF for the people who receive. Generated from live data into a designed document, so the PDF and the dashboard cannot disagree.

Budget size decides this more often than preference does. An independent shop or restaurant spending a few hundred dollars a month cannot carry a reporting surface that costs a meaningful fraction of the media, which rules out most of the table above and leaves a scheduled export and a short written note. That constraint is the defining one for main-street retail and hospitality in the ByWard Market and the Glebe.

Scheduled email is the mechanism most agencies reach for, and it has limits that are easy to hit at scale. Looker Studio's scheduled delivery sends the report as a PDF attachment with a preview and a link, and it caps a schedule at 50 recipient addresses. Free accounts carry daily and monthly email quotas, larger on Workspace accounts and lifted on the Pro tier.

For a single client that is irrelevant. For forty locations, each with a franchisee and a manager, on a schedule that also mails a corporate rollup, it is a design constraint you want to know about before the first month rather than during it.

The related constraint is freshness. A dashboard shows cached results, and the refresh interval is set per connector, with Google marketing products fixed at every 12 hours. That is fine, and it means a dashboard is never a live view of today. Say so in the footer rather than letting a client discover it during a call about this morning's spend.

Send the report on a fixed day rather than when it is ready. A predictable date makes the report part of the client's own cycle; an unpredictable one makes it something that arrives when your team has time, which is how it reads.

A report that publishes stale or wrong numbers silently is worse than one that fails visibly. Every pipeline should carry freshness and sanity checks (row counts against the prior period, spend reconciled to the platform, conversions bounded to plausible ranges) and a failed check should block publication and alert your team.

Write the checks against the failures you have actually had. A source that returns zero rows rather than an error. A currency that changes. A location that disappears from the data because someone renamed it upstream. Each of those is one line of validation and each has cost somebody a client conversation.

The rule underneath it: your team should learn a source broke before your client does. That single property is most of what separates a reporting system from a reporting habit.

The upstream half matters as much as the pipeline. Numbers can be delivered perfectly and still be wrong, because the events feeding them broke conditionally and nothing alerted. A reporting gate checks that data arrived; it cannot check that the data was ever correct.

For a franchise operator with more than fifteen clinics, that discipline is what made automated per-location quarterly reporting safe to send at all: each location's PDF generated from live data, with a corporate rollup on the same definitions.

Not the dashboard. First fix whatever makes the numbers untrustworthy, because automating an untrustworthy number just distributes it faster. If per-location figures are not comparable, close the attribution gap first.

Then decide whether the reporting layer needs a warehouse underneath it. If everything reads from one platform, it does not: a dashboard is genuinely enough more often than vendors admit.

Then build the reporting itself: scheduled pulls, one dashboard per audience, a generated PDF, and a runbook your team can operate without the person who built it. That handover is the point: automated client reporting that only its author can run is not automation, it is a dependency.

Measure the thing you were trying to fix. Days of senior time spent on reporting in the first week of the month, before and after. If that number has not moved, you have added a system on top of the manual process rather than replacing it, which is a common and expensive outcome.

The second measure is whether anyone reads it. A link in an email tells you almost nothing about that; a client who references a specific number on a call tells you everything. If nobody has quoted the report back to you in a quarter, the pages are wrong regardless of how automated they are.

The third is whether it survives a holiday. A reporting system that runs when its author is away is infrastructure. One that does not is a person with a spreadsheet and a nicer interface, and it will fail in the month you can least afford it.