Client approval for freelance work: a clear decision on the right version.

Explain what this approval will confirm.

Start with the outcome you need from this stage. Is the client confirming a visual direction, content, functionality or a package ready for handoff? An intermediate approval does not necessarily cover the entire project. Name its purpose so agreement on an initial direction is not treated as approval of every future deliverable.

Choose the right level of decision

For a homepage mockup, you might ask the client to confirm the section order and visual direction before moving to mobile adaptations. State what they can assess now and what is not yet ready. The criteria should follow the accepted scope; a review is not the moment to introduce new requirements without discussion.

Describe what the decision enables in your own plan: preparing another version, producing variations or assembling the final package. That connection makes the request understandable without suggesting that every technical or financial action automatically follows a positive reply.

Identify the decision-maker and contributors

Ask who can confirm this stage and who consolidates other people’s opinions. A marketing lead may consult colleagues and send a common response. If another person needs to be involved, include them in the schedule instead of discovering their role after an initial approval.

In Dealokr, deliverables and revisions can be described in the signed agreement. You establish what the client will examine before presenting the preview. Approval then connects to the project and scope, rather than depending on an isolated exchange that each person remembers differently.

Write criteria your client can actually check.

A useful criterion connects an agreed expectation to something observable. “Professional” or “modern” can guide a discussion, but may not be enough to reach a decision. Return to the brief and identify the points the client can confirm or respond to with a specific reservation.

An example for a homepage mockup

This table illustrates a design review before development. It is neither a mandatory checklist for every website nor a claim that production testing has already taken place.

Make a response possible for each important point

Choose a few decisive criteria instead of a long form whose priorities nobody understands. Ask for an actionable observation: location, difference from the expected result and adjustment requested. If feedback remains subjective, suggest a discussion to clarify it before turning it into a production task.

Keep the criterion beside the relevant review material. Feedback on an old version or a screenshot without context may not support a decision on the current document. If a point cannot yet be checked, mark it as open and identify the stage when it will be reviewed. The client should not need to guess what an empty field means.

Make the preview usable without confusing review with production.

Give the version a stable reference and explain what changed since the previous presentation. The recipient should be able to open the correct material and find the criteria without searching several message threads. If you replace a file, retain the version used in earlier discussions.

Show enough to support a genuine decision

A preview should be readable and representative of the point being approved. An image that is too small or a demonstration the client cannot access prevents a useful review. Equally, review material does not always need to be the complete working file or an export immediately usable in production. Explain its purpose within the agreement.

Identify temporary elements, missing dependencies and anything you are not yet asking the client to approve. They can then comment on what is presented without treating the preview’s stated limits as defects in the final deliverable.

Check access and keep feedback in context

Test the permissions and channel you specified. For an external tool, check who can view, comment, download or edit. Those settings belong to that service: a public link remains public until its own permissions change. Do not rely on the appearance of a link to infer that access is restricted.

In Dealokr, the client reviews the preview and can request agreed revisions. Messages and stages stay in the timestamped project history while hosted final files follow the protected handoff process. You can connect the reply with what was presented, without claiming to prevent every copy of a preview or protect links hosted elsewhere.

Offer a clear choice between approval, reservations and revisions.

Ask the client to identify their decision. A version may be approved, approved with specific reservations or returned for corrections before a decision. A request for clarification is useful too: it identifies what is needed to decide instead of allowing assumed approval to take its place.

A message that frames the request

A short response format to offer the client

This structure helps organise the answer without asking for a general waiver. Remove irrelevant choices and confirm the effect of any reservations before proceeding.

“Approved with reservations” should remain understandable: what has been accepted and what still needs action? Do not infer permission to hand over everything or proceed through every stage. Confirm the scope of that decision with the client before using it as the reference for the next action.

Agree on a realistic response period and handle silence.

Choose the period with the people who need to assess the work. Volume, complexity and contributors matter more than a number copied from a template. Consider the team’s availability too: a date during a known absence will not help you obtain a considered response.

An illustrative schedule to agree together

For a small presentation, you might allow review from Tuesday to Thursday and discuss outstanding points on Friday. This example organises the conversation; it establishes no universal legal period or minimum. A larger package may require a different arrangement.

Specify when the period starts: an accessible version is available with the necessary material, under your agreement. If the client receives a significant new version or a corrected link late in the process, confirm an appropriate schedule. Do not retain a date that no longer makes sense simply because it appeared in the first message.

In French B2B relationships covered by Article L441-10, a planned acceptance or verification procedure is generally limited to thirty days after the service is performed, unless an express, non-abusive contractual provision states otherwise. It cannot freely postpone statutory maximum payment periods. This period does not create automatic approval of the work.

Follow up without manufacturing acceptance

Under French law, silence does not generally amount to acceptance, with exceptions connected to legislation, established practices, business relationships or particular circumstances. Passing a response date does not, by itself, mean that the client has approved the work.

Ask whether they accessed the material and what is blocking their decision. Identify the points still open, then confirm another date or the schedule implications under the accepted terms. Keep the reply and follow-ups. Do not add an automatic-acceptance condition retrospectively to an ordinary reminder.

Date the decision and identify subsequent changes.

Keep the presented version, review request and client response together. Record who decided, when and on which points. This record first helps people understand the project: someone taking over should be able to separate what was accepted from what still needs work.

Summarise the actual answer faithfully

After a call, send a factual summary of the version discussed, decision expressed, reservations and planned actions. Invite the client to correct an error and confirm anything that remains unclear. A summary you wrote should not quietly become an approval you attribute to the other person without their response.

Keep the original material alongside the summary. A project history helps reconstruct events, but this guide does not promise that a status or screenshot provides sufficient legal evidence in every situation. Clear references make the record more useful without deciding its legal weight.

Handle a change after approval

If the client later changes some wording or adds a request, identify the new version. State which criteria are affected and whether another review is needed. A limited adjustment does not necessarily reopen every earlier decision; make clear what has actually changed before starting the next round.

Compare the request with the scope and included revisions. If it changes the price, deliverables or dates, have the change accepted before producing it. Preserve the previous decision and new agreement rather than silently replacing the document already reviewed. That makes the progression understandable to both parties.

Separate approval, final-file handoff and money movements.

Approval records a decision about the work. Handoff provides access to the agreed materials. Client payment, a transfer to a connected account and a bank payout are separate events again. Connecting them in the project is useful; calling all of them “approval” makes the process harder to understand.

Name the next action

After the decision, confirm what you will do: apply the remaining corrections, prepare exports or hand over the final package under the accepted terms. Check reservations and the relevant version before announcing completion. A positive response to an intermediate mockup does not necessarily approve files that do not yet exist.

For fixed-price Dealokr projects, the client pays 100% upfront through Stripe Connect, before production. Review comes later: you request the transfer under the project’s conditions, then the client gains access to hosted final files after that transfer is confirmed. This does not mean the money has already reached your bank; a date or reply does not automatically trigger the movement.

Confirm what the handoff covers

A first milestone transfer does not unlock every file. Use the project’s handoff process as the reference and check which materials are actually concerned. For externally hosted material, permissions still need to be managed in the relevant service.

Finish with a message identifying the package handed over, any outstanding reservations and the follow-up agreed. That provides a clear continuation from the client’s decision, without turning their response into general approval of every future request. Each stage remains understandable in its own right.