# How to Automate a Weekly Report People Actually Read

*How-to — 2026-11-02 — by Mahmoud Zalt*

Automate the weekly report end to end, from data pull to delivery, and lead with the answer and the exception so it stops going unopened.

**Short answer.** **Automate a weekly report in two halves: a scheduled pull that assembles the numbers, and a short written summary that leads with the answer and the exception.** The pull is the easy half, and every tool you already own can do it. The summary is the half that decides whether anyone opens the email, and it is the half most teams skip.

Here is the test that matters. Send next Monday's report with one number quietly wrong, and see how long it takes for someone to say something. If the answer is never, you do not have a reporting problem to automate. You have a report nobody reads, and speeding that up just wastes time faster.

That is not a reason to stop reporting. It is a reason to change what you send. People do not want a weekly dashboard tour. They want to know whether things are on track, and what broke that they did not already hear about. Two things. Everything else is backup material.

## What is a weekly report actually for?

A weekly report exists to trigger a decision or to prevent a surprise. That is the whole job. If a section of your report has never once caused someone to act differently, it is not reporting, it is record keeping, and record keeping belongs in a database rather than in somebody's inbox on a Monday morning.

Try this before you automate anything. Take last month's four reports and mark every section that changed a decision. Most teams find two or three sections carrying the whole thing, and eight sections that exist because someone asked for them a year ago. Automate the two or three. Retire the rest, or move them to a page people can open when they are curious.

## Which parts of a weekly report can be automated?

Collecting, assembling and delivering are fully automatable with tools you already pay for. Interpreting and chasing are the parts that stay human unless something can read context, and they are also where the time actually goes. Splitting the job this way tells you where to spend your setup effort.

| Stage | What it involves | How automatable |
|---|---|---|
| Collect | Pulling numbers out of the CRM, the analytics tool, the finance system, the project tracker | Fully. Every major tool schedules an export or an email. |
| Assemble | Putting the numbers into one consistent shape, week over week | Fully, once the shape is fixed and stops changing. |
| Interpret | Saying what moved, what broke, what it means, what to do | Only with something that knows what normal looks like. |
| Deliver | Getting it in front of the right people, in the place they read | Fully. Schedule it, do not send it by hand. |
| Chase | Getting the two people whose input is missing to reply | Partly. A reminder is easy, a persuasive nudge is not. |

## How do you build the automated version?

Start from the delivery end, not the data end. Decide who reads it, in what channel, and what decision it should trigger. Then work backwards to the smallest set of numbers that supports that decision. Building forwards from the data is how reports end up with nine sections and two readers.

### Building a weekly report that runs itself

1. **Name the reader and the decision** — One reader, one decision. If the same file serves the board, the team and a client, you have three reports pretending to be one, and all three are worse for it. Write the sentence: after reading this, [person] should be able to decide [thing].
2. **Freeze the shape** — Same sections, same order, same units, every single week. A reader who has to relearn the layout will stop reading by week four. Freezing the shape is also what makes the automation possible, because a stable shape is just a template with holes.
3. **Schedule the pull from each source** — Use the native scheduler wherever one exists. Most business tools have one, and a native schedule is one fewer moving part than a middleman. Where there is no scheduler, a script on a timer will do the same job.
4. **Assemble into one place** — A sheet, a doc, a page. It does not matter which, as long as it is the same one every week and the history is preserved. The history is what makes this week's number mean something.
5. **Write the top three lines last** — The answer, the exception, and the ask. This is the only part a reader is guaranteed to see, so it gets written after the numbers land, not before. If nothing broke, say that explicitly rather than leaving silence.
6. **Deliver where they already are** — An email that lands at the same hour every week beats a link to a dashboard someone has to remember to visit. Put the summary in the body of the message, not behind a click.

The native schedulers are better than most people realise, and they are free with software you already have. Salesforce lets you subscribe yourself and other users, groups or roles to a report on a schedule you set, with attachments in a formatted spreadsheet or a details file. HubSpot's recurring emails for reports and dashboards offer daily, weekly or monthly, with a choice of day and time.

On the Google side, Looker Studio schedules a PDF of a report from Share, then Schedule delivery, where you pick recipients, pages, a start time and a repeat pattern, including a custom option for something like every Tuesday and Thursday. Google Apps Script covers everything else with time-driven triggers that run from once a minute to once a month.

**Scheduled does not mean punctual to the minute.** Google's Apps Script documentation notes that trigger times are slightly randomised. Create a recurring 9am trigger and Apps Script picks a time between 9am and 10am, then keeps that timing consistent day to day. Salesforce also caps how many subscriptions each user can hold, at seven reports and seven dashboards on most editions and fifteen on Unlimited. Neither is a problem, but both will bite if you promise someone a report at exactly 9am or try to subscribe one person to every report you own.

Once the plumbing runs, you will notice something slightly deflating. The report arrives on time, it is accurate, and the open rate barely moves. That is because you automated the delivery of a document whose first screen still asks the reader to do the interpreting. Fixing that is a writing problem, not a tooling problem, and it is worth more than everything above.

## How do you make a weekly report get read?

Lead with the answer and the exception, in that order, in the first three lines. On track or not. What broke. What you need from the reader. If a busy person reads only those three lines and stops, they should still have got the point of the entire report.

Then keep it to one screen. Not one page, one screen, on a phone. Everything else becomes a link at the bottom for the person who wants to check your working. Almost nobody clicks it, and that is fine, because its job is to make the summary trustworthy rather than to be read.

One more habit that changes everything: name a person next to every exception. Not a team, a person, and what they will do by when. An exception without an owner is a complaint. An exception with an owner is a decision, which is the only reason the report exists.

Writing that summary week after week is the part we handed to software. A [Sistava](/features) AI Employee connects to the same sources your report pulls from, learns what a normal week looks like for your business, and drafts the three lines at the top along with the numbers underneath. You edit it if it missed the nuance, which takes minutes rather than the whole afternoon.

## What automating a weekly report will not fix

Automation is an amplifier. It makes a good report cheap and a bad report frequent. These are the failures it cannot touch, and each one is worth checking before you build anything.

- **It will not create trust in the numbers. **If two systems disagree about revenue, a scheduled email just delivers the disagreement faster. Reconcile the sources first.
- **It will not give you a reader. **If the report goes to a distribution list assembled by accretion, trim it. Five people who need it beats twenty who tolerate it.
- **It will not replace the conversation. **A report can surface a problem. Only a person can walk into a room and argue for a different plan because of it.
- **It will not know what is unusual on its own. **Any system that flags exceptions needs a baseline, and building that baseline takes a few weeks of history before the flags mean anything.

If you want a single change that pays off before you automate anything, it is this: cut the report in half, and put the two things you cut back only if someone asks. Most of the time nobody does, which tells you everything about what was worth automating. If you would rather hand the whole rhythm over, the cost of running it on [Sistava](/pricing) is worth comparing against the hours the report currently takes someone every week.

## FAQ

### How do I automate a weekly report for free?

Use the schedulers already inside the tools you pay for. Salesforce subscriptions, HubSpot recurring dashboard emails and Looker Studio scheduled delivery all cost nothing extra on the plans that include them. Google Apps Script covers anything left over with a time-driven trigger, and it is free with a Google account.

### What should a weekly report include?

Three lines at the top: are we on track, what broke, and what is needed from the reader. Under that, the small set of numbers that supports those three lines, shown against the previous week so the change is visible. Anything that has never changed a decision should be a link rather than a section.

### Should I send a dashboard link or an email?

Send the summary in the body of an email or a message, and put the dashboard link underneath. A link asks the reader to start the work. A summary hands them the conclusion and lets them dig only if something surprises them, which is what most people actually do.

### How often should the report go out?

Match the cadence to the decision. If the decision it supports is made monthly, a weekly report is noise four times a month. Weekly works well for anything a team can change course on within a week, like pipeline, spending or delivery progress.

### Can a scheduled report run at an exact time?

Not always. Google's Apps Script documentation notes that a recurring trigger set for 9am will be given a randomised time between 9am and 10am, then kept consistent from day to day. Vendor schedulers such as Looker Studio and HubSpot let you pick a time, but delivery still depends on queues, so build in slack rather than promising a precise minute.

### How many people should a weekly report go to?

As few as possible, and each of them should be able to act on it. Large distribution lists lower the perceived responsibility of every recipient, so nobody follows up. If people want visibility without responsibility, give them access to the page rather than a scheduled email.

**About this guide.** The product behaviour described here comes from Salesforce, HubSpot and Google's own published documentation, checked on 17 August 2026. Sistava is not affiliated with any of them. Interfaces, limits and plan availability change, so confirm the current steps in each vendor's documentation before relying on them.

## Sources

- [Salesforce Help, ](https://help.salesforce.com/s/articleView?id=analytics.reports_subscribe_lex.htm&language=en_US&type=5)Subscribe to Reports in Lightning Experience
- [Salesforce Help, ](https://help.salesforce.com/s/articleView?id=000383344&language=en_US&type=1)Report or Dashboard Subscription Limit Reached
- [HubSpot Knowledge Base, ](https://knowledge.hubspot.com/dashboard/email-or-export-reports-and-dashboards)Share or export reports and dashboards
- [Looker Studio Help, ](https://support.google.com/looker-studio/answer/9263641?hl=en)Schedule automatic report delivery
- [Google for Developers, ](https://developers.google.com/apps-script/guides/triggers/installable)Installable triggers in Apps Script

**Tags:** weekly-report, reporting, automation, status-report, ai-employee