A client change-request template that actually helps your developer

A client change-request template only earns its keep if it produces tickets a developer can act on without a follow-up email. Most templates fail that test because they're written from the developer's side of the desk: they ask for browser versions, steps to reproduce, maybe a console screenshot. A non-technical client can't answer those questions — so they skip the form and email you "the page looks weird" anyway.

The fix is to ask only for things the client actually knows, in their own words, and structure it so the answers add up to a fixable ticket. Five questions do it.

The template

Copy this into your email footer, your intake form, or a shared doc your clients can find:

WEBSITE CHANGE REQUEST

1. WHAT needs to change?
   One sentence, plain words.
   Example: "The phone number at the bottom of the site is wrong."

2. WHERE is it?
   Paste the page's web address (the long text at the top of your
   browser), and say which part of the page — top, middle, bottom.
   A screenshot of the area helps a lot.

3. CURRENT — what does it say or do right now?
   Copy the exact text, or describe exactly what happens when you
   use it. "Exact" matters — it's how we find the right spot.

4. DESIRED — what should it say or do instead?
   The exact new wording if you have it, or describe the result
   you want in your own words.

5. SCOPE — just here, or everywhere?
   Should this change apply only on this page, or wherever it
   appears across the site?

Why these five fields

Each one exists to kill a specific reply-cycle:

• What forces one request per ticket. The "small tweaks" email with nine unrelated items in one paragraph is where estimates go to die.
• Where is the question you'd otherwise spend the first email round on. Asking for a pasted address — described as "the long text at the top of your browser," not "the URL" — is the difference between getting it and not.
• Current is the anchor. The exact existing text lets you search the codebase or CMS and land on the right element in seconds, and it protects you from fixing the wrong instance of a phrase that appears twice.
• Desired separates "I want it different" from what different means. When the client supplies exact replacement wording, the change becomes mechanical — no interpretation, no revision round.
• Scope is the sleeper. "This instance or everywhere?" is the ambiguity most likely to surface a week later as "that's not what I meant."

Current-versus-desired is the heart of it: a request that states both is a diff, and a diff is something you can quote, schedule, and ship.

The honest limits of a template

A template is a big upgrade over a blank email, but it has a ceiling. Clients fill it in from memory, not from the live page, so "where" still arrives as "the about page, I think." Nothing in a form can capture the context you actually debug with — browser, device, console errors, what they clicked before it broke. And compliance decays: the client in a hurry reverts to texting you.

That ceiling is why we built the capture side of SiteUpdate around the same five facts — what, where, current, desired, scope — except the client just points at the element on the live page and talks, while the software fills in the fields and the technical context automatically. Same ticket structure; nobody has to fill in a form to get it.

Start with the template — it costs nothing and improves your intake this week. When you find yourself re-typing its answers from screenshots, that's the signal to automate it.