Client approval email templates for every stage

The work is finished, and now you need a yes. How you ask decides how quickly that yes comes back, and whether it's clear enough to act on when it does.

Most approval emails ask "Any thoughts?" and get thoughts back. The templates below ask for a decision instead. There are six, one for each stage of a sign-off: the first ask, a new version, a reminder, an overdue follow-up, confirming the sign-off, and handling a yes that comes with changes. Copy them, fill in the square brackets, and cut anything that doesn't fit your client.

1. Asking for sign-off on a first version#

Use it when a piece of work goes to the client for the first time.

Subject: [Project]: [what it is] ready for your approval by [day, date]

Hi [Name],

[What it is] is ready for you to review: [link]

What I need from you: approve it, approve it with small changes, or tell us what needs to change before we go further.

Please look at: [the two or three open questions, e.g. the headline and the colour ratios]. Already settled: [e.g. the typefaces, agreed on [date]].

Who decides: [you / you and [Name], and we need a yes from both of you].

Could you let me know by [day, date]? That keeps [the print date / the launch on [date]] on track.

Thanks, [Your name]

Why it works: the client knows the three answers you can use, so "looks nice" isn't one of them. Naming the open questions points their attention at what's undecided, and naming what's settled stops a new round of opinions on the typeface. The date comes with a reason, which makes it a plan rather than a demand.

2. Sending a new version, with what changed#

Use it after the client has asked for changes and you have a new version ready.

Subject: [Project]: version [2] of [what it is], ready for approval

Hi [Name],

Thanks for your notes on version [1]. Version [2] is here: [link]

What changed:

• [Darker navy for print, as you asked]
• [The logo misuse page now shows the minimum size]

Nothing else has moved since version [1].

As this is a new version, it needs your decision again, even where you'd already said yes to parts of the last one.

Could you decide by [day, date]?

Thanks, [Your name]

Why it works: the list of changes lets the client check only what moved, which is faster for them and less likely to start a new conversation about something that was fine. Asking for a decision on the whole version keeps the approval tied to the exact file you'll ship, not to a memory of an earlier one.

3. A friendly reminder before the due date#

Use it the day before the decision is due.

Subject: Reminder: [what it is] needs your approval by tomorrow

Hi [Name],

A quick reminder that [what it is] is due for your decision tomorrow, [day, date]. Here's the link again: [link]

If you need longer, tell me which date works and I'll plan around it.

Thanks, [Your name]

Why it works: it arrives while there's still time to act, carries the link so nobody hunts for the first email, and offers a way out. A client who can't make the date will usually tell you a real one, which beats silence.

4. An overdue follow-up#

Use it the day after the due date, and again a few days later if you still have nothing.

Subject: [What it is]: still waiting on your decision (due [date])

Hi [Name],

[What it is] was due for your approval on [date], and we don't have a decision yet. Here's the link: [link]

While it's open, [the next step, e.g. booking the printer] is on hold. If we have your decision by [new date], we can still [make the launch on [date]].

If someone else should be making this call, tell me who and I'll send it to them.

Thanks, [Your name]

Why it works: it states the consequence plainly, without blame, and gives a new date that still works. The last line catches a common cause of silence: the email reached someone who doesn't feel it's their decision to make.

5. Confirming sign-off and next steps#

Use it as soon as the approval comes in.

Subject: Approved: [what it is], version [2]

Hi [Name],

Thanks for approving version [2] of [what it is] on [date]. That's the version we'll use from here: [link or file name].

Next: [we send it to print on [date] / we start building the pages this week].

If anything needs to change from here, it becomes a new round, and I'll let you know first if it affects the timing or the cost.

Thanks, [Your name]

Why it works: it records which version was approved and when, in words the client has seen. It tells them what happens next, and it draws a line: a change after sign-off is new work, agreed before it starts.

6. Handling "approve with changes"#

Use it when the client says yes, with a few small fixes.

Subject: [What it is]: approved with your changes

Hi [Name],

Thanks for approving [what it is]. Here's what we'll change before it goes out:

• [Swap the hero photo for the one from the March shoot]
• [Correct the phone number on page 4]

We'll make these without asking you to approve again, unless [you'd like to see it first / anything turns out bigger than it looks]. If I've misread any of them, tell me by [day].

Thanks, [Your name]

Why it works: an approval with changes is a yes, and treating it as a no wastes a round. The risk is a misread, so you write the changes back in your own words and give the client a day to correct you. Agreeing up front whether they'll see it again saves an awkward email later.

Why one link and one due date do most of the work#

Look back over the six templates and two things carry most of the weight.

One link#

An attachment splits the work from the decision. The client downloads it, replies from their phone, forwards it to a colleague, and now there are three copies and a "yes" that could mean any of them. A single link to the version being decided keeps the file, the feedback and the answer together. The reminder and the chaser then point at the same thing as the first ask.

One due date#

"When you get a chance" means "after everything else". A date gives the client a reason to open it this week, and gives you a fair point at which to follow up. Without one, a reminder feels like nagging. With one, it's simply the plan. The date should be a calendar day, with the reason it matters written next to it.

The rest (who decides, what's settled, what changed) makes the answer one you can act on. There's more on the shape of the whole process in client approvals without the email chain.

How Skybase sends the ask, the reminders and the link for you#

In Skybase, most of these emails write themselves from the approval request. You keep the judgement; the app does the sending and the chasing.

The ask (template 1)#

On the job's Files tab, select the files and choose Ask for approval, then name the approvers: anyone on the project except you, client guests included. Choose Everyone must approve or Any one approver, set a due date, and write the brief under What should they look at?. That brief is where the open questions and the settled points from template 1 go. Each approver gets an email with the brief, the due date and their own secure link, which opens the review without signing in or a password. Clients join the project once as a single-project guest, which is free.

The decision#

The review offers three answers: Approve, Approve with changes and Request changes. The last two need a note, so a "no" always says what to change. Each person decides once per version, and Skybase records who decided, when and how.

A new version (template 2)#

Choose New version, add the files and write what changed. Everyone is asked again, the note goes into their email, and the earlier version keeps its files and decisions.

Reminders and chasers (templates 3 and 4)#

With a due date set, the people still to decide are reminded the day before, on the day, and one and three days after it's overdue, at 9am in each person's own time zone. You're told once, the day after it goes overdue. If you want to prompt them sooner, Nudge reminds the people still to decide, at most once a day.

That leaves templates 5 and 6 as yours to send. The record of the sign-off is already in Skybase, but a short personal note about next steps, or about exactly which changes you'll make, is still worth writing yourself.

A worked example at Harbour Studio#

Take a small studio, say Harbour Studio, rebranding a client called Northwind. Leo, a designer, has "Brand guidelines v3" ready for Tom Becker, Northwind's contact.

Leo asks for approval with a due date and a brief that is template 1 cut down: "Please look at the colour ratios and the logo misuse page. The typefaces are settled." The day before the due date Tom is reminded, and Leo writes nothing.

Tom chooses Request changes with a note: "Darker navy for print, please." Leo adds Deep Harbour (#0B2545) and uploads a new version with the note "Added Deep Harbour (#0B2545) to the secondary palette for print". That's template 2, written once. Tom approves, and Leo sends his own short version of template 5: approved on the day, off to the printer on Thursday.

If you're still choosing a tool for this, how to choose client approval software sets out what to look for, and the design approval software page shows how Skybase handles the files themselves.

A short checklist before you press send#

• One link to the version being decided.
• The three answers you'll accept.
• What to look at, and what's settled.
• Who decides, and whether one yes is enough.
• A due date, with the reason it matters.
• For a new version: what changed, and that it needs a decision again.

Want the reminders and the record without writing them? See how approvals work in Skybase.