templates Customer Winback Email Templates
A winback email that opens with a discount usually solves the wrong problem. Most churned customers left for a reason that is not price. The templates below are organized by the actual likely reason and the pitch that addresses it.
last updated 2026-08-13 5 templates
implementation note
Replace variables before sending, keep one primary action per email, and connect each template to a specific trigger rather than a generic drip schedule.
subject
Requested feature is live
preview
A specific change since you left.
body
Hi {{first_name}},
When you left {{ProductName}}, you mentioned {{feature_request}}.
The feature is now live: {{feature_link}}.
If it sounds like the right time to come back: {{reactivation_url}}.
{{Founder name}} variables
{{first_name}}{{ProductName}}{{feature_request}}{{feature_link}}{{reactivation_url}}{{Founder name}}
mistakes to avoid
- ›Sending this without the actual feature request data on file.
- ›Generic comeback framing.
subject
A leaner plan for {{ProductName}}
preview
No tricks, just smaller.
body
Hi {{first_name}},
When you cancelled, price was the reason.
A leaner {{new_lower_plan}} plan is now available at {{price}} and covers {{covered_use_case}}. If that fits, here is a clean reactivation link: {{reactivation_url}}.
If the answer is still no, no worries.
{{Founder name}} variables
{{first_name}}{{ProductName}}{{new_lower_plan}}{{price}}{{covered_use_case}}{{reactivation_url}}{{Founder name}}
mistakes to avoid
- ›Discount in the subject line.
- ›A guilt trip for cancelling.
subject
A better path through {{ProductName}}
preview
A simpler walkthrough.
body
Hi {{first_name}},
Fair point that onboarding got in the way the first time. The rebuilt version is here: {{onboarding_link}}.
If a 15-minute walkthrough is easier: {{calendar_link}}.
{{Founder name}} variables
{{first_name}}{{ProductName}}{{onboarding_link}}{{calendar_link}}{{Founder name}}
mistakes to avoid
- ›Pretending the original onboarding was fine.
subject
Heads up, in case it is useful again
preview
No pressure.
body
Hi {{first_name}},
You used {{ProductName}} for {{prior_use_case}}.
Most teams in your space now also use it for {{new_use_case}}, added since your account went inactive: {{feature_link}}.
Not a pitch, just keeping the thread current. Reactivation is one click if useful: {{reactivation_url}}.
{{Founder name}} variables
{{first_name}}{{ProductName}}{{prior_use_case}}{{new_use_case}}{{feature_link}}{{reactivation_url}}{{Founder name}}
mistakes to avoid
- ›Pretending the user is still in the same shape.
subject
A few things changed at {{ProductName}}
preview
A short list of changes since you left.
body
Hi {{first_name}},
A few things changed since you cancelled {{ProductName}}:
- {{change_1}}
- {{change_2}}
- {{change_3}}
If any of those fix what made you leave, reactivation is here: {{reactivation_url}}.
Reply if you want to talk through it.
{{Founder name}} variables
{{first_name}}{{ProductName}}{{change_1}}{{change_2}}{{change_3}}{{reactivation_url}}{{Founder name}}
mistakes to avoid
- ›Sending this on a regular schedule. Use only when there is something real to say.
reading this as developers picking email infrastructure
The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.
Applied to customer winback email templates, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.