How to Collect Website Feedback from Clients (Without the WhatsApp Chaos)

You send the staging link. A day later, feedback arrives as three WhatsApp voice notes, a blurry phone photo of a laptop screen, and an email that says “the button on top looks weird.” Which button? Which page? Which device? Here is a simple process to get feedback you can actually act on.

Why client feedback goes wrong

Clients are not trying to be difficult. They are reviewing a website in between meetings, on whatever device is in their hand, and describing visual problems in words. Most feedback problems come from four gaps:

• No context. “The header looks off” could mean any page, any screen size or any browser.
• Too many channels. Notes arrive by WhatsApp, email, calls and spreadsheets, and nobody has the full list.
• No clear owner. Three people at the client send conflicting requests, and nobody decides.
• No status. Nobody knows which comments are fixed, which are waiting and which were rejected.

Fix those four gaps and revision rounds get shorter on their own.

1. Agree on the rules before the first review

Set expectations in the proposal or kickoff call, not after the first messy round. Agree on:

• How many review rounds are included (two or three is common) and what counts as a round.
• One approver on the client side who collects internal opinions and has the final say.
• A review window, for example “feedback within 3 working days of each staging link.”
• What feedback is for in each round: layout and content first, small polish last.

2. Choose one feedback channel

Chat apps are great for quick questions and terrible for tracking changes. Tell clients where change requests go, and gently move them there whenever they arrive somewhere else: “Thanks! Could you add this as a comment on the site so it doesn’t get lost?”

A shared spreadsheet is better than chat, but clients still have to describe where the problem is in words, and developers still have to guess.

3. Let clients comment on the website itself

The single biggest improvement is letting clients click the exact element they mean and leave a comment right there. A pinned comment carries its own context: the page, the element, and where it sits on screen. “Make this bolder” on the actual headline is clearer than a paragraph explaining which headline.

Whatever tool you use, check that it is easy for non-technical clients:

• No account or password for the client to create
• No browser extension to install
• Works on phones and tablets, not only desktop
• Comments stay attached to the right page and element

4. Ask better questions

Open questions like “any feedback?” invite vague answers. Guide each review with a short prompt:

• Is any information wrong or missing on this page?
• Is anything hard to read or find on your phone?
• Does the main button do what you expect when you click it?
• Is there anything you would not be comfortable showing your customers?

Ask clients to describe the problem, not the solution. “Visitors won’t notice the price” is more useful than “make it red.”

5. Capture technical details automatically

Developers waste the most time on bugs they cannot reproduce. Clients rarely know their browser version or screen size, and they should not have to. Collect the basics automatically with each comment:

• A screenshot of what the client saw
• Browser, operating system and screen size
• The page URL and the element that was clicked
• Any console errors from the page at that moment

With those details, “the button does nothing” becomes a bug your developer can fix in minutes instead of a week of back-and-forth.

6. Triage, reply and close the loop

Treat feedback like a small task board, not an inbox:

• Sort each comment into bug, design, copy or new feature. New features usually belong in a separate quote.
• Prioritise what blocks launch first.
• Reply on the comment so the client sees the answer where they asked.
• Mark it resolved and ask the client to confirm in the next round.

Clients trust the process more when they can see every request moving from open to done.

Quick checklist

FAQ