Client Support Retainer Performance Degradation (P2) Pack with AI

Your retainer client says the app "feels slow" but login still works. That is not your urgent P1 outage playbook, and it is not a planned maintenance window. It is performance degradation (P2): partial impact, ambiguous scope, and a high risk of endless tuning unless you document baselines and bisect the problem in writing.

This pack gives freelancers and small agencies a repeatable way to respond while the retainer stays billable and defensible.

When to use this pack (and when not to)

Use it when:

• Core functions work but latency, timeouts, or queue backlog are worse than baseline.
• Users can still work, even if painfully.
• You need a written plan before spending another hour on guesses.

Do not use it when:

• The service is down for most users → switch to your urgent P1 incident pack.
• You already know the root cause and are executing a scheduled change → use your maintenance window brief.
• The ask is net-new build work → route to change request or out-of-scope redirect.

What you will produce

1. A FACT / ASSUMPTION snapshot from ChatGPT (you verify every fact).
2. A one-page Performance Degradation Brief in Google Docs (baseline, scope, bisection plan, escalation triggers).
3. A three-email Gmail cadence (acknowledge → midpoint → resolved or escalated).
4. A monthly review log row so repeat slowness does not look like twelve one-off mysteries.

Browse more playbooks in guides.

End-to-end flow

Step 1 — Triage with ChatGPT (FACT vs ASSUMPTION)

Paste the client message and any screenshots (describe them; do not upload secrets). Use a prompt like:

You are my support triage assistant. Separate FACT (quoted or measured) from ASSUMPTION (guesses). List missing data I need for a performance brief: affected URLs, user count, start time, error codes, recent changes, hosting region. Propose three bisection checks ordered cheapest-first. Do not invent metrics.

Human rule: If ChatGPT labels something FACT but the client only said "it's slow," downgrade it to ASSUMPTION until you measure.

Step 2 — Build the Performance Degradation Brief (Google Doc)

Create a doc from this outline (copy-paste friendly):

Section	Content
Severity	P2 — degraded, not down
User impact	Who, how many, which workflows
Baseline	Last-known-good latency or error rate (link monitoring if you have it)
Current signal	Timestamps, sample HAR or server metric, screenshot of queue depth
Recent changes	Deploys, DNS, SSL, plugin, client-side edit
Bisection plan	Ordered checks (local network → DNS → app tier → database → third party)
Time box	Max billable hours before client decision (see options below)
P1 triggers	e.g. >50% users cannot complete checkout; data loss risk
Owner	You vs client vs vendor ticket #

Share view-only with the client primary contact once the baseline row is filled. Empty baseline cells are a stop sign—capture at least one number (even a manual stopwatch test) before deep debugging.

Step 3 — Bisect without heroics

Work the bisection plan top to bottom. Document each result in the doc as a single line: Check → Result → Next.

Typical order for SMB stacks:

1. Confirm scope (one user vs all; one browser vs all; VPN on/off).
2. Compare off-peak vs peak (rules out capacity).
3. Check third-party status pages if APIs are in the path.
4. Inspect recent deploys or client-side plugin updates.
5. Open vendor ticket only when your side is ruled out.

If you are waiting on the client for a test login or HAR export, pause the SLA clock only if your retainer SOW allows it—and say so in writing.

Step 4 — Gmail cadence (three emails)

Email 1 — Acknowledge (within your response SLA):

Subject: [P2 Performance] We are investigating slowness — brief attached

Body bullets: what you understand, what you measured, link to the Google Doc, next check and ETA, max hours in this time box.

Email 2 — Midpoint (before half the time box expires):

Share bisection results, what is ruled out, what you need from them (if anything), and whether you are approaching a P1 trigger.

Email 3 — Resolved or escalated:

• Resolved: before/after metric, root cause category (client change, capacity, vendor, bug), prevention note.
• Escalated to P1: state trigger met, switch to incident mode, new update frequency.

Keep threads short; put detail in the doc.

Step 5 — Client options when the fix is not quick

If bisection points to a larger project (bad query, missing cache, migration), add an Options block to the doc:

• A — Workaround (temporary, hours cap)
• B — Proper fix (change request quote)
• C — Pause investigation until client provides access/data

Send the choice request in Email 2 or 3. Do not silently absorb unlimited tuning hours.

Step 6 — Log it in the monthly retainer review

Add one row to your review table:

Month	Incident type	Root cause category	Repeat?	Follow-up
…	P2 performance	e.g. client plugin	Y/N	e.g. add monitoring alert

That row connects this event to your monthly support retainer review so leadership sees patterns, not anecdotes.

QA checklist before you close the ticket

• Baseline and after metrics recorded in the brief
• FACT/ASSUMPTION reviewed by a human
• Client acknowledged resolution or approved CR path
• No open vendor ticket orphaned without owner
• Gmail thread matches doc timestamps

Why this is different from your other retainer packs

• P1 urgent pack assumes major outage and war-room cadence.
• Post-incident RCA runs after stability returns for blameless learning.
• Scheduled maintenance covers changes you plan.
• This pack covers slow-not-down with measurement-first bisection and explicit escalation to P1 when thresholds hit.

Ship the brief before the next hour of random log diving. Your future self—and your client—will read the numbers instead of re-litigating what "slow" meant.