Change Request Template for Changes After Approval
By Danial Pourgolab · 10 min read · October 2026
The client approved the brief. Design is under way. Then a message lands late in the afternoon: 'Quick one, could we add a news section? Shouldn't be much.' You know it is not quick. You also know that if you reply with a yes and a smiley, nobody will ever pay for it.
Changes after approval are normal. Clients learn things once they see the work taking shape, and some of their new ideas really are better than the original plan. The change itself is not the problem. The problem is a change that gets absorbed without anyone writing down what it costs, or what the client approved before it.
This post gives you a change request template to copy, a filled-in example, and the habits around it: telling a change from a clarification, pricing it, getting a written yes, and keeping the original approval intact while the brief moves on.
First, is it a change or a clarification?
Not every question after approval is a change. Before you write anything up, check the request against the approved brief.
A clarification asks how to do something the brief already covers. 'Which photos go on the team page?' is a clarification if the brief includes a team page. Answer it and move on. A change moves what you deliver, when you deliver it, or what it costs. 'Can the team page have a profile for each partner?' is a change if the brief said one page with a group photo.
The test is short: does the request alter a deliverable, a date or the price? If yes, it needs a change request, however small it sounds in the email. Most of the scope creep examples agencies run into start with a request that nobody ran through this test, because it arrived sounding like a clarification.
Scope change vs scope creep
A scope change and scope creep can be the same piece of work. The difference is what happens before anyone starts it.
A scope change is written down, priced and approved by the client. Everyone knows what moved, what it costs and when it will land. Scope creep is the same request absorbed without that step. The work gets done, the hours come out of your margin, and the client never learns they asked for anything new.
So a scope change request does not say no. It says: here is what this would take, do you still want it? Most clients respect that question. Most of the habits that prevent scope creep happen before the brief is approved. The change request is the one that works after it.
The rule: every change gets its own written approval
When the client approved the brief, they approved that brief: the scope, the price and the dates as they stood that day. That approval does not stretch to cover what is added later.
So every change gets three things of its own. Its own written approval from the person who holds the budget. Its own price, or a written 'no charge', and its own line on the invoice. And a place in the project file, next to the original approval rather than instead of it.
Keeping both matters later. The original approval shows what was agreed at the start. The change requests show what moved, when and why. Together they explain the final invoice without anyone having to remember a phone call.
The change request template
Copy the block below into a doc or an email. Keep it to one page: if the form takes longer to fill in than the change takes to build, nobody will use it. Each bracket tells you what belongs there; delete it as you fill it in.
CHANGE REQUEST Project: [project name] Reference: [CR-01, CR-02 and so on, one reference per change] Date raised: [date] Requested by: [name and role] Decided by: [the person who holds the budget, as named in the statement of work] Original approval: [who approved the brief, when, and where you keep the copy they approved] 1. WHAT CHANGES Now: [what the approved brief says, quoted or summarised] After: [what it will say if this change is approved, in plain words] 2. WHY [The reason, in the client's words. The goal behind the request, not only the request.] 3. EFFECT ON SCOPE Added: [new deliverables, pages or features] Removed or swapped: [anything that comes out to make room, or "nothing"] Rework: [finished work that has to be redone, or "none"] 4. EFFECT ON PRICE [The tasks and hours at the rate in the statement of work, or a fixed fee. If the change costs nothing, write "No charge", so that free is a decision.] Invoice line: [how it will appear on the invoice, for example "CR-02: news section"] 5. EFFECT ON DATES [Which milestones move and to when, or "No dates move".] 6. OPTIONS A: [the change as requested] B: [a smaller version, with its own price and dates] C: [move it to a later phase] D: [keep the brief as approved] 7. CLIENT'S DECISION Option chosen: [A, B, C or D] Name and role: [ ] Date: [ ] How it was approved: [an email reply quoting this reference, or similar] Work on this change starts once section 7 is filled in.
A few of the fields do more work than they look like they do:
- 1Decided by. A request from the marketing coordinator is not a decision from the person who holds the budget. Naming the decider up front saves sending the form twice.
- 2Original approval. Points back to the brief the client approved, so anyone reading the change request later can see what it changed from.
- 3Now and After. Quoting what the brief says now settles 'I thought that was included' before the argument starts. If you cannot write the After in a sentence or two, it is probably two change requests.
- 4Options. A smaller version or a later phase turns the request into a choice rather than a confrontation, and a cheaper path often gets a faster yes.
A filled-in example
The project is a five-page website for a regional accountancy firm. The approved brief has a contact form and no news section. Partway through design, the marketing lead asks for one.
It is one of the most common changes for web design agencies, because a 'simple blog' touches templates, the CMS, navigation and content all at once. Here is the change request, with the hours and dates left to your own task list and plan.
CHANGE REQUEST Project: Website for a regional accountancy firm Reference: CR-02 Date raised: [date] Requested by: Priya, Marketing Lead Decided by: James, Managing Partner (budget holder in the statement of work) Original approval: Brief approved by James; the approved brief, exported as a PDF before any edits, is attached. 1. WHAT CHANGES Now: Five pages (Home, Services, About, Team, Contact). A blog or news section is listed under "Out of scope". After: A news section with a listing page, an article template and simple category filters, editable by the client in the CMS. 2. WHY The partners want to publish deadline reminders and firm news, and hope it helps the site show up in search. 3. EFFECT ON SCOPE Added: two templates, the CMS collection, a navigation update on every page, a short training session for the client. Removed or swapped: nothing. Rework: the main navigation, which is already built. 4. EFFECT ON PRICE The tasks and hours in the attached list, at the day rate in the statement of work. Invoice line: "CR-02: news section" 5. EFFECT ON DATES Launch moves by the build and review time in the attached plan. The client supplies the first articles before launch, or the section launches empty. 6. OPTIONS A: Full news section as requested. B: Listing page and article template only, no category filters. Fewer hours and a shorter delay, both in the attached plan. C: Launch as approved and build the news section in a second phase. D: Keep the brief as approved. 7. CLIENT'S DECISION Option chosen: B Name and role: James, Managing Partner Date: [date] How it was approved: email reply quoting CR-02
Notice what the example does not do. It never argues about whether the firm should want a news section. It sets out what having one costs and lets the person with the budget choose. It also names the rework, the navigation that is already built, which clients rarely picture on their own.
Pricing the change without a fight
Clients rarely object to paying for extra work. They object to a number that appears from nowhere. Show your working, in the same units you used for the original quote.
If you priced the project by breaking it into tasks and estimating each one, do the same for the change: list the tasks, put hours next to them, and use the rate already in the contract. The client has already agreed to the rate, so the only thing left to discuss is the hours.
Two costs are easy to forget. Rework: if the change means redoing a finished design or rebuilding a component, that time counts. And overhead: another review round, another pass of testing, another meeting. The template has a line for rework so that it is visible before the client decides, not after.
Then price it promptly. A change request that sits unanswered while the team keeps building is worse than none: the work happens anyway, and the conversation about money only starts once it is finished.
What counts as a written yes
Section 7 is the point of the whole template, so be strict about it. A written yes comes from the person who holds the budget, refers to the change by its reference, and says which option they chose.
A thumbs-up in a chat, 'sounds good' on a call, a yes from someone who cannot approve spending, or a reply that approves the idea but ignores the price: none of these count. They feel like agreement in the moment. At invoice time, they are your memory against theirs.
A plain email reply that quotes the reference is enough. The format matters less than recording three facts: who approved, what they approved, and when.
Small changes and an agreed threshold
A form for every swapped photo is how change processes die. The team stops using it, and you are back to absorbing everything.
Agree a threshold before the project starts instead. When you write the statement of work, add a change-control clause: changes below a set size are absorbed up to an agreed allowance across the project, and anything larger, or anything after the allowance is used, goes through a change request. Pick the size and the allowance to suit your projects.
Log the small changes anyway, at the bottom of the same document. When the allowance runs out, you can show the client exactly what has already been included, which turns an awkward conversation into a factual one.
Keep the approved brief before you edit it
Once a change is approved, the brief needs updating so it describes the project you are actually building. That is where agencies lose the record of what the client approved first.
The order is simple. Before you edit the brief, save a copy of the version the client approved. Attach it to the change request. Then update the brief and ask the client to approve the new version. The next change request is measured against that version, and the trail from the first approval to the latest one is all in the project file.
If you send the brief for approval in ReqBrief
In ReqBrief, "Send for approval" gives you a link for your client. They read the brief, choose "Approve this scope" and confirm with their name. ReqBrief keeps a timestamped record of the approval and a snapshot of the brief they approved.
If something is wrong before they approve, the client can choose "Request changes" instead and answer "What needs to change?" in a comment, so the first round of changes arrives in writing.
If you edit the brief after the client approved it, the approval status changes to "Approved, brief edited since". Below it, "What changed since the approval" lists each section of the brief that moved, with the lines added and removed. Only you see that comparison. It shows what moved. It does not price the change or get the client's yes. That is the change request's job.
Two details decide the order of work. A new link keeps the earlier response, which the confirmation spells out: "Issue a new link? The old one stops working. Any response already recorded stays on this card as an earlier round." And the brief's own PDF export carries the "Client approval" line only while the brief still matches what the client approved. Once you edit, the approval card still offers the PDF of the brief exactly as the client approved it, with that line.
- 1Download the approved PDF. It carries the approval line with the client's name and the date. Before you edit, the brief's export gives it to you; after, "Download the approved PDF" on the approval card does. That file is your copy of what they approved.
- 2Keep it with the change request. Attach the PDF to the change request, or file the two together, so the original approval and the change sit side by side.
- 3Edit the brief, then send a new link. Once the change is approved, update the brief and send a new link so the client approves the brief as it now stands. The first approval stays on the card as an earlier round, with its own PDF.
Copy the template, agree a threshold in the next statement of work you send, and make the written yes non-negotiable. Changes will keep coming. They just stop being free.
ReqBrief interviews your client, turns their answers into a structured brief, and lets them approve it through a link with their name, so every change has a clear baseline to point to. Try it free on your next project.
Try ReqBrief free →Frequently asked questions
What should a change request template include?
A reference and the date, who asked for the change and who decides it, and a pointer to the original approval. Then what the approved brief says now and what it will say after the change, why the client wants it, and its effect on scope, price and dates. It ends with options and the client's written decision. Work starts only once that decision is recorded.
What is the difference between a scope change and scope creep?
A scope change is a change to the approved scope that is written down, priced and approved by the client before the work starts. Scope creep is the same kind of change absorbed without that step: the work gets done, nobody pays for it, and the client may not realise they asked for anything new. A scope change request is the document that turns one into the other.
Who should approve a change request on an agency project?
The person who holds the budget on the client side, not simply the person who asked. Requests often come from a day-to-day contact, but only someone who can approve spending can agree to a new price or a later launch. Name that person in your statement of work so everyone knows whose approval counts.
Does a change after approval cancel the original approval?
No, but the original approval only covers the brief as it was when the client approved it. Keep a copy of that version, file the change request next to it, and get the change approved on its own. Once the brief is updated, have the client approve the new version too, so the brief and the latest approval match again.