A client approval portal is useful when the studio needs more than a place to display images.
The useful version connects the client-facing parts of one job:
- current brief;
- product or SKU context;
- proof versions;
- asset-specific comments;
- requested changes;
- approval;
- optional invoice;
- final-file release.
A simple gallery can still be enough for a straightforward job.
The decision is not whether portals look more professional.
It is whether the studio needs a clearer record of what the client reviewed, what they decided, and which files were released.
Start with the job the tool needs to do
A portal, gallery, and proofing tool can overlap.
Use the category names as a starting point, not as a guarantee of capability.
Gallery
A gallery is usually centered on presentation and access.
It can support:
- viewing;
- favorites;
- downloads;
- sharing;
- light comments;
- photo sales in some products.
A gallery can be enough when the client mainly needs to view or select files.
Proofing tool
A proofing tool is centered on reviewing creative files.
It can support:
- image or file comments;
- annotations;
- selections;
- versions;
- requested changes;
- approval;
- reviewer groups in specialist products.
A proofing tool can be the right choice when deep visual review is the main requirement.
Client approval portal or client area
A client area connects the proof to the broader client job.
It can support:
- the current brief;
- product and shot context;
- proof review;
- status;
- messages;
- optional invoice;
- final-file release.
Some products cover more than one category.
Choose the product based on the current job, not the vendor label.
When email and a shared folder can still be enough
A separate portal is not required for every studio or every job.
Email and a shared folder can remain workable when:
- One clear client contact reviews the work
- The proof set is small
- The client gives one consolidated response
- The version is easy to identify
- The final-file handoff is simple
- The studio does not need a durable in-product review record
Do not add another client surface merely because software exists.
A portal creates another place the studio and client must understand.
Use it when the connected record is worth maintaining.
What changes when the job becomes harder to reconstruct
A more structured client area becomes relevant when the studio needs to answer questions such as:
- Which proof or version is the client reviewing?
- Which product or SKU does this comment refer to?
- Is the client selecting an option or approving the final file?
- Who can make the current decision?
- Which requested changes remain open?
- Which version was approved?
- What final set did the studio release?
- Does payment affect download access?
- When can the client link expire or be revoked?
These are record-keeping questions.
The portal does not make the answers correct automatically.
The studio still needs a current brief, review rules, decision owner, and delivery policy.
Six records a useful portal should connect
1. The job identity
The client should be able to recognize:
- Studio
- Job title
- Products or collection
- Current stage
- Relevant deadline
Do not rely on a generic folder name.
2. The current brief and shot context
The client should see the requirements selected for review.
Examples:
- Products or SKUs
- Relevant variants
- Required views
- Approved references
- Output groups
- Open decisions
The client does not need the studio's private notes or internal pricing calculations.
3. The proof and version
The review should identify:
- Proof or set name
- Version
- Date
- Product or asset
- Current review state
A thumbnail without a version can leave the studio and client discussing different files.
4. Comments and requested changes
Keep a comment attached to the relevant proof, asset, or set.
A comment can be:
- a question;
- a preference;
- an observation;
- a reference;
- an instruction.
A requested change is a separate operational decision that the current version is not approved.
Do not treat every comment as a change request.
5. Approval
Approval should identify:
- Named proof, version, or set
- Person making the decision
- Date
- Open exceptions
The client agreement defines the legal effect.
The portal records the operational decision.
6. Final-file release
The studio should be able to identify:
- What was released
- Which approved set it corresponds to
- Who received access
- When access can expire or be revoked
- Whether approval, payment, or manual release still applies
Approval and release are related.
They are not the same record.
Selection is not automatically approval
A favorite, heart, checkbox, or selected thumbnail can mean:
- this is the preferred option;
- retouch this image;
- include this image in a purchase;
- compare this image with another;
- use this as the current direction.
It does not automatically mean:
This version is approved as the final deliverable.
When selection and approval are separate in the studio's process, label them separately.
In per-photo billing, selecting an image can be part of a purchase flow.
That is not the same as a project-level approval decision.
Project billing and per-photo billing
Project billing
The client reviews the current proof or set.
The client can:
- comment;
- request changes;
- distinguish revision or reshoot under the current studio process;
- approve the current version.
The invoice and release state remain separate.
Per-photo billing
The client selects eligible photos and continues to payment.
Purchased originals become available under the current payment and release policy.
There is no equivalent project-level approval step for the selection checkout.
Do not present the two flows as one universal portal process.
What the client should understand without training
A useful client area should make these actions clear:
- What am I reviewing?
- Which version is current?
- Where do I leave a comment?
- How do I request a change?
- How do I approve?
- Do I need to pay?
- Are the final files released?
- How do I contact the studio?
The interface does not need to expose every internal project state.
It needs to explain the client's current action.
What the studio should understand
The studio should be able to identify:
- Client access state
- Current proof version
- Unresolved comments
- Requested changes
- Approval state
- Invoice state when used
- Final-file release state
- Delivery record
Do not infer one state from another.
An approved proof can still have:
- an open invoice;
- manual release;
- another unreleased set;
- an accepted exception.
Access and retention boundaries
Client access should be described accurately.
Use:
- Project-specific access
- Time-limited email link
- Can expire
- Can be revoked
- Can be replaced
- No paid client seat
Do not promise:
- Permanent access
- Every past project in one library
- Self-service repeat ordering
- A universal client account across studios
Retention depends on the current studio agreement, subscription, storage, account state, and Lenso policies.
Questions to ask before choosing a portal
Use this evaluation list.
- Does the product support the studio's actual billing mode?
- Can the client identify the current proof and version?
- Can comments stay attached to the right asset?
- Are selection, requested changes, and approval distinct?
- Can the studio identify the decision maker?
- Does the product show the current release state?
- Can the studio revoke and replace access?
- Do clients consume paid studio seats?
- Can the studio keep specialist tools where they remain stronger?
- Does the product disclose its current storage and retention boundaries?
- Can the client complete the task without a training call?
When a specialist proofing product is the better fit
Choose a specialist proofing product when the studio needs capabilities such as:
- detailed visual annotation;
- broad video, document, design, or website review;
- side-by-side or overlay version comparison;
- several reviewer groups;
- multi-stage approvals;
- review reports;
- verified approval controls.
Lenso does not match all of that depth.
Use the current Lenso versus Filestage comparison for the sourced product distinction.
Either way, the review mechanics — comments, selections, requested changes, and approval kept distinct — matter more than the label on the tool; see online proofing for product photography for that setup.
How this fits in Lenso
Lenso's client area is project specific.
Depending on the current job and enabled features, the client can:
- review the brief;
- view proofs;
- leave comments;
- request changes;
- approve;
- view or pay an invoice;
- download released final files.
The studio controls what is available and when.
Clients do not consume paid studio seats.
The link can expire or be revoked.
The client area is not a permanent cross-project asset library or a self-service reorder system.
Questions about client approval portals
Does every product photography studio need a portal?
No. A simple job with one reviewer and a small proof set can work through email or a gallery. Use a portal when the connected client record solves a real job requirement.
Is a gallery the same as an approval portal?
Not necessarily. A gallery is often centered on presentation and access. A portal can connect review to the broader job.
Are favorites the same as approval?
Only when the studio has deliberately defined them that way. In many processes, a favorite is a selection and approval is a separate decision.
Do clients need a paid seat in Lenso?
No. Invited clients use project-specific access and do not consume paid studio seats.
Can clients permanently return to every job?
No universal permanent-access promise applies. Access and retention follow the current job and account policy.