Why your client says they never got the files
Three days after you hit send, your client messages back: I never got the files. You definitely sent them. The upload finished, the confirmation looked normal, and now you're stuck defending a delivery you can't see from their side. Here's where a transfer actually goes missing between your send button and their inbox, and how to find out fast instead of resending blind.
This happens more than you'd think, and it's rarely the transfer itself
A finished upload and a received download are two different events, and almost every "I never got it" case lives in the gap between them. The files made it to us. What went wrong is how the link found its way, or didn't, to the person waiting for it.
That's good news, actually. A missing link has a short list of usual causes, and most of them take under a minute to check.
Check these two things before you assume anything is broken
- How did you send it? ZappFiles gives you two ways to share a transfer: generate a link yourself, or use send via email and let us deliver it straight to a recipient's inbox. If you picked a link and pasted it in a message thread, an old email, or a project tool, it's worth confirming the client actually opened that specific thread.
- Did you type the address right? If you used email delivery, a single typo in the receiver field sends the notification into the void instead of an inbox. Enter your own email address too when you upload, so you get a confirmation copy of the link in your own inbox as proof it went out, and something to forward if the original never lands.
The most common culprit: spam and promotions folders
Automated delivery emails from a sender your client hasn't received mail from before are exactly the profile spam filters are built to catch. Corporate inboxes are worse, since some company filters block anything containing a download link from an unknown domain outright, no folder to check at all.
The first message from you to a new client is the one most likely to get caught. After that, most mail providers learn the sender is fine and stop filtering it. Ask the client to search their inbox for "zappfiles" rather than scrolling, and to check spam, promotions, and any IT-managed quarantine folder if they're on a work account.
If it's not spam, one of these usually is
| What the client is seeing | Likely cause |
|---|---|
| Nothing at all, no email, no message | Wrong recipient address, or the link never actually got sent to them |
| A link that leads to an expired page | The transfer's expiry passed before they opened it. Free transfers expire fastest |
| A lock screen with no way in | The transfer has a password and you sent the link without it |
| They found it, but weeks after you sent it | It was there the whole time, buried under newer email |
Expiry catches people out more than anything else on this list. A transfer without an account expires in 10 days and a free account transfer in 14, which is plenty for an active back and forth but not for a client who opens their inbox once a week. If the job calls for a longer runway, Pro stretches that to 60 days and Max to a full year, and you can extend an existing transfer's expiry after sending from transfer management instead of starting over.
A password protected transfer is a common one too, especially if you set the password days before sending and forgot it wasn't bundled with the link. We recommend sending the password through a different channel than the link itself, but that only helps if you remember to send it at all.
Confirm it before you resend anything
Resending blind fixes some of these problems and wastes your time on the rest. Check your upload history first. Every transfer shows a download count, so a count still at zero tells you the link genuinely hasn't been opened, while any number above zero means it landed and got clicked, whatever the client remembers. We cover reading those numbers properly in how to know if your client actually downloaded your files.
If the count is zero and the transfer hasn't expired, the link itself is fine. The problem is upstream, in an inbox or a filter you can't see into, which is exactly when switching delivery method helps: paste the link directly into a chat message instead of relying on email to carry it through.
A short checklist for next time
- Enter your own email address when you upload, so you get a copy of the link as proof it went out.
- Double check the recipient's address before you hit send, especially the first time you're sending them anything.
- Set an expiry that matches how often the client actually checks their inbox, not the shortest option on the screen.
- If you password protect a transfer, send the password the moment you send the link, not an hour later once you remember.
- When in doubt, check the download count before you resend anything. It answers the question faster than another email back and forth.
None of this replaces sending a clean, well organized transfer in the first place. If the delivery itself needs work before it goes out the door, start with how to organize client project files before you send them.
Send it once, and know it landed
A confirmation copy in your inbox, a download count on every transfer, and an expiry you control. No more guessing whether it arrived.