← All articles

AI app guides

Build a client approval portal that approves the right version

Tie feedback and approval to a specific deliverable so later revisions do not rewrite the meaning of an earlier decision.

Zocri · 2 min read · Sources checked

Make the deliverable identifiable

HTTP's standard describes conditional requests that can prevent one user's change from accidentally overwriting another user's concurrent work. For a client approval portal, the business requirement is broader: every comment and decision should refer to the version the client actually reviewed. A file called final can change repeatedly, so a filename alone is not a reliable approval reference.

Give each submitted version a clear label, date and short description of changes. State what the client is being asked to approve, such as the homepage copy or a particular design. Avoid a single approve button that leaves the scope of the decision unclear.

Keep feedback attached to context

Allow comments on the relevant deliverable or section, with enough context to understand them later. A request to move the button is ambiguous once the layout changes. Preserve the reviewed version alongside the comment so the team can see what the client meant.

Separate discussion from an approval decision. A positive comment may not mean the client has approved every part. Define explicit actions such as request changes or approve this version, and identify who is authorized to make that decision on the client's behalf.

Handle a new revision honestly

When the team uploads a revision, decide whether earlier approval remains relevant or a new review is required. Show the current state plainly. Do not display approved on a new version merely because a previous version was approved, unless the business has a clearly defined exception.

Consider two people acting at once. A client may approve while a team member submits a newer revision. Ask the implementation to detect that mismatch and prompt a clear decision rather than silently attaching approval to the latest file. Test the sequence using separate accounts and distinguishable versions.

Close the review with a record

The final view should show the accepted version, decision maker, decision time and any agreed conditions. Keep the underlying deliverable accessible to the appropriate people. If an approval is later withdrawn or superseded, record the new action without rewriting the earlier decision as though it never happened.

Pilot with one deliverable that receives comments, a revision and final approval. Have a teammate reconstruct the sequence without reading the original chat. A useful approval portal lets someone explain exactly what was reviewed and accepted, which is more valuable than a dashboard full of reassuring green labels.

Put it into practice.

Open Zocri →