Website Change Request Form and Process (With Free Template and Example)

Most disputes on a website project come down to one thing: work that happened outside the agreed scope, with no paper trail. A change-request process fixes that. It gives both sides a calm, repeatable way to handle the “can you also…” moments that show up on every build, so out-of-scope work gets documented, priced, and approved instead of quietly absorbed.

We run this process on the white-label projects we deliver for agencies, so here’s the version that actually holds up in practice, including the change request form we use and a worked example. You can lift any of it straight into your own workflow.

What is a change request?

A change request is a formal, written request to change something outside a project’s agreed scope, like a new feature, a design revision, or an extra page. On a website project it records what the client wants, the reason behind it, and what it costs in time and money, all before any work begins. The written part is what matters. A request made in passing on a call isn’t a change request until it’s on paper with a price next to it.

Change request examples for web projects

Most change requests on a website build are not clients being difficult. They are reasonable asks that simply landed after the scope was agreed. Here are ten that come up again and again, with realistic time ranges for an experienced team. Treat these as typical ranges, not fixed prices: your actual hours depend on your stack, how far along the build is, and the specific tools involved. Dollar figures use the $95 an hour from the filled example below. Small items usually slot in without moving the launch date, while big ones like a store or a second language can push it by a week or more.

1. Add a testimonial slider to the homepage. The client lands a few strong reviews after kickoff and wants them higher up the page. About 2 to 6 hours ($190 to $570). A ready slider block sits at the low end; a custom carousel matched to a bespoke design runs higher.
2. Swap a basic contact form for a booking widget. The client wants visitors to schedule calls directly instead of emailing. Wide spread, because it is really two jobs: a styled Calendly-type embed is about 2 to 4 hours ($190 to $380), while a full native booking system with services, availability, and payments runs 8 to 20 hours ($760 to $1,900).
3. Add a blog or news section that was not in the original scope. The client commits to content marketing after seeing competitors do it. About 6 to 14 hours ($570 to $1,330), depending on how much the post and archive templates need custom design versus leaning on the theme defaults.
4. Add a custom section after sign-off, such as a case studies post type or a team page with its own layout. About 6 to 16 hours ($570 to $1,520). A simple team grid sits low; a filterable case-studies type with its own detail pages sits high.
5. Change the logo and brand colors mid-build. The client rebrands partway through. About 2 to 12 hours ($190 to $1,140). A quick swap if colors live in global styles and few pages are built, much more if many pages are already styled with per-section colors that each need re-touching.
6. Add a second language with a basic multilingual setup. The client expands into a new market and wants key pages translated. About 14 to 40 hours ($1,330 to $3,800), and the most underestimated item here. The low end is Polylang on a clean theme with a few pages; the high end is WPML on a page-builder theme with menus, form fields, SEO, and real hand-translation. The parts people forget: theme strings, confirmation emails, hreflang, and who re-translates content when it changes.
7. Turn a brochure site into a basic online store. The client decides to sell products during the build. About 12 to 30 hours ($1,140 to $2,850), and almost always a separate quote. The plugin installs in an hour, but a real basic store means payment setup, shipping and tax, a batch of products, styling the store pages to match, and end-to-end test orders. Expect the high end when the theme is not built for WooCommerce.
8. Integrate a third-party tool such as a CRM, email platform, or payment gateway. The widest spread on the list, because it depends entirely on the tool. A connector plugin or an official gateway like Mailchimp or Stripe is about 3 to 8 hours ($285 to $760). A custom CRM sync with field mapping and webhooks, or a non-standard gateway, climbs to 20 to 40 hours ($1,900 to $3,800) or more.
9. Add post-launch SEO work beyond the agreed basics. The client wants meta titles across the site, schema, and redirects from an old site. About 8 to 25 hours ($760 to $2,375). It is volume-driven: unique titles and a clean redirect map on a 20-page site is a different job from a few-hundred-URL migration.
10. Run an extra revision round past the agreed cap. A stakeholder joins late and wants another pass at the homepage. About 2 to 6 hours ($190 to $570) per round, depending on whether it is a light tweak or a substantive rethink, plus the time to build the approved changes.

Notice the through line: every one of these is a fair request, not a fight. That is the whole point of a change-request process. It is not a way to say no, it is a way to say yes with the cost and timeline attached. The line between a legitimate change and scope creep is not the size of the ask. It is whether the work got documented, priced, and approved before it started.

Why does an agency need a change-request process?

Without one, every new idea mid-project forces a bad choice: do the work for free, or stop and have an uncomfortable money conversation you weren’t prepared for. A change-request process removes that tension. The client knows up front that new requests are welcome and that each one comes with a clear cost and timeline impact. You protect your margin, and they never get surprised by an invoice.

The risk is real and well documented. PMI’s 2018 Pulse of the Profession found that 52% of projects ran into scope creep or uncontrolled change, up from 43% five years earlier. On website builds, that creep almost always enters through informal requests that never got priced. A simple form closes the gap.

How do you define the change-request process in the contract?

Spell it out in the web design proposal, scope of work, or contract before the project starts, so it’s a shared agreement rather than a rule you spring later. Cover three things: how changes get requested, how they get assessed, and how approval and billing work. A short clause does the job:

“Any request beyond the agreed scope will be reviewed and subject to a formal change order. Additional costs and timeline adjustments will be presented for your approval before any out-of-scope work begins.”

That single paragraph turns later conversations from a negotiation into a reminder of something already agreed.

What should a change request form capture?

Use one standard form so every request is recorded the same way. It can be a Google Form, a PDF, or a field in your project tool. Capture:

• Requestor name and contact
• Project name and reference number
• A clear description of the change, for example “add a testimonial slider on the homepage”
• The reason behind it, so you understand the goal, not just the ask
• Priority level (low, medium, high)
• Requested deadline, if there is one

The reason field matters more than it looks. Half the time, once you understand what the client is actually trying to achieve, there’s a simpler in-scope way to get there.

A change request form template you can copy

Here’s the full form, ready to copy into a Google Doc, a PDF, or your project tool. The top half is for the client, the bottom half is for your team. Keep it to one page.

CHANGE REQUEST FORM

Project:            [project name / reference no.]
Date:               [date]
Requested by:       [client name + contact]

Change requested:   [what should change, in plain terms]
Reason / goal:      [what the client is trying to achieve]
Priority:           [low / medium / high]
Needed by:          [deadline, if any]

--- Agency assessment ---
Feasibility:        [clean within current build, or touches the foundation?]
Added cost:         [hours x rate]
Timeline impact:    [days added / new dates]
Status:             [approved / declined / on hold]
Client approval:    [name + date]

That’s the whole template. Save it as your standard change request template and reuse it on every project. The one field people skip and regret is “reason,” so keep it in.

A filled-in change request example

Same form, filled out for a real-world scenario: a client asks for a homepage testimonial slider midway through a dental practice redesign.

CHANGE REQUEST FORM

Project:            Greenline Dental redesign (#GD-204)
Date:               14 March 2026
Requested by:       Sarah Lin, Greenline Dental

Change requested:   Add a rotating testimonial slider to the homepage,
                    below the services section.
Reason / goal:      Wants social proof higher up the page to lift
                    consult bookings.
Priority:           Medium
Needed by:          Before launch (28 March)

--- Agency assessment ---
Feasibility:        Clean. Slider already used elsewhere on the build.
Added cost:         4 hours x $95 = $380
Timeline impact:    +1 day; launch holds at 28 March
Status:             Approved
Client approval:    S. Lin, 15 March 2026

The change order you send back is just the bottom half of that form: the cost, the new dates, and a line to approve. Short enough to read in under a minute, specific enough that nobody argues about it later.

How do you review and approve a change request?

When a request comes in, the project lead assesses three things before quoting anything:

• Feasibility. Can it be done cleanly within the current build, or does it touch the foundation?
• Cost. The real hours, not a guess you’ll regret.
• Timeline. What it pushes back, so the client can weigh speed against scope.

Then send a short change order with the price and the new dates, and wait for written approval before starting. No approval, no work. That discipline is the whole point: it keeps the project’s scope, budget, and timeline honest from kickoff to launch.

A clean change-request process is also what makes scope creep manageable in the first place. If you want the wider playbook, read how agencies take control of scope creep. And if the real constraint is that you don’t have the dev capacity to deliver the changes clients keep asking for, our white-label WordPress team can build them under your brand. Send us the details to see how it fits.

Frequently asked questions