The average design revision cycle goes like this:
You send the files. The client opens them three days later. They reply with "looks great, just a few small things" in an email. The "few small things" are seven items written in paragraph form with no clear priority. You make the changes. You send a new version. They forward it to someone else, who replies with contradictory feedback. You're now on revision 4 of what was supposed to be a two-revision project, and you still don't have written sign-off.
This isn't a client problem. It's a workflow problem. The tools most freelancers use for client delivery: email attachments, Google Drive links, WeTransfer: were not designed for structured feedback and approval. They were designed for moving files from one place to another.
Here's how to fix the process.
Why the approval process breaks down
Before fixing it, it helps to understand exactly where it breaks.
Problem 1: Feedback is verbal or unstructured.
"I'll take a look and let you know" leads to a phone call where the client talks through vague reactions while you take notes and hope you captured it correctly. The notes aren't in the file. Nobody can verify them later.
Problem 2: There's no explicit approval moment.
Most client delivery workflows end with the client saying "this looks good" over email or Slack. That's not approval: it's an informal positive reaction. Six months later, when they want changes, there's no record that they signed off.
Problem 3: Multiple versions create confusion.
Sending v1, v2, and v3 as separate links or attachments means your client has three things in their email. They download the wrong one. They send the old one to their printer. You get a call.
Problem 4: You don't know if they've looked at it.
"Did you get a chance to look?" is a question freelancers send thousands of times per year. There's no mechanism in email attachments or Google Drive that tells you when the client opened the file.
The approval workflow that actually works
A well-designed approval workflow has four properties:
- One link per project, not per version. The client has one URL they always come back to. You update what's behind it.
- Feedback is written and pinned to specific elements. Not "the logo looks off": "the logo looks off [dot annotation on the specific element]."
- There is an explicit approval action. Not "looks good" in an email. An actual button that says Approve, with a record of who clicked it and when.
- You can see when they opened it. No more chasing.
Step 1: Stop sending file attachments
Attachments have a few problems: they bloat email inboxes, they don't let you update the file without re-sending, and the client downloads the file to their desktop where it sits in Downloads next to 400 other files.
Replace attachments with a delivery link: a permanent URL that hosts the file and lets the client view it in-browser or download it. When you update the file, the link stays the same.
This solves the "which version is the latest" problem immediately. There's only one URL. It always points to the current version.
Step 2: Put all deliverables for a project in one place
If you're delivering a brand identity project that includes a logo, a brand guide, social templates, and a typeface recommendation, sending four separate links is asking your client to manage four things.
Create a portal: one URL that contains all the deliverables for the project. The client opens one link and sees everything they need to review. You can add or update files in the portal without changing the URL.
This also makes the approval conversation simpler: instead of emailing about "the logo link" and "the brand guide link", you're talking about "the project portal."
Step 3: Let clients annotate directly on the work
The feedback you get from "please send any comments by email" is much vaguer than the feedback you get from "click anywhere on the image to leave a comment."
When clients can pin a comment to a specific spot on a design, their feedback gets dramatically more useful: "the tracking on this headline feels tight" with a pin on the exact headline is actionable. "The typography feels a bit off" in an email thread is not.
For video work, timestamped comments solve the same problem. "At 1:43, the transition is too fast" is unambiguous. "Around the middle, something feels rushed" is not.
The key requirement: clients should be able to do this without creating an account. Any friction in the feedback process reduces the quality and quantity of feedback you receive.
Step 4: Get explicit written approval
This is the step most freelancers skip because there's no natural way to do it in their current workflow. "They said it looked good" is not the same as a timestamped record of approval.
The approval mechanism should be:
- A button that says "Approve" (and optionally "Request changes")
- Per file, not per project: so if three of four deliverables are approved but one needs a revision, that's visible
- Recorded with the reviewer's name and a timestamp
- Triggers an email notification to you
This creates a paper trail. If a client comes back six months later saying they never approved the logo, you have a record of when they clicked Approve, what name they used, and any note they left.
It also closes the project cleanly. When every deliverable shows "Approved," the project is done. Not "I think they were happy with it": done.
Step 5: Know when they've opened it before following up
"Did you get a chance to look?" is the most common freelancer email and the most avoidable one.
If your delivery tool has open tracking: showing you when the client opened the link and how many times: you already know whether they've looked. You can follow up with context: "I saw you opened the portal yesterday: let me know if you have any questions" is more useful than the blank "just checking in."
More importantly, if the portal shows the file opened 4 times but no approval, that tells you the client is stuck on something. A quick "anything you'd like to discuss before signing off?" is more targeted than a generic follow-up.
The tools
For single file delivery with view tracking:
Upload the file, get a permanent branded link, see when it's opened. Any tool that does this works: 8fs ($12/month), or build something custom if you have the time.
For multi-file portals with approval:
This is where the options narrow. WeTransfer had this with Portals and Reviews until December 2025 when it was discontinued. The current options:
- 8fs ($12/month): multi-file portals, client annotation on images and video, Approve / Request changes buttons, view tracking, no client login required. Designed for the exact use case described in this post.
- Dash (£79/month): full DAM platform with approval features. Good for marketing teams; expensive for solo freelancers.
- Frame.io (requires Adobe CC, $54+/month): excellent for video review, limited for non-video files.
- Hightail: older product, has delivery + review, UX less polished.
The gap that existed when WeTransfer Portals was killed: a lightweight, affordable portal with client approval at freelancer pricing: is what 8fs is built to fill.
What to say when you deliver the work
The delivery message matters. Most freelancers send something like "Here are the files, let me know what you think." This invites vague feedback and delays approval.
A better delivery message:
Hi [name],
Here's the [project name] portal: [link]
Everything for the project is in there: [list what's included]. You can view each file in your browser, leave comments by clicking on the image, and click Approve when you're happy with each deliverable.
I've marked [X] as ready for final sign-off. Let me know if you'd like to discuss anything before approving.
[Your name]
This message:
- Tells them what to do (view, comment, approve)
- Sets the expectation that approval is the goal
- Gives them an out to ask questions before approving
- Doesn't ask "what do you think": which invites revision requests rather than sign-off
The feedback you want vs. the feedback you get
The worst client feedback is the kind that requires interpretation. "Can you make it pop more?" "It feels a bit corporate." "I'm not sure about the energy."
You can't eliminate subjective feedback, but you can reduce it by structuring the review process:
Ask specific questions alongside the delivery. "Does the logo work in both light and dark contexts? Does the type feel right for the tone of the brand? Is the colour palette aligned with what you had in mind?" Specific questions get specific answers.
Give clients something to react to, not just look at. A mood board with "we're going in this direction: does this feel right?" before the full delivery is better than a full delivery that misses the mark.
Make the revision scope explicit upfront. "This scope includes two rounds of revisions. Structural changes to the concept after approval will require a change order." Having this in the contract and restating it gently at delivery ("this is round 1 of 2") resets expectations.
The approval document
For any project over a certain value, it's worth generating a simple approval record: what was delivered, when the client approved it, any notes they left.
If your delivery tool records approvals with timestamps, this record already exists. Screenshot it or export it and file it with the project.
For projects where disputes are more likely: anything involving intellectual property, print production, or contractual deliverables: a formal sign-off document is worth the two minutes it takes to generate. Something as simple as: "I confirm approval of the deliverables listed below on [date]" with the client's name and email is enough.
The short version
- Send a link, not an attachment: so you can update without resending
- Put all project files in one portal: one URL, not four
- Let clients annotate directly on the work: pins and timestamps beat email feedback
- Get explicit approval per file: a button, a record, a timestamp
- Track opens: so you know when to follow up and why
The email chain is optional. Most freelancers just don't realize there's a better workflow available.