Client Support Retainer Post-Incident Retrospective Pack (With AI)

When a support retainer client finally sees green again after a P1, the hardest mistake is going quiet. They still have board questions, open tickets, and fear the next outage. Your live incident pack handled severity, updates, and hour burn during the fire. This playbook closes the loop after resolution: a short, blameless retrospective your client can forward internally—without you writing a novel on retainer time you never scoped.

If you run monthly retainer reviews or just survived a urgent P1 on retainer, treat the post-incident retrospective as a required deliverable, not optional polish. More how-tos live in Guides.

What this pack is (and is not)

This is: a 48–72 hour post-resolution workflow that produces a one-page RCA-style summary, a preventive-action backlog, and a Gmail thread that records client acknowledgment.

This is not: live war-room comms (see the P1 pack), a change request for new scope, or a forensic audit you bill by surprise. Decide up front whether the retrospective is included in retainer or a fixed-fee add-on, and say so in the doc header.

When to run it

Trigger the pack when all of these are true:

1. Severity is downgraded from P1 (or your highest tier) and production work is stable.
2. You have sent a final “resolved” update on the incident thread.
3. You are inside 72 hours of resolution—long enough for facts, short enough that memory is fresh.

If the client asks for a deeper audit, route that to your change request process instead of expanding this doc for free.

Tools and inputs

• ChatGPT — draft RCA sections from raw notes (you edit every claim).
• Google Docs — single source of truth the client can comment on.
• Gmail — send the doc link plus a tight executive summary; keep the legal record on-thread.

Gather before you prompt: ticket IDs, timestamps from your helpdesk or inbox, deployment notes, and the hour burn you already communicated during the incident.

End-to-end flow

Step 1 — Freeze the timeline (facts only)

Open a blank Google Doc. Title it: Post-Incident Summary — [Client] — [YYYY-MM-DD] — [Short name].

In the first section, paste a bullet timeline with UTC or agreed timezone, each line tagged FACT (you can verify) or ASSUMPTION (needs client input). Pull from tickets, status emails, and deploy logs—not memory alone.

Example row format:

14:02 — Monitoring alert (FACT) — Ticket #8841
14:18 — Client notified P1 (FACT) — Gmail thread "Acme outage"
15:40 — Rollback completed (FACT) — Deploy log

Do not assign blame in this section. Names of systems and versions are fine; names of people are optional and usually omitted on retainer accounts.

Step 2 — Draft RCA sections with ChatGPT

Paste your timeline and any internal notes into ChatGPT with a strict instruction block:

You are helping a freelance support lead write a CLIENT-FACING post-incident summary.
Rules:
- Blameless tone; no individual blame.
- Separate FACT vs ASSUMPTION; mark guesses clearly.
- Root cause: use categories (config, dependency, capacity, process, unknown).
- Max 120 words per section.
Sections: Impact, Timeline (bullets), Root cause (category + narrative), What we did, Preventive actions (max 5), Open questions.
Do not invent metrics or downtime numbers not in my notes.

Read every sentence. If ChatGPT invented a duration or root cause, delete it or downgrade to ASSUMPTION.

Step 3 — Add retainer billing transparency

Add a short Retainer / billing box at the top or bottom of the Doc:

Retainer note: This retrospective is included in [Month] support hours / billed as fixed fee $X / not included—approved on [date].
Incident hours consumed: [N]h (as previously reported on [date]).

This prevents the “surprise invoice after the post-mortem” argument and mirrors what you already surfaced during the P1 hour-burn updates.

Step 4 — Preventive actions with owners

Turn the ChatGPT Preventive actions list into a table:

Action	Owner	Target date	Retainer / CR
Add runbook for rollback	You	Next sprint	Included
Upgrade dependency X	Client infra	TBD	CR if out of scope

Anything that changes scope, SLA, or deliverables belongs in a change request—not buried as “free” retainer work.

Step 5 — Internal review (15 minutes)

Before the client sees the Doc, check:

• No confidential credentials or internal-only URLs.
• Downtime and impact numbers match what you already emailed.
• Preventive items you cannot deliver are marked Client or CR.
• Tone matches your retainer kickoff norms (channels, response targets).

Step 6 — Gmail executive summary + acknowledgment

Send one new email (or reply on the incident thread if the client prefers a single chain). Template:

Subject: Post-incident summary — [Short name] — action items

Hi [Name],

We’ve published a short post-incident summary here: [Google Doc link]

Executive summary:
- Impact: [one line]
- Root cause (category): [config / dependency / etc.]
- Status: resolved; preventive actions listed in the doc

Please reply “Acknowledged” or leave comments in the doc by [date].
Open preventive items will roll into our next monthly retainer review.

Thanks,
[You]

Human sends after you review AI drafts—same discipline as the rest of your client comms guides.

Step 7 — Feed the monthly review backlog

Copy unfinished preventive rows into the agenda for your monthly support retainer review. Incidents that repeat without preventive closure are the top reason retainers churn at renewal.

Common failure modes

• Skipping the doc and only sending a cheerful “all fixed” email—clients cannot forward anything to leadership.
• Blameful language that triggers HR or vendor politics; stick to categories and systems.
• Scope creep disguised as “quick hardening” after the incident; use CR instead.
• Late retrospectives (two weeks later) when nobody remembers timestamps; keep the 72-hour window.

Quick checklist

• Timeline with FACT / ASSUMPTION tags
• ChatGPT draft fully human-verified
• Billing / included-hours note in the Doc
• Preventive table with Owner and Retainer vs CR
• Gmail summary + acknowledgment request
• Items copied to next monthly review

Bottom line

Retainer clients pay for steady ops, not adrenaline amnesia. A lightweight post-incident retrospective—built with ChatGPT, locked in Google Docs, and closed in Gmail—turns a scary P1 into trust you can renew on. Ship it while the incident is still recent, keep it blameless, and be explicit about what retainer covers versus what needs a change request.