Project Post-Mortem Email to a Client: 8 Templates

A project post-mortem email to a client is the message you send after a project closes to name what worked, what didn't, and what changes as a result — before the relationship moves on to the next engagement or ends for good. Get the order wrong and it reads as either a scorecard or a excuse. Get it right and it's the reason the client comes back.

This post gives you eight templates you can copy, edit the brackets, and send: the invitation to a joint retro, the findings summary, the commitments note, the shared-responsibility version for when the client's own decisions caused real delays, an internal-only draft you write but never send as-is, a short form for small projects, a post-call action-item follow-up, and an executive summary for stakeholders who missed the retro entirely.

When to send this email#

Send it within five to ten business days of project close, while the details are still fresh enough to be specific and before the client's attention has fully moved to whatever comes next. Waiting a month turns a retrospective into an apology for being late with the retrospective.

Three situations call for slightly different timing and tone:

• Successful project, ongoing relationship — send within a week, invite a short call first if the engagement was substantial, keep the write-up itself light.
• Rocky project, relationship you want to keep — send within a week of the final deliverable, always propose a call before or alongside the email, and do not let the written version arrive as the first the client hears of any hard finding.
• Project that's ending regardless of tone — send the retrospective as part of, or right after, the offboarding message. See our companion post on the client offboarding email for the handover side of that message.

What a good client retrospective email contains#

Five things, in this order. Skip the order and the email reads defensively even when the content is honest.

• A plain statement of what worked — specific enough that the client recognizes it as their project, not a template.
• A plain statement of what didn't, owned by your team first, without a qualifier in the same sentence undoing the ownership.
• The one or two changes you're committing to, described as an action with an owner, not a hope.
• Any client-side factor, only after your own misses are named, and only if it's true and specific — a date, a decision, an approval that was late.
• A clear next step — a call, a signature on the write-up, or simply an open door if the relationship is ending.

Quick reference: which template fits your situation#

Template 1: Invitation to a joint retro#

Use this before you write anything else, on any project big enough that a one-way email would feel like a verdict handed down. It costs you one email and buys you a shared account of what happened, which is worth more than a perfectly worded write-up the client didn't get to shape.

Subject: Wrapping up [PROJECT] — 30 minutes to look back together

Template 2: The findings summary#

This is the core document — the one you send after the call, or in place of it on a smaller project. Keep [WHAT WORKED] and [WHAT DID NOT] to three items each. A findings list with nine bullets under each heading reads as padding, not thoroughness.

Template 3: What we're changing#

Send this as a short follow-up to Template 2, a day or two later, once you've had time to turn the findings into an actual decision. It matters because a findings list without this follow-up reads as analysis with no consequence — the client remembers what you said was wrong, not that you did anything about it.

Template 4: The shared-responsibility version#

This is the template writers reach for last, and the one they get wrong most often. Some delays genuinely are the client's — a late approval, a scope change signed off in week six, a decision-maker who was unreachable for three weeks. Naming that honestly is not blame-shifting. Naming it before you've named your own misses is.

The rule: your team's contribution to the delay appears first, by name, with no softening. The client's contribution appears second, described as a fact with a date attached, never as a character judgment. "The scope change on [DATE] added roughly [TIME] to the build" survives a client reading it twice. "You kept changing your mind" does not, even if it's the truer sentence in your head.

Template 5: The internal-only draft (do not send this to the client)#

Write this one first, for your own team, before you write anything the client will see. It exists to get the unfiltered version out of your head — the resourcing decision that was actually the cause, the internal handoff that broke, the thing your PM said in Slack that you'd never put in an email — so that the client-facing version isn't the first place your team processes what happened.

The bracket that matters here is the one you strip out before Template 2 goes anywhere near a client: anything that names an individual by role or performance rather than a process. "Our estimation process didn't account for X" survives the edit into a client email. "[TEAM MEMBER] missed the handoff" does not — that's a performance conversation, and it belongs in a 1:1, not in either version of the post-mortem.

Template 6: The short version for a small project#

A two-week logo refresh doesn't need a five-paragraph retrospective, and sending one signals that you're following a template rather than reading the room. Use this instead — three sentences, no call required.

Template 7: Follow-up after the retro call#

If the retro happened live, the written follow-up isn't the findings summary again — it's the action-item recap, sent within 24 hours while the commitments made on the call are still what everyone remembers agreeing to. Format it as a list with owners, not as prose.

1. 1

   List each action item

   One line each: what, who owns it, and by when — pulled directly from what was said on the call, not reinterpreted.

2. 2

   Flag anything unresolved

   If the call ended without agreement on a point, say so explicitly rather than letting the recap imply consensus that wasn't reached.

3. 3

   Ask for a correction window

   Give the client 48 hours to flag anything that doesn't match their memory of the call before you treat the recap as final.

Template 8: Executive summary for stakeholders who missed the call#

Send this when the retro involved your day-to-day contacts but a decision-maker one level up needs the outcome without the full findings document. Condense to three lines and drop the process detail — an executive reading this wants the verdict and the commitment, not the mechanism.

The hard version of this situation#

The genuinely difficult case isn't a project that went badly because of your team's mistakes — that email, while uncomfortable, has a clear structure: own it, fix it, move on. The hard case is a project where a real share of the delay traces back to the client's own decisions, and you still have to send something honest without it reading as an attack.

Two things make Template 4 land instead of backfiring. First, sequence: your miss comes first, unconditionally, in its own sentence. Second, specificity: the client's contribution is described as an event with a date, never as a pattern of behavior. "The approval on the [DATE] mockups took three weeks instead of the agreed three days" is a fact both parties can check against the email thread. "You're always slow to approve things" is an opinion, and opinions are what clients push back on.

If the relationship is one you want to continue, send this template with a call offered alongside it, not instead of it — a shared-responsibility finding delivered cold, in writing, with no chance to talk it through, is the version most likely to end the relationship rather than repair it.

What to do if there's no reply#

Most retrospective emails get no reply, and that's not a signal that something went wrong with the email — it's usually just that the client has moved on and the retro, while appreciated, wasn't urgent enough to answer. Give it a week before following up once.

One follow-up, framed as closing the loop rather than chasing a response, is enough: "Wanted to make sure this landed — no need to reply unless something reads differently from your side." If a second follow-up would feel like pressure, that's the signal to stop; treat the silence as tacit agreement with the write-up and move on. Chasing a retrospective past two touches costs more goodwill than the reply would have been worth.

A faster way to send these consistently#

Everything above works fine sent by hand, and most retrospectives are low-volume enough that hand-writing them is the right call. Where it breaks down is at scale — an agency running fifteen projects a quarter, where the write-up quality depends on whoever happens to be closing that engagement, and the honest-but-careful tone in Template 4 is the first thing to slip when someone's writing their fourth retro of the week under deadline pressure.

AI Emaily's AI drafting starts from a saved reply template like the ones above and fills in the project-specific brackets from the thread it's replying in, in a voice set from your own Personal Context and client profile rather than a generic tone — so the shared-responsibility version still reads like you wrote it at your most careful, on a Friday afternoon, every time. Every draft sits for your approval before it sends; nothing here goes out on autopilot. We build AI Emaily.