Automate Marketing Reporting: From Monday Panic to Standing Fact

In most 10–150-person companies, marketing reporting is a person. Every Monday someone spends two to four hours exporting from the ad platforms, pasting into a spreadsheet, fixing what broke since last week, and assembling a document that is obsolete by the meeting it was built for. When that person is on vacation, the company flies blind and mostly doesn't notice — which tells you what the report was worth. Automating this is some of the highest-yield operations work I do, and the yield is not the hours saved. It is that decisions start being made on numbers that arrive on time, the same way, every week.

First: decide what a metric means, in writing

Automation exposes ambiguity that manual reporting papered over. The person assembling the spreadsheet was quietly making judgment calls every week — which conversions count, whether brand campaigns are included, what "lead" means this month. A pipeline cannot make judgment calls, so the calls must be made once, explicitly. I write a metric contract before building anything: each number's name, exact definition, source system, owner, and the decision it exists to inform. If no one can name a decision a metric informs, it does not go on the report. This document is usually one page, takes a contentious afternoon to agree, and is worth more than the automation itself — it is the reason the numbers stop being argued about in the meeting.

The plumbing, sized for a small company

You do not need a data warehouse at this size. You need the numbers from four or five systems landing in one place on a schedule. My default build: n8n (or Make) pulls from the ad platforms' APIs, analytics, and the CRM on Sunday night; normalizes to the metric contract; writes to a single store — a database table if engineering exists, a structured sheet if not; and posts the report to where the team already lives, usually Slack or email, Monday at 7. HubSpot's own reporting covers a surprising amount of this when HubSpot is genuinely the system of record — one more argument for the consolidation I push in the RevOps build.

Rules that keep the plumbing trustworthy:

• Pull from APIs, never from emailed exports. An export is a person with extra steps.
• Store the raw pull before normalizing. When a number looks wrong — and one will — you need to know whether the source or your math changed.
• Fail loudly. A pipeline that silently posts stale numbers is worse than no pipeline. Every fetch checks freshness; a failed source appears on the report as "data missing since Thursday," never as last week's figure wearing this week's date.
• Reconcile monthly against the platforms' own dashboards. Attribution windows and API quirks drift; fifteen minutes a month catches it.

The AI layer: narrative, anomalies, and nothing else

Numbers alone get skimmed. The useful additions are the two things a good analyst would say about the numbers, and both automate well. First, the delta narrative: a model receives this week's metrics, the trailing eight weeks, and the metric contract, and writes six sentences — what moved, against which trend, in plain language, with an explicit "worth a look" flag on anything outside its normal range. Second, anomaly context: for each flagged number, the pipeline attaches what else changed that week from a simple change log (campaigns launched, budgets shifted, site deploys) so the meeting starts at "the spike coincides with Thursday's landing-page change" instead of at archaeology.

The guardrail matters more than the feature: the model narrates, it never calculates. Every figure in the prose is substituted from the pipeline's own numbers, not generated — a model asked to do arithmetic in prose will eventually, confidently, get one wrong, and one wrong number costs the report its credibility for a quarter. Same principle I hold everywhere AI touches operations, from qualification to content: the model proposes and explains; systems of record do the recording.

The ritual is the product

An automated report nobody discusses is a scheduled email. The asset is the thirty-minute Monday review run from the report: one owner per metric speaks to their flagged items, one decision minimum leaves the room, and the decision gets a line in the change log — which feeds next week's anomaly context, closing the loop. I hold the meeting to the report and the report to the meeting: any number that hasn't driven a decision in a quarter comes off, per the contract, and any recurring question the report can't answer becomes a candidate metric. The report stays under fifteen numbers this way, permanently. Growth in report length is drift in disguise; it means questions are being added faster than they are being retired, which is how you get the forty-metric dashboard that informs nothing — the exact failure my week-one audit checks for.

What this replaces, measured honestly

The build takes one to three weeks of part-time focused work depending on how many sources need connecting, and it retires two to four hours of weekly assembly labor immediately — that part is just arithmetic. The compounding return is subtler: numbers that arrive identically every week develop authority that hand-assembled numbers never had, disagreements shift from "whose figure is right" to "what should we do," and the reporting habit survives personnel changes because it no longer lives in anyone's muscle memory. In my engagements this is reliably the first automation I ship, before anything more glamorous, because every later piece of work — funnel fixes, budget shifts, the whole operations-first rebuild — gets easier to justify and faster to verify once the instruments are trustworthy. Instrument first. Everything else is flying by feel.