The five stages of the notification lifecycle

When notifications work well, your users don’t think twice. They chalk it up to a pleasant user experience and good product design. But when they’re not working—when you’re sending too many or too few notifications—users either forget about your product or opt-out of notifications altogether.

That’s why the hardest part of building great notifications isn’t last-mile delivery, it’s orchestrating a high-quality, cross-channel notification experience for your product, then maintaining that experience over time as you add new channels and new features.

Today’s leading product teams either build or buy a system to manage cross-channel notification templates and routing logic, and layer on testing, environment versioning, and analytics. The best teams can point to exactly which notifications are actively being sent to customers, know that they’ve been thoroughly tested before reaching production, and evaluate their efficacy and ensure they're not spamming users. Taken together, we call this the product notification lifecycle.

In this article, we’ll share examples and learnings from leading product teams within each stage of this lifecycle:

1. Develop templates and workflows for your notifications
2. Test notifications before they reach users
3. Ship your notifications to production
4. Measure effectiveness and find opportunities for improvement
5. Create a maintenance plan

Develop templates and workflows for your notifications

Before you build a notification engine, you need to understand the full scope of your notification workflows. What types of notifications will you be sending? When should those notifications be sent? Across which channels do you want to send these notifications?

Depending on your use case, there are a few things you’ll want to consider for your notification workflows:

• Batching/digesting. Do you send enough notifications of a specific type, or in total, to warrant introducing batching logic to reduce the notification volume your customers receive.
• Channel sequencing. If you’re sending notifications across multiple channels, you should consider whether it makes sense to sequence those channels based on where your customers may be at a given point in time. For productivity SaaS apps with high daily use, you may want to opt for notifying users via in-app channels before you send them an email.
• Conditional sending. Can you conditionally send notifications based on read status or device status to reduce the number of redundant notifications your customers receive.

After mapping out all of the workflows you’ve already built or want to build, you can start thinking about templates. Within a workflow, you’ll have a notification template for any per-channel messages you want to send to a given user. These templates determine the actual content of the notification that is sent to the user, along with any personalization and styling that should be included.

As you’re designing and building your templates, think about the different audiences for your notifications and what those personas imply for the channels you’ll use to send notifications. As an example, the team at Zendoor sends email notifications to the property managers on the business-to-business side of their rental marketplace. These notifications wouldn’t make sense to send to their consumer renters, who are more likely to engage with push or SMS notifications.

The best teams have a system for previewing these templates as they’re drafting them, so they can understand how notifications will appear for a given workflow across that workflow’s different channels. If an engineer wants to see how a notification appears across channels, such as an email service or on an iOS device, they can preview the contents across templates to ensure that everything is displaying correctly. These previews should be able to handle advanced workflow functionality, like a template that iterates over multiple items in a digest to render items in a list.

In the early stages of your product, you may only have a handful of notification workflows, with a few channel templates. But as your team adds features and channels to your product notifications, this number ramps fast. Take stock of your workflows early, so that when your notifications get more complex, you have full visibility into every notification and channel. This also helps to keep product messaging consistent as your team grows to include separate squads for different parts of your product.

As the scope of a notification system starts to expand, it’s common for product teams to start using tools such as Google Sheets, Airtable, or Notion to keep a manual inventory of their notification workflows. These inventories get stale fast, which can compromise your ability to keep a holistic view of the notifications that you send to customers.

When it starts to feel unmanageable to track notification workflows, or your team doesn’t have complete visibility into what’s sent to customers, it’s a good time to consider building an internal dashboard user interface (UI) for managing notification workflows (either in-house or with an internal tool service such as Retool) or using a third-party notification system (like Knock 😄). This way your notification inventory updates automatically as you introduce new workflows and templates, ensuring you have a comprehensive view of everything you’re sending customers across your entire notification lifecycle.

Test notifications before they reach users

Now that you’ve developed your notification workflows and templates, the next step is to test what you’ve built before you ship it to customers. Testing your workflows ensures that your users have the best experience possible each time they receive a notification, regardless of the channel in which they're receiving it.

You’ll want to test your end-to-end workflows in a development environment before rolling out to production. This is when you’ll catch and fix any issues with your workflow runs.

The product team at Standard Metrics, a financial collaboration platform, prioritizes regular testing to understand how notifications impact the user experience. They use a dashboard—accessible to both engineering and product teams to understand what’s happening in their platform when a customer action triggers a notification. Engineers can make and test updates to notification logic, while the product team can understand how notifications drive customer engagement on the platform.

Additionally, many product teams allow users to customize notifications to match their preferences. This complexity requires a formal testing process to anticipate all possible outcomes.

VendorPM, for example, built a user preferences model into their product. This lets users opt-out of channels and notification types as they choose, reducing the likelihood that they’ll opt-out of notifications altogether. They keep a comprehensive view of processes to oversee workflows, tweak notification logic, and A/B test the system. Having a centralized view in a single location means they can find and fix issues in a matter of minutes.

You can think of testing as your failsafe for your notifications. When you bake testing into your regular processes, you catch issues early and create an environment that encourages learning and improvement.

Ship product notifications to production

Now that you’ve tested your workflows, and you’re happy with the way they work and look, it’s time to ship your product notifications to production.

In this stage, product teams should have a few key mechanisms in place:

• Alerting when indicators fail. Establish a process for when major indicators fall off a cliff, such as when notifications stop sending. Internal alerts help you catch errors before they impact your users.
• Process for rolling back production changes. Create a straightforward process in case you need to roll back production changes. Make sure you have a way to roll back to the previous state of the notification system if needed. Another way to manage this is through using feature flags or kill switches on each notification type you send so you have a way to disable the notification should it start spamming users.

You might be noticing a theme throughout all of these stages: visibility. Visibility is critical throughout the notification lifecycle, leading to faster shipping times and a more efficient use of engineering resources. Shipping your notifications isn’t the end of the lifecycle and the work doesn’t stop here. You need to ensure that notifications are serving their purpose and helping you achieve your goals.

Measure effectiveness and find opportunities for improvement

Just because notifications are working properly doesn’t mean that they’re effective. High-quality notifications support your business goals and deliver a world-class user experience.

Product teams should have processes in place to analyze the effectiveness of their notification engine. A few questions to evaluate:

• Are your notifications driving the behavior you expect across different channels?
• Are there opportunities to streamline your workflows to reduce the volume of notifications your users receive?
• How are notification engagement rates correlated with activation metrics and retention in your product?

The answers to these questions help you choose your north star metrics for notifications. Let’s say you want to measure channel effectiveness. You might analyze the total volume of notifications per channel and notification type. You could also layer engagement data like opens and clicks to see how users interact with these notifications.

Zendoor’s product team performs regular analyses on their notification workflows. At one point they found that property managers preferred receiving email notifications while renters preferred text message (SMS) notifications. This insight helped them customize their notification templates for each channel, leading to higher user engagement.

As your user base grows, you’ll also want to analyze the amount of notifications that users receive to find opportunities for batching. The team at VendorPM found that batching reduced opt-out rates and drove higher response rates to quotes and proposals.You’ll also want to evaluate your notification engagement data alongside the rest of your behavioral event data. This helps you better understand your user base, including how notification send volume and engagement rates impact activation and retention.

If you decide to build a notification system in-house, you’ll need to retrieve any data from downstream channels where you deliver notifications and pipe that data into your behavioral analytics tool (e.g. Amplitude). If you use a third-party vendor for your notification system, they should provide you with a single data source containing all your notification data that you can bring into your analytics platform.

Understanding how your notifications perform over time has a net-positive impact on your overall user experience. It also gives you a more targeted approach when making changes or adding workflows, reducing the burden on your engineering team.

Create a maintenance plan

Building notifications isn’t a one-and-done process. They require ongoing maintenance from a team of people with different roles and responsibilities.

Whether you’re building a notification system in-house or using a vendor, you’ll want to plan for the following stakeholders to have access to the system with the correct roles and permissions.

• Engineering: Has access to update notification workflows and templates. They can make changes to system-wide globals such as email layouts and constants. They should also have access to your logs, the deploy mechanism for your notifications, and testing suite.
• Product: Has access to update notification workflows and templates, so they can make changes to existing notifications without having to take time from engineering. They should also have access to the test suite if it exists.
• Support: Does not have update rights on notification workflows and templates, but ideally has the ability to read notification logs so they can debug issues for customers.

By giving different roles varying levels of access to the same notification system (instead of just limiting the system to engineering), teams encourage communication between functions and prevent blind spots. Let’s say your support or customer success team notices that welcome invites keep going into spam folders or worse, they aren’t being sent at all. Because these roles have access to the same notification system, even if that access is at different levels, they can promptly communicate and solve the issue.

Establishing a braintrust of people who understand your notification system encourages accountability and transparency across your organization.

Summary

Since product teams are constantly refining their notification workflows, this lifecycle isn’t always a linear process. You might build a set of notifications and spend most of your time on testing and maintenance, while high-growth products might spend more time in the building phase.

You’ll know you have a well-functioning notification system when you have visibility into all of your notification workflows and you can quickly build, test, and ship notifications and then monitor the success of your efforts.

If you need support in any of these lifecycle stages and don’t want to invest in building and maintaining a notification system in-house, you should try Knock. Knock is a flexible, reliable notifications infrastructure built to scale with you. Schedule, batch, and deliver notifications to all your channels—no custom application code required.

Thanks to Annie Cusack for help in reviewing and editing versions of this post.