Client Project UAT & Go-Live Pack (With AI)

Freelancers and SMB delivery teams often treat “UAT” as a vague week where the client clicks around and files random bugs in Slack. That is how you launch on a Friday with no written pass criteria, no severity rules, and a stakeholder who thought “UAT” meant training. User acceptance testing (UAT) is the window where business users prove the build meets agreed acceptance criteria—not a surprise scope demo, not billing sign-off on a milestone invoice, and not post-launch hypercare.

This playbook sits after development is feature-complete and before production cutover. It pairs ChatGPT to turn SOW language into executable test scripts, a UAT Brief in Google Docs, a defect log in Google Sheets, and a three-email Gmail sequence that ends in an explicit go/no-go. If you need phase billing sign-off first, use milestone acceptance; for the delivery package itself, see project handoff. For the first month after launch, pivot to hypercare.

When to run UAT

Open this pack when all are true:

• Staging (or a client-approved UAT environment) reflects the release candidate you intend to ship.
• Written acceptance criteria exist—from SOW, milestone doc, or signed spec.
• A named UAT owner on the client side can schedule testers and approve go/no-go.
• You need a paper trail before DNS, payments, or public URLs flip.

Skip it if you are still negotiating scope (use change requests) or if the client only wants a demo with no commitment to test.

End-to-end flow

Step 1 — Turn acceptance criteria into test scripts (ChatGPT)

Paste criteria into ChatGPT with a strict output format:

You are a QA lead for a client UAT week. Given these acceptance criteria: [paste from SOW or milestone doc]

Output:
1) 12–25 concrete test cases in table form: ID, role, preconditions, steps, expected result, priority (P0/P1/P2)
2) Five negative tests (permissions, empty states, edge inputs)
3) Out of scope for UAT (list explicitly)

No filler. Every test must map to a cited criterion sentence.

Export the table into the UAT Brief. You verify each test is observable by a non-developer.

Step 2 — One-page UAT Brief (Google Docs)

Section	Content
Header	Project, RC version/build ID, UAT start/end dates (time zones)
Environments	URLs, test accounts, data reset rules
Roles	UAT owner, testers, your support contact, escalation
Entry criteria	What must be true before day 1 (smoke passed, content loaded)
Exit criteria	P0=0 open, P1 documented waiver or fix, signed go/no-go
Severity defs	P0 block launch, P1 fix or waiver before launch, P2 backlog
Test scripts	Link to full script table from ChatGPT
Defect process	How to log in Sheets, SLA for triage responses
Go/no-go meeting	Agenda + decision rule (majority of critical paths green)

Share comment-only until scripts are agreed; then grant edit on the defect log only.

Step 3 — Defect log (Google Sheets)

Columns: ID, Test case, Severity, Steps, Expected, Actual, Screenshot link, Status (New/Triage/Fixed/Waived/Deferred), Owner, Retest date.

Triage with ChatGPT (paste one row at a time, redact PII):

Label FACT vs ASSUMPTION. Given this UAT defect: [paste].
Classify severity P0/P1/P2 using our brief definitions.
Suggest: reproduce ask for client, or acceptable waiver language if cosmetic.

Never let the model auto-close defects without human retest.

Step 4 — Gmail cadence (three emails)

1. UAT kickoff — Link Brief, environment URLs, tester invites, hours you will answer questions, defect log link.
2. Mid-UAT checkpoint — Count by severity, blockers, waiver candidates, reminder of go/no-go date.
3. Go/no-go outcome — Explicit GO or NO-GO, open P1 waivers with client sign-off text, next step (launch window or retest plan).

Draft in ChatGPT; you send from Gmail with real dates and build IDs.

Step 5 — Go/no-go meeting (30 minutes)

Agenda:

1. Smoke recap on staging (5 min)
2. P0/P1 review from Sheets (15 min)
3. Waivers and launch risks (5 min)
4. Decision + communication owner (5 min)

If NO-GO, attach a retest scope (P0/P1 only)—do not rerun the entire suite unless criteria changed.

Step 6 — Bridge to launch, hypercare, or warranty

On GO:

• Send launch confirmation with rollback contact and first-hour monitor plan.
• Hand the defect log forward: deferred P2 items become hypercare or backlog entries.
• Note warranty start date if your contract defines one—see warranty vs change after delivery.

On NO-GO:

• Time-box fixes; rerun affected scripts only.
• Do not slip launch without a written NO-GO follow-up email—protects you when the client later claims “we approved verbally.”

Common mistakes

• No exit criteria — UAT never ends; scope bleeds into launch week.
• Developers only test — business users never exercise real workflows.
• Slack as defect system — items vanish; use Sheets.
• Confusing UAT with training — schedule enablement separately or label it in the Brief.
• Go-live without waiver text — P1 cosmetics become warranty fights.

Quick checklist

• RC build ID frozen in the Brief
• Test scripts trace to written criteria
• UAT owner named
• Sheets log is the only defect intake
• Three Gmail messages scheduled
• Go/no-go decision recorded in the Doc

More delivery playbooks live in guides for teams shipping client work with AI—structured testing without pretending automation replaces human sign-off.