How do I write a polite approval reminder email?
Name the exact version, the decision you need and the date it affects, then make replying easy. Follow up at a calm pace and never treat silence as approval.
Why approval requests stall
Most clients do not ignore approval requests on purpose. The email arrives during a busy week, the decision looks bigger than it is, or it is unclear what they are being asked to do. A reminder that only says “just a gentle follow up” repeats the same problem politely.
A good approval reminder email fixes the request itself. It tells the reader which file or version to look at, what answer you need and what happens to the schedule while you wait. The tone can stay friendly because the content is doing the work.
Sometimes the delay is a signal. The reviewer may be waiting on someone else, may disagree with the direction or may not be the right person to decide. A specific reminder surfaces those problems sooner, because it invites a specific answer instead of another “will look soon.”
Make the request answerable
Before you write a reminder, check that the original request was clear. If it was vague, the follow-up is your chance to repair it. Every request for approval should cover four points.
- The exact version: a link and a label, such as “homepage design, version 3.”
- The decision: approve as is, or send consolidated revision notes.
- The date: when you need an answer and which milestone depends on it.
- The person: who you are asking, if several people are copied.
Write a clear first request
Use a subject line that names the item and the action, such as “Approval needed: homepage design v3 by May 22.” The reader should know what the email wants before opening it.
Lead with the decision, not with an apology for interrupting. Use the active voice so it is obvious who needs to do what. Plain-language guidance from the US government makes the same point: active voice removes ambiguity about responsibilities.
Example: “Hi John, version 3 of the homepage design is ready for your review at the link below. Could you approve it, or send any revision notes, by Thursday, May 22? That keeps the build on track to start Monday. This is the second of the two feedback rounds in our quote. Thanks, Emi”
That email names the version, the decision, the deadline and the consequence in four sentences. John can answer it without opening another thread to work out what is being asked.
Time your follow-ups
Pace reminders around the deadline you gave, not around your impatience. For most small projects, a sensible rhythm is a gentle follow-up one or two business days before the deadline, then a final follow-up one or two business days after it passes. Adjust for the client’s known schedule, holidays and time zone.
Give enough time for a real review. A one-page design may need a day or two; a full website or a long document may need a week. If you set a short deadline, explain why, such as a booked developer or a launch date. A reason makes the date feel fair rather than arbitrary, and it helps the client tell you early if the date will not work.
Keep each message in the same thread so the history stays together. If the reviewer has changed, or you learn someone is away, ask who can make the decision instead of repeating the request to an empty inbox.
Stop after the final follow-up. More emails rarely help once the schedule effect is stated. Switch channels instead: a short call, a message to the project contact you agreed at kickoff or a note in your next scheduled check-in. Then wait for an actual answer before moving the work forward.
Use gentle and final follow-up examples
A gentle follow-up should be short and self-contained. Repeat the essentials so the reader does not need to scroll back.
Gentle follow-up example: “Hi John, a quick reminder that homepage design version 3 is waiting for your approval or revision notes. If Thursday no longer works, just tell me a new date and I will adjust the build start. Here is the link again. Thanks, Emi”
A final follow-up after no response states the effect on the schedule plainly, without blame. It should also offer a simple way to pause.
Final follow-up example: “Hi John, I have not received a decision on homepage design version 3, so the build cannot start Monday as planned. I will hold the build until you approve or send notes, and I will share a revised timeline once I hear from you. If a short call would help, I am free Tuesday or Wednesday afternoon. Thanks, Emi”
What not to do in an approval reminder
Do not write “if I do not hear back by Friday, I will assume you approve.” Silence is not acceptance, and treating it that way creates a record that the client never actually agreed to. If you need a decision, keep asking for one and adjust the schedule while you wait.
Do not reword the request into a different question. If a newer version replaces the one under review, say so and send the new link, rather than letting an old approval carry over. Do not bundle a price change into a reminder about design feedback either; a change in scope deserves its own clear proposal and its own decision.
Avoid guilt and urgency you cannot justify. “Just checking in again!!” adds pressure without information. A calm, specific reminder is easier to answer and keeps the relationship intact.
When the approval finally arrives, confirm it in one line: “Thanks, John. Recording your approval of homepage design version 3 today; the build starts Monday.” That short reply closes the loop and gives both of you a dated record of what was approved. Then supersede any older review requests so nobody acts on a stale link.
How Moolamochi handles approval requests
In Moolamochi, delivery approval applies to the current published version, and a stale version cannot be approved as if it were current. A revision acknowledgement confirms receipt only; it never accepts delivery or creates a priced change. Commercial approval of scope stays separate from delivery review, and only the designated client approver can accept or reject a scope proposal in the portal. New accounts are currently waitlist-only.
Primary-source references
External providers maintain their own requirements; consult the linked documentation for their current details.
