Change order script · New feature
Client requests a feature after launch
The project launched last week and the warranty covers defects. The client sends a feature request labelled as a bug. Here is how to separate the two kindly.
Ben Adeyemi10:42 AM
Found a bug: customers can't save items to a wishlist. Can you fix that under warranty?
Possible scope change, visible to your team only
Cites SOW section 9.1, Warranty. Estimated 26 hours. Change order draft ready for PM review.
The situation
Warranty periods cover defects: things that do not work as specified. A wishlist was never in scope, so its absence is not a defect. The client may genuinely believe it is a bug. Handling this well matters because post-launch is when the relationship either becomes a retainer or ends.
Why this script works
The script thanks the client, checks the spec openly, and explains the difference between a defect and a feature in friendly terms. It then makes the feature easy to buy and suggests a backlog for future work, which opens the door to ongoing engagement.
- Scenario
- New feature
- Clause to cite
- SOW section 9.1, Warranty
- Typical effort
- 26 hours
- Typical change order
- $4,290 at $165/hr
- Reply within
- Same business day
The script
Three versions: the quick reply, the email and the nudge.
Start in the channel where the request arrived, then follow with the email and change order. Copy any version and replace the bracketed placeholders.
Youdraft, reply in thread
Hi [Name], thanks for flagging! I checked the spec: wishlists weren't part of the original build (Appendix A), so this is a new feature rather than a bug, and the warranty covers fixes to built features. The good news is it's a great idea, and we can scope it quickly. I'll send an estimate, and if you have a few more ideas, we could bundle them into a small post-launch phase.
Replace every [bracketed] placeholder before sending. Your PM approves every message, TWINJAM never contacts clients on its own.
What not to say
Small wording changes decide whether the client hears help or a bill.
| Avoid | Say instead | Why |
|---|---|---|
| “That's not a bug.” | “Wishlists weren't in the original build, so this is a new feature.” | Explains the classification without contradicting them. |
| “Warranty doesn't cover that.” | “Warranty covers fixes to built features, here is the estimate for this one.” | Pairs the boundary with a next step. |
| “Sure, small fix.” | “Here is a quick estimate.” | Post-launch freebies quickly become a support desk. |
SOW clause to cite
SOW section 9.1, Warranty
For 30 days after launch, Agency will fix defects where delivered features do not function as specified in Appendix A. New features and enhancements are outside the warranty and handled under the Change Control clause.
No clause like this in your SOW? Use one of the SOW templates for your next engagement, and have your counsel review final contract language.
CO-NGO-SHOP-07
Client requests a feature after launch
| Line item | Hours | Amount |
|---|---|---|
| Wishlist data model and APIEngineer | 8 | $1,320 |
| Save, view and share UI on product and account pagesFront-end engineer | 10 | $1,650 |
| Guest to logged-in wishlist syncEngineer | 4 | $660 |
| Testing and releaseQA engineer | 4 | $660 |
| Total | 26 | $4,290 |
Priced at a $165 blended hourly rate. Cites SOW section 9.1, Warranty.
Step by step
From the client’s message to a signed change order.
The script is one step. The process around it is what keeps scope conversations short and friendly.
- 1
Check the request against your signed SOW. For this scenario the clause to cite is usually SOW section 9.1, Warranty.
- 2
Reply the same day in the channel where the request arrived, using the Slack version. Agree with the goal before you mention scope.
- 3
Estimate the work as line items with hours. This scenario typically lands around 26 hours.
- 4
Send the email version with the change order attached and two or three options, including a lighter or free path where one exists.
- 5
Set a decision date tied to the schedule. If there is no reply in three business days, send the follow-up.
- 6
Record the approval or the decision to defer, so the SOW baseline stays accurate for the next request.
Related scripts
- New featureClient asks for a new payment gatewayThe checkout was scoped for Stripe. Now the client wants PayPal and Klarna too. Here is how to say yes to the idea and yes to the budget in the same message.
- New featureClient asks for extra landing pagesThe site build included 20 pages. Marketing now wants six campaign landing pages before launch. This script turns a favor request into a quick, approved add-on.
- New featureClient wants a new user roleThe app was scoped with three roles. The client wants a fourth, a regional manager who sees some data but not all. This script shows why roles are bigger than they look.
- Extra revisionClient requests a fourth design revisionThe SOW includes two revision rounds. The client is asking for round four. This script keeps the relationship warm while making the next round a paid, scoped decision.
Agency Change Order Scriptbook
12 polite Slack and email templates to ask for more budget without friction.
The scriptbook collects the twelve conversations agency PMs dread most, from the fourth design round to the after-launch feature, with the SOW clause to cite and a change order form for each.
Spot the request before the work starts.
TWINJAM flags out-of-scope requests in Slack, Teams and Jira, cites the SOW clause and drafts a change order like this one for your PM to approve.