Web Design Change Order Template: Handle Scope Creep With AI

A web design change order should state what is new, what it does to price and deadline, what is not included, and carry a clear client approval line. AI can draft it from a client's extra request in a couple of minutes. You supply the hours and rate, then read every line before sending.

The common failure is the quiet yes: "sure, we can add that" in a call, no record, and a Friday invoice dispute. The template and workflow below turn each extra request into a short document the client signs before the work starts. They are written for a web studio, covering design and build projects with pages, features and integrations.

Follow me on Instagram@sagnikteaches

What counts as a change, and what is just feedback

Settle this in the contract, and test every request against it.

Connect on LinkedInSagnik Bhattacharya

Three questions sort most requests. Does it add a page, feature, integration or content type that the proposal did not list? Does it reverse something the client approved in writing? Does it need more than your threshold of time, say 30 minutes? Two "yes" answers or one "yes" to the first two means a change order.

Subscribe on YouTube@sagnikteaches

The change order template, section by section

This is the whole document. Keep it to one page. Each line has a reason.

CHANGE ORDER [number], [project name]
Date: [date]            Requested by: [client contact]
Original agreement: [proposal / contract reference and date]

1. Requested change
[One to three sentences describing what the client asked for, in their terms.]

2. What we will do
[Bullet list of deliverables: pages, components, integrations, content.]

3. What is not included
[Bullet list of things the client might assume but are not part of this change.]

4. Effect on price
Estimated hours: [n]   Rate: $[n] per hour   Change order price: $[n]
Basis: [fixed fee for the above / estimate, billed at actual up to cap of $[n]]

5. Effect on schedule
[Launch date moves from X to Y / launch date unchanged / depends on content received by Z.]

6. Dependencies
[What we need from the client, by when.]

7. Approval
Reply to this email with "Approved, change order [number]" or sign below. Work on this change begins once we receive approval. If we have not heard back by [date], the schedule may move.

Client name: ________    Date: ________    Signature: ________

Why each section earns its place: section 1 records the client's request in words they recognise; section 2 makes the scope concrete; section 3 protects you from the sentence "I assumed that was included"; sections 4 and 5 state the two consequences every client wants to know; section 6 stops delays from being your fault; section 7 gives you an approval trail.

A price rule you can apply without a debate

The documents most often fail on price, because the request feels small and you want to be generous. A simple rule keeps you consistent.

1. Estimate hours by task, not by feeling. Design, build, content entry, testing, project management.
2. Add a coordination allowance of 10 to 20 per cent for communication and testing, because small changes ripple.
3. Apply your change rate. Some studios charge change work above the project rate because it interrupts planned work; if you do, 10 to 25 per cent above is a range to test against your own margins. Whatever you choose, put it in the contract so it is not a surprise.
4. Round to a fixed fee where you know the work, and an estimate with a cap where you do not.
5. Add a timing note if the change delays the launch.

Illustration: a client asks for a members-only resources page with a login. Hours: design 3, build 6, login setup and testing 4, content entry 2, coordination at 15 per cent of 15 hours, rounded to 2. Total 17 hours at a change rate of $95 an hour gives $1,615. You quote a fixed $1,600, add a line that excludes writing the resources, and state that the launch moves by three working days.

From a catering client's email to a signed change order

Say a five-person web studio is building a ten-page site for a catering company. Two weeks before launch, the client emails:

Hi [name], I was talking to a friend and we really should have an online ordering page for the Christmas menu, with a form where people pick items and a delivery date. Can we add that before launch? Also can you make the homepage slider auto-play? Thanks!

Two requests, two outcomes. Auto-play on the slider is a revision (tick it, log it). The ordering page is new: a new page, a form with logic and presumably notification emails. Use this prompt:

You are drafting a web design change order for a studio. Use plain, friendly English and short sentences.

Context: the studio is building a 10-page site for a catering company under a fixed-price contract. Our contract says: new pages, features and integrations are change orders priced at our change rate of $95 an hour; revisions to agreed pages are covered by two revision rounds.

Client request (verbatim): [paste email]

Our estimate: design 2 hours, build 5 hours (form with menu items, quantities, delivery date picker), email notifications to client and customer 2 hours, testing 2 hours, coordination 2 hours. Fixed fee $1,235.

Draft the change order using this template: [paste template]. In "What is not included", list things a client commonly assumes: online payment, stock control, delivery-slot capacity limits, translation, menu copywriting, photography. In "Effect on schedule", say the launch moves from 14 December to 19 December unless the client approves the menu items by 5 December.

Do not invent hours or prices beyond those given. Flag any assumption you made.

A realistic output, trimmed:

1. Requested change
Add an online ordering page for the Christmas menu, where customers choose items and a delivery date and submit an order.

3. What is not included
- Online payment (orders are sent as requests; you confirm and invoice as now)
- Stock control or limits on delivery slots
- Writing or photographing the menu
- Changes to the ordering form after approval of the design

What to fix: the AI assumed orders arrive as requests, which may not match what the client expects. Check that assumption with the client before sending. Also confirm the date picker will accept any date, because a blackout list for fully booked days counts as extra work. The draft is useful because it asks you the questions you should have asked on the call.

Prompts for the other tasks in a change-order workflow

Turn a rambling call note into a change request

Here are my notes from a client call. List every request the client made as a separate numbered item. For each: Is this (a) a revision inside our agreed scope, (b) a change order, or (c) unclear? Quote the contract line that supports your answer. Contract scope: [paste scope section]. Notes: [paste]

The scope paste is the point. Without it, the AI guesses what you agreed. With it, you get a first sort you can check in a minute.

Write the cover email

Write a short, warm email to a client attaching a change order. Say we are happy to do this, what it costs, how it affects the launch date, and the one thing we need from them. Do not apologise for charging. Under 120 words.

Sample output (illustrative) reads: "Thanks for the idea; an online ordering page is a good fit for the Christmas menu. The attached change order covers it at $1,235 and moves launch to 19 December. To keep that date we need the menu items by 5 December. Reply 'Approved, change order 3' and we'll start the same day." Short, specific, no grovelling.

Check a draft against the contract

Compare this change order with the contract below. List anything in the change order that contradicts the contract, anything the contract requires that the change order omits (for example approval method or payment terms), and any ambiguous wording. Contract: [paste]. Change order: [paste]

This is the check that catches a rate that differs from the contract or an approval line that differs from what you agreed. It does not replace a lawyer reading the contract itself; see writing terms with AI and when a lawyer is needed.

The change log: one table the whole team can see

A change log turns scattered requests into a record. Keep it in a shared spreadsheet or your project tool, one row per request, including the ones you absorb.

The log has two jobs. Day to day, it shows the team what has been agreed so nobody builds an unapproved change. At the end of the project, it lets you show a client the whole picture: how much was absorbed, how much was paid for, and why the launch moved. If you track time, the utilisation and timesheet tutorial shows how to compare your estimate with the real hours.

AI can maintain the log too. Paste the week's client emails and ask it to list new requests with a suggested type, then you confirm and enter them. Do not let it classify without your review: it will sometimes call a new feature a "minor tweak" because the client used mild words.

Approval wording that stands up

Weak: "Let us know what you think." Better: "Reply 'Approved, change order 4' to authorise this work at $475; we will not start until we receive this." The approval should name the number, the price and the effect on the schedule. Capture it from the person who can authorise spending. If the client contact is a junior who does not hold the budget, copy the decision-maker on the email.

Make sure your original contract says that change orders, once approved, form part of the agreement, and that work outside the agreed scope is chargeable. Have a lawyer check that wording for your own situation. The template here is a business document, not legal advice.

Where scope creep comes from, project phase by phase

Requests arrive at predictable moments, and knowing them lets you set expectations before they land.

Discovery and proposal

Creep starts here, with a proposal that says "a modern, responsive website" and nothing else. Clients fill silence with their own assumptions. A proposal that lists pages by name, the features on each, the integrations, who supplies copy and images, and the number of revision rounds removes most later arguments. If you use AI to draft proposals, make the exclusions list a required section; the model will otherwise write warmly about everything the client might want.

Design review

This is where "can we also" appears, because the client sees a design and imagines more. Offer a parking list: any new idea goes on a page called "Phase 2 and extras", which you price once at the end of the review round. The client feels heard, and you quote once rather than ten times.

Build and content entry

Late content, a different logo file, a decision to restructure navigation. These cause delay rather than extra features, but they cost you time all the same. Section 6 of the template and a content-due date in the contract are the tools.

Testing and launch

The most expensive requests appear here: "it needs to work in an older browser", "can the form also connect to our accounting tool", "the CEO wants a different homepage". Price them honestly, because the schedule effect is largest now. A change order that says launch moves five working days is often what makes a client reconsider whether they truly need it.

Fixed fee, estimate with cap, or time and materials

A sensible default is a fixed fee for well-understood changes and a capped estimate for anything involving another company's system. An integration is the classic trap: the other tool's documentation looks simple, and two hours turn into ten because of authentication or rate limits. Quote integrations as capped estimates and say "we will tell you at 80 per cent" so the client is never surprised.

Reversing an approved design for a translation agency

Say a studio designs a site for a translation agency. The client approves the homepage in writing, the studio builds it, and then a new marketing manager joins and asks for a different layout, with a language switcher at the top and a full-width video in place of the hero image. This is not a revision, because the earlier design was approved; it is a reversal.

The hours: new design 4, rebuild of the homepage template 6, video embedding and performance testing 3, retesting other pages that share components 2, coordination 2. Total 17 at a change rate of $95 is $1,615. The change order says so, with the effect on schedule (four working days), a line that the previous design was approved on a named date, and a dependency (video file supplied by the client). The cover email does not blame anyone: "We're happy to rework the homepage. Because the first design was signed off on 4 November, the rework is a change order; details attached."

What often goes wrong in this case is that the studio quotes only the new design hours and forgets the rebuild and retest. Ask the AI to list every task a change touches, by phase, before you total anything:

This change reverses an approved homepage design. List every task across design, build, content, QA and project management that the change affects, including pages and components that share code with the homepage. Output a table: task, who does it, estimated hours (give a range). Then list what could make the estimate higher.

Treat the ranges as a starting point. You know your team's speed; the model does not.

A third example: the urgent change you must start today

A client emails at 4 pm: a pricing error on the site, an offer has ended, take the banner down. Waiting for a change order would cost them money, and the fix takes ten minutes. Your contract should say that urgent corrections under, say, 30 minutes may be done immediately and logged. Do it, log it, send a one-line confirmation. If the urgent request is large, such as "add a new landing page for tomorrow's ad", say yes to the principle and send a short change order immediately with an express rate. The approval can be a one-word reply. Fast does not mean unrecorded.

When the client says "this should have been included"

It happens, and sometimes they are right. Look at the proposal and the contract first. If the item was listed, deliver it. If it was ambiguous, decide whether your wording or their assumption caused it. A fair studio absorbs the cost when the ambiguity is its own, and says so: "The proposal says 'contact form' without describing fields; we'll include the extra fields at no charge, and we've tightened the wording in future proposals." If the item was clearly outside the proposal, say so kindly, quote the change order and offer a short call. Do not paste a legal-sounding AI paragraph into the reply. A short, factual email works better: what the document says, what the request needs, what it costs. Keeping the relationship intact is worth more than winning the point, and the template exists to make that conversation easy.

What AI should and should not do in this process

• Good uses: sorting a messy email into separate requests; drafting sections 1 to 3 of the change order; listing the tasks a change touches; writing the cover email in a friendly tone; checking the draft against your contract; summarising the change log for a monthly report.
• Uses to avoid: setting the price; deciding whether something is in scope without the contract text in front of it; sending anything to a client unread; approving on the client's behalf; storing client confidential material in a consumer chatbot account.

For teams, the real gain is consistency: every change order has the same sections, the same exclusions list and the same approval line, whoever wrote it. Put the template and your prompts in a shared project or document so nobody improvises. If you are starting with AI in a small agency, the rollout plan for a ten-person marketing agency shows how to introduce tools without chaos, and if you want to see the same discipline in another trade, builders pricing variations face the same arguments with bricks instead of pixels.

A one-page checklist for the studio

1. Contract defines scope, revision rounds, the change rate and the approval method.
2. Proposal lists pages, features, integrations and exclusions by name.
3. Every client request goes in the change log within a working day.
4. Anything new gets a change order; revisions inside scope are counted against the rounds.
5. Price comes from hours and rate, with a coordination allowance.
6. The order states the schedule effect and the client's dependencies.
7. Work starts only on written approval, except urgent items under the contract threshold.
8. At project close, send a summary of the log: absorbed, charged, schedule changes.

Five ways change orders go wrong

• The verbal approval. A client says yes on a call, then disputes the invoice. Fix: send the order or a confirming email the same day, and start work only after written approval.
• Vague scope. "Add a news section" with no page count, design or import. Fix: list deliverables, then what is excluded.
• Hidden dependencies. The change needs a logo file, a copy deck or a third-party login that arrives late. Fix: section 6 names the dependency and the date.
• Underpricing coordination. The hours for building are right, but emails and testing double the time. Fix: the coordination allowance in the price rule.
• Letting AI price it. The model gives a confident number with no link to your delivery costs. Fix: you supply hours and rate; the AI only formats.

Where it looks different on a retainer

On a monthly retainer, requests do not become change orders one by one; they draw down a block of hours. The same documents still help. Swap "price" for "hours drawn", record the balance, and raise a change order only when a request would exceed the block or alter the agreed scope. A line in the monthly report works: "Used 11 of 12 hours; the ordering page request needs a change order." If the client sees the balance each month, the conversation about extra hours stops being a surprise.

Introducing the process to a client who has never seen one

Raise it at kickoff, not when the first extra request appears. A paragraph in the proposal works: "Anything not listed in this proposal is quoted separately as a change order before work starts. You approve it by email. Small adjustments to agreed pages are covered by two revision rounds." A rule explained early and applied evenly is far easier for a client to accept than one introduced mid-project as a reaction to a request. If a client has already drifted into the habit of asking for extras by phone, say so kindly: "I've started writing these up so we both have a record. Here's the first one." Send the document, not a lecture.

If you would rather have the whole flow mapped to your own tools, that is the kind of job my AI implementation consultation covers.

Web design change order questions

Should small changes go through a change order?

Set a threshold in your contract, such as anything over 30 minutes or any change to pages, features or integrations. Below it, log the change and absorb it. Above it, quote it. A threshold stops you debating every tweak and stops clients feeling nickel-and-dimed.

Can I bill for a change order before the client signs?

No. Do not start the work until the client approves in writing, unless your contract says urgent work may proceed at the stated rate. Approval by reply email is fine if the wording is clear. Keep the approving message with the change order.

What is the difference between a change order and a revision round?

A revision round is feedback on work inside the agreed scope, such as adjusting the layout of a page you agreed to design. A change order covers something new: another page, a new feature, a different integration, or a reversal of an approved decision. Define both in the contract.

Can AI draft the whole change order?

It can draft the description, assumptions and wording well. It should not set the price or approve the scope. You provide the hours and rate, then read every line before the client sees it. Treat it as a fast first draft from the client's email.

Further reads

• AI Engagement Letters for Accountants: Faster Drafts, Clear Scope — Scope wording in an engagement letter works the same way.
• How Freelancers Use AI for Invoices, Proposals and Chasers — Invoices and payment chasers once the change order is approved.
• How to Mention AI Use in Client Contracts and Proposals — How to mention AI use in your client contract and proposal.
• AV Scope of Work: Draft It From Discovery Notes With AI — Another trade drafting scope from discovery notes with AI.
• How Consultants Use AI to Write Proposals in Under an Hour — Tighter proposals mean fewer change orders later.
• AI Email Triage for Professional Firms: Sort, Summarise, Draft — Catch scope requests buried in client email.
• Timesheet Software for Agencies: Budgets, Billable Hours and AI — Four timesheet tools compared on project budgets, burn alerts, billable-hour reports and AI, with a worked fixed-fee project and a weekly AI budget digest.
• AI Scope of Work Generator for Agencies: SOWs With Change Control — A worked example from client call to signed SOW: counted deliverables, exclusions, change-control wording and a filled change request form.
• Figma Make for Web Designers: Client Prototypes and Where It Breaks — How a web designer can turn a brief into a clickable Figma Make prototype, which plan to check, and the places it tends to fall short on real client work.
• Web Design Client Questionnaire: Collect Content and Goals With AI Help — Twenty questions to ask a new web design client, then prompts that turn the answers into a brief, sitemap and content plan.
• Web Design Proposal Template: Draft Scope, Fees and Timeline With AI — A filled-in web design proposal: scope, phases, payment schedule, assumptions and revision limits, drafted with AI and checked by you.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: general freelance and agency contracting practice. Prices and hours in the examples are illustrative; no vendor facts are used. Have a lawyer review contract wording before you rely on it.