A Website Change Request Template for Clearer Scope and Sign-Off

Website changes go wrong in a predictable way. Someone sends a short message such as “can you update the homepage?”, the person making the change fills in the blanks with their best guess, and the result is not what the requester pictured. Then comes a round of revisions that a clearer request could have avoided.

A good change request is not long. It answers four questions before any work starts: what is the goal, which page is affected, what is the evidence that a change is needed, and how will anyone know it worked. This article gives a template built around those four questions, with an example, and explains where it fits next to a website change log.

This is a practical working template, not a research finding. We have not measured how much rework it prevents, and we are not claiming a number. It is a way of making the request explicit so that misunderstandings show up before the work, not after.

Where a request fits in the sequence

A change request comes before the work. A change log, which we cover in our post on keeping a website change log after updates, is the record that comes after. Keeping the two apart helps. The request says what you want and why. The log says what was actually done and when.

If you are reporting something that is already broken, rather than asking for an improvement, our guide on how to report a website problem is the better starting point. This template is for planned changes.

The four-part change request

1. The goal

State what the change is supposed to achieve in one sentence, in terms a visitor or the business would recognize.

• Weak: “Update the services page.”
• Better: “Make it clear on the services page that we offer weekend appointments, so that people stop calling to ask.”

A goal tells the person doing the work what to optimize for when a detail is not specified. Without one, they can only follow instructions literally.

2. The page

Name the exact page or pages, using the address (URL) if you can, and say which part of the page. “The homepage” can mean the top banner, the menu, or the footer.

If the change affects more than one page, list each. If you are not sure how many pages are affected, say so in the request, and let whoever does the work report back what they find.

3. The evidence

Say what led you to ask for the change. Evidence can be small and still useful:

• A customer question that keeps recurring.
• A screenshot of something that looks wrong on a phone.
• A figure from a report you already look at, with the date range.
• A comment from a staff member who handles inquiries.

Evidence does two things. It helps the person doing the work understand the problem, and it gives you something to compare against afterwards. If you have no evidence beyond a preference, write that down honestly. A preference is a legitimate reason, but it is better recorded as one.

4. The acceptance test

Write down, before the change is made, how you will decide it is done. Make it something a person can check:

• “The weekend appointment line appears in the first paragraph on desktop and on a phone.”
• “The new form sends a test message to the address we listed, and we receive it.”
• “The old page address still opens and sends visitors to the new one.”

An acceptance test turns “does this look right?” into a short checklist. It also stops a request from growing quietly, because anything not on the list is a separate request.

A template you can copy

Request title:
Requested by / date:
Goal (one sentence):
Page(s) and section(s):
Evidence (what prompted this):
What should stay the same:
Acceptance test (how we will check it is done):
Deadline, if any, and why:
Who approves it:

Two lines in that template are worth a second look. What should stay the same protects things people forget to mention, such as the phone number in the header or the wording a lawyer approved. Who approves it avoids the situation where three people each assume someone else will sign off.

A short example

Request title: Add weekend hours to the services page
Goal: Make it clear that weekend appointments are available so fewer people call to ask.
Page(s) and section(s): Services page, the paragraph under the main heading.
Evidence: Front-desk staff say the question comes up several times a week. (Staff estimate, not measured.)
What should stay the same: Phone number and the rest of the page text.
Acceptance test: The weekend line is visible without scrolling on a phone and on a desktop screen; the page still loads normally.
Approved by: Office manager.

Notice that the example labels the evidence as an estimate. A request does not need hard numbers, but it should not make an estimate look like a measurement.

Common ways a request still goes wrong

• The goal is really a method. “Make the button red” is an instruction. Ask what the button is meant to do, and the right change may be different.
• The acceptance test is vague. “Looks good” is not a test. If you cannot write a check, you may not yet know what you want.
• Several changes are bundled together. Separate requests are easier to approve, test, and reverse.
• Nobody is named as the approver. The change waits, or ships without anyone having agreed to it.

Making the process light enough to use

A template that takes an hour to fill in will be skipped. Keep a request to a few minutes for a small change, and save the longer version for work that touches several pages or affects how people contact you. Keep requests somewhere that others can find them, so you can see what was asked, and what was decided, long after the conversation has been forgotten.

If you would like help setting up a request and approval process for your website, you can ask for a change-process review through our website design page, or contact us directly.