Set a clear purpose for final review
Final review is the last check against the agreed project brief and acceptance criteria. It is a chance to find broken links, missing files, incorrect copy or work that does not meet an approved requirement. It is not automatically a new planning phase, although worthwhile ideas often surface when reviewers see the finished work together.
Before sharing a website, presentation, video or design package, tell reviewers what they are checking, where to leave comments and when feedback is due. Include a link to the current brief or approved deliverables. This gives everyone the same reference point and makes it easier to distinguish a correction from an added request. If the original agreement is informal, write down the understood deliverables before the review begins.
Capture each request before deciding what to do
A late request can arrive in a meeting, a message thread or a comment on a file. Put it in one review log rather than trying to resolve it in the moment. Record the requested change, the person who raised it, the location in the work and the reason it matters. For example, “Replace the outdated contact email on the final slide” is more actionable than “Fix the ending.”
Ask for clarification when a comment describes a reaction rather than an action. “The page feels busy” might mean the hierarchy is unclear, an image is distracting or the reviewer prefers a different style. A brief question about the intended outcome can prevent several rounds of revisions. Acknowledge the comment without promising a solution until its effect on the work is understood.
Sort corrections from additions
Compare each request with the brief and the latest approved decisions. A correction brings the work into line with what was already agreed: fixing a misspelled name, restoring a specified feature or supplying a missing export. An addition introduces something new, such as another page, a second video format that was not planned or a fresh round of visual exploration. Some requests fall between those categories. Note the uncertainty and discuss it rather than forcing a quick label.
Then assess impact, not just effort. A small-looking change can affect layout, accessibility, testing or other deliverables. A new button label may need checking across screens; a revised illustration may require updated exports and documentation. For each request, note whether it affects quality or usability, what needs to change, who must approve it and whether it threatens the delivery date. This is enough information to make a decision without turning final review into a lengthy replanning exercise.
Offer a decision, not an open-ended revision cycle
Group the requests into three practical paths: fix before delivery, schedule as a separate follow-up or decline with a reason. Issues that prevent the agreed work from functioning or being accurately presented usually belong in the first group. Useful enhancements that were not part of the brief may be better suited to a later phase. If a request conflicts with an approved decision, explain the conflict and ask the relevant decision-maker to choose a direction.
When a late addition changes the workload, state the trade-off plainly. A freelancer might say that adding a new page requires a revised estimate or a later handoff. A student team might agree to include the idea in its presentation as a proposed next step rather than trying to build it overnight. A small team might swap a lower-priority task out of the current release. Record the agreed choice, owner and deadline in the same place as the request so that nobody has to reconstruct the decision from messages.
Close the loop and protect the handoff
After changes are made, check the affected work again. Confirm that the fix appears in the final version, that connected files or screens still work and that reviewers know which version they are approving. A short summary can list completed corrections, deferred ideas and any requests that were not adopted. Ask for explicit approval from the person responsible for sign-off rather than treating silence across a long comment thread as acceptance.
Keep the review log with the final files and delivery notes. It provides context if someone asks about a decision later and helps define the starting point for future work. For a portfolio case study, the useful story is not that every late request was accepted. It is how the project team weighed feedback against the brief, made clear decisions and delivered a coherent result.
