Screenshot approval often fails in the handoff, not in the image. A message such as “Looks good?” gives the client no stable scope. They may approve the color, assume they approved mobile behavior, and later notice that the copy also changed. A reliable workflow turns the screenshot into a specific decision record.
Define what “approved” means for this review
Approval should attach to a named version and state. Before preparing the images, write a scope statement that a client can accept without knowing your development process.
Decision requested: Approve the revised desktop hero and pricing-card styling shown in version 3 for publication.
Included: English landing page at 1440-pixel viewport, signed-out state.
Excluded: mobile layout, checkout flow, footer copy, and analytics behavior.
Choose the approver before sending the report. Collecting reactions from many stakeholders is useful, but the final record needs one responsible client owner or an agreed approval group.
Prepare a review that respects the client’s time
- Stabilize the state. Match the route, viewport, data, scroll, fonts, and transient UI across captures.
- Remove environmental noise. Retake images affected by animation, consent banners, late assets, or different crops.
- Classify the findings internally. Do not ask a client to sort expected edits from known capture noise.
- Write the decision request. State whether you need approval, a choice between options, or confirmation of one detail.
- Set a response point. Give a date or release dependency without inventing urgency.
Use the before-and-after report guideto assemble the scope, source images, diff, and findings. Keep internal implementation notes in the ticket if they do not help the client decide.
Present the evidence in decision order
A client should encounter the requested decision before the technical detail. Use this sequence:
- one-sentence decision request;
- included and excluded scope;
- before and after images;
- two to five numbered findings;
- your recommendation;
- response choices.
The visual diff belongs after the source images. It helps locate changed pixels, but clients generally make decisions from the rendered design. Label any environmental region that remains visible. If the report needs a long verbal defense before it can be understood, the capture or scope is probably not ready.
Separate defects from preferences
Mark a deviation from an already accepted requirement as a correction. Mark a new visual preference as a change request. This distinction keeps approval fair and helps both parties understand whether the requested work belongs inside the current scope.
Keep one source of truth
Send the conversation through email, chat, or a project system, but link back to one versioned report. When the image or findings change, issue a new version and leave the earlier decision intact. Replacing a screenshot under an old approval breaks the evidence chain.
Record the decision with its conditions
The final record should contain the approver, date, report version, decision, and conditions. A concise entry is enough:
Version 3 desktop hero and pricing card approved by Morgan Lee on July 12, 2026. Approval includes findings 01 and 02 as shown. Mobile and checkout remain outside this review. Footer spacing will be reviewed in version 4.
Preserve the approved report with the project record. If you export a SiteReceipt image or report, give the file a versioned name and avoid overwriting it after the decision.
Worked example: agency homepage revision
An agency has changed a manufacturer’s homepage headline, CTA color, and testimonial order. Its internal review also finds a tablet breakpoint regression. The client only needs to approve desktop copy and styling, so the agency fixes the tablet issue before sending the report and lists tablet as separately tested, not part of the visual approval request.
| Finding | Client-facing explanation | Requested decision |
|---|---|---|
| 01 | Headline uses the approved product name and wraps to two lines | Approve copy and line break |
| 02 | Primary CTA changes from gray to brand blue | Approve color treatment |
| 03 | Testimonial order follows the client’s supplied priority | Confirm sequence |
The client approves findings 01 and 02 but asks to swap the second and third testimonials. The agency records partial approval, updates only finding 03, and sends version 2 with the unchanged findings carried forward. No one needs to re-approve the CTA color.
Approval does not replace broader acceptance testing
A visual report covers the states shown. It does not demonstrate that forms submit, links resolve, analytics fire, accessibility requirements are met, or every responsive size works. Keep functional acceptance criteria and visual approval separate in the project record.
Contracts and industries differ. This workflow is operational guidance, not legal advice or an electronic-signature system. If a contract requires a particular approval method, authority level, or retention period, use that process. Review the SiteReceipt terms for the tool’s current conditions.
Frequently asked questions
Is an email reply enough for approval?
It can be a useful record when the message identifies the report version and scope. Follow any approval or signature requirements in your contract. Copy the decision into the project’s source of truth so it is not separated from the reviewed evidence.
What if the client comments on something outside scope?
Acknowledge the comment, classify it as a new request or separate defect, and state whether it affects the current decision. Do not expand the approval scope silently.
Should I send the raw diff to every client?
Include it when it helps locate subtle changes or supports the review record. For a visually obvious redesign, clear before and after views with numbered notes may be easier. Always retain the source images.
How should I handle a new revision after approval?
Create a new version, compare it with the last approved state, and ask for approval only on the changed findings. Preserve the earlier report and decision unchanged.