How to run a client website review that leads to clear decisions

A staging link is ready. You send it to the client with a friendly “Let us know what you think.” A few days later, the replies arrive: a screenshot in an email, a list of changes in a document, and a message saying the homepage needs more impact.

None of these is necessarily bad feedback. The problem is that nobody agreed what this review was supposed to decide.

A useful website review gives people a bounded job. It tells them what to inspect, how to report a problem, who will reconcile the responses, and what happens when the round ends. Here is a process you can adapt to your next project.

1. Give the round one clear purpose

Before inviting anyone, finish this sentence: “At the end of this review, we need a decision on…”

That might be the homepage's message and visual direction. It might be whether the site contains the approved copy. Or it might be whether the agreed customer journeys are ready for launch. These are different reviews, with different questions and different evidence.

Write down three things:

• In scope: the pages, journeys, or decisions you want reviewed.
• Already agreed: decisions that should only reopen if new evidence changes them.
• Not ready: incomplete pages and known issues that reviewers can safely skip.

For example: “Review the homepage, services page, and enquiry journey. Check copy accuracy, mobile readability, and whether a visitor can understand the offer. The logo and overall page structure are already approved. The blog is outside this round.”

This still leaves room for an important unexpected finding. It simply prevents every review from turning into a complete redesign.

2. Prepare the version people will review

Walk through the site before you hand it over. Check that the links in your invitation work, that the selected pages are accessible, and that any required access instructions are clear. Use fictional details when testing forms, and agree how test submissions will be handled.

Record a version or build identifier and the date. If you update the site during a review, tell reviewers what changed. Otherwise, two people can reach different conclusions because they saw different versions.

Include a short list of known issues. “The team photos are placeholders” is useful context; “There are a few things still to do” leaves reviewers guessing. Our website review checklist can help you prepare a consistent handover.

3. Choose the people and the decision owner

Invite people for a reason. The person responsible for the service should check its description. Someone who handles enquiries can assess whether the contact journey asks for the right information. A brand owner can review the language and presentation.

You also need one person on the client side who can reconcile conflicting requests. That person does not have to answer every comment. They do need authority to confirm the final direction.

Make ownership explicit: who reports findings, who responds, who implements changes, and who approves the result. A shared review becomes slow when every participant assumes another person will make the decision.

4. Send an invitation people can act on

The invitation should fit into one readable message. Give a deadline, a rough expectation of the work involved, and a single place for feedback. Choose a review window that works for the actual people involved; a deadline nobody can meet creates avoidable silence.

You can adapt this template:

Hi team,

The next website review is ready: [review link].

Please review [pages or journeys] by [date and time, including time zone]. This round is for [decision or review purpose].

Focus on [two or three specific questions]. [Known issues] are already logged, and [excluded work] is outside this round.

Leave each finding in [agreed feedback location], with the page, what you noticed, and what you expected instead. Please keep unrelated findings separate.

[Name] will reconcile client feedback. We will confirm the agreed changes and any remaining decisions after the deadline.

Please reply if you need more time or cannot access the site.

Avoid treating a missed deadline as approval unless that process has been explicitly agreed. Ask for a clear response, even if the response is “No changes from me.”

5. Ask for observable feedback

A useful comment connects a location, an observation, and a reason. A suggested fix can help, but it should not obscure the underlying problem.

Consider this illustrative example:

Vague: “The mobile page looks wrong.”

Actionable: “On the services page at a narrow phone width, the enquiry button overlaps the final line of the introduction. I expected to read the paragraph and tap the button separately. Screenshot attached.”

The second version gives the team somewhere to start. For a functional problem, add the steps taken, the expected result, and the actual result. For a preference, explain the goal behind it: “This wording sounds too formal for our customers” is more useful than “I don't like this.”

Share a few website feedback examples before the round starts. They give reviewers a model without turning the review into training.

6. Turn the responses into decisions

Once the review closes, combine duplicate findings and identify the comments that need clarification. Preserve the original context when grouping related requests.

Give each item a clear outcome: fix now, needs a decision, plan for later, or decline with a reason. Distinguish defects against an agreed requirement from requests that change the scope. Both can be valid; they have different implications for delivery.

When comments conflict, return to the page's purpose and the agreed criteria. Ask the decision owner to resolve the tradeoff. Do not quietly implement whichever suggestion arrived last.

7. Close the loop before calling it approved

Send a short summary of what changed, what remains open, and what needs another look. Ask the relevant reviewer to check the actual fix rather than relying on a status label.

Record approval against the reviewed version and agreed scope. Include any accepted limitations and their owners. Approval of the homepage copy should not accidentally become approval of every page and every launch requirement.

A visual feedback tool such as Sima can be part of this process. The essential work is still human: make the review specific, keep the discussion anchored to the work, and end with a decision everyone can understand.