Can you build a complete notification system without breaking a sweat?

User notifications significantly increase engagement in social apps and productivity in business apps. Today, email notifications, web browser notifications, and cross-platform mobile push notifications have become the standard in user expectations. While some savvy customers want notifications sent to their Slack channels, others might want SMS notifications. Keeping customers in the loop through all the channels is a monumental task--and not one of your development team's core competency or interest.

Before Mailgun and Postmark were on the map, companies struggled with reliably delivering emails. Before Facebook Connect or Google Auth, everyone built their own authentication systems.

All products know the benefits of having a notification service of sorts, but few truly spend the time and money needed to implement their own in the right way. It is usually not fully thought out and far exceeds initial expectations. Despite the time and effort invested, it will often not deliver all the anticipated features. Additionally, as the notification system grows in complexity, more maintenance and upgrade expenses will arise.

Not anymore. With MagicBell, nobody has to worry about building a notification system, bespoke or otherwise, ever again.

The Complexity of a Notification System

Let's consider the most basic, cross-platform notification setup. A system event requires a user notification (for example, if they were tagged in a comment). If you provide a web app, you'll need to verify the user is online before sending them a notification in-app. If they are offline, you'll need to push the notification via email. (You can push the notification through both channels, but we believe this practice to be less effective).

If you also offer a mobile app, you may send them a push notification, but then you should remember to remove it if your user sees it on another notification channel. To get an idea of just how complex the notification system can get, look at this flow chart that Slack, which offers a visual of their notifications logic:

And that's just the basic notification. What if you would like your users to act on notifications, send them a digest version, or offer other channels like Slack or SMS? Then things get even more complex. What if you want to split-test your notification? Or access analytics on the effectiveness of your notifications on user engagement? It is guaranteed you will have to build out even more pathways.

The Secret World of Notification Mismanagement

Many companies build a notification system but barely have time to maintain or improve it. Notifications are not just fired and forgotten. You need to worry about deliverability, giving your users subscription options and troubleshooting help. You also need to be aware that many users will unsubscribe without robust notification delivery preferences at the first sign of a notification they consider irrelevant. So, engagement in these push messages is something to keep in mind for your product's general success or return usage.

An additional concern is the management of notification preferences; you'll need to build a screen where they can select how and when they want to be notified and about what. Finally, there's security. Most don't have any debugging or customer support infrastructure around notifications and just hope for the best. This approach can also lead to unsubscribes or unengaged users.

Introducing MagicBell

There's a silver lining. These implementation patterns are highly similar across products and companies and render themselves well to a SaaS service.

We have been thinking about the problem of building a notification system for many years in SupportBee and finally decided we were the ones to solve it.

We introduce our solution: MagicBell.

Your Email Notifications, Supercharged!

One more thing.

Apps and services almost always offer email notifications. In the early days of MagicBell, we allowed users to turn their email inboxes into a notification centre, automagically. All you had to do was to BCC: your email notifications to a project-specific magic email address, and we did the rest! MagicBell sorted emails and understood who the notification was for, what the notification's title was, and where it should direct the user.

We now offer far more than just supercharged email notifications. Using a customisable notification API endpoint, you can send up to 1000 notifications in a single request across multiple channels, depending on your preference. All in real-time. These channels include email, web push, mobile push, Slack and SMS. How you send the notification and how it is received depends on how you identify users in your app.

Despite the power of our notification inbox, you can still launch within an hour. For more details on how and what we do you can also refer to our Docs page sending notifications.

MagicBell Notification System

We are already powering the notifications for companies like Pitch and GitBook. We invite you to give us a try and test MagicBell in your product.

Still not convinced? Don't take our word for it! Listen to our customer story with Pitch here and see how we have collaborated on building their notification system.

Curious? Why not signup for an account?

Related article:

• In-App Notification Design: How to Get Started and Best Practices for Engaging, Effective Notifications