Hand over freelance work with clear client approval.

Describe what the client will receive before producing it.

Turn the general project promise into identifiable items. “A visual identity” might include a logo, several variations, a guidelines document and exports for different uses. Your client should be able to find what is included, what remains optional and what you need from them to proceed.

Write a package someone can check

For each item, state its name, expected format, number of variations and intended use. For example: “primary logo and monochrome version, SVG and PNG exports, PDF usage guide”. List any working files, documentation and access separately. The package should match the accepted price and scope.

Record relevant exclusions too: copywriting, font purchases, technical integration or maintenance, depending on the project. Clarifying an exclusion before work starts is easier than introducing an additional charge after presenting the result. Ask what the client needs to do with each file so the format serves a real purpose.

Identify who makes the decision

A contact may collect several opinions without having authority to approve the work. Ask who consolidates feedback, who confirms the decision and who receives the files. If another team will use them, establish its technical requirements before preparing the final exports.

In Dealokr, the scope, price, deliverables and revisions can sit in the agreement signed before payment. For a fixed-price project, the client pays 100% upfront through Stripe Connect. You can establish the delivery framework before production, with confirmed client payment rather than an unresolved payment request.

Prepare a preview that supports a useful review.

A review version should show enough of the result for the client to assess it. Choose a presentation suited to the work: a readable document, demonstration, mockup or review export. Explain the points to examine instead of leaving the recipient to guess what kind of answer you need.

Name versions and highlight open points

Use a consistent name with a version number and, where useful, a date: “identity-v03-review”. Explain what changed since the previous delivery. If a photograph or text is still missing, identify it clearly. A stated limitation is easier to assess than an incomplete preview presented as a finished handoff.

Check access from the recipient’s perspective: does the file open, is the text readable, does the link work and are permissions appropriate? A message containing a closed link does not give the client a genuine opportunity to review the work.

Separate a review preview from usable final files

A preview and a final package can serve different purposes. If your client is already asking for production-ready assets, the guide to final files before payment helps explain the distinction in line with your agreement, without inventing a new condition at the last minute.

In Dealokr, the client reviews a preview and can request agreed revisions while hosted final files follow the protected handoff process. For a Drive, Figma or other external-service link, that service’s permissions still apply. Check them separately before sharing; the project does not change an external provider’s access settings for you.

Connect approval to a specific version and review criteria.

Your client should know what they are confirming: the agreed brief, content, format or expected behaviour. “Do you like it?” opens a different discussion from “does this version meet the three agreed points?” Leave room for objections while asking the client to connect them to something specific.

Agree on the response channel and date

Set a review period that fits the client’s availability, then repeat the version, criteria and response date in your message. The client approval guide explains how to identify the decision-maker and describe the approval you are requesting.

This template asks for a review under arrangements you have already agreed. It does not add automatic acceptance or create a new contractual duty.

Replace every placeholder and attach only the material needed for that decision. When the client replies, keep their wording with the version reference. “Received, thank you” acknowledges receipt; it does not necessarily describe an approval of the result.

Separate corrections, revisions and additional scope.

Consolidate feedback before restarting production. Ask for a location, observation and intended result: “replace this heading with the attached wording” is actionable; “make the whole thing more impactful” needs clarification. A combined response helps you avoid applying incompatible instructions in separate rounds.

Compare feedback with the accepted scope

An error against the agreed requirements, a preference addressed within included revisions and an extension of the project are different situations. Check the agreement before deciding how to handle them. The guide to managing client revisions helps organise that discussion and price additional work when it falls outside the scope.

Confirm the changes retained, what stays the same and the next version expected. If a request changes the price or schedule, have that change accepted before quietly absorbing it into production. The client should understand which decision they are making and what it changes.

Do not turn a missing response into assumed approval

Under French law, silence does not generally amount to acceptance. Exceptions can arise from legislation, established practices, business relationships or particular circumstances. Do not invent automatic approval in a reminder simply because the planned response date has passed.

First check access to the preview, the decision-maker’s availability and receipt of the request. If the client is not responding after delivery, identify the decision still needed and explain possible schedule effects under the agreement. Keep a record of follow-ups without attributing a decision to the client that they have not expressed.

Clarify source files, usage rights and dependencies.

A ready-to-use export and a working file need different preparation. A native document may contain layers, components, plugins or intermediate material the client cannot easily open. If it is part of the commission, prepare a usable version with the information needed to continue working with it.

Check what belongs in the agreed package

Do not assume either that every working file is included or that source files are always excluded. The freelance source files guide helps describe what will be handed over, in which format and with what limits. Address it when scoping the work, then check the package before sending it.

List relevant dependencies: software version, font, licensed media or a client-supplied resource. Check what you can pass on and what requires a separate purchase or account. Remove material belonging to other clients and internal documents unrelated to this project. The recipient needs a usable package, rather than every intermediate file you happened to create.

Distinguish technical handoff from usage rights

Where French copyright applies, an assignment must identify the rights transferred separately and define their exploitation: scope, purpose, territory and duration. A filename alone does not provide those details. Have the terms adapted to the creation and intended uses rather than relying on a general phrase meant to cover every project.

Finally, check that the files match the rights and materials described in the agreement. The technical package and permission to use it should be understandable together, including limitations associated with third-party resources. Do not leave a necessary licence or application requirement for the recipient to discover later.

Check the final delivery and keep its record.

Prepare a final package separate from experiments and drafts. Use understandable names, remove obsolete versions and include a short inventory. The recipient should not have to choose between “final”, “final2” and “actual-final-version” to work out which file to use.

A check before final handoff

Use the delivery and validation checklist to revisit these points throughout the project. It helps you check the steps while keeping your particular agreement as the reference for the handoff.

In the Dealokr workflow, you request the transfer under the project’s conditions following the required review. The client gains access to the hosted final files after the transfer is confirmed; this does not mean the money has already reached your bank. A date or comment does not automatically trigger a transfer, and a first milestone transfer does not unlock every file.

Confirm receipt and retention arrangements

Ask the client to confirm that they retrieved the correct materials and can open them. Keep the inventory, delivered version and related exchanges. Explain how long access will remain available under your arrangement and who handles backups. Avoid leaving either person to assume that hosting or support continues indefinitely.

Five answers for a simpler delivery.

Should I wait until the whole project is finished before showing it?

Intermediate reviews can confirm a direction before you produce everything. Choose moments when the client can make a useful decision. Explain what they are seeing and what will follow, so an in-progress presentation is not confused with the final handoff. Record the direction agreed for the next stage.

How many days should the client have to approve the work?

Agree on a realistic period based on the amount of material and the people involved. Put the date in the schedule and review request. This guide does not prescribe a mandatory number of days: two screens and a detailed report may need different review arrangements.

What if several people give opposing feedback?

Return to the contact responsible for consolidating feedback and ask for a decision. Summarise the incompatible requests before changing the file. You can suggest an option and explain its consequences, but the project needs a common response on which to continue.

Is a file that has been sent necessarily approved?

No. State its status: preview, version needing changes or agreed final version. Keep the response associated with its reference. If something changes after approval, name the new version and explain how it affects the previous decision instead of silently replacing the document.

What should I retain after the handoff?

Keep the accepted terms, relevant versions, feedback, inventory and receipt confirmation in a way suited to your activity. Remove unnecessary access in line with the agreement and tools used. A backup of the delivered package helps answer a later question without reconstructing the work from scattered drafts.