Send "did you know" emails based on features users haven't tried

Most SaaS products have features that would save a customer real time, yet the customer never finds them. A “did you know” email spots a user doing something the hard way and shows them the feature built for it. It fits products with more depth than a new user sees in the first week, and it works best once you have event tracking on your key features.

Why it works

Customers who use more of a product tend to get more value from it and have more reasons to stay. Each adopted feature adds another workflow that would be painful to rebuild somewhere else. The trouble is that people learn just enough to get by and then stop exploring.

A behaviour-based email works because it is specific. “You exported 12 reports by hand this month. Scheduled reports can send them for you” speaks to something the reader did last week. A generic feature tour asks them to imagine a problem. A tip that names their own behaviour asks them to fix one they already have.

How to do it

1. List your sticky features. Pick features that solve a recurring job and that retained customers use more than churned ones. Your product analytics can show which features separate the two groups.
2. Map each feature to a “slow way” signal. For scheduled reports, the signal might be repeated manual exports. For templates, it might be creating similar projects from scratch. For integrations, it might be importing CSVs every week.
3. Build one segment per feature. The segment is users who show the slow-way signal and have never used the feature. Exclude anyone who used it, even once.
4. Write short, plain emails. Use one subject line that names the job, two or three sentences on how the feature helps, one screenshot or GIF, and one button. Send from a real person on the product or success team.
5. Deep link to the setup screen. The button should open the feature with the user’s data ready, such as the report they export most often already selected.
6. Space the emails out. Allow only one feature email per user in a set window, and choose the feature with the strongest signal first.
7. Stop on adoption. As soon as the user tries the feature, remove them from that segment and suppress any follow-up.
8. Test against a holdout. Keep a small group who never get the email so you can see whether adoption came from the email or would have happened anyway.

Example

A hypothetical B2B scheduling tool sees that many team admins add new staff one at a time through a form, while a bulk CSV import sits unused. It builds a segment of admins who added five or more users individually in the past month and have never opened the import screen. They get an email with the subject “Adding your team one by one?” and a button that opens the import screen with a template file ready to download. Admins who use the import stop receiving the email, and the team compares import adoption and 90-day retention against a holdout group.

Metrics to track

• Feature adoption rate per email. The share of recipients who use the feature within 14 days, compared with the holdout group.
• Repeat use. The share of adopters still using the feature a month later. One try followed by nothing suggests the feature did not fit their need.
• Retention of adopters. Compare churn or renewal rates for accounts that adopted the feature after an email against similar accounts that did not.
• Unsubscribe rate on product emails. Should stay low. A rise means emails feel frequent or irrelevant.

When it backfires

• Emailing about features people already use. Bad data, such as tracking that misses mobile usage, makes you look careless. Check the event before you build the segment.
• Pushing paid features as tips. If the “did you know” email ends at an upgrade wall, readers learn to treat every tip as a sales pitch. Label upsells clearly or keep them separate.
• Too many at once. A run of feature emails in one week reads like a newsletter that nobody signed up for.
• Features that are hard to set up. If the feature needs an hour of configuration, an email alone will not get it adopted. Offer a short call or a guided setup instead.

Questions people ask

How often should feature emails go out?

Keep it occasional, for example one every week or two at most per user, and pause them while a user is in a sales or support conversation. Each one should read like a single useful tip.

Should these emails go to every user or only admins?

Send them to the person who would actually use the feature. Admin features such as permissions or billing exports go to admins, and workflow features go to the people doing the work.

Can in-app messages replace these emails?

In-app tips reach people who are already logged in. Emails reach people who have drifted away. Most teams use both, with the email as the backup when the in-app tip was not seen.