Client Project Warranty & Defect Liability Pack (With AI)

Freelancers and small agencies lose margin in the quiet weeks after launch when clients treat every new idea as a “bug” and every bug as an emergency change. Your contract’s warranty or defect liability period (often 30–90 days) is a different lane from hypercare, handoff, or a paid change request. This playbook uses ChatGPT, Google Docs, and Gmail so you respond fast, document what is in warranty, and route everything else cleanly.

When this pack applies

Use it when:

• Delivery is signed off (or you are in the post-launch window defined in your SOW).
• The client reports “something is broken” or “this is not what we agreed.”
• You need a written record of defect vs change vs how-to before billable work resumes.

Skip it if you are still inside a time-boxed hypercare window with different rules, or if the engagement already moved to a support retainer.

Step 1 — Capture the report without debating on Slack

Ask the client (or your PM) to paste one structured message per issue. Meanwhile, paste their raw text into ChatGPT with this instruction:

You are a delivery lead. Separate FACT (observable) from ASSUMPTION (interpretation).
List: steps to reproduce, expected vs actual, environment, screenshots/links mentioned, and whether this sounds like (A) defect in delivered scope, (B) change/new feature, (C) training/how-to, (D) third-party/vendor.
Do not promise fixes or timelines.

Save the model output at the top of your working doc. You are building evidence, not winning an argument.

Step 2 — Classify before you open the IDE

Warranty work fixes regressions or non-conformance to agreed acceptance criteria. Enhancements, new integrations, and “while you are in there” asks belong in a change lane—even if the client labels them bugs.

Defect (warranty): worked at acceptance, now fails the same acceptance test, or never met a written criterion you both signed.

Change: new behavior, new integration, or scope that was explicitly out of the milestone.

How-to: permissions, content entry, or workflow the client has not learned yet—answer with docs, not free build time.

When unsure, default to written classification in the brief below; do not silently absorb scope.

Step 3 — One-page Warranty Defect Brief (Google Docs)

Duplicate this skeleton into a shared client folder. One doc per defect; link related CRs separately.

Section	What to write
Header	Project name, warranty end date, defect ID
Facts	Repro steps, browsers, roles, timestamps
Expected vs actual	Quote acceptance criteria or spec section
Classification	Defect / How-to / Change (with one-sentence rationale)
Impact	User-facing severity; workaround if any
Owner	Who fixes; who validates on client side
Fix plan	Branch, deploy window, rollback note
Verification	Test cases client will run to close the ticket

Send a view link in email—do not rely on chat scrollback as the system of record.

Step 4 — Gmail cadence (three emails)

Keep tone calm and contractual without sounding legalistic.

1. Acknowledgment (same business day): “We received report #ID. Classification by [date]. Warranty window ends [date].”
2. Classification + plan: Link the brief. If defect: ETA and what you need from them. If change: link to CR template and pause coding until approved. If how-to: short answer + doc link.
3. Verification close: “Please run tests 1–3 in the brief by [date]. We will mark closed when confirmed or move to CR #.”

Draft all three in ChatGPT, then you edit names, dates, and promises before send.

Step 5 — Fix, deploy, and verify

For warranty defects only:

• Time-box investigation (e.g., 90 minutes) before you escalate internally or discuss CR.
• Note the last known good build or config if rollback is possible—same discipline as production support, but scoped to delivered work.
• After deploy, update the brief’s verification section with what you tested and what the client must still sign.

If the fix touches auth, payments, or data, get explicit client approval for the deploy window—even in warranty.

Step 6 — Warranty log (Google Sheets)

One row per report (defect, how-to, or redirected CR):

Column	Example
Report date	2026-11-07
ID	W-014
Classification	Defect
Status	Closed / CR-221
Days in warranty	12 of 60
Billable?	No / Yes (CR)

Review the log weekly. Patterns of “how-to” mean you need a better runbook; patterns of “change” mean expectations were not nailed at milestone acceptance.

Prompts you can paste today

Triage prompt (after client paste):

Given our SOW acceptance criteria below, classify this report. Output: classification, missing info to ask, and 3 verification tests the client can run.
SOW excerpt: [paste]
Report: [paste]

Brief polish:

Turn this triage into a client-ready Warranty Defect Brief table. Use short sentences. Flag anything that sounds like scope creep.

What good looks like

Within one warranty period you want: every report numbered, most defects closed with client verification, changes always on a CR, and no surprise invoices because scope shifted in DMs. When warranty ends, send a short summary email with open items and hand off to retainer or exit offboarding if the engagement ends.

More playbooks like this live in our guides for freelancers and SMB teams shipping client work with AI assistants—not replacing your judgment, but making the paper trail fast enough that you keep the relationship and the margin.