KoltrixSunsetting a Feature: The Email Sequence Customers Deserve
Removing a feature people use is a trust test. Who to email, when to send each message, what to say, and how to handle the angry replies that will arrive.
On this page(9 sections)
Every product eventually removes something. A legacy integration that costs more to maintain than it earns, a report three customers use, an export format nobody has touched since the redesign. The engineering part is usually easy. The part that decides whether customers trust you afterward is how you tell them.
A sunset done badly feels like a rug pull. Done well, most affected customers will barely remember it, and a few will thank you for the warning.
Start with who actually uses it
The most common mistake is announcing a sunset to everyone. Most of your customers have never touched the feature, and an email saying "we're removing X" makes them wonder whether they should worry, which creates support tickets from people who aren't affected.
Pull usage data before writing anything:
- Active users: used the feature in the last 30 to 90 days. They get the full sequence.
- Lapsed users: used it once, long ago. They get the announcement and the final notice.
- Everyone else: a line in your regular product update is enough, if you mention it at all.
For B2B products, identify the account admin as well as the individual users. The person who set up an integration often isn't the person who depends on its output every Monday.
The timeline
How much notice you give depends on how painful the change is. Removing a cosmetic option needs a couple of weeks. Removing an integration that feeds a customer's accounting system needs months. A rough guide:
| Impact on the customer | Minimum notice | Emails |
|---|---|---|
| Cosmetic or rarely used | 2 to 4 weeks | Announcement, final notice |
| Workflow change with a clear replacement | 6 to 8 weeks | Announcement, reminder, final notice, after |
| Data or integration loss | 3 months or more | Announcement, two reminders, final notice, after |
If a customer's contract or your own terms promise a notice period, that is the floor, not the target.
Email one: the announcement
This email does the most work, so it carries the most information. It should answer, in this order:
- What is changing, named exactly as it appears in the product.
- When, as a specific date, not "in the coming months".
- Why, in one or two honest sentences. "Fewer than a handful of accounts use it and maintaining it slows down work on things more of you asked for" is better than vague talk about streamlining.
- What to do instead, with a link to the replacement or a migration guide.
- What happens to their data, and how to export it before the date.
- How to get help, ideally by replying to the email.
Sample:
Subject: The legacy CSV export is going away on November 14
Hi Sam,
You've used the legacy CSV export in the last month, so we wanted you to hear this directly: we're removing it on November 14.
The new export (Reports → Export) covers the same fields and adds date filtering. If your workflow depends on the old column order, this guide shows how to match it: [link].
Your existing files aren't affected, and nothing changes before the 14th.
If the new export doesn't cover something you rely on, reply to this email. A person on our team reads every reply, and we'd rather hear about a gap now than after the date.
Notice what's missing: no marketing, no "exciting changes", no other announcements bundled in.
Email two: the reminder
Send it roughly halfway through the notice period, only to people who are still using the old feature. Anyone who has already migrated should drop out of the sequence, so this list should be shorter than the first one.
Keep it short. Restate the date, link the replacement, and include something new: a common question from the first round of replies, or a note that you added a missing field to the replacement because someone asked.
Email three: the final notice
One week before, sometimes again a day or two before for high-impact changes. This email is blunt about timing: "The legacy export stops working next Thursday." Repeat the export instructions. If there is anything a customer must do to avoid losing data, make it the first sentence.
Email four: after the change
Often skipped, and worth sending. A brief note to the people who were affected, confirming that the change happened, where things now live, and how to get help if something broke. It closes the loop and catches the customers who ignored all three earlier emails and are about to discover the change on their own.
Handling the replies
Some replies will be angry, and some of that anger will be fair. A customer built a process around something you gave them, and now you're taking it away. A few principles:
- Answer quickly and personally. A reply from a real person within a day calms more situations than any amount of careful wording in the announcement.
- Don't argue about the decision. Acknowledge the disruption, explain the replacement, and offer concrete help.
- Look for patterns. If several customers raise the same missing capability, that is a gap in the replacement. Fixing it before the date is often cheaper than losing those accounts.
- Have a short list of exceptions in mind. For your largest or most affected customers, a short extension or a hands-on migration call may be worth it. Decide this before the announcement, so whoever answers replies knows what they can offer.
Make sure replies go somewhere the whole team can see. A sunset sent from a noreply@ address, or replies routed to one person's inbox, guarantees that some of the most important feedback will be missed. If your product email already goes through a provider that threads replies back into a shared inbox, use that path. If not, set the Reply-To to a monitored shared address for this sequence.
A pre-send checklist
- Usage data pulled; recipient lists split by active and lapsed users
- Specific removal date chosen and checked against contractual notice periods
- Replacement or migration guide published and linked
- Data export instructions tested end to end
- Exceptions policy decided and shared with whoever answers replies
- Migrated users automatically removed from later emails
- Reply-To set to a monitored, shared address
- Help docs and in-app copy updated on the removal date
Bottom line
Only email the people who actually use the feature, give them a real date and a real replacement, and keep them informed until after the switch is done. Then read every reply. A sunset is one of the few times customers will tell you exactly how they use your product, and your next roadmap can use that information.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
