Twelve Transactional E-mails Every SaaS Needs
by Sebastien Mirolo on Wed, 13 Jul 2022You have decided to launch your SaaS product and are looking forward to subscribers signing up with their credit card. Congratulations! Let's now see the transactional e-mails your customers will be expecting.
Access Control Notifications
The first category of transactional notifications relates to user accounts management.
These includes verification of the communication channel, typically through a round-trip and a secret identification code, example:
- Website sends a code to e-mail address on file
- User clicks on link in e-mail and/or enter code in e-mail into Website
- Website marks e-mail address as verified.
1. E-mail verification
To: user
This notification is sent to the user account to verify their e-mail address (see example).
Some communication - like password resets - should not be sent unless the communication channel has been previously verified.
Frictionless registration often leads to sign-ups by bots. Account activation and e-mail verification before a accessing more sensitive pages can be a good balance between building smooth onboarding and cutting down on nefarious sign-up bots.
2. Password reset
To: user
This notification is sent to a user that has requested to reset their password through a "forgot password?" link. (see example).
It is very likely you will have to implement some kind of account recovery workflow. Forgotten password is very near the top of any teams supporting a SaaS product.
3. One-time login code (MFA)
To: user
This notification is sent to a user every time they login. It contains a one-time login code they must copy/paste into an input field during the login workflow. (see example).
Many products will sent a one-time code to a secondary communication channel (like a phone number) but sending a one-time code to the primary channel (e-mail) is no less secure when users are accessing the product on their mobile phone anyway.
Unless you run a pure consumer SaaS product - even so, you might still end-up with parents wanted to manage their children accounts - you will need to implement role requests and grants.
4. Role granted
To: user, Bcc: profile managers
This notification is sent to the user when a profile manager has granted a role of the profile to that user. (see example).
5. Role grant accepted
To: profile managers
This notification is sent to profile managers in response to a user accepting a role on the profile. This e-mails are only sent for roles requiring a double opt-in.
6. Role requested
To: profile primary contact
This notification is sent to the primary contact for a profile when a user has requested a role on that profile. (see example).
Sometimes a profile manager will invite a user to have a role on a profile and the user would already be registered in the product under a different e-mail address. This happens quite often in marketplaces that have customers hiring a significant amount of freelancers (ex: GitHub).
Cross-teams knowledge-based systems also deal with role requests. For example, a Sales person might be directed to a third-party Website as part of a Bid process to respond to Environmental Social and Governance (ESG) questions. It is highly likely the Sales person's company Sustainability Officer has already answered those questions as part of previous bids and/or annual surveys. So the Sales person needs to be linked to a read-only version of the company profile on that third-party Website. She will do so by generating a role request.
7. Profile updated
To: profile managers
This notification is sent to profile managers when contact information are updated. (see example).
This purely informative notification is useful to detect suspicious activity on a profile, thus starting potential breach investigation sooner rather than later.
Billing Notifications
Unless your SaaS products is supported through grants and/or big ticket customers that cut you a check, you will most likely implement a "pay with credit card" option.
Quite a few notifications are linked to payment processing and credit card management, especially when you are dealing with recurring payments.
8. Charge receipt
To: profile primary contact
This notification is sent when a charge is created on a credit card. It is also sent when the charge is refunded. (see example).
There is more than meets the eye in the elements that make a good receipt.
9. Order confirmation
To: profile primary contact
This notification is sent when an order has been confirmed but a charge has not been successfully processed yet. (see example).
A few SaaS products have an off-line payment step (ex: checks, wire transfer) so a invoice notification is necessary.
SaaS are a service business typically involving recurring payments with very low ongoing costs to deliver that service to a specific subscriber. It is thus often best for a SaaS business to grant access to the product first and recover payment later. Most SaaS thus at term always manage a customer billing cycle as a monthly statement with balance credit for services paid in advance and balance due for late payment.
10. Card updated
To: profile primary contact, Bcc: profile managers
This notification is sent when a credit card on file is updated. (see example).
This purely informative notification is useful to detect suspicious activity on a profile, thus starting potential breach investigation sooner rather than later.
11. Renewal failed
To: profile primary contact Bcc: profile managers
This notification is sent when a renewal charge failed. (see example).
This is opportunity for the customer to update the card on file and/or make sure there is enough money in their account.
12. Card expires soon
To: profile primary contact Bcc: profile managers
This notification is sent when a card on file is about to expire. (see example).
This is opportunity for the customer to update the card on file before the next billing cycle leads to a card denied.
Bonus: Subscription Notifications
Many SaaS products conflate subscriptions and billing, using the terms interchangeably. There are quite a few businesses that benefit to keep both concept separate (ex: gym memberships, co-working spaces, etc.) either because billing often happens offline and/or space is limited and thus need to be allocated before a subscription is granted.
Quite a few notifications are linked to payment processing and credit card management, especially when you are dealing with recurring payments.
13. Subscription expires soon
To: profile primary contact
This notification is sent when a subscription is about to expire. (see example).
Some subscriptions might not be set on auto-renew. This happens in SaaS products providing training and professional certifications. Those typically require a user to read updated content and re-take a certification exam.
Auto-renew can also be turned off for trial periods. In such case, these notifications are an opportunity to nudge users to upgrade to a paid plan.
14. Subscription grant created
To: profile primary contact
This notification is sent when a subscription is granted (see example).
15. Subscription grant accepted
To: profile primary contact
This notification is sent when a granted subscription was accepted (see example).
16. Subscription request created
To: profile primary contact
This notification is sent when a subscription request is created (see example).
17. Subscription request accepted
To: profile primary contact
This notification is sent when a requested subscription was accepted (see example).
18. Claim code generated
To: profile primary contact
This notification is sent sent to notify a user that a third-party has paid for their subscription on the site as part of GroupBuy checkout workflow. (see example).
More to read
If you are looking for related posts, elements that make a good receipt and Payment screens and the checkout pipeline are good reads.
More business lessons we learned running a SaaS application hosting platform are also available on the DjaoDjin blog. For our fellow engineers, there are in-depth technical posts available.