Guide
How to collect client feedback on a website
By Piotr, founder of Voicedot
On this page
Before sharing the site, agree what needs review, where comments belong and who decides. Keep each comment with its page and the answers that follow.
Give the review a clear purpose
“Let me know what you think” leaves the task up to the client. You may get opinions on colors when you need to check the package description.
Name the goal, pages and deadline. Say what is ready and what is unfinished. Agree who will settle conflicting requests.
For a services site, focus on the offer, pricing and contact flow. Every margin, image and sentence does not need review at once.
Start small. Make the feedback useful.
1. Give the reviewer a place to begin
Send the exact URL and a short task. Ask the client to act as a customer: find a service, check what is included and choose the next step.
Choose two or three review questions that fit the task. A long questionnaire can make the review feel like a separate project.
2. Ask for a place, an observation and an expectation
Ask where they were, what they noticed and what they expected. They do not need to design the solution.
On-page feedback carries the location with the comment. For email or a shared document, ask for a URL and a screenshot showing the element.
3. Clarify the missing decision
Ask the smallest question that makes the next step clear. Understand the request before writing implementation instructions.
4. Sort the work before starting it
Separate bugs, questions, preferences and new scope. Each may need a different person or decision.
5. Close the loop with the reviewer
Show what changed, what is open and what needs a decision. Ask the client to check the affected view; revisit the whole site only when needed.
One question makes the change clear
Client — pricing section: “Can you make this clearer?”
Agency: “Which part is unclear: what the package includes, how long it takes, or the final price?”
Client: “What it includes. The description sounds as if copywriting is included for every page, but it only covers the homepage.”
Agreed change: State that homepage copywriting is included. Make the additional-page option clear in the same section.
The first comment gave you a start. One question turned it into a decision the team could act on.
Choose the next step
Choose the next step
A control does not do what was agreed
- Useful next step
- Reproduce the issue and identify the intended behavior
- What not to assume
- That the reviewer has found the technical cause
The description leaves something unclear
- Useful next step
- Clarify the offer, then revise the relevant words
- What not to assume
- That changing a button color solves the confusion
Two stakeholders want different things
- Useful next step
- Ask the decision owner to resolve the conflict
- What not to assume
- That both requests can be implemented together
A new capability is requested
- Useful next step
- Discuss scope and priority before implementation
- What not to assume
- That submitting a comment approves extra work
| What the comment reveals | Useful next step | What not to assume |
|---|---|---|
| A control does not do what was agreed | Reproduce the issue and identify the intended behavior | That the reviewer has found the technical cause |
| The description leaves something unclear | Clarify the offer, then revise the relevant words | That changing a button color solves the confusion |
| Two stakeholders want different things | Ask the decision owner to resolve the conflict | That both requests can be implemented together |
| A new capability is requested | Discuss scope and priority before implementation | That submitting a comment approves extra work |
A comment marked resolved is a workflow state. Formal sign-off for a project is a separate agreement and should not be inferred from that state alone.
Where Voicedot fits
Reviewers point and type, or speak and check the transcript on plans with voice. Your team gets the text and context, with room to discuss the details.
Work in the dashboard, export Markdown or connect your coding agent. Keep the explanation with the work while you decide what to change.
A review invitation you can adapt
Hi [name],
The next version of [website] is ready to review:
[review URL]
For this round, please focus on:
- whether the service and what it includes are clear;
- anything that does not match how your business works;
- any point where the next step is unclear.
Please leave each comment next to the relevant part of the page.
Explain what you expected and what needs attention. You do not need
to write a technical solution.
[Items not ready yet] are outside this round.
Please send your comments by [date]. [Decision owner] will consolidate
any conflicting requests before we start the changes.
Thank you,
[name]Use the review checklist to check the task, link and handoff before sending the invitation.
When a simpler method is enough
For a few clear changes from one person, an email with a URL and screenshot may be enough. A call may help when the decision is complex or people disagree.
Use a process people can follow. A small review does not need a bigger tool just to look organized.
Common questions
Should the client suggest the exact solution?
They can, but they do not have to. Start with the problem and expected outcome; your team can work out the implementation.
What should we do with comments from several people?
Keep the author with each comment. Ask the agreed decision owner to settle conflicts, so the developer knows whose decision to follow.
Can a coding agent take over the review?
An agent can organize feedback and help prepare or implement an agreed change. The customer’s intent, project scope and permission to act still need to be clear. See the brief-to-review workflow.