“Looks good” is not always approval. It may mean the direction is promising, one reviewer has no changes, or the client has not noticed that someone else still needs to respond.
A reliable client approval process makes four things explicit: the item, the version, the decision-maker, and the decision.
Define approval before review begins
Write the approval rule into the review instructions before comments begin. A quiet thread can mean the review is complete, delayed, or simply unattended.
For each review round, name:
- The exact file or work item under review
- The current version or date
- The client contact authorized to make the decision
- The feedback deadline
- The allowed outcomes
- What happens after each outcome
A useful decision set is simple:
- Approved: the named reviewer accepts the current version for the stated next step.
- Revisions requested: the reviewer identifies changes against the current version.
- Decision deferred: the reviewer names the missing information or stakeholder and a new decision date.
Avoid “approved with changes.” It combines two different states and leaves the production team guessing whether work can move forward.
Lock the review object
Approval needs a stable object. If the team changes the file while the client is reviewing it, the final comment may refer to a state that no longer exists.
Use one file record with visible versions. Tell reviewers which version is current, and add the next version only after the round closes.
For visual work, keep comments on the image or PDF page where the change belongs. Sydnee Files can keep the current version and numbered feedback pins together when those controls and access settings are enabled.
Pins locate feedback. The named decision closes the review.
Choose one decision-maker
Several people can review. One person should resolve the final decision.
Ask the client to name that person during onboarding. If legal, brand, or executive review is required, record how those stakeholders feed into the named approver.
Without that rule, the team may receive three valid but incompatible responses. The problem is not that the client has several opinions. The problem is that the workflow never defined how those opinions become one instruction.
Record the decision in a complete sentence
The approval statement should be understandable without reconstructing the conversation around it.
Use language such as:
I approve homepage design version 3, dated September 10, for development. This approval covers the desktop and mobile layouts shown in the file.
For revisions:
I am requesting revisions to homepage design version 3. The required changes are recorded as pins 4–7, and the next review will cover version 4.
Adapt the wording to your agreement and risk. This article does not replace contractual or legal advice. Your contract should define the commercial effect of approval, revision limits, and scope changes.
Separate feedback from scope changes
Feedback evaluates the work against the agreed brief. A scope change asks for a different outcome.
When a review comment changes the audience, deliverable, integration, or approved direction, stop the revision round and route the request through the process that owns scope.
That may require a new estimate, task, decision, or agreement. Record the scope change where the production team can see its impact before continuing.
Give every decision a next action
Approval is a transition, not the end of the record.
| Decision | Next action |
|---|---|
| Approved | Move the named version into the next production or delivery stage |
| Revisions requested | Assign the changes, owner, and next review date |
| Deferred | Record the missing input, owner, and revised decision date |
| Scope change | Pause the review and route the change through the agreed commercial process |
Use a Task when someone needs to act. Keep the approval statement with the reviewed file or in the decision record your agreement requires.
Task comments and activity can coordinate the next action, but a completed Task does not automatically prove client approval.
Publish only after approval is settled
In Sydnee, a Deliverable is a view-only client presentation created from a Files folder. It is the final handoff, not the approval step.
Finish review first. Then place the approved work in the delivery folder, confirm its contents, and publish it as a Deliverable. Sydnee can record which portal contacts opened the Deliverable, but an open event is not acceptance or sign-off.
This boundary matters: feedback belongs with the current work, the explicit decision closes review, and the Deliverable presents the finished package.
Audit one review round
Before the next client review, check:
- Is one version clearly under review?
- Can every reviewer access the file and comment in the agreed place?
- Is one client contact responsible for the final decision?
- Are the allowed outcomes written down?
- Will revisions become owned work instead of remaining comments?
- Does the final package wait until the decision is explicit?
Use the guide to keep client feedback with the right file version for the review mechanics, then explore Sydnee File Sharing for versions, comments, and final Deliverables.
