A client emails a week after launch with a list of "bugs," and half of the items are not bugs at all. They are new requirements, configuration changes, or features nobody scoped. Now you need to write an email handling a client who requests free post-launch bug fixes outside warranty without sounding defensive, without losing the account, and without setting a precedent that free work is your default. The reply fails when it opens with a refusal and succeeds when it opens with a clear classification. The triage steps and templates below give you that structure.
Triage the Request Before You Write Back
Every reply to this kind of email has the same foundation: you cannot classify the request in the same message that you answer it. Separate the review from the response, even if only by an hour.
Work through these steps in order. The output of the triage becomes the body of your email.
- Pull the signed specification. Compare the reported behavior to what was approved, not to what the client remembers discussing.
- Reproduce each item. Confirm whether the issue appears in the delivered environment, in a changed environment, or only under conditions the client introduced after handover.
- Check the warranty terms. Note the coverage window, what counts as a defect, and what the agreement excludes.
- Sort into three buckets: covered defect, out-of-scope change, and environment or third-party cause.
- Price the out-of-scope work. A fixed quote or a clear hourly estimate, plus a realistic turnaround.
- Identify the covered fixes you can start immediately. Action on the free items is what makes the paid conversation tolerable.
Only after those six steps should you write a single sentence to the client. The triage gives you the one thing that makes this email work: a factual classification rather than an opinion about the request.
Pro tip: If more than one item lands in the covered bucket, lead with those in your email. Demonstrating that you are already fixing something at no charge makes the scope boundary on the rest far easier to accept.
Common Mistakes That Turn a Small Fix Into a Contract Dispute
Most of the damage in these exchanges is done by phrasing rather than policy. The classification is usually correct and the delivery is what creates the argument.
- Opening with the refusal. "That is not covered under warranty" as the first line reads as hostile, even when it is accurate. Acknowledge the issue, then classify it.
- Debating whether it is a bug. Arguing about the label wastes goodwill. Describe the item factually and move to the options.
- Fixing it quietly and sending a bill later. Work performed without prior approval is the most reliable way to create an invoice dispute.
- Offering a discount immediately. A fast discount signals that your original rate had room in it, which invites a discount request on every future change order.
- Absorbing everything to keep the peace. Unbilled work compounds, and the resentment surfaces later in worse ways than a polite scope email would have.
- Answering one item and ignoring the rest. A partial reply forces the client to chase you, which reads as avoidance.
- Explaining your costs. Internal margin, staffing, and overhead details are not the client's concern and make the boundary sound negotiable.
Warning: A one-time free fix is a courtesy, not a policy. If you absorb out-of-scope work, state in writing that it is a goodwill gesture and does not change the warranty scope, or the next request will arrive with the same expectation.
Templates for a Soft, Relationship-Preserving Reply
Use this register when the relationship is strong, the client is reasonable, and the out-of-scope items are modest. The voice should sound like a partner separating signal from noise, not like a vendor citing fine print.
Template 1 — Mixed Response With Covered Fixes First
Subject line options:
- Your post-launch issue report for [Project Name]
- Review of the reported issues on [Project Name]
- Bug report findings and next steps for [Project Name]
Hi [Recipient Name],
Thank you for the detailed report. Our team has gone through every item, and I want to share the findings along with a plan for both categories.
Covered under warranty, no charge:
- [Issue 1] — reproduced in the delivered build and confirmed as a defect. Fix is scheduled for [Deployment Window].
- [Issue 2] — same status, fix included in the same deployment.
Outside warranty scope:
- [Issue 3] — the approved specification for [Feature] did not include this behavior, so it is a change rather than a defect.
- [Issue 4] — this traces to [Configuration Change / Third-Party Update] made after handover.
For the second group, I can send a fixed quote by [Quote Date] with a turnaround of [Timeframe] from approval. If it is easier to budget, we can also fold these into your [Support Plan / Retainer].
To keep momentum, the covered fixes will be deployed on [Date] regardless of what you decide on the rest.
Best regards,
[Your Name]
[Company Name]Template 2 — Short Reply for a Single Clear-Cut Item
Subject line options:
- Quick answer on the [Feature] behavior in [Project Name]
- Status of your [Feature] question for [Project Name]
- Findings on the [Feature] report for [Project Name]
Hi [Recipient Name],
Thanks for flagging this. [Engineer Name] reproduced it, and it is not a defect in the delivered build.
The current behavior matches the approved specification for [Feature]. What you are describing is a new requirement, which places it outside the warranty period.
Two practical ways to handle it:
- I scope it and send a fixed quote, usually within [Timeframe].
- We add it to your next release cycle under [Support Plan] if bundling is easier.
Given the size of the change, I would lean toward the second option. Tell me which you prefer by [Decision Date] and I will get it moving.
Best regards,
[Your Name]
[Company Name]Pro tip: Name the engineer who reproduced the issue. It signals real investigation rather than a policy response, and it makes the classification much harder to dispute.
Templates for a Firm, Contract-Anchored Reply
Switch to this register when the request is large, when the client has pushed back before, or when the warranty terms clearly exclude the work. The language stays respectful but becomes documentary, with explicit references to the agreement and a written approval path.
Subject line options:
- [Project Name]: warranty determination and quote for reported issues
- Response to your issue report for [Project Name]
- Scope review of the items reported on [Project Name]
Hi [Recipient Name],
Thank you for the report. We have reviewed each item against the approved specification for [Project Name] and the warranty terms in [Agreement Name].
Of the [Number] items reported, [Number] fall within the warranty and will be corrected at no charge. Those fixes are scheduled for deployment by [Date].
The remaining [Number] items fall outside the warranty for the following reasons:
- [Issue] requires functionality that was not part of the approved scope referenced in [Specification Name].
- [Issue] results from [Environment / Third-Party Change] introduced after handover and is unrelated to the delivered build.
Work outside the warranty is performed at [Hourly Rate] or on a fixed-quote basis. The estimate for the out-of-scope items is [Amount], with a turnaround of [Timeframe] from written approval.
To proceed, please reply with approval of the quote by [Decision Date]. The warranty fixes do not depend on that decision and will proceed as scheduled.
If your team believes any item has been misclassified, send the specific details and I will review it within [Response Window].
Best regards,
[Your Name]
[Company Name]Two features make this version effective. It does not apologize for the warranty terms, and it does not leave the classification open to negotiation. It states the finding, offers a review path, and sets a decision deadline.
What If the Client Pushes Back Hard?
Pushback is normal, and it usually takes one of three forms: a claim that the item was always part of the deal, a request to absorb the cost as a favor, or an escalation to someone more senior. Each needs a different response.
- Disputed classification: Ask for the specific reference — a meeting note, an email, a line in a document. If they produce one, review it seriously and adjust. If they cannot, restate the specification reference once and move to options.
- Request for a favor: Offer something small and bounded, described as a one-time courtesy with a written note that it does not alter the warranty scope. Never agree to an open-ended waiver.
- Escalation: Welcome it. Offer a short call with whoever is now involved, bring the specification and the itemized classification, and keep the tone the same as in writing.
If the client goes quiet after your reply, send one short follow-up that restates the two paths and sets a default outcome. Silence should produce a documented next step rather than an indefinite pause on the covered fixes.
- Is every reported item classified, with none left unanswered?
- Are the covered fixes moving on a stated schedule?
- Is the out-of-scope work priced as a single clear figure?
- Is there one decision, one deadline, and one named approver?
- Have you avoided apologizing for the warranty terms?
- Is the message under 250 words with the classification visible in the first half?
- Will the client read this before any out-of-scope work begins?
Handled this way, the email does more than protect your margin. It shows the client that you investigate before you answer, which is exactly the behavior that makes a scope boundary credible in the first place.
Frequently Asked Questions
Q. How do I tell a client that bug fixes are outside the warranty?
A. Acknowledge the issue first, then separate the items into covered and out-of-scope categories. Confirm which items fall inside the warranty window and scope, and which are new requests, environment changes, or enhancements. State the out-of-scope items with a fixed quote, and start the covered fixes immediately so the client sees progress.
Q. Should I fix small out-of-scope issues for free as a goodwill gesture?
A. Occasionally, and only with clear boundaries. A small fix offered as a one-time courtesy can protect a long relationship, but it must be framed as a gesture rather than an obligation, and it should not become a pattern. Document the decision in writing so future requests are not treated as precedent.
Q. What is the difference between a warranty bug fix and a change request?
A. A warranty fix restores delivered functionality to the specification both parties approved. A change request adds new behavior, modifies approved scope, or addresses something the original specification never covered. The deciding factor is the signed specification, not the client's expectation.
Q. How do I handle a client who insists the fix should be free?
A. Restate the scope boundary once in neutral language and reference the agreed specification or warranty terms. Then give a concrete path forward with a price and a timeline. Avoid repeating the refusal, and avoid discounting the work immediately, since a quick discount suggests the original price was inflated.
Q. When should I escalate to a formal change order?
A. Escalate when the request involves meaningful build time, alters agreed functionality, or affects a fixed launch commitment. A change order protects both parties by recording the scope, cost, and timeline before work begins. Verbal agreements on out-of-scope fixes are the most common source of later disputes.