A Product Manager’s Guide to Email Notifications & App-Generated Emails

I recently met up with an old friend who’s the product manager of a growing SaaS application.

Like a lot of product teams, hers approaches app notifications as a core feature of their product platform. However, they’ve been handling the different types of emails their app sends (ranging from onboarding messages to password resets) in a somewhat ad-hoc fashion. Some of those emails were being sent using a marketing-centric tool, others inflexibly hard-coded into the app.

That disconnect was frustrating to her—it resulted in an inconsistent user experience for her customers. It also meant she wasn’t really sure when (or if) they were delivered, and her team had limited visibility into how different sorts of messages affected user engagement.

So, my friend was excited about a new project they were undertaking to bring all of those emails into a shared infrastructure service similar to how they treated other forms of notifications. That was one of the reasons we were talking—she was looking to learn from the experiences of other product teams.

Email Is Essential to Growing SaaS Applications

In that, she isn’t alone. Email is essential to growing SaaS applications. The emails they send are indispensable tools for driving user activity, building trust, and nurturing long-term engagement. But sometimes hard to know where to begin.

That’s why the email experts at SparkPost created a guide to help product teams get started with email notifications and other app-generated emails. It provides a great foundation for teams building fast-growing services to make the most of email in their products.

It’s called (very creatively) “The Product Manager’s Guide to Email.” Check it out and send us a tweet, and let me know what you think. I’d love to hear what kinds of questions your team has about email notifications and other kinds of app-generated emails.

Brent

Why Are Subject Lines Important?

The average person receives a lot of emails every day. The Radicati Group said in a February 2017 report that it expects 269 billion business and consumer emails to be sent and received per day in 2017, with 3.7 billion email users worldwide.

Even when you eliminate the spam, that’s still a large number of emails hitting your users’ inboxes each day. Many of those messages will be of the transactional or notification variety, such as when someone makes a purchase or changes their password.

While notifications and transactional emails tend to have significantly higher open rates than newsletters and other commercial messages, it’s still important to pay close attention to the subject lines you use. After all, putting careful thought into the writing and design of the message inside doesn’t do much good if people don’t click to open it. That’s particularly true for notification emails that recipients didn’t necessarily ask for but which are designed to increase engagement, such as those “Your profile isn’t 100% complete” and “See who liked your post” kinds of messages.

Time To Get Started

Before you begin, take some time to review your user profile. Who are they? What are they likely doing when they receive your transactional or notification email? How do they feel at that moment? What will prompt them to open your message now, instead of one of many other unopened emails?

Keep the answers to those questions in mind as you read these 5 tips to help you write effective subject lines.

Personalization is key, but make sure it’s the right kind.

It’s standard operating practice these days to put someone’s name in the subject line, but there’s plenty of other information you can include. Just make sure you don’t overload the subject line.

Here are 7 ways you can insert personalization:

  1. Who they are (name insertion is key, but don’t stop there)
  2. Who they care about, such as friends and co-workers (such as the emails Facebook and LinkedIn send to you)
  3. What they did (not just purchases but also browsing and other activity)
  4. What they didn’t do (abandoning their online cart or not completing a profile)
  5. What others did in reaction to their activity (responses to status updates, or the number of reactions to a product review)
  6. What they have (account balances, or care or service instructions for a purchased product)
  7. Where they are (geolocation-based messaging, such as letting a customer know about a sale at their local store) For example: [FIRST NAME], [#] people replied to your comment – see what they said

Yes, you can use an emoji (or two), but remember the word “sparingly.”

An emoji can add a splash of fun to a subject line, especially if it’s something lighthearted, but you probably don’t want to use more than two emojis in a subject line. For example:
Wondering who commented on your review? 🤔

Just remember that emojis render differently across various email platforms, so make sure you double-check your choices with a resource like Emojipedia.

Be funny, or memorable, or just fun.

This is another potential minefield, but if you approach it the right way, your email could be the subject of a viral “Check out this great email I received” post on social media. At the very least, it can bump up your open rates.

If you’re not sure about turning your subject line into a mini stand-up routine, try making an impression with a memorable quote, fun fact, or pop culture reference. There are plenty of places online where you can find quotes and facts, and we assume you, or someone in your office, know a bit about pop culture.

For example: Dolphins still know each other 20 years later — don’t wait 20 years to reply to [USER NAME]’s post

Create a sense of urgency with a deadline.

You can let someone know that the items they’ve saved in their cart have low quantities on hand, or that those items will be cleared from their cart if they don’t purchase then by a certain date. Or that an offer they signed up for is about to expire. For example:

For example: Uh oh: Your cart will be empty – and lonely – if you don’t buy what’s in it by [DAY]

Try an old-fashioned straightforward approach.

If you feel like everyone else is trying really hard to stand out by shoving personalization, emojis, jokes, and deadlines into their subject lines (subscribing to your competitors’ services and using their apps can help you stay abreast of trends), maybe you should simply tell it like it is.

For example: Here’s your receipt for [ITEM] – thanks for your purchase!

Make A Great First Impression

Like all sorts of emails, email notification subject lines are important to get right. They’re the impression your user will have of your notification content and are a crucial step in driving activity and engagement with your app.

An effective notification subject line packs a lot of punch by capturing the essence of the information you’re delivering, as well as the action you want your user to take. Treat them as seriously as any other part of your app’s UX—not an afterthought. What are the most effective and creative email notification subject lines you’ve received from the apps you use? We’d love to see your examples. Tweet us or shoot us a note in our community slack channel.

Brent Sleeper

SaaS User Engagement Tips

Increasing user engagement has become a mantra for SaaS product teams, and with good reason. That engagement is an essential quality of a high-growth product that retains customers and minimizes churn.

Recently, my colleague Amie highlighted how emails like welcome messages, activity notifications, and even password resets are an important tool for activating and retaining SaaS users.

But to be successful, product teams need to approach those emails with more care than the simple faith that “if you send it, they will come.” In fact, app teams can learn a lot about engagement from another group of people who’ve been using email to drive customer engagement for a long time: email marketers.

Here are three lessons from email marketing that can help product teams develop more effective email notifications and other app-generated messages.

1. Optimize relevance and deliverability

In email marketing, a basic metric of a message’s relevance to the target is its deliverability—that is to say, whether it even makes it to the user’s inbox. That sometimes surprises folks who aren’t steeped in the world of email, but here’s why it’s an issue.

When email doesn’t reach the inbox, it’s often for reasons more complex than a straightforward bounced email address. Mailbox providers like Gmail and Outlook use complex algorithms to assess whether you belong in user inboxes. These algorithms look at a spectrum of factors to determine whether your message should be tagged as a relevant message, a promotion, or junk.

We’ll drill down into some of these in the future, but there are already great deliverability resources for learning about everything from boosting sender reputation to SPF implementation.

It’s the same as in software design: If an app isn’t user-friendly or lacks sufficient utility, the user will delete it without a backward glance, exactly the same way they (or their email service provider) are hitting the spam button on irrelevant or badly-timed emails.

2. Use behavioral triggers

How do you promote retention as an engagement factor, whether in email marketing or software? By designing your campaign – or your product – to respond to the recipient or user’s behaviors.

In the case of email marketing, one example is to nurture people through the sales funnel by sending emails calibrated to their actions along that path.

Here’s an example from Groove, a help desk software provider. A user opening a trial account was the trigger for an email that welcomed them aboard with a personalized message from the customer support lead.  Did it work? Their conversion of trial users to paid users increased by 10%.

Exploiting behavioral triggers shouldn’t end once your users have been converted. Again, sustaining engagement over the long haul depends on conveying the right prompts at the right times. That’s a key factor in determining  the types of emails your product sends (and when).

In software product design, including unlocks or upgrades that reward trial, regular usage, or other actions is a common way of maintaining user engagement throughout a product’s lifecycle. Apply that same same growth hacking method to your product’s emails.

3. Test (and test again)

Perfecting the user experience—again, whether it’s in product design or email—means constant refinement, and that only comes from testing prototypes. That’s why the onboarding and notification mails your product sends should be tested as rigorously as you test your app’s UX (and your marketing team tests their promotional messages).

I mentioned how Groove used behavioral triggers as part of the email strategy for their product. They provide a good example of how to use testing, too, in how they optimized those behavioral emails:

The version above prompted users to open a free mailbox. The one below nudged them to try a product demo.

 

In all, according to Optimizely, Groove tested 22 different emails based on user triggers to get to the final six they sent during user trial periods. Testing like this is critical to optimizing an individual message or an entire campaign.

The lesson for SaaS teams? If you don’t test and refine your app’s notifications and engagement messages to make sure they actually connect and meet the real needs of users, you’re leaving a lot of potential engagement (and revenue!) on the table. Ineffective emails—whether marketing or product messages—squander one of your most precious resources: your users’ time and attention.

There’s more!

There are even more lessons to be had from email marketing that can help SaaS product teams increase user engagement via app notifications. In my next post, I’ll look at some of the specific qualities of good marketing emails that also can help product teams develop more effective alerts and notifications for their product.

—Brent
@brentsleeper

Zapier and SparkPost

Today’s blog is by guest author Chris Dunne, who writes for the GetJirified blog. The original post can be found here.

Creating Magic using webhooks with Zapier and SparkPost for email

JIRA Service Desk is a great product. It provides all the essential features to set up a fully functional business and customer friendly service desk. It is, like the rest of JIRA, quite flexible.
But there is one area that I believe is seriously lacking in terms of flexibility. Email Handling!
Whilst many users will prefer to login to the portal and raise requests, others will prefer to email. The majority will prefer to receive change notifications for requests by email too.
The ‘Default’ Email Notifications feature is baked into JIRA Service Desk. This will send customers email notifications using Atlassian’s own built-in HTML email template.

Zapier and SparkPost notification message

But many JIRA Service Desk customers want to send these emails with their own branding, own look and feel, and customized data items in the body of the email.

The lack of ability to customize this essential function has been outstanding for a long time. Check out JSD-218 – As an Admin I want to be able to customize the Service Desk notifications’ subject, content and format

Read through the 330+ comments and you can see there is a lot of frustration in the community with Atlassian’s lack of progress on this issue. Only recently Atlassian announced a slow rollout of features related to Email customization in a beta program for JIRA Cloud customers.

The comments do provide some workarounds using ScriptRunner and velocity template modifications but I wanted to see if I could come up with an alternative that didn’t involve add-ons.

Without further ado, let’s define the requirements. We would like to be able to do the following:

  • Send emails in response to events on issues in JSD.
  • We want to be able to completely customize the look and feel of those emails.
  • We want to be able to insert data from the issue into those emails.
  • The emails should come from an email domain that the customer recognizes and won’t be blocked or treated as spam.
  • Customers should be able to reply to these emails.

In this article I will show you how you can do all of this in JIRA Service Desk (for both cloud and server versions). We will use a combination of JIRA’s webhooks, Zapier, and SparkPost.

JIRA Email Notifications

So what are these email notifications that JSD / JIRA sends? They are emails, triggered by JIRA issue events that are sent to a defined set of recipients. The content of the email is defined in a template.

When we are dealing with JIRA Service Desk there are actually two flavours of email notifications.

  • JSD Customer Notifications. These are the notifications that are baked into the JIRA Service Desk project. There is very little we can do to change the behaviour of these notifications, or customize the content. We cannot change the layout or content without cracking open the source code, and on Cloud this is not even an option.
  • JIRA User Notifications. This is the traditional means of sending email notifications. Using notification schemes, we have the ability to define who receives the notifications for each type of event. But these email notifications are only sent to licensed JIRA users and not to JIRA Service Desk customers (free, and unlicensed). For the server instance we can also modify the Velocity templates used to control the layout and appearance of the emails.

Here are some examples of the out-of-the-box notifications; one is a standard JIRA Service Desk notification a customer would receive and the other is the type of notification received by licensed JIRA users.

Zapier and SparkPost notification message

Zapier and SparkPost notification message

The challenge for many Atlassian customers, and the challenge we set out to tackle in this article, is to provide a mechanism to change the content and branding of the emails, preferably without additional plugins.

An Alternative Approach

We want to send customized emails in response to events in our primary system. When you think about it this sounds a lot like the function of transactional email systems like Mandrill and SparkPost.

These are normally used in e-commerce systems to send receipts and other automated replies. They provide users with the ability to trigger emails and define templates for the content of those emails.

So I thought – could we disable JIRA’s native notifications and instead use one of these transactional email systems.

To do that we need a means of sending a message to our transactional email system when an event of interest occurs in JIRA. JIRA has webhooks which can do exactly that. But we need something that would catch the webhook, parse the content, and trigger the sending of the email.

Zapier has the capability to do this and is quite easy to set up.

Finally, we need to have something to actually send the email. There’s a bunch of candidates, but the new kid on the block is SparkPost and I’ve decided for the purposes of this post to give it a try.

So the next step is to set up our accounts with Zapier and SparkPost.

Zap it

Firstly lets set up the Zapier account we need and create the webhook we are going to use.

  1. Create your account on the Zapier site here, and sign up for a free plan.
  2. Click Make a Zap and then select Choose App under trigger. Type Webhook and select the result.
  3. Select the Catch Hook option and then click the Save + Continue button.
  4. On the next screen select Continue. A custom webhook URL is generated. This is the webhook that JIRA will use to trigger the Zap. Click the Copy to Clipboard button.
  5. Click OK, I did this button and keep this window open. Zapier is waiting to intercept this webhook. So we need to open another window and set up the webhook in JIRA.
  6. Go to JIRA->Admin->System->Webhooks and configure the webhook.
  7. Give the Webhook a name.
  8. Paste the URL copied to the clipboard in step 4 into the URL field.
  9. Select the events that will trigger this webhook. We will select the Issue Created and the Issue Updated event.
  10. Click the Save button.
  11. Now create an issue in any project and switch back to your Zapier browser window. Zapier should detect the webhook. You can click the view your hook link to see the actual data sent.

Note: In part 2 of this article we will further customize this to fire events from our workflow, restrict the issues we are interested in using JQL, and create webhooks for other events.

Here’s a screencast showing you what to do.

So we have JIRA talking to Zapier and sending the details of events as JSON.

But this is only half the story. We can’t complete the full Zapier definition yet as we need to also configure SparkPost.

Spark it

Now we are going to set up our email system using SparkPost. We just want to test a very basic scenario and ensure that we can send an email with some data from our JIRA issue created/updated event.

So first we need an account and then an email template.

Setting up a SparkPost Account and Linking it to Zapier

  1. First things first, set up a SparkPost account here. When you first set up an account, SparkPost will ask you about your sending domain. I advise skipping this for now. Click the Skip For Now button.
  2. Click the Get A Key button under ‘Send with REST’. Copy the Key to notepad.
  3. Switch back to Zapier. The next step is to set up the Action which will be called when the Zap is triggered by the webhook.
  4. In Choose App, type SparkPost and select it. The next step is to Choose the Action. There is only one – Send Email.
  5. Click the Connect a New Account button. Paste the key you just copied and click Yes, Continue.
  6. Click the Test button next to the new account. If this is successful, click Save + Continue.

Here’s another short screencast to demonstrate these steps, although in this case I already had a SparkPost account.

So we’ve connected Zapier and SparkPost. Next we need to trigger an email in SparkPost. We need a template for the email.

Setting up the SparkPost Email Template

  1. On the next screen we can select the Template for the email that SparkPost will send. Right now we don’t have any template, but there is a draft template called “My First Email” set up for you in SparkPost.
  2. Switch to the SparkPost browser window.
  3. Click Templates. Then click My First Email. This will bring you into the editor. We are just going to use the default template as this is really a proof of concept.
  4. Our Zap is going to take some data from the webhook body and construct a subject line that contains the Issue Key and Summary. In the Subject field in the template editor enter the text “{{mysubject}}” (without the quotes).
  5. Click the button to Save & Publish.

Double-check your work with this screencast.

Complete the Zap

  1. Switch back to Zapier to complete the configuration.
  2. Select My First Email in the Template ID field.
  3. In the Inline Recipients field choose Issue Fields Reporter EmailAddress.
  4. In Substitution Data we provide key value pairs. The first field box is the key and here we can enter the key name mysubject. The second box is the value and here we can select Issue Key from the dropdown. After Issue Key, type a ” – ” (space, hyphen space) and then select Issue Fields Summary from the dropdown. This builds up a string of text for the subject line which will be injected into our email template.
  5. Click Continue and a test email should be sent to you.

This screencast shows the setting up of the key value pairs in Zapier.

Now let’s see if it was all worth it. Create an Issue in JIRA using your own account. You should receive a notification from [email protected] and the email subject line should contain your new issue key and summary. Then update any field, such as the description field. You should very quickly receive another email from SparkPost.

Hopefully it worked. If not, get in touch with me on the comments and I’ll try to help you diagnose it.

Zapier and SparkPost Together

OK so there are quite a few steps involved but they are reasonably simple and give you a good sense of the power of Webhooks and Zapier. Let’s review where we are at and what we can do next.

At the beginning of this post we set a number of requirements.

  • Send emails in response to events on issues in JSD. We are using webhooks, triggered by JIRA events, to trigger emails using Zapier and SparkPost.
  • We want to be able to completely customize the look and feel of those emails. Although we didn’t show it here we have full access to the email template in SparkPost and we can completely customize the emails. Check out the SparkPost docs for more information.
  • We want to be able to insert data from the issue into those emails. We can inject substitution data (issue data from webhook body JSON content) into the templates. In this example we only injected data into the Subject but we can also do this in the body of the email. You can read up on the substitution data and its capabilities here.
  • The emails should come from an email domain that the customer recognises and won’t be blocked or treated as spam. We used the *.sparkpost.com domain as the sender domain for our proof-of-concept. You can set up your own sending domain and then verify it with SPF and DKIM to allow SparkPost send emails from your own domain. See docs here.
  • Customers should be able to reply to these emails. We have not yet addressed this requirement. But I believe it is possible and this worked in my initial tests. You would first need to set up sending from your company mail domain so that notifications arrive in recipients inboxes coming from [email protected] When customers reply, the replies will go to this address. If you have JIRA set up to poll this account then JIRA should be able to process those emails and add the replies to the original issue. Alternatively you could auto-forward the emails to whatever email address is configured in JIRA.

To be honest I have not had time to completely test all scenarios and this is merely a proof-of-concept. I hope it inspires others to try this out and if you feel like it please add comments below and share your results.

In the next post (assuming there is interest), I will look into how you can send the emails from your own domain, how to filter the events using JQL, and how we can customize the email templates. I’ll also look at triggering the emails from workflow transitions and by using the JIRA Automation Plugin.

We won’t be able to create an email notification system as flexible as Notification Schemes but I think we can solve the problem of customizing email content for JIRA Service Desk customers.

-Chris Dunne

Chris Dunne - Get Jirified Blog Author Zapier and SparkPost