Add to Preferred Sources
Every website change request template is a structured form that captures each modification to an agreed web project scope — what needs to change, why it matters, what it will cost, and who approved it before a single line of code is written. Understanding the full cost of a website in South Africa means accounting for what happens when the scope shifts mid-build, and this template is the tool that keeps both sides protected when it does.
Most web project disputes in South Africa do not start with the original brief. They start with a string of "quick changes" requested over WhatsApp or in passing — a new section here, a revised layout there — none ever priced, none ever signed off. By the time the site launches, the agency has absorbed extra hours it never quoted and the client is reading an invoice they did not expect. A website project brief locks the starting scope; the change request template is what you use when the scope moves beyond what was agreed.
Quick Answer
A website change request template is a short form — typically eight to twelve fields across three sections — that both the client and the agency complete before any out-of-scope work begins. It captures the change description, the reason behind it, the cost and timeline impact, and written client approval. Use one for every modification that falls outside the original brief: a new page, a layout change, an added feature, or a revised user flow. The rule that protects both parties: no written approval, no work starts.
Jump To
Not sure what falls inside your current website scope?
Send us your project brief and we will flag the grey areas before scope disputes start — no obligation.
Talk to UsWhat a Website Change Request Does for Your Project
A website change request creates a documented record for every modification that falls outside the original agreed scope — it separates a paid change from an assumed favour, and an authorised revision from a verbal instruction that nobody remembers clearly six weeks later. Without this record, scope expands through messages, calls and informal conversations, leaving neither party with a clear audit trail of what was approved.
According to PM Study Circle, drawing on PMI research, 52% of all projects experience scope creep, with those projects averaging a 27% cost overrun against the original budget. On a typical web build, a 27% overrun is a material unplanned invoice — absorbed by someone. Without a formal change request process, it is typically absorbed by the agency in the form of unlogged hours, which eventually surfaces in rushed delivery, reduced quality, or a tense final handover.
The template also forces clarity at the right moment. Clients who must describe what they want changed, and why, frequently discover that the real goal can be achieved within the existing scope. The reason field is the most valuable part of the form: it surfaces intent, and intent often has a simpler solution than the specific change first requested.
Key Point
A website change request template protects both parties: the agency recovers the cost of genuine additions to scope, and the client sees exactly what they are approving — including cost and timeline impact — before the work starts and before the invoice arrives.
What Your Website Change Request Template Must Include
A usable website change request template contains two distinct blocks — a client-facing request section that defines the change, and an agency-side assessment section that prices and approves it — plus a final sign-off block. Anything shorter creates ambiguity; anything longer creates enough friction that the form stops getting used. The structure below draws on the field guidance from the WP Super Help change request guide and ProjectManager's free template.
Section A — Client Request
| Field | What to Enter |
|---|---|
| Project name | Your website or project name as stated in the original brief |
| Change request number | CR-001, CR-002 — number each new request sequentially |
| Requested by | Full name, role, and contact email address |
| Date submitted | DD/MM/YYYY |
| Change description | Clear description of what must change and exactly where on the site — be specific |
| Reason for change | The goal this change achieves — not just what you want but why you want it |
| Priority level | Low / Medium / High |
| Requested completion date | DD/MM/YYYY — allow realistic time for assessment before this date |
Section B — Agency Assessment (Agency Use Only)
| Field | Agency Entry |
|---|---|
| Feasibility | Is this achievable as described? Note any technical constraints or dependencies |
| Estimated hours | [Hours required to design, build and test the change] |
| Hourly rate | R[rate]/hr as specified in the project agreement |
| Additional cost | R[total] — estimated hours × agreed rate |
| Timeline impact | How many working days does this add to the agreed delivery or launch date? |
| Status | Approved / Declined / On Hold / Requires clarification |
| Agency sign-off | Project lead name and date |
Section C — Written Approval
| Field | Detail |
|---|---|
| Client approval | Signature, or written confirmation by email (attach or log the thread) |
| Date approved | DD/MM/YYYY |
| Terms | Work on this change commences only after this section is signed or confirmed in writing. |
Keep a numbered change log alongside the forms — a simple spreadsheet with one row per change request, tracking the status and approved cost of each. This makes the total scope additions visible throughout the project and removes billing surprises at launch.
The Five-Step Website Change Request Process
A reliable website change request process follows five stages in sequence — submit, assess, quote, approve, execute — with no stage skipped and no work beginning before written approval is in hand. Shortcutting any stage is where most web project disputes originate, and the disputes are always harder and more expensive to resolve after the work has been done.
- Submit. The client completes Section A and sends it to the project lead. Verbal requests — made in calls, over WhatsApp, or in meetings — do not trigger an assessment. If it is not submitted in writing, it is not a request. This single rule filters out the most casual scope additions before they become entrenched assumptions.
- Assess. The project lead evaluates whether the change is technically feasible, estimates the hours required, and identifies the impact on the current delivery timeline. As a working guide, assessment should happen within one to two business days for non-urgent requests — enough time to think clearly without creating bottlenecks for the client.
- Quote. The agency completes Section B and returns the assessed form to the client as a formal change order — cost, hours estimate, rate, and timeline impact all documented. This is not a rough estimate; it is the number the client approves or declines.
- Approve. The client reviews and approves in writing — by signing Section C or by replying to the change order with explicit written confirmation. Silence is not approval and must never be treated as such.
- Execute. Only after Section C is complete does the work begin. The completed form is filed and a new row is added to the change log. The project continues with an updated timeline if the change added days.
This five-step flow mirrors the discipline used in the web design process that South African agencies apply to the original brief — applying the same rigour to scope changes gives the whole project coherent governance from kickoff to handover.
The Rule That Prevents Most Disputes
No written approval, no work starts. Applied from day one and without exceptions, this single rule prevents the majority of scope disputes on web design projects — for both the agency and the client.
Which Website Changes to Log as a Change Request and Which to Absorb
Not every client request warrants a formal change order — the distinction rests on whether the modification falls inside the original agreed brief or whether it genuinely adds work and cost that were never part of the agreement. A website scope change request should only be raised when the work clearly falls outside the signed-off scope; the table below is the working reference.
| Type of Change | Log as Change Request? | Reason |
|---|---|---|
| Bug or error in work the agency delivered | No — absorb | Defects in delivered work are the agency's responsibility to fix at no charge |
| Copy error on a page the agency wrote | No — absorb | Errors in deliverables are not scope changes — they are quality issues |
| Minor wording tweak in the original, agreed copy | No — absorb (within reason) | Small text edits on an in-scope page are typically covered, up to a reasonable limit |
| New page not in the original site map | Yes — log it | An additional page adds design, build and content work outside the agreed scope |
| Layout change to an already-approved page design | Yes — log it | A signed-off design is a completed deliverable; redesigning it is new billable work |
| New functionality (booking form, calculator, map integration) | Yes — log it | Features not in the brief require development time and often additional tools or licences |
| Brand colour or font change after design sign-off | Yes — log it | Systematic design changes affect every page already built and require full re-implementation |
| Extra product categories or custom post types in the CMS | Yes — log it | Structural CMS additions require planning, templates and testing beyond the original scope |
The practical rule: if the original brief, agreed site map, or signed design file covers it, the agency fixes or adjusts at no additional charge. If it was not in any of those documents, it is a scope addition and a web design change request applies.
Why Small Changes Add Up
Minor wording edits on approved pages sound trivial. But as a working heuristic, five text adjustments across a fifteen-page site can add two to three hours of development and QA time. At R550/hr — the midpoint of the R400–R700 mid-level developer band from freelancian.co.za (2026) — that is R1,100–R1,650 in unrecovered cost from a single project. A running change log keeps these invisible costs visible before they become a dispute at billing time.
South African Web Project Considerations
South African web projects carry specific context that shapes how change requests should be structured — from developer rate benchmarks in Rand to the written approval norms that local business practice and consumer protection law both favour.
Developer rate context for costing change orders
According to freelancian.co.za (2026), SA web developer rates run approximately R200–R400/hr for junior-level work, R400–R700/hr at mid-level, and R700–R1,200+/hr for senior and full-stack development. Agency rates typically sit at the mid-to-senior end of these bands depending on the studio, and retainer work often has a different structure. Whatever rate applies to your project should be stated explicitly in Section B of every change order — this removes any ambiguity when the invoice arrives.
Illustrative Cost Calculation: One Untracked New Page
Using R550/hr as a working example (midpoint of the R400–R700 mid-level band, freelancian.co.za 2026 — confirm your actual rate with your developer). A new page build typically takes 3–6 hours of design, development and QA work as a practical working heuristic. At R550/hr that is R1,650–R3,300 for a single new page added after the site map was agreed. A completed web design change request with an approved cost figure makes this visible before it becomes a post-launch invoice.
Written agreements and SA business practice
South African business practice strongly favours written agreements for service work — a position reinforced by the Consumer Protection Act 68 of 2008, which provides consumer protections around agreed service terms and material changes to them. A signed change order is the practical instrument that satisfies this: it records what was agreed, by whom, and on what date. An email thread confirming the change constitutes written approval in most circumstances, but a numbered change request form is cleaner, sequentially traceable, and significantly harder to dispute.
Website deposit and payment terms in South Africa are most commonly structured with a deposit at the start, a milestone payment during the build, and a final payment on launch. Change order costs should be invoiced at the milestone nearest to when the change is executed, or consolidated at launch — whichever approach is specified in the original contract. State this upfront in the engagement letter.
WhatsApp approvals and the SA context
In South Africa, WhatsApp is the dominant channel for day-to-day business communication. Many clients and agencies run entire website projects through chat threads. This creates a specific risk: approvals that happen in a WhatsApp message are real agreements, but they are difficult to locate, easy to misread out of context, and almost impossible to audit clearly three months after launch. Use WhatsApp to discuss changes in real time — then formalise the outcome in a completed website change request form before any work starts.
Managing website changes and not sure what they should cost?
Share your project scope with us and we will map out which requests fall inside your brief and what a clear change order structure looks like — no commitment required.
Get a Scope ReviewWhy South African Businesses Choose Growth Pulse Media
Growth Pulse Media was founded by Dirk van Greuning, who built and scaled a large South African ecommerce business before moving into digital agency work. That operator background means GPM treats website projects the way a business owner does: scope is defined before work starts, changes are priced honestly, and communication does not fall through the gap between a junior account manager and a developer you never speak to directly.
Our web design service runs with a limited client load, which means every project gets senior-level attention from brief to handover. We document change requests using the same process described in this guide — written, numbered, costed and approved before a single revision is made. That discipline keeps budgets predictable and launch conversations productive rather than adversarial.
All work is executed in-house in Johannesburg. No subcontracting. No offshore builds where WhatsApp approvals disappear in time-zone gaps and no one owns the accountability.
Who This Is NOT For
Ready to start your website project with clear scope from day one?
Tell us what you need and we will audit your project brief for scope gaps before we quote — so there are no surprises on either side of the engagement.
Request a Brief AuditFrequently Asked Questions
What should a website change request template include?
A website change request template should include three sections: a client request block covering the project name, sequential request number, requestor details, change description, reason for the change, priority level, and requested date; an agency assessment block covering feasibility, estimated hours, agreed rate, additional cost, timeline impact, and approval status; and a final approval block for written client sign-off and date. Numbering each request sequentially allows both parties to track all scope changes in a log across the full project lifetime.
What is a website change order?
A website change order is the agency's formal response to a change request — it states what the change will cost, how long it will take, and what impact it has on the agreed delivery date, presented to the client for written sign-off before work begins. The terms "change request" and "change order" are often used interchangeably, but technically the request originates with the client and the order is what the agency issues back after completing the assessment in Section B of the template.
How do I handle scope creep on a web design project in South Africa?
Handle scope creep by introducing a change request process before the project starts — not after the problem appears. Define what is in scope in writing, make the change request form part of the original contract or engagement letter, and apply the rule that no out-of-scope work begins without a completed and signed change order. For SA projects, email confirmation is legally sufficient as written approval under most circumstances, but a numbered change request form is easier to audit at billing time and far harder to dispute.
Do I need a change request form for small website updates?
For genuinely minor updates — fixing a typo, swapping an image the client supplied, correcting a broken link — a formal three-section change request adds more friction than the update warrants. As a practical working heuristic, use the form for any change that would take more than roughly 30–60 minutes of developer time, introduces new functionality, or modifies an already-approved design element. A simple shared threshold like "would this take more than an hour?" helps both sides agree consistently without turning every small request into a documentation exercise.
How much does a website change request typically cost in South Africa?
The cost depends entirely on the nature of the change and the developer rate in your project agreement. According to freelancian.co.za (2026), SA web developer rates run R200–R400/hr at junior level, R400–R700/hr at mid-level, and R700–R1,200+/hr for senior and full-stack work. As a working heuristic, a new page typically takes 3–6 hours of build and QA work; a layout revision on an existing approved page typically takes 2–4 hours. Your change order should always state the specific hours estimate and rate applied so the cost is transparent before sign-off.
Build Your Website Without Budget Surprises
Growth Pulse Media handles web design on WordPress with full SA context — POPIA-aware structure, local payment gateway integration (PayFast, Peach Payments, Yoco), and a documented change request process built into every engagement from brief to launch. All work is executed in-house in Johannesburg with no subcontracting. No obligation — we will get back to you within 24 hours.
Talk to Us