# How to share a mix with a client and keep a delivery record

> Share a clearly identified mix version, ask for explicit approval, and keep track of files, recipients, sending, and downloads without mixing up their statuses.

Author: Roye
URL: https://wuse.works/en/blog/share-mix-track-delivery/

## Share an identified version and track each status separately

To share a mix with a client and keep a delivery record, identify the version, explain what response you need, and save the message alongside the files you sent. Track sending, downloading, and approval separately. In the wuse workflow, keeping these separate helps connect your music collaboration to a delivery you can retrace later.

For example: you send Aurora_Mezcla_v03 for review and receive confirmation that it was downloaded. Keep approval marked as pending until the person responsible confirms that version; then prepare the agreed final package. That way, you can answer what you sent, who you sent it to, and why, without relying on your memory of a conversation.

## What the workflow should cover and how to assess its cost

Before choosing a tool, break down what you need into four tasks: presenting the mix, collecting feedback, getting a decision, and delivering the agreed files. For a one-off send, a transfer with a clear message may be enough. For a project with several revisions, it's also worth considering how you'll keep the context behind each decision.

If you only need to send a package, Dropbox Transfer lets you share it through a link without giving access to a working folder. Check your plan's size limit and expiration options before sending it.

Assess the cost based on your project volume, the storage you need, the people involved, and the client's access requirements. Before subscribing, check the current price and exactly what's included in the plan you choose. A feature shown in a product overview may come with requirements that don't fit your delivery needs.

Include your admin work in the comparison too: how long it takes to gather responses, find the approved version, and handle requests to resend files. As a practical exercise, retrace your last delivery using your current system. Write down which information you found right away and what you had to ask for again; that list will give you concrete criteria for assessing an alternative.

- Clear identification of the project, version, and purpose of the send.
- An agreed channel for feedback and a person responsible for approval.
- Access requirements and availability that work for the recipient.
- A record you can keep alongside the files you sent.

## Who wuse is for and when to choose a simple transfer

wuse works as a workspace for music projects that bring together audio versions, stems, files, collaborators, feedback, and deliveries. Consider that approach when your problem starts before you send anything: several people are giving feedback, different versions are circulating, and you need to keep the project's decisions connected.

If the mix is already approved and you just need to send a package to one person, a simple transfer may be enough. But if you still need to decide what to change, your buying criteria should include how you'll handle revisions. Choose based on the task still ahead and the team's willingness to use the workflow.

The tool also needs to feel comfortable for the client. If they end up sending feedback through WhatsApp or email, you need a way to bring it into the project. Before choosing, think about how you'll collect those notes so no revision gets lost.

Agree on a simple solution: whoever is coordinating gathers those responses, identifies where they came from, and connects them to the relevant version. If a message is ambiguous, confirm what it means before changing the mix. Buying a tool doesn't replace that working agreement.

## Step 1: prepare the project and define what you're sending

In your wuse project, organize the audio version and files for this round. Use a consistent naming convention, for example Aurora_Mezcla_v03_2026-10-07. This name is a suggested convention: the goal is for you and the client to be able to point to the same mix without using phrases like the latest one or the good one.

Define the purpose before sharing: review, approval, or final delivery. For a review, explain which aspects you want to assess. For approval, ask for a decision on a specific version. For final delivery, list the agreed contents and ask for confirmation of receipt.

Example review message: I'm sharing Aurora, mix v03. In this round, we'll review the vocal presence and the balance of the chorus. Send your feedback with minutes and seconds, and gather the team's notes before Friday. This version is pending approval.

If you still need to organize the material, see the existing guide [How to organize versions and stems in a music project](/en/blog/organize-music-project-versions-and-stems/). That work gives you a clear reference before you send anything. Here, the next step is to record what left the project and what response you expect to receive.

- Check that the audio matches the stated version name.
- Check that the included files match the agreed scope.
- State who gathers feedback and who can approve.
- Keep an identifiable copy of the material you're going to send.

## Step 2: share the mix and turn feedback into a decision

When sharing the delivery, include a short message with the access details that states the project, version, purpose, and next action. Check how your client will receive the material and explain any access requirements. If there's an expiration date, make it easy to see so they can plan their download.

Ask for feedback in an easy-to-repeat format: version, timestamp, observation, and desired change. For example: In v03, from 01:12 to 01:20, the vocal feels further back than in the verse; I'd like to hear the lyrics more clearly. You can ask for this format in writing without relying on the player having timestamped comments.

Sending files and discussing a mix are two different tasks. If you need the client to tell you what's happening at 1:20, look for a workflow that lets you keep that comment alongside the version they listened to.

When feedback comes in from several people, gather an agreed round of notes before making conflicting changes. To build out that process, see [How to give mix feedback and avoid endless revisions](/en/blog/mix-feedback/). Here, the main thing is to keep the final decision: who approved, which version they approved, and the message they used to approve it.

Example approval request: Can you confirm that Aurora_Mezcla_v03 is approved so I can prepare the agreed delivery? If the response includes a change that's still needed, record that change and ask for approval of the resulting version. Avoid automatically carrying an earlier approval over to audio you changed afterward.

## Step 3: record the send, activity, and approval

Create an entry for each delivery in whatever work log you use. The following template is a suggested way to do this that you can fill in manually. Its value is in connecting the material, the message, and the response; it doesn't require a platform to generate every field automatically.

Example identification: Delivery AUR-003; client: Lucía; project: Aurora; version: v03; purpose: review; file: Aurora_Mezcla_v03.wav. Replace the details with those of your project, and list the full filenames when the package contains several files.

Example send details: recipient: Lucía, via the agreed email address; date: October 7, 2026, 16:30 UTC; link: paste the link you used; expiration: copy the date shown in the service. Also attach or save the message you sent. Including the time zone keeps remote teams from interpreting the same time differently.

Example tracking: send recorded; download still to be verified; approval pending. Update each status with the relevant evidence. If the client confirms receipt by message, save that confirmation with its date, even if you don't have a download counter.

In Dropbox Transfer, you can check views and downloads from the Sent tab and manage download notifications. I'd keep that record separate from approval: someone opening or downloading the link doesn't mean they've listened to the mix or are happy with it.

When you prepare the final package, record another send linked to the approved version. If you need to resend it later, add the new link and date without deleting the earlier record. If you changed any files, identify that change too, so the entry doesn't describe two different packages as though they were the same.

## Mistakes to fix before closing out the delivery

A common organizational mistake is using a single status called delivered for the whole process. Replace it with information that answers specific questions: was it sent? Is there confirmation of receipt or download? Was the version approved? A send can be completed successfully while approval is still pending.

It's also worth avoiding ambiguous names, files replaced without a record, and replies like perfect whose context hasn't been saved. If an approval is unclear, ask for a brief confirmation that mentions the version. It's better to clear that up while the conversation is still active.

Another point is the scope of the package. Don't add stems, instrumentals, or other material just because they might be useful: check which ones were agreed on and which are ready. To define those contents, see [Stems or multitracks: what to send for mixing a song](/en/blog/stems-or-multitracks/), the third guide related to this workflow.

Before closing out, agree on what will happen if the client needs you to resend the files or asks for a change later. Record the new request and its scope instead of silently changing the previous delivery. The goal is to keep a sequence of decisions and files that's easy to follow.

- The record distinguishes sending, receipt or download, and approval.
- The approval identifies the relevant version.
- The package contains the agreed files and keeps their names.
- The message states how long the link will be available and what to do next.

## Next step: apply the workflow to a specific delivery

Start with one song and one person responsible for approval. Define the version, write the message, and fill in the record before sending. Then add the responses and events you can actually verify. This exercise will help you assess which part of the process needs a tool and which part needs a clearer agreement.

If you want to bring your music work together around the project, head into wuse and organize your next delivery with that in mind. Use the related guides to organize versions, prepare feedback, and define the files. You'll have a clear picture at the end when you can identify the material sent, its recipient, and the decision that's still pending or has already been confirmed.

## Frequently asked questions

### Does the client need to create an account to receive the mix?

That depends on the tool and the access method you choose. Check the recipient's experience before sending, and explain any registration or permissions needed. If the client needs to avoid creating an account, make that one of your selection criteria and verify that the specific option meets it.

### What format should I send for review and for final delivery?

Agree on the format based on how the file will be used. Define separately what the client needs for review and what they expect to receive when the work is finished. Record the agreed names and specifications; avoid assuming that the same package works for every recipient.

### Does a download confirm that the client approved the mix?

Record the download as activity and ask for explicit approval that mentions the version. The Views and Downloads counters documented by Dropbox Transfer describe transfer activity; they don't establish musical approval on their own. Keep the decision message alongside the record.

### What should I do if feedback comes through email, chat, and voice notes?

Assign one person to gather it into a round of notes, identifying the author and version. Ask for timestamps when they help locate the problem. If two comments contradict each other, ask for a decision before changing the mix and keep the agreed response.

### What should I save when I resend a delivery?

Keep the original record and add the date, recipient, and link for the resend. State whether it's the same package or whether any files changed. If there's a new version, identify it and determine whether it needs another approval.

## About Roye

Roye writes wuse's guides on music production and collaboration. Under the name Dibo Roye, he has public production credits for ALE ALAS and songwriting credits for Tillaz.
