To automate client reporting with AI, pull each client's numbers into a sheet with Make, send them to Claude through the API with a strict prompt, route the draft to a human for approval, then deliver by email or Google Doc. Add checks for empty data and failed runs before you trust it.
Key takeaways
- You can automate client reporting with AI using Make, Claude and Google Sheets, with no reporting platform required.
- Connect Claude to Make with an API key from the Anthropic console. It is separate from a Claude chat seat, so keep it in your agency's own account.
- Write the prompt so Claude uses only the numbers you send, names the source of each figure, and says when the data does not explain a change.
- Never let the AI send to a client. A named person approves every report, and delivery runs as a separate scenario.
- The worst failure is silent: a run that succeeds with zero rows. Add a row-count check that alerts a person and stops the run.
Most small agencies I talk to lose hours every month copying numbers into slides and writing the same three paragraphs about them. You can automate client reporting with AI without buying a reporting platform. This guide walks through the setup I would build for a 3 to 25 person team using Make and Claude: pull the data, have Claude draft the summary, have a person approve it, then send it. It also covers what breaks, because something will.
What this setup does and what it leaves to people
The goal is not a hands-off report. The goal is that a person reviews a good draft instead of building one from a blank page. The AI writes. A human signs off.
Here is the whole flow at a glance:
| Step | Tool | Output | Owner |
|---|---|---|---|
| 1. Data pull | Make + Google Sheets | One clean table per client | Ops lead |
| 2. AI summary | Make + Claude API | Draft in a fixed shape | Automation |
| 3. Human review | Google Sheet or Doc | Approved or edited draft | Account manager |
| 4. Delivery | Make + Gmail or Google Docs | Report sent and logged | Automation |
One honest warning before you start. If your numbers live in five places and nobody agrees which one is right, fix that first. Automating a messy process gives you a faster mess. If you are not sure reporting is the right first build, read what to automate first in a small agency.
The four-step build to automate client reporting with AI
Step 1: Pull the data into one sheet per client
Give each client a Google Sheet with a fixed layout. One tab holds this month's raw numbers. One tab holds this month next to last month. Keep the column names stable, because the prompt and every later step depend on them. In my experience, Claude writes a better summary from a small, clean table than from a raw platform export with forty columns.
Add a config sheet with one row per client: client name, analytics property ID, ad account ID, reviewer, recipient email, report day and tone notes. Every scenario reads from this row. When a client changes something, you edit one cell instead of hunting through modules.
Schedule the pulls with care. Google Analytics requests use up quota tokens, and Google's help page notes that a GA4 360 property gets 20,000 tokens per day, at most 5,000 per query, shared by every user of that property. Standard properties have their own limits, so check Google's current Data API quota page before you schedule many clients. Your dashboards and your teammates draw from the same pool. I space client runs out across the morning instead of firing them all at once.
Step 2: Send the numbers to Claude
Make has an official Anthropic Claude app. You connect it with an API key from the Anthropic console, which is separate from a Claude chat seat. Paying for Claude seats does not give you API access. Create the key in your agency's own Anthropic account so the billing and access stay with you.
The same page notes that Make's Simple Text Prompt module can send prompts without an Anthropic account or a connection in Make. That is handy for a first test. The trade-off is that the key and the billing are not in your name, so move to your own connection before real client data flows through it.
Pass Claude the comparison table as plain text, plus the client's tone notes from the config row. Ask for the answer back as JSON with fixed keys. A fixed shape means the review sheet always has the same columns, and you can spot a missing section at a glance.
Step 3: Route the draft to a human
Write each draft to a review sheet, one row per client, with a status column set to "Needs review." Include a link to the source table and the recipient email so the reviewer sees exactly where it is going.
The reviewer checks every number against the source table, edits the tone, answers any questions Claude raised, and changes the status to "Approved." Make the rule plain: nothing goes to a client without a named person approving it.
Step 4: Deliver and log
Build delivery as a second scenario. It watches for rows marked "Approved," fills a Google Doc template or an email, sends from the account manager's address, and writes the sent date back to the sheet. Keeping it separate means one stuck review never blocks the other clients, and a resend is one status change.
The prompt that keeps the summary honest
Anthropic's guide to reducing hallucinations points to a few core tactics: let Claude say it does not know, require citations, and use direct quotes. For a client report, that translates to three rules. Use only the numbers provided. Name the source of every figure. When the data does not explain a change, say so and ask the reviewer instead of guessing.
Here is a starting prompt you can copy and adapt:
You are drafting a monthly performance summary for {client_name}.
Use only the numbers in the table below. Do not calculate new figures except month over month change, and show the two numbers you compared.
Every number you mention must name the metric and the month it came from.
If the data does not explain why a number moved, do not guess. Write "Cause not in data" and add a question for the reviewer.
If a row is missing or shows zero, list it under questions_for_reviewer.
Tone notes: {tone_notes}
Return JSON with these keys: headline, wins, concerns, next_month_focus, questions_for_reviewer.
The questions field does a lot of work. It gives Claude a safe place to put uncertainty, and it gives the reviewer a short list of things to check first. If your team already has a brand voice setup in Claude, paste the relevant rules into the tone notes so the report sounds like you.
What breaks, and how to watch for it
Make handles some common errors on its own. Its error handling overview lists RateLimitError and ConnectionError as the two most frequent errors in running scenarios. It also explains that when incomplete executions are turned on, an error stops the scenario and the run moves to the "Incomplete executions" tab, where someone has to deal with it by hand.
Retries have a limit worth knowing. A retried incomplete execution restarts at the module that failed with the same settings as when the error happened. That works for a short outage. It does nothing if the problem is a wrong property ID or an expired login.
The failure that worries me most never shows as an error. In my experience, when a Google token expires or a property ID changes, a run can finish "successfully" and hand Claude an empty table or a row of zeros. Claude then writes a calm, confident summary of nothing. Make will not flag it, because nothing technically failed.
The fix is a row-count check. Right after the data step, add a filter: if the table has zero rows, or a core metric is zero when last month was not, stop the run and send an alert to a person.
| Failure | What you see | How to catch it | Fix |
|---|---|---|---|
| Rate limit or connection error | Run errors in history | Turn on incomplete executions | Retry after the outage |
| Expired token or changed property ID | Run succeeds, empty or zero data | Row-count filter that alerts and stops | Reconnect, update the config row |
| Analytics quota used up | Errors or gaps at busy times | Stagger client runs | Reschedule the run |
| Claude invents a cause | Draft reads well, claim not in data | Reviewer checks against the table | Tighten the prompt |
| Review stalls | Rows sit at "Needs review" | Daily digest of rows older than two days | Name a backup reviewer |
| Wrong recipient | Report goes to the wrong inbox | Recipient comes only from config, shown to reviewer | Lock edits to the config sheet |
A pre-launch checklist you can copy
- Each client has a sheet with fixed column names and a config row.
- The Claude connection uses an API key from your own Anthropic account.
- The prompt limits Claude to the provided numbers and returns fixed JSON keys.
- A row-count filter stops the run and alerts someone when data is empty or zero.
- Incomplete executions are on, and someone checks that tab weekly.
- Client runs are spaced out instead of scheduled at the same minute.
- Every draft lands at "Needs review" with a link to its source table.
- A named reviewer and a backup exist for every client.
- Delivery is a separate scenario that sends only "Approved" rows and logs the date.
- You ran two or three clients alongside your old process for one full cycle and compared results.
Costs and limits to check before you scale
There are three costs to plan for. First, your Make plan, and how AI modules count against it, so check Make's current pricing page before you add clients. Second, Anthropic API usage, which is billed apart from any chat seats, so check Anthropic's current model prices. Third, reviewer time, which does not go away and should not.
I am not going to quote an industry figure for hours saved on reporting, because I have not seen a reliable one. Measure your own. Time the old process for one cycle, then time the review step on the new one. That number is the one that matters to your team.
Doing it yourself versus getting help
If someone on your team is comfortable in Make and can protect a few focused sessions, you can build this yourself with the steps above. Start with one client, run it next to your current process, and add clients only after the checks catch a real problem.
Get help if nobody owns automations, if your data sources are a tangle, or if you have been burned by scenarios that broke quietly. Keeplight's AI Workflow Audit looks at every recurring workflow and tells you whether reporting is the right first build or whether something else should come first. You can see how that works in how to run an AI workflow audit. For teams that want it built and watched, Keeplight Care and Build plans monitor automations, including ones that run and quietly produce nothing, and anything that breaks is looked at within one business day. If you want to talk it through, book a free 20-minute intro call.
Frequently asked questions
Can I automate client reporting with AI without paying for a tool like AgencyAnalytics or Swydo?
Yes. Make, Claude and Google Sheets can handle the data pull, the written summary, the review step and delivery. You trade a polished dashboard for more control and lower tool overhead, and you take on the job of watching for failures yourself.
Do I need a separate Claude API key if we already pay for Claude seats?
Yes. Make connects to Claude with an API key from the Anthropic console, which is separate from a Claude chat seat. Create it in your agency's own account so the billing and access stay with you.
How do I stop Claude from making up numbers in client reports?
Tell it to use only the numbers you send, to name the metric and month for every figure, and to write "Cause not in data" instead of guessing. Give it a questions field for uncertainty. Then have a person check every number against the source table before anything is sent.
What happens when a Make scenario fails partway through?
With incomplete executions turned on, the run stops and moves to the Incomplete executions tab for someone to handle. A retry restarts at the module that failed with the same settings, so it helps with outages but not with bad inputs like a wrong property ID.
Should the AI send reports straight to clients?
No. A named person should approve every report before it goes out. Keep delivery as a separate scenario that only sends rows marked approved, so nothing reaches a client by accident.
How long does it take to build this setup?
In my experience, a first working version for one client takes a few focused working sessions for someone who knows Make. Plan on one full reporting cycle running alongside your old process before you trust it with more clients.
