A website change request is a formal, documented ask to modify work already agreed on in your contract or project scope. Handling it well comes down to four steps: define the process in your contract before you start, capture every request on a standard form, run a quick impact assessment, and get written approval through a signed change order before anyone touches the build. The rest of this guide gives you the templates and rules to make that happen.
TL;DR:
- Most change requests that impact scope, timeline, cost, or technical systems should follow a formal process with written approval and impact assessments.
- Impact evaluations must consider effects on SEO, analytics, accessibility, privacy, and ongoing maintenance to avoid hidden costs or delays.
- A change request form must include detailed descriptions, business reasons, scope boundaries, dependencies, effort estimates, and approval tracking to prevent scope creep.
- Approval should be swift, with a clear owner, and work must not commence until a signed change order is in place, especially for large or high-risk modifications.
- Small, non-impactful requests like minor copy edits can be handled informally, but everything that affects project scope requires a documented change process.
Table of Contents
- What Is a Change Request in Web Design, and When Do You Need One?
- What Do Change Requests Look Like on Real Projects?
- What Should a Change Request Form Actually Capture?
- How Do You Assess the Impact of a Change Request?
- How Should You Structure Approval and Decision-Making?
- What Happens to a Change Request After It’s Approved?
- What Contract Language Protects You From Scope Creep?
- How tcosi Applies This Process to Real Client Projects
- When to Hold the Line and When to Just Say Yes
- How tcosi Can Set Up This Process for Your Website
- Templates and Standards Worth Bookmarking
- Sources
- FAQ
What Is a Change Request in Web Design, and When Do You Need One?
Every change request follows a similar path: draft, then submitted, then under review, then approved or rejected, then done. That lifecycle, laid out in Oracle’s project management documentation, gives you a checkpoint at every stage instead of letting requests drift into “we’ll figure it out later.”
The hard part is knowing when a request actually needs this process versus when it’s just a small fix you handle and move on. Anything smaller is usually a revision you can knock out in an hour.
Common triggers that should always route through a change request:
- A new deliverable that wasn’t in the original scope (extra pages, new features)
- A shift in launch date or a dependency on another vendor’s timeline
- Anything touching tracking, analytics, or third-party integrations
- Structural changes to URLs, navigation, or page hierarchy
Set a response SLA for triage, too. One business day to acknowledge a request and flag whether it needs a full impact assessment keeps clients from feeling ignored while you protect your own bandwidth.
What Do Change Requests Look Like on Real Projects?
Not every request deserves the same paperwork. Some are quick tickets; others need a full change order. Here’s how common ones typically break down:
- A new landing page mid-build. Usually a formal change request. Hidden work includes navigation updates, internal linking, and a new entry in your analytics dashboard.
- A gated resource (ebook, whitepaper) behind an email form. Formal change request. It touches CRM integration, form validation, and often legal review for data collection language.
- A login or member portal added late. Almost always formal. This affects architecture, security, and hosting costs, not just design.
- A request to change how conversions are tracked. Ticket-level if it’s a single event; formal if it changes your whole measurement plan. Either way, according to Azure DevOps guidance, tag it and track it as a work item so it doesn’t vanish into a Slack thread.
- Renaming or restructuring URLs. Formal, always. This demands a redirect map and an SEO risk check before anything goes live.
- A new third-party integration (booking tool, chat widget, payment processor). Formal, since it usually needs QA across browsers and devices.
- An accessibility fix requested after launch. Often a ticket, unless it requires a structural rebuild of a component.
- “Can we just add this one thing before we go live?” Treat as a formal, expedited change request, not a favor.
What Should a Change Request Form Actually Capture?
A good form does two jobs: it gives you enough information to size the work fast, and it creates a paper trail if a client later asks “wait, who approved this?” Skip fields and you’ll end up guessing at scope weeks later.
Core fields every form needs:
- Requester name and date
- Unique request ID (tie it to your project management tool)
- Plain-language description of the change
- Business reason behind the request
- Acceptance criteria (what “done” looks like)
- What’s explicitly in scope and out of scope
- Dependencies on other pages, systems, or vendors
- Attachments (mockups, reference URLs, screenshots)
Commercial fields matter just as much, even if they feel awkward to ask for upfront:
- Estimated effort band (small, medium, large, or hours if you bill hourly)
- Pricing model for this specific change (flat fee, hourly, or bundled into a retainer)
- Any administrative or scoping fee for larger estimates
- Payment terms and timing (before work starts, on delivery, etc.)
Process fields close the loop: status (draft, submitted, in review, approved), approver name, approval date, and the baseline or version number this change modifies.
Pro Tip: Build this form once as a reusable document or a form in your project management tool, and require every client request to go through it, even the ones that arrive as a two-line email. It takes five minutes to fill out and saves hours of “wait, what did we agree to?” later.
How Do You Assess the Impact of a Change Request?
Every change request gets measured against three core axes: timeline, budget, and technical dependencies. Miss one of these and you’ll either blow a deadline or discover a hidden cost after the work is already done. PMMajik’s guidance on impact assessment recommends evaluating all three before anyone commits to a change, and treating large changes as their own workstream so they don’t derail the current sprint.
Beyond the basics, run these specialized checks depending on what the change touches:
- SEO: Does it rename or remove a page? You’ll need a redirect plan before launch, not after.
- Analytics: Does it change a form, button, or tracked event? Map the new event to your existing reporting so you don’t lose historical data.
- Accessibility: Does it add a new interactive component? Confirm keyboard navigation and screen reader support, especially with ADA compliance deadlines approaching in 2027.
- Privacy and security: Does it collect new user data? Flag it for a quick legal review.
- Maintenance: Will this add ongoing upkeep (a new plugin, a custom integration)?
A simple scoring approach helps here: rate business value, urgency, effort, risk, and reversibility on a 1 to 5 scale. A request that scores high on value and low on effort gets fast-tracked; one that scores high on risk and low on reversibility gets a longer look.
Once you know the impact, you generally have four options: split the work into phases, defer it to post-launch, accept it with an adjusted timeline and budget, or, for genuinely large changes, run it as a parallel stream so it doesn’t disrupt the current build.
How Should You Structure Approval and Decision-Making?
Triage happens fast, ideally within one business day of a request landing, so the client knows whether it’s a quick yes or something that needs a closer look. From there, anything beyond a minor fix goes to a change-control meeting.
- Present the impact. Whoever ran the assessment walks through timeline, budget, and technical risk in plain terms.
- Propose options. Approve now, defer to a later phase, split the request, or reject it, each with a clear reason.
- Decide and name an owner. One person signs off, no group consensus required. ProjectManager’s guidance on this is blunt: naming a single decision owner shortens approval cycles and stops requests from bouncing between five people forever.
- Log the decision. Written record, timestamped, tied to the request ID.
Approval rules should be non-negotiable: no work starts until someone with budget authority signs the change order. For requests that land inside a tight launch window, use a critical, defer, or swap framework instead of a full meeting; near-launch changes need a documented rollback plan and a fast, limited approval, not a week of back-and-forth.
Pro Tip: If a client pushes back on the “no signature, no work” rule, frame it as protection for them too. It means nothing gets built that they didn’t explicitly agree to pay for.
What Happens to a Change Request After It’s Approved?
Approval isn’t the finish line. It’s the point where the request becomes real, trackable work. Once a change order is signed, update your project baseline: new milestone dates, revised budget line, and a version number tied to the change request ID so anyone reviewing the project later can see exactly what changed and when.
From there, break the approved change into discrete tickets:
- Design mockups or updated wireframes
- Development tasks, tagged to the change request ID
- QA testing across devices and browsers
- Analytics mapping for any new or modified tracked events
- Content updates or copywriting
- Deployment steps, plus a rollback plan if something breaks
Assign an owner and a due date to each ticket. Azure DevOps recommends tracking these as work items with velocity or burndown charts so scope creep shows up visually instead of quietly eating your schedule.
Keep a running change log: request ID, one-line summary, owner, approver name, approval date, and a link to the updated baseline. It takes two minutes per entry and turns “what did we agree to in March?” into a five-second lookup.
What Contract Language Protects You From Scope Creep?
The best change-request process in the world doesn’t help if your contract never mentions it. Set the rules before the project starts, not after the first surprise request shows up.
A few clauses worth adding to every proposal or statement of work:
- Define what counts as “in scope” explicitly, and state that anything outside it requires a written change order before work begins.
- Set a threshold (a percentage of the original quote, or a flat dollar figure) above which a scoping or administrative fee applies.
- State clearly that no design or development work starts on a change until it’s signed.
- Note billing terms for approved changes, whether that’s upfront, on delivery, or added to the next invoice.
When you introduce this to a client, keep the tone collaborative, not defensive. Something like: “As we build, you might think of things you’d like to add or adjust. That’s normal. Here’s how we’ll handle it so nothing falls through the cracks and there are no surprise costs.” A short line like that in your kickoff call sets the expectation early, without making it feel like a warning.
How tcosi Applies This Process to Real Client Projects
Every project I take on runs through a version of this exact process, because I’ve seen what happens without one: scope drifts, timelines slip, and nobody remembers who agreed to what. A documented change request policy fixes that before it starts.
On tcosi projects, a few operational rules stay consistent:
- Impact assessments get a same-day or next-business-day turnaround, so clients aren’t left guessing.
- Every approved change gets a written change order, even for small requests, so pricing and timeline adjustments are on record.
- Version numbers get tied to each approved baseline, so if a client asks “what did the site look like before this change,” there’s a clear answer.
If you’re setting this up for your own projects, start with a simple form covering the fields above and a short clause in your contract defining what triggers a formal request.
When to Hold the Line and When to Just Say Yes
Not every small request deserves a full change order. If a client asks to swap two words in a headline, just do it. Save the formal process for anything that touches timeline, budget, or technical risk. The mistake I see most often isn’t being too strict. It’s being too flexible early on, which trains clients to expect free scope forever. A five-minute form filled out consistently protects the relationship far better than an awkward conversation about unpaid hours three weeks later.
— Tommy Cosimano
How tcosi Can Set Up This Process for Your Website
tcosi gives you a working change request system from day one, not something you have to build yourself after your first scope disagreement. Every project, from a new website design build to an ongoing site, gets a documented process for handling requests, assessing impact, and getting written sign off before any billable work starts.
If you’re mid-project and dealing with change requests that keep slipping through the cracks, or you’re about to kick off a new site and want the process set up correctly from the start, tcosi’s Ongoing Maintenance plan at $100 per month includes structured content updates and plugin management with clear turnaround expectations. For a new build, Growth at $2,400 one-off and Premium at $4,800 one-off both include the scoping conversations that prevent most change requests before they happen. Reach out through tcosi’s contact page to talk through your project and get pricing specific to your scope.
Templates and Standards Worth Bookmarking
For the underlying frameworks referenced throughout this guide, Oracle’s change request documentation covers the standard lifecycle in detail, while PMMajik’s impact assessment guide walks through scoring timeline, budget, and technical risk. For accessibility-specific impact checks, this guide on web accessibility and SEO explains why interface changes need an accessibility pass before launch, not after.
Sources
- Change requests (Oracle Cloud Project Management)
- Impact assessment of project change requests (PMMajik)
- Manage change across services (Azure DevOps docs)
- Change request: how to submit (ProjectManager blog)
FAQ
What Are the Four Types of Change Requests?
Definitions vary slightly by industry, but in web design projects, change requests generally fall into four buckets: scope changes (new deliverables), timeline changes (deadline shifts), budget changes (cost adjustments), and technical changes (integrations, tracking, or infrastructure updates). Most real requests combine two or more of these at once.
What Are Some Examples of Change Requests in Web Design?
Common examples include adding a new page mid-build, introducing a login or member portal, changing how conversions are tracked, restructuring URLs, or adding a third-party integration like a booking tool. Each carries different hidden work, from redirect maps to legal review, which is why every one should go through a standard form before work starts.
What Is a Design Change Request?
A design change request is a documented ask to modify an already-approved design element, such as a layout, color scheme, or component, after that design has been signed off. It follows the same lifecycle as any other change request: draft, submit, review, and approve or reject, ideally with a written change order before the designer starts revising.
What Is a Change Request, Exactly?
A change request is a formal, written proposal to modify something already agreed on in a project’s approved scope, whether that’s a deliverable, timeline, or budget. It exists to create a clear record of what changed, why, and who approved it, so nobody is left guessing later.
Does tcosi Charge Extra for Change Requests?
Pricing for changes depends on the scope of the request and the type of project agreement in place. Current pricing for new builds and ongoing plans, including the $100 per month Ongoing Maintenance plan, is listed on tcosi’s pricing page.
