Skip to content

Data Export and Account Deletion Emails Done Right

Export-ready notices, deletion warnings and final confirmations are the last emails a customer gets from you. How to write them so nothing is lost by surprise.

Koltrix Team5 min read
Stacked cardboard moving boxes and houseplants in a room
Photo by Dina Badamshina on Unsplash
On this page(7 sections)
  1. Why these emails deserve care
  2. Email 1: Your export is ready
  3. Email 2: The deletion warning
  4. State the timer in plain terms
  5. Send more than one warning
  6. Give two clear ways out
  7. Consider who else should hear
  8. Email 3: Deletion confirmation
  9. Practical details that prevent disasters
  10. A quick checklist
  11. Key takeaways

The emails a SaaS product sends at the end of a relationship get less attention than any others, and they carry the highest stakes. A missed "your data will be deleted in 7 days" warning can cost a former customer years of records, and it'll cost you whatever goodwill was left.

This post covers the three end-of-life emails most products need: the export-ready notice, the deletion warning, and the deletion confirmation. It's practical guidance, not legal advice. Retention and deletion obligations vary by jurisdiction and contract, so check yours with counsel.

Why these emails deserve care

Most transactional email is about something the user just did. End-of-life email is often about something that's going to happen to them, on a timer they may have forgotten about. That changes the writing:

  • The reader may not be paying attention. They may have stopped using the product months ago.
  • The consequences are permanent. A deleted account usually can't be restored.
  • The recipient may have changed. The person who signed up may have left the company, and the address might bounce or land with someone new.

So these emails need to be unmissable, specific and boring in the best sense: dates, actions and nothing else.

Email 1: Your export is ready

Exports are often generated asynchronously, because zipping up a large account takes time. The email that announces the finished file should contain:

  • What's in it. "All projects, comments and attachments as of 14:02 UTC on March 3" is better than "your data."
  • The format. CSV, JSON, MBOX, ZIP. Say which, and briefly how to open it.
  • An expiring, authenticated link. Don't attach the archive to the email. Link to a download that requires the user to be signed in, or that uses a long random token and expires.
  • When the link expires. State the date and time, with a time zone.
  • What to do if it expires. Usually: request a new export from settings.

A plain version:

Subject: Your Fieldnote export is ready (link expires Mar 10)

Your export of the "Operations" workspace is ready to download.

Includes: all notes, comments and attachments as of
Mar 3, 14:02 UTC. Format: ZIP containing JSON files and
the original attachments.

[Download export]

This link expires on Mar 10 at 14:02 UTC. After that you can
request a new export from Settings > Data.

Didn't request this? Reply to this email and we'll look into it.

Fieldnote is a made-up product. Note the last line. An export is a copy of everything in the account, and an unexpected export request can be a sign of a compromised login. Make it easy to report.

Email 2: The deletion warning

This is the email that matters most, and the one most often sent once, late, from an address nobody recognizes.

State the timer in plain terms

Customers should never have to work out from your terms of service when their data disappears. Say it directly in the email, with dates. A good model is to describe the whole sequence up front, so each email is a reminder of something already explained rather than a surprise.

We try to do this ourselves. When a Koltrix trial ends without a plan, the workspace becomes read-only after 7 days: mail still arrives and everything stays readable and exportable, but sending, the API and SMTP pause. If it's still unpaid 30 days after that, the data is deleted, after three warning emails. Customers can disagree with the timers, but they can't say they weren't told.

Send more than one warning

A single warning is fragile: it can land in spam, arrive during a vacation, or go to someone who's left. A sequence works better:

Warning Timing (example) Main message
First When the account enters the grace period What happened, the deletion date, how to keep the data
Second About halfway through Same facts, shorter, with the export link
Final A few days before deletion "Last notice" in the subject, exact date and time

Pick timings that suit your grace period. The structure matters more than the exact days.

Give two clear ways out

Every warning should offer both options a customer might want:

  1. Keep the account, by reactivating, paying an invoice or signing in, depending on why deletion is scheduled.
  2. Leave with the data, by downloading an export.

Hiding the export option to push reactivation is short-sighted. A customer who got their data out cleanly may come back. One who lost it won't, and will say so publicly.

Consider who else should hear

If the account has more than one admin, send the warnings to all of them, not just the original signup address. People leave companies; their accounts don't always follow.

Email 3: Deletion confirmation

After deletion, send a short confirmation:

  • What was deleted, and when.
  • What wasn't, if anything. For example, invoices you're legally required to keep, or anonymized usage statistics. Be honest here; don't claim everything is gone if it isn't.
  • That it can't be undone, if that's true.
  • How to start again, in one line, without a sales pitch.

For deletions the user requested themselves, the same email doubles as a receipt for their request. For privacy requests in particular, keep a record of when the request arrived and when it was completed, because you may need to show it later.

Practical details that prevent disasters

  • Send from a replyable address. "Wait, don't delete it, we just forgot to pay" is exactly the reply you want to receive.
  • Use a clear sender name and consistent subject format so warnings are recognizable and searchable.
  • Never put the data itself in email. Links, not attachments.
  • Respect suppression, but think about it. If the address bounces, the warning didn't land. Try another admin address if you have one.
  • Make the timers configurable internally so staging can test the full sequence in minutes instead of weeks.
  • Log every warning sent, with the address and result, so support can answer "we never got a warning" with facts.
  • Test the export link from a different device before shipping the feature. Expired or broken export links are a common source of angry tickets.

A quick checklist

  • Export emails state contents, format, link expiry and how to re-request
  • Export links are authenticated or long random tokens, and they expire
  • Deletion timeline explained in plain words before the first warning
  • At least two warnings plus a final notice, each with exact dates
  • Every warning offers both "keep it" and "export it"
  • Warnings go to all admins, not only the signup address
  • Confirmation says what was deleted and what was retained
  • Every send is logged for support

Key takeaways

  • End-of-life emails are rare but irreversible in effect, so they need dates, actions and nothing else.
  • Explain the full deletion timeline up front, then send several warnings rather than one.
  • Always offer an export alongside reactivation; customers who leave cleanly are more likely to return.
  • Link to data, never attach it, and log every warning you send.

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.

SharePost on XLinkedIn