A client website review needs more than a link and a request for thoughts. The client knows the business facts, while the delivery team knows the design and implementation. This worksheet separates those responsibilities so the review can produce accurate content, clear decisions, and an approval tied to a specific version.
Fill in a review brief before sending the link
Write down the release, review environment, page list, deadline with time zone, and client decision owner. State the decisions you need now: approving service descriptions is different from choosing an entirely new navigation structure. If several stakeholders will comment, name the person authorized to consolidate contradictory instructions.
Tell the client what is ready, what is still placeholder content, and what has already been approved. A staging payment flow or test inbox should be identified clearly so the reviewer does not mistake it for a production failure. Supply safe test details through the appropriate channel; keep passwords and private customer information out of the worksheet.
Review brief Release: [version and date] Review link: [staging URL] Pages: [exact list] We need decisions on: [copy accuracy / design direction / visitor task] Not part of this round: [named areas] Please finish by: [date, time, time zone] Client decision owner: [name] Send feedback through: [one agreed place]
Ask the client to verify facts and replacement copy
Clients are well placed to check names, offerings, qualifications, locations, prices, service conditions, and contact details. Ask for the exact replacement when wording is incorrect. “Fix our description” requires another conversation; a corrected sentence and the person responsible for its accuracy can move directly to implementation.
- Confirm that service descriptions match what the business actually delivers, including eligibility and limitations.
- Check names, contact destinations, opening hours, addresses, and any dates that change.
- Review price wording, billing intervals, exclusions, and the next step after an inquiry.
- Identify content that needs approval from a named specialist rather than treating silence as permission.
- Check whether images and captions represent the right offering and have approval for use.
Keep factual corrections separate from style preferences. If two reviewers provide different prices, ask the decision owner to supply one authoritative value. Do not combine the two suggestions or assume the newest comment is the approved answer.
| Field | Completed example |
|---|---|
| Page / element | Commercial services page / opening paragraph |
| Current wording | “Every installation is completed in one day.” |
| Correct replacement | “We confirm the installation schedule after the site assessment.” |
| Reason | The schedule depends on the property and requested work. |
| Approval | Operations manager to confirm before publishing. |
Use visitor tasks instead of asking for an overall score
Ask the client to act like someone with a concrete need: find the appropriate service, understand what it includes, and contact the business. Have them write what they expected and what made the task difficult. An overall rating such as eight out of ten cannot tell the team which detail to change.
Include one task for each important page family. For a small service site, that could be selecting an offering from a listing, reading a detail page, and submitting an inquiry with synthetic data. This worksheet records the client’s understanding and decisions; technical acceptance testing should still cover delivery and failure conditions.
Ask reviewers to inspect the site on the devices they normally use. Record the actual browser and viewport when something looks wrong. Browser simulation can help a delivery team inspect layouts, but it does not reproduce every aspect of a physical device.
Separate a design observation from an approved instruction
Give the client three fields: what they noticed, why it matters for the visitor, and the outcome they want. An optional solution can follow. This lets the designer assess the problem without treating every proposed font, color, or layout change as a final requirement.
Page / element: [specific location] Observation: [what is visible or unclear] Consequence: [effect on the visitor’s task] Desired outcome: [what should become clearer or easier] Suggestion, if any: [a possible solution] Requirement or preference: [identify which] Approval needed from: [decision owner]
For accessibility questions, include a concrete concern such as an unreadable label or an unreachable control. W3C’s Easy Checks can support an initial review, but passing those checks is not a complete accessibility evaluation. Route specialist requirements to someone who can evaluate them properly.
Finish with a decision log and scoped approval
Record accepted changes, questions, and deferred requests with the client approver and date. Each accepted outcome needs an owner and a verification point. Preserve the reason when a suggestion is declined; otherwise it may reappear in the next review because nobody can find the original decision.
An approval should identify the reviewed release and pages, unresolved issues, and untested areas. Avoid a blanket “all approved” statement when the client only checked desktop copy. This is a practical project record; it does not replace your contract or imply agreement from someone who has not responded.
In Annot8, public review links let guest reviewers leave page-specific feedback without consuming a paid team seat. The Free plan includes three distinct guest reviewers, and paid plans make them unlimited. Use the worksheet to explain the review scope, then link each decision to its original comment so the wording and context stay together.
