What’s New widget vs. email digest — use both, for different jobs
In-app widgets catch people who never open email. Digests catch people who asked. How to split SaaS update communication without spamming either channel.
Teams pick a side. Either they hammer a monthly newsletter until it is ignored, or they ship an in-app badge and assume everyone will click it. Both channels work. They work for different people, at different times, with different costs if you get them wrong.
What the widget is for
A What’s New widget lives in the product. It has an unread count. It is the right tool for the customer who is already logged in and will never open “Product updates — April.” The job is interrupt-light: a badge, a short list, a link to the full timeline.
Constraints that make widgets work:
- Short entries. Titles and a two-line excerpt. The full markdown belongs on the hosted page.
- Isolation. Shadow DOM (or equivalent) so your marketing CSS does not restyle the popup, and the popup does not restyle the app.
- Brand color. One accent so it feels native without a design project.
- Honest unread state. Reset when they open it. Do not badge-bomb after every typo fix.
The widget is a discovery surface, not an archive. Search, filters, and a year of history live on the public changelog.
What email is for
Email is for people who opted in, and for changes they might not see if they skip the app for a week. Breaking changes, migrations, and billing updates belong here. Feature tours usually do not — unless the subscriber asked for that stream.
A digest should be a list of permalinks back to the canonical notes, not a second prose version. The moment the email and the changelog diverge, support has two sources of truth.
Never dump the whole customer list into “updates.” That is how unsubscribes happen and how the next breaking-change email gets filtered. Subscribe is a checkbox on the changelog, not a default.
A simple split
| Job | Widget | |
|---|---|---|
| “What shipped since I last opened the app?” | Yes | No |
| “I’m away for two weeks, ping me.” | No | Yes, if they subscribed |
| Breaking change | Yes | Yes |
| Tiny copy fix | No (or batch) | No |
| Sales / security audit | Link out to /c/slug |
Optional forward |
If you only have time for one, install the widget. It is closer to the work. Add email when the subscriber box has a reason to exist.
Slack is not a customer channel
Posting releases into your own #shipping channel is excellent internal hygiene. It is not customer communication. Pull the same REST feed your widget uses so the internal post cannot drift from the public note. Customers should get the widget, the page, and maybe an email — not an invite to your Slack.
Implementation that stays small
You do not need a CDP to do this. Publish markdown with a version. Host the timeline. Embed a script tag. Let the public JSON feed drive a worker that posts to Slack or to your own webhook. Let subscribe capture emails for the people who want a digest.
A practical default for a five-person SaaS: widget always on, email only for breaking changes plus a monthly digest if you have more than a handful of subscribers, Slack for the internal shipping channel. Review the split once a quarter. If the digest open rate dies, shorten it. If the badge is ignored, your titles are probably still written for engineers.
The mistake is treating “customer communication” as a single blast. The widget catches presence. Email catches absence. The changelog catches everyone else, including the buyer who was not even a user yet. Use each one for that job and you will stop arguing about which channel is “the” channel.