Where Should Website Change Requests Be Written Down?

One numbered list per round, in one message, in the same place every time — that single habit is the difference between two revision rounds and six. Scattered requests across days is the main reason changes get missed, and both sides then blame the other.

The moment it happens

Where should website change requests be written down becomes a live question after the second round, when you notice three of your changes weren’t made. You sent them. You’re certain. They’re in the chat somewhere between a voice note and a photograph.

The developer isn’t ignoring you. Your changes arrived as eleven messages over three days, mixed in with a question about hosting and a forwarded image. Some got actioned, some got scrolled past.

Why scattered feedback fails

Messages get buried. A request sent at 10pm between two other topics is functionally invisible by the next morning.

There’s no checklist to work from. A developer with a numbered list can tick items off. A developer with a conversation has to reconstruct one, and reconstruction loses items.

Nobody can tell when a round is finished. If changes keep arriving, the round never closes — which is how two rounds become six and how both sides end up resentful.

Voice notes are the worst offender. Convenient to send, painful to work from. A five-minute voice note containing seven changes has to be listened to repeatedly, and items get missed every time.

The format that works

One message. Numbered. Per round.

Round 1 changes: 1. Home page — phone number isn’t visible until I scroll on my phone. Move it up. 2. Home page — change “Best in Delhi” to “Serving Delhi NCR since 2011”. 3. Services — add “AMC contracts” as a fourth item. 4. Services — price for the second item should be ₹4,500, not ₹4,000. 5. Contact — the WhatsApp button opens without the country code. Should be +91. 6. Gallery — replace the third photograph with the one I’m sending after this. That’s everything for this round.

Five things make this work. Each item names the page. Each says what’s wrong and what it should be instead. It’s numbered, so nothing gets missed and either side can refer to “item 4”. It ends explicitly, which closes the round. And it’s in one message, so it’s findable.

The last line matters more than it looks. “That’s everything for this round” is what allows a developer to treat it as a batch and give you a date.

Where to put it

WhatsApp is fine, and it’s what most small projects use. The medium isn’t the problem; the scattering is. Send one message per round rather than a stream, and pin it if the app allows.

Email is better for larger projects, because threads stay together and are searchable months later.

A shared document or sheet is best for anything ongoing — a column for the item, a column for status. Useful for stores and for maintenance relationships, overkill for a five-page build.

Screenshots with arrows are excellent for visual issues. One annotated screenshot replaces three paragraphs of description. Send it inside the numbered message, referenced by item number.

Method Good for Weakness
One WhatsApp message, numbered Most small projects Gets buried if you send several
Email thread Bigger builds, records Slower replies from small vendors
Shared sheet Ongoing work, stores Overkill for a small build
Annotated screenshots Visual and layout issues Needs to sit inside a numbered list
Voice notes Nothing, for change requests Items get missed reliably
Phone calls Discussing an approach No record; changes get forgotten

What to do about phone calls

Calls are useful for discussing why something should change. They’re unreliable for recording what will change.

The fix: after any call, send a summary. “Confirming from our call: moving the number up, changing the tagline, adding AMC to services.” Three lines. Their acknowledgement is the record.

The rule that halves your rounds

Wait until you have all your changes before sending any.

Reviewing the site once and sending seven items produces one round. Reviewing it seven times and sending one item each produces seven rounds — and if your agreement includes two or three rounds, you’ve used them up on the first day.

So: look at the whole site properly, on your own phone, write everything down, send it as one message. Then wait for the round to be completed before looking again.

This also gets you treated as a priority client. A vendor with five projects attends first to the one that sends clean, actionable lists.

What to do this week

  1. Agree with your developer where change lists will go, once.
  2. Review the whole site on your own phone before sending anything.
  3. Send one numbered message per round, ending with “that’s everything for this round”.
  4. Name the page and the intended replacement text for each item.
  5. Summarise any phone call in three lines afterwards.

If you want it done the certain way

We ask for one numbered list per round and give you a completion date for that round — so nothing gets missed and the design phase has an end. Revision rounds agreed in writing before we start. WhatsApp us; we reply in about five minutes between 9am and 7pm.

Related reading

FAQ

How should I send website change requests to my developer?
As one numbered message per round, naming the page, what’s wrong and what it should say instead, ending with “that’s everything for this round”. Scattered messages across days are the main reason changes get missed.

Are voice notes a bad way to request website changes?
For change requests, yes. A voice note containing several changes has to be replayed repeatedly and items get missed reliably. Use it to explain an approach, then send the list in writing.

Why do my developer’s revisions keep missing items?
Almost always because the requests arrived as separate messages mixed with other topics, so there was no checklist to work from. One numbered list per round fixes it and typically halves the number of rounds needed.

What do you think?

What to read next