How to collect client feedback on a website

The fastest way to collect client feedback on a live website is to give the client a single link that lets them click directly on the page and leave a comment, rather than asking them to describe what they see in an email. This avoids the two most common failure modes: vague descriptions (“the button on the homepage looks wrong”) and friction (clients who won't create an account just to leave one comment). A link-based review tool that captures the exact element alongside the comment removes both problems at once, and it works whether the client is reviewing a marketing site, a staging build, or a client portal.

Why email and screenshots cost you days

A client emailing “the pricing page looks off on mobile” with an attached screenshot forces the developer to reproduce the exact browser, viewport, and page state before they can even start fixing it. Every round trip to ask “which button?” or “what error did you see?” adds a day to the fix.

The cost compounds in a way that is easy to miss. Feedback arrives across email, a messaging app and a call, so there is no single list of what is outstanding. Nobody can tell whether an item was fixed, rejected or forgotten. And because each item takes a follow-up question to become actionable, the client experiences the process as slow and starts batching feedback into long, unstructured messages — which makes the next round worse. A review cycle that should take two days takes two weeks, and neither side can point at the reason.

What every piece of client feedback actually needs

Before a developer can act on a comment without asking a follow-up question, four things have to be present:

1. Which element.Not “the header” — the specific node, so there is no ambiguity between three things that could all be called the header.
2. What the page looked like. A screenshot at the moment of the comment, because the page may look different by the time anyone reads it.
3. What the browser was doing.Console errors and failed or slow network requests, which is the difference between “the form is broken” and a fix.
4. What the client expected instead. The one thing that cannot be captured automatically, and therefore the only thing worth asking the client to write.

That last point is the whole design principle. A client who is asked to supply all four will supply none of them. A client who is asked for one, while the tool captures the other three, will give you consistently useful feedback without being trained.

Set up a client review in five steps

1. Create a dock for the site. A dock is one website plus one review workspace. Point it at the URL the client will actually be looking at — the staging build if they are reviewing pre-launch, the live site if they are reporting problems on production.
2. Send the client the review link. Every dock generates one shareable link. The client does not create an account, set a password, or get added to your team. They open the link, install the browser extension once, and type their name.
3. Let the client pin feedback directly on the page. The client clicks the element they have feedback on and types a comment. The exact element, its position, a screenshot, the page URL, and the browser and viewport are all recorded automatically.
4. Triage the pins into a working order. Each pin moves through open, in review, changes requested, approved and resolved. Assign the ones that are real work and close the ones that are questions, so the list reflects what is actually left to do.
5. Push the real work into your tracker. Connect Slack, Linear, GitHub, Jira, Trello or ClickUp so pins that need a developer become tickets where your team already works, instead of living in a second system nobody checks.

How to brief the client so they actually use it

The tool is the easy half. Most review cycles fail on the brief, and the failure is almost always one of these:

• Give a deadline and a scope.“Have a look and let me know” produces feedback for three weeks. “Please leave all your comments on the checkout flow by Thursday” produces feedback by Thursday.
• Tell them one comment per issue. A single pin containing five unrelated problems cannot be triaged, assigned or closed as a unit.
• Say who else is reviewing. If three stakeholders review independently, they will contradict each other, and you will be the one discovering it.
• Show them once, live. Two minutes on a call, pinning one comment together, converts far better than a written guide the client will not read.

Expect to redirect emailed feedback back into the tool for the first round or two. The habit holds after that, provided the tool genuinely takes less effort than the email did.

Triaging what comes back

Not all feedback is work. A useful first pass sorts every pin into one of three piles: a real change, a question that needs an answer rather than a commit, or a request that is out of scope and needs a conversation about budget. Doing this pass before anything reaches a developer is what stops a review round from turning into unplanned scope. Once sorted, only the first pile should become tickets — and it should become tickets in the tracker your team already uses, not in a second system that only exists during review.

Common mistakes

• Asking the client to install something complicated.Every extra step measurably reduces the amount of feedback you get, and the feedback you lose is disproportionately from the least technical stakeholder — often the decision-maker.
• Reviewing on the wrong URL. Feedback pinned to a stale preview is feedback about a site that no longer exists.
• Leaving pins open after they are fixed. If the list stops reflecting reality, the client stops trusting it and reverts to email.
• Collecting feedback with no layer or build boundary.Comments on last week's build and this week's build in one undifferentiated list is the fastest way to re-fix something you already fixed.

Doing this with Layerdock

Create a dock for the site, share the generated review link with your client, and every pin they leave arrives with the element, screenshot, and console and network context already attached — no account, no extension setup beyond the one-time install. Pins stay anchored to their element through your next redeploy, and each dock holds separate layers so feedback on this build and last build never mix. See how Layerdock compares to other website feedback tools, or go to pricing.

Common questions