Name the reviewed version
Use a stable filename, version number or clearly identified link. A link whose contents are later overwritten does not by itself explain what was originally reviewed. Keep the relevant version available according to your project process.
State what you want confirmed. “Please confirm the contact details in version three” is narrower than approval of an entire website. If only certain parts were reviewed, the internal state should not simply say everything is approved.
Record reservations separately
A reply can contain agreement and outstanding points together. “The text is fine; images to follow” does not approve the images. Split the message into the confirmed part and remaining decision. Assign an owner and next step to the open point.
Ask a specific question when wording is unclear. Instead of repeating the project history, identify the uncertainty: does approval include the mobile view or only the attached desktop image? Record the answer alongside the version reviewed.
Identify changes after confirmation
If anything changes after approval, give the new version its own identifier. Note whether the change corrects a typo or alters content and behavior. Follow the agreed process to decide whether another review is needed.
Keep the response where project owners can find it again. A reference to the message may be enough if access remains available. Avoid copying unnecessary personal information into additional lists.
Before final handover, compare the delivery with the confirmed components. A well-recorded approval achieves little if an older file is subsequently sent by mistake. This final comparison connects the decision to the result actually delivered.
