Online proofing is the client review stage between the studio's internal work and the current decision.
A useful proofing process identifies:
- what the client is reviewing;
- which version is current;
- which product or asset a comment belongs to;
- whether the client selected an option, requested a change, or approved;
- what happens after the decision.
Proofing can happen in a specialist tool, gallery, or project-specific client area.
The process matters more than the label.
Define the review task before sharing files
Before sending a proof, decide what the client is expected to do.
Possible tasks include:
- Choose one capture for retouching
- Review the first retouched version
- Confirm a crop
- Request a revision
- Request a reshoot
- Approve a named set
- Select individual photos to purchase
- Confirm a brief or shot-list change
Do not send a gallery with:
Let me know what you think.
when the studio needs a specific decision.
Use a direct instruction.
Example:
Review the current retouched proof set. Leave asset-specific comments where a change is needed, then select Request changes or Approve for this version.
Prepare the proof for review
A proof should identify:
- Job
- Product or SKU
- View or asset
- Version
- Review purpose
- Preview limitation
- Current requested action
- Feedback due date when agreed
A protected preview can be appropriate when originals are not yet released.
State that it is a review file.
Do not make the client infer whether it is the final deliverable.
Use one review source of truth
The studio can still communicate by email or call.
Choose one place as the current review record.
When a client sends feedback outside it:
- identify the relevant proof and version;
- add or summarize the decision in the current record when permitted;
- identify who made the decision;
- preserve separate evidence when the studio records a decision on the client's behalf.
Do not leave the only final decision in a private conversation that the production team cannot access.
Keep comments attached to the right work
An asset-specific comment should identify:
- Proof or asset
- Version
- Comment author
- Comment text
- Date
- Current resolution
A useful comment states the expected change.
Example:
Keep the current crop. Reduce the highlight on the upper-right edge to match Reference B.
A less useful comment is:
This feels off.
The second comment can still be valid.
It needs a follow-up question before the studio treats it as a production instruction.
Separate four client actions
Comment
A question, observation, preference, or instruction.
Selection
A choice of an image or option for the next stage or purchase.
Request changes
A decision that the current proof or set is not approved.
Approve
A decision that the named proof, version, or set can move to the next agreed stage.
Do not turn a comment into approval.
Do not turn a favorite into approval unless the process explicitly defines it that way.
Request changes without hiding the type of work
When the client requests changes, the studio can distinguish:
- Revision
- Reshoot
- Client decision needed
- New requirement
Use the current product labels and the studio's agreement.
A revision or reshoot label records the operational path.
It does not decide who pays.
The client agreement defines the commercial and legal treatment.
Use versions deliberately
Create a new version when the image or set changes materially.
Record:
- Version name or number
- Date
- What changed
- Who requested it
- Which earlier version it replaces
- Current review state
Do not keep the same visible version after a material change.
A comment on version 1 should not silently become a comment on version 2.
Review a set without losing asset detail
A product job can need both levels.
Asset level
Use for:
- image-specific comment;
- crop;
- product detail;
- retouching issue;
- variant mapping;
- revision or reshoot intent.
Set level
Use for:
- overall direction;
- approval of the complete proof set;
- final unresolved exception;
- consolidated client note.
The set-level decision should not erase unresolved asset-level changes.
Project billing review
In a project-billing job, the current process can ask the client to:
- review each required proof;
- leave asset-specific comments;
- mark assets approved or needing changes under the current UI;
- identify revision or reshoot when applicable;
- submit the feedback set;
- reach the derived job-level state.
The latest working tree controls the exact labels.
Do not publish:
- Request changes
- Approve
- Submit feedback
unless the visible product uses those labels.
Cursor must align this article, Client Area Help, and product UI.
Per-photo selection
In a per-photo job, the client:
- reviews eligible photos;
- selects individual photos;
- creates or opens a selection invoice;
- pays;
- receives purchased originals under the current entitlement.
There is no equivalent project-level approval step for that checkout.
A selection can still receive comments.
Selection, comment, purchase, and approval remain separate facts.
Approval is not final-file release
After approval, the final files can still be:
- Awaiting payment
- Awaiting studio release
- Partially released
- Released, payment required
- Released
The current job policy controls release.
Do not tell the client that approval always unlocks originals.
Do not tell the client that payment always unlocks originals.
Proofing is one gate in a longer chain. The full post-production workflow covers ingest, retouch, internal QC, proofing, channel exports, and archive — this post owns what to look for in a proofing tool; that one owns the ordered pipeline.
A simple gallery can still be enough
A simple gallery can be suitable when:
- The review purpose is selection
- One reviewer makes the decision
- The proof set is small
- The version is obvious
- The studio does not need detailed annotation
- The final-file handoff is separate and understood
Use a specialist proofing tool when the job needs deeper annotation, comparison, reviewer groups, or review governance.
Use a broader client area when the studio needs the proof connected to the brief, invoice, release state, and final files.
Copyable proofing setup checklist
- REVIEW PURPOSE
- What should the client decide?
- Which proof or set is in scope?
- Which version is current?
- REVIEWERS
- Who can comment?
- Who can approve?
- Who consolidates client feedback?
- PROOF IDENTITY
- Job:
- Product or SKU:
- View or asset:
- Version:
- Date:
- Preview limitation:
- CLIENT ACTIONS
- Comment:
- Select:
- Request changes:
- Approve:
- Submit feedback:
- CHANGE PATH
- Revision:
- Reshoot:
- Client decision needed:
- New requirement:
- VERSIONING
- What changed:
- Requested by:
- Replaces:
- Open comments:
- Accepted exceptions:
- RELEASE
- Approval condition:
- Payment condition:
- Manual release:
- Final-file recipient:
- Access expiry or revocation:
Adjust the labels to the current studio process.
Review the review before closing it
Before moving the job forward, confirm:
- The current version is identified
- Every required asset has a decision or accepted exception
- Requested changes apply to the correct proof
- The final decision maker is identified
- The job-level state matches the asset decisions
- Approval, invoice, and release states remain separate
- The next studio action is visible
How this fits in Lenso
Lenso can keep:
- current brief;
- SKU and shot context;
- proof versions;
- asset comments;
- requested changes;
- approval;
- optional invoice;
- final-file release
inside one project-specific client job.
Lenso is not a deep visual-annotation or enterprise review-governance product.
The Lenso versus Filestage comparison explains the fit difference.
Questions about online proofing
Is proofing the same as approval?
No. Proofing is the review activity. Approval is a recorded decision attached to the named version or set.
Is a favorite the same as a selection?
It can be one selection mechanism. The studio should define what the favorite means.
Is a selection the same as approval?
Not automatically. Selection can identify what to retouch or purchase. Approval records the decision required by the current project process.
Can a client approve before paying?
Yes, depending on the job. Approval and payment are separate states.
Does approval release final files?
Only when the current release policy allows it. Manual or payment conditions can still apply.