AI Client Summaries From Project Data: A Guide

Most agencies write client summaries the same way: someone opens the project board on the last Thursday of the month, scrolls back through four weeks of tickets, tries to remember why the content sprint slipped, pastes a rankings screenshot, and writes 400 words of narrative. Multiply that by twelve retainers and you've spent a full day of senior time reformatting information that already exists in your system.

AI client summaries fix the writing, not the knowing. That distinction matters. A language model can turn structured project data into a readable monthly recap in seconds, but it cannot tell you what happened on an account where the work was never logged. The quality ceiling is set by your data hygiene, not by your prompt.

Here's the workflow that actually holds up in production.

What counts as "project data" for a client summary

Before you touch a prompt, decide what the model is allowed to see. A useful input snapshot for one client, one month, contains five things:

• Completed work items — task title, workstream tag (technical, content, links, reporting), completion date, and the one-line outcome note.
• Hours by workstream — from your time tracking, not from memory. "Technical SEO: 11.5h, Content: 22h, Reporting: 4h" against a 40-hour retainer.
• KPI deltas — non-brand clicks, impressions, average position for the tracked set, conversions, and the comparison window you're using.
• Blockers and dependencies — anything waiting on the client, with the date it started waiting.
• Next period's committed scope — the top three to five items already planned.

That's it. If a fact isn't in those five buckets, it shouldn't appear in the summary. This constraint is what separates a defensible AI-generated recap from a plausible-sounding hallucination.

The exports that make this painless

The friction is almost always in assembly. If it takes you 25 minutes to build the input snapshot, you've saved nothing. Standardise your task naming and workstream tags once, and the export becomes a two-click job. Agencies running audits converted into tagged to-dos rather than PDF deliverables get this almost for free — the audit findings, their status, and the hours against them are already structured.

The three summaries clients actually want

Don't build one prompt. Build three, because the audiences differ.

1. The weekly pulse (150–200 words)

For the day-to-day marketing contact. Shipped this week, in flight, waiting on you. No metrics commentary — a week is noise. This one can be near-fully automated because the format never changes.

2. The monthly retainer recap (500–700 words)

For the marketing manager who has to justify the invoice internally. Hours delivered against hours contracted, work completed grouped by workstream, KPI movement with honest attribution, blockers, and next month's plan. This is where AI saves the most time and where review matters most.

3. The quarterly review narrative (900–1,200 words)

For the director or founder. Three months of data compressed into a story about direction: what we bet on, what worked, what we're reallocating. AI drafts the chronology; a human writes the argument. Never ship this one unedited.

A prompt structure that survives contact with real accounts

The prompts that fail are the ones that say "summarise this project data for a client." The ones that work are closer to a spec sheet. Four components:

1. Role and audience. "You are writing for the in-house marketing manager at a mid-market B2B SaaS company. They are not technical. They report this summary upward to a CFO."
2. Hard data boundary. "Use only the figures in the DATA block. If a metric is missing, write [MISSING: metric name] rather than estimating. Do not infer that any deliverable caused any metric change unless the DATA block states a causal note."
3. Fixed structure. Give it your actual section headings and target word counts per section. Consistency month over month is worth more to the client than elegant prose.
4. Tone constraints. "No superlatives. No 'we're excited to.' Lead each section with the outcome, not the activity. Flag underdelivery explicitly."

That last instruction is the one agencies skip and shouldn't. If you delivered 31 hours against a 40-hour retainer, the summary should say so and explain why — client-side delays, a paused workstream, hours banked. A model that only reports good news trains clients to distrust the whole document.

Worked example: 40 tickets into a monthly recap

Take a typical month on a £4,000 retainer. Your export shows 38 completed items, 37.5 hours logged across four workstreams, non-brand clicks up 14% month over month, one blocker (dev team hasn't shipped the schema changes from the audit — 23 days waiting), and four items committed for next month.

The raw ticket list is unreadable: "Fix 301 chain /resources/*", "Draft brief — comparison page", "QA meta titles batch 3." The model's job is grouping and translation. Good output turns those 38 lines into four paragraphs:

• Technical (11.5h): "We resolved 19 redirect chains across the resources section and corrected metadata on 40 product pages. The schema markup recommended in February's audit remains unshipped — this is with your development team and has been open 23 days."
• Content (18h): "Three briefs delivered, two articles published. Both published pieces are indexed; neither has accumulated enough impression data for a position read yet."
• Performance: "Non-brand clicks rose 14% versus January. The tracked keyword set moved from average position 18.4 to 16.1. We are not attributing this to February's publishing — the timing is too tight."
• Delivery: "37.5 of 40 contracted hours used. The 2.5-hour shortfall reflects the paused schema work; these hours carry into March."

That's the standard. Notice the refusal to claim credit in paragraph three — a human would have been tempted, and the AI won't be if you tell it not to be. This is the same discipline needed when connecting search data to project milestones: correlation in a 30-day window is usually just correlation.

Guardrails: the four things AI must never do

Write these into your prompt template and your QA checklist:

• Never invent a number. Missing data gets a bracket flag, not an estimate.
• Never assert causation. "Following the technical fixes, clicks increased" is fine. "The technical fixes drove a 14% increase" is a claim you'll be held to.
• Never commit to a date that isn't already in the project plan.
• Never soften a blocker. "Pending client input" hides a 23-day delay that will become an argument in month four.

The broader point is that AI in agency operations works best on bounded, repetitive translation tasks — which is exactly the framing in our piece on what AI changes for agency operations. Summarisation is bounded. Strategy is not.

Where this breaks

Three failure modes, in order of frequency.

Untracked work. If your team logs "Client work — 6h" instead of tagged tasks, the summary will be vague because the input is vague. Fix the logging before you blame the model.

Inconsistent task naming. "Meta descriptions" in one sprint and "SERP snippet optimisation" in the next means the model groups them separately. Pick a vocabulary and enforce it in your templates.