Automated Social Media Reports, and What Belongs in One

Every Monday you open the same four tabs, copy the same numbers into the same spreadsheet, and send it to somebody who does not open it. The pulling is not really the problem. The report is.

Automated social media reports only save you anything if the thing arriving on a schedule is worth reading. The tooling question, how do I get a report to send itself, is answered on every vendor’s help page. The editorial question, what belongs in it, is the harder one. So this goes in that order: the template, the cadence, the metrics, then the delivery. Reporting is the cheapest of the workflow patterns to build and usually the last one anybody builds.

Why scheduled reports get ignored

A report nobody reads fails in one of three ways, and almost always the same one.

Too many metrics. Twenty rows of numbers is not thoroughness, it is a refusal to decide what matters. The reader cannot tell which figure they are supposed to react to, so they react to none of them. Three numbers you are willing to defend beat a dashboard export every time, and a dashboard export is exactly what a scheduled report defaults to, because the tool will happily send you everything it has.

No comparison. A number on its own carries no information. Reach of 14,000 is good, bad or irrelevant depending on what it was last week and what it was in the same week last quarter. Every figure needs a period comparison attached to it or it should not be in the report. This is the failure that survives automation best, because a tool that pulls one period is easier to build than one that pulls two.

No recommendation. The report tells the reader what happened and leaves them to work out what to do, which is the part they were paying you for. If nothing in the document commits you to a change, you have sent a receipt. Receipts get filed. Decisions get discussed. Fix this one first even when the reader is your own team, because it is the reason automating social media properly ends up being judged on reporting rather than on publishing.

The weekly report template

Five blocks, in this order, on one page. If it does not fit on one page, cut a block rather than shrinking the type.

Weekly social report: the five blocks

1. What changed. Two or three sentences in plain language, written last and read first. “Reach fell about a fifth because we published four times instead of seven. The four that went out did better per post than last week’s seven.”
2. Three headline numbers, each with a trend. The same three every week, each shown against the previous period and marked up or down. Changing which three you report is how a report loses its trend.
3. Best and worst post, with a reason. Not the two numbers. The two posts, with one sentence each on why you think it went that way. A guess, labelled as a guess, is more useful than a ranking with no explanation.
4. One thing we are changing. Singular. A change you will have made before the next report, so next week’s version can say whether it worked.
5. Anything that needs a decision. The only block allowed to be empty, and the one that gets the report opened. Budget, approval, a dropped account, a policy question. Name who has to decide and by when.

Blocks two and three are the only parts a machine can fill. Blocks one, four and five are yours, and they are the reason the report gets read. That split is the design: automate the retrieval and the layout, keep the judgement manual. A fully generated report is a dashboard with a covering email, and your reader already has a dashboard they do not open.

Two rules that keep the template usable for longer than a month. Fix the three headline numbers in advance and keep them fixed for at least a quarter, even in a week where a different metric would flatter you. And write block one into the same field every week, in the same place, so the person skimming on a phone gets the answer before they get the numbers.

If the queue behind the report is fed by a repurposing pass, tag each post with the source it came from. Then block three can tell you which source earned the attention, which is the only way blog-to-social repurposing gets measured rather than assumed.

Weekly versus monthly versus quarterly

Three cadences, three different jobs. Sending the same content at all three is how two of them become noise.

Weekly is operational. Did the plan happen, and what are we doing differently in the next seven days. Short, same shape every time, no narrative. A week is too short a window to show anything about strategy and exactly the right window to catch a queue that stopped publishing on Wednesday.

Monthly is pattern-finding. Four weeks of posts is enough to say something about format and timing rather than about single posts. This is where you compare content types against each other, look at which accounts are diverging, and retire the thing that has been quietly underperforming since August. Leave the week-by-week operational detail out: it has already been read.

Quarterly is strategy. Three months in, you can ask whether the channel mix is right, whether the effort matches the return, and whether anything should stop. This is the only cadence where the honest answer might be “stop doing this”, which is why it is the one worth putting in front of whoever controls the budget. It is also the natural place to work out whether automation paid off, a quarter being the shortest window in which setup time can have been repaid.

Cadence	The question it answers	What goes in	What to leave out
Weekly	Did the plan happen, and what changes now	Three fixed numbers with a trend, best and worst post, one change, open decisions	Narrative, channel strategy, anything you cannot act on inside a week
Monthly	What pattern is forming	Format and timing comparisons, per-account divergence, what to retire	Individual post detail, week-by-week operational notes
Quarterly	Is this worth continuing in this shape	Channel mix, effort against return, recommendations to start or stop	Everything a weekly report already covered, and any metric you cannot explain

Which metrics to report

Pick three for the weekly report. These are the candidates worth arguing about, roughly in order of how much they tell you.

Engagement rate, not raw engagement. Raw engagement rises with reach, so a post that got pushed to more people looks better than a post that landed harder with fewer. Dividing by reach or impressions removes that, and it is the single change that makes a weekly number comparable week to week. Write the formula you used next to the number. Change the denominator and the number stops comparing, which is also why two sources can disagree without either being wrong.

Reach, with impressions kept separate. Reach is people, impressions are views, and collapsing them is the commonest error in a hand-built report. Report whichever your source returns, named as that source names it, and do not add two platforms together if they count differently.

Saves and shares. The most informative and least reported pair. A save or a share costs the reader something, which makes them a better signal of whether the content was worth the attention than a like. If you only add one metric to an existing report, add these.

Click-through, when there is something to click. Useful on the posts that carry a link and meaningless as an account-level average, because it mostly tracks how many of your posts had links. Report it per post or per campaign, never as a monthly blend.

Follower change, last and smallest. It is the weakest number in common use: slow to move, easy to inflate, and almost never the thing you changed. Keep it as a one-line footnote so nobody thinks you are hiding it, and never make it a headline number.

On what is safe to show a client: a metric is client-safe when you can explain it in one sentence, say where it came from, and reproduce it next month from the same place. That rules out anything a tool computes without documenting how, anything blended across platforms that count differently, and any figure you would caveat out loud. If a number needs a paragraph of explanation, it belongs in the email body, not in the three.

Automating the delivery

Three routes, in increasing order of effort.

Your scheduler’s own reports. Cheapest, and worth checking before you build anything, because what a vendor documents and what you assume it does are often different. Our own example: SchedPilot’s homepage documents report export and its white-label page documents branded client reports, but across both of those and all nineteen URLs in its developer documentation sitemap we found nothing describing a report that sends itself on a schedule. That is an absence from those pages rather than a claim about the product, and it is what to establish before promising a Monday email. Check yours the same way. Feature comparisons sit in agency-grade scheduling tools.

A workflow tool pulling into a sheet. Where most teams end up: a scheduled run reads the API, appends a row per post to a spreadsheet, and a template reads the sheet. The sheet is the useful part, because it accumulates history the platform will eventually stop giving you. Orchestrator trade-offs are in workflow tooling compared.

Budget your read calls before you design the pull. SchedPilot’s rate-limit guide puts reads at 60 GET requests an hour per user and writes at 30, tracked per user account rather than per address, and lists post analytics as one read unit per call. Analytics there is per post, so an hour’s reads cover fewer than sixty posts, and the window is rolling with no fixed reset at the top of the hour. Read that limit off the document for the exact path you are calling, though: the marketing API page says limits scale with your plan, starter plans getting 1,000 requests an hour, while the developer guide’s table mentions no plan at all. The two documents disagree and we cannot say which surface each governs. Both read 23 October 2026. Design against the lower number.

An email digest you assemble. The most work, and the only version that can carry blocks one, four and five. The sheet fills itself, you write three sentences and a recommendation into the top of a template, and the send is scheduled. Fifteen minutes a week, and it is the version that gets opened.

Recipients and timing matter more than they sound. Send to named people, not a distribution list: a list has no author and nobody replies to it. Land it before the meeting it feeds. And account for lag in the data when you pick the send time, because Facebook Page Insights refreshes every 24 hours.

Then decide in advance what the report does when a source goes missing, because it will. The rule that works: a report that cannot fill a block says so in that block and still sends. A blank cell reads as zero, and a zero is the most expensive character in an automated report. SchedPilot’s analytics reference makes that point about its own data, stating that metric availability varies by platform and that fields for unavailable metrics are returned as 0. Some gaps you cannot close: Meta’s developer documentation index lists no Groups API, so there is no documented route to pull numbers out of a Facebook Group, and a report promising Group performance cannot be sourced. The per-client version sits in scaling client work.

Reporting on the automation itself

Here is the sixth block, and it is how you find out your publishing stopped working three weeks ago. Four lines: posts published, posts scheduled, publish failures, and queue depth at the end of the period.

Platform analytics cannot give you these, and that is structural. Nothing in Facebook Page Insights’ metric list keys on how a post was published, so Insights can tell you nothing about your queue. The numbers come from the tool that holds it.

Look for a status filter on your tool’s post list. SchedPilot’s list-posts endpoint has one, and the documented statuses are scheduled, posted, failed, draft and pending_approval, with a date range and up to 100 per page. That is your four lines in one or two calls, and it is a different call from the analytics one: analytics there covers published posts only, and asking for a post that is scheduled, draft or failed returns an error instead. Which is the point. The report on whether the automation worked cannot be assembled from the report on how the content performed.

Failures deserve a push rather than a poll. SchedPilot’s webhooks guide documents two events, post.published and post.failed, the failure payload carrying an error message, and it is explicit about the limit: “Retries are not currently implemented. If your endpoint is down when an event fires, the delivery will be lost.” Its own advice follows, to log every event on arrival inside a five-second window. So use the webhook for alerting and the weekly status counts as the reconciliation that catches whatever it dropped. One without the other gives you a number you cannot trust or an alert you cannot verify.

Queue depth is the line that predicts rather than describes. Posts published tells you about last week. Twelve posts left in the queue on a Friday tells you which week the content runs out, and it is the only number in the report anybody can act on before the problem happens.

Where to start with automated social media reports

Build it in this order and it is an afternoon plus fifteen minutes a week.

Write the five-block template as an empty document first, before you touch any tool, and fill it by hand once. You will change your three headline numbers after doing it manually, and changing them later costs you the trend. Then automate blocks two and three only: one scheduled pull, appending to a sheet, with a period comparison built in from the start rather than added later. Add the automation block in the same pass: it is the same API call, and it is the block that pays for the project the first time a token expires quietly.

Leave blocks one, four and five manual permanently. That is not a staging decision you revisit. The three sentences at the top and the one change at the bottom are the report, and the numbers are the evidence for them. Get the cadence split right, send to named people, and the thing you are sending stops being a spreadsheet nobody opens.