Client approvals without the email chain

Most client approvals still happen in an email thread. The file is attached to message four, the feedback arrives in message nine, and the "yes, go ahead" is a one-line reply that nobody can find when the printer asks which version was signed off.

That isn't a people problem. It's what happens when the work, the decision and the record live in three different places. This article sets out a client approval process that keeps them together: one place for every file, a clear yes or no, a reason whenever the answer is no, and a record you can point to later.

Why approvals get lost in email#

Email is good at conversation and bad at decisions. The same few things go wrong on almost every project:

• The file and the decision drift apart. Someone replies "approved" to a thread with three attachments, and you have to guess which one they meant.
• Versions multiply. logo-final.pdf, logo-final-v2.pdf and logo-final-v2-edits.pdf all exist, and each one is in somebody's downloads folder.
• "Looks good" isn't a decision. It might mean approved. It might mean "I haven't opened it yet, but I'm being polite".
• Nobody knows whose call it is. The account lead, the client's marketing manager and their managing director all reply, and they don't agree.
• The record lives in one person's inbox. When that person is on holiday, so is your proof.

What a good client approval process needs#

Before you pick a tool, agree the shape. A design approval workflow that holds up under pressure has five parts:

1. One home per file. The thing being approved lives in one place, next to the conversation about it.
2. A named decider. Everyone knows whose yes counts before the file goes out.
3. A clear decision. Approve or reject, not "thoughts?".
4. A reason for every no. A rejection says what needs to change, so the next version fixes the right thing.
5. One live version. When a new version arrives, it takes over the approval, and the old one is marked as replaced.

Skybase is built around that shape, so the steps below use it. The principles hold whatever you use.

Set up approvals on the job, step by step#

In Skybase, a file belongs to a job: the card on the board that also holds the brief, the comments and the checklist of tasks. That job is the file's one home.

1. Bring the client onto the project and the job#

Invite the client as a guest. A single-project guest is free, and can comment, upload files and approve or reject them. Then add them to the job itself through Collaborators, or invite them from there with Invite someone new. The guide to inviting your team and clients covers every route.

Being on the job matters. The Approvals filter in each person's Inbox lists the files waiting on the jobs they're part of, so a client who isn't on the job won't find the file there.

2. Post the file with a clear ask#

Attach the file to a comment on the job and tick Request approval before you post it. In the same comment, write the ask:

• what you want them to decide, such as "the colour ratios and the logo misuse page"
• what is already settled and not up for review
• when you need the answer

Put that date on the job as its due date too. Skybase reminds the people on the job the day before, on the day and once it's overdue, so the reminder does the chasing rather than you.

The people on the job are told that a file needs their approval, and the job's Files tab shows how many files are waiting.

3. Get a yes, or a no with a reason#

Anyone on the project except the person who uploaded the file can Approve or Reject it, from the comment thread, the Files tab or the Approvals filter in the Inbox. An approval can carry an optional note. A rejection asks "What needs to change?" and won't go through without an answer.

That one rule removes most of the back and forth. Every no arrives with the next step attached, and the uploader is told either way.

4. Send the next version into the same place#

When a file is rejected, use Upload new version on it in the Files tab. The new file goes up for approval straight away, and the rejected one stays in the list, marked Replaced by new version, with its note. Nobody has to work out which attachment is current: the status tells you, not the file name.

Each file gets one decision. Once it has been approved or rejected, that's final, and a change means a new version. It keeps the record honest.

5. Hand off only what was approved#

When the work is signed off, Download all on the Files tab gathers the job's files into a zip. It leaves out anything still awaiting approval and anything that was rejected, so nothing pending or rejected ends up in the zip you send to the printer or the developer.

Decide whose yes counts before you ask#

One detail catches teams out. Approval isn't limited to the client: anyone on the project other than the uploader can decide, and that includes your colleagues. Since each file gets one decision, a teammate who approves the file "to help" has closed the client's request.

Three habits stop that happening:

• Name the decider in the comment with an @mention, so everyone can see whose call it is.
• Agree as a team that on client-facing files, the client presses the button.
• If you want an internal check first, run it as its own round. Post the file for your studio lead, then post the version they approve for the client. Both decisions stay on the job.

Guests can see every job in the project they belong to. If an internal round is something the client shouldn't see, keep it in an internal project instead. Sharing work with clients covers where to draw that line.

A worked example: Harbour Studio and Northwind#

Take a small studio, say Harbour Studio, rebranding a client called Northwind. Harbour and its people are made up: they're the example in Skybase's sample workspace. Two approvals are in flight on the Northwind Rebrand board.

The first is internal. Priya, a designer, has finished hero-direction-b.png for the homepage hero. It goes on a comment with Request approval ticked and a note: "@Maya direction B is ready for your approval, with the shorter headline." Maya Chen, the studio lead, is on the job, so the file is waiting in the Approvals filter. Maya approves it, and Priya can take it to the client round.

The second is the client's. Leo has "Brand guidelines v3" in the Client review column, and Tom Becker, Northwind's contact, is on the job as a collaborator. As a single-project guest, Tom costs the studio nothing. Leo posts brand-guidelines-v3.pdf with approval requested and a due date.

Tom shares the PDF with Northwind's marketing team, and the job goes overdue while they read it. The due reminders keep it in front of Tom without Leo writing a chaser. The team wants a darker navy for print, so Tom rejects the file with that note. Leo adds Deep Harbour (#0B2545) to the secondary palette, updates the print specs and uses Upload new version. Tom approves the new file with a short note: "Looks right to us."

When the printer asks what was signed off, nobody searches an inbox. Leo opens the job.

The record you end up with#

After sign-off, the job holds the whole story:

• the approved file, marked with who approved it and any note they left
• every rejected version, with the reason it was rejected, marked Replaced by new version
• an entry for each request, decision and new version, which you can see by filtering the comments to Activity

Download links are signed and expire after 8 hours, so a link forwarded round the client's office doesn't stay open for good. Anyone who needs the file again opens the job, where their access is checked.

A checklist for your next approval#

• The client is invited as a single-project guest and added to the job.
• The decider is named in the comment with an @mention.
• The ask says what to decide, what's settled and by when.
• The job has a due date, so reminders do the chasing.
• Request approval is ticked when the file goes up.
• Every rejection carries a note, and the next version goes up with Upload new version.
• The hand-off zip comes from Download all, so nothing pending or rejected goes out.

Approvals are one part of running client work in the open. The features page shows the rest of what sits on a job, and the agencies page shows how studios put it together.