Guide

Tutorial

Product News

Courier Updates

User Experience

Product Management

Integrations

Engineering

Live Streaming

Notifications Landscape

Courier

Thomas Schiavone

Notifications are the lifeblood of modern apps. They re-engage users, keep them informed, and build trust. But most apps rely solely on push notifications—without an in-app inbox, critical updates can easily be lost.

Push notifications grab attention in the moment—perfect for a flight delay, an account alert, or a message from a teammate. But they’re fleeting—once dismissed, they’re gone. If a user is busy or distracted, that information is lost, along with the opportunity to engage them.

An in-app inbox solves this. Unlike push notifications, an inbox provides a persistent record—a place users can revisit to see what they missed. It ensures important updates aren’t lost, helps users prioritize, and creates a seamless notification experience: push drives immediacy, while the inbox provides depth and context.

This is a big reason why we built [Courier Inbox](https://docs.courier.com/docs/inbox). Let’s look at a few ways that push notifications and in-app notifications (Courier Inbox) can work together.

## 2\. Push and In-App Done Right: How B2C Sets the Standard for B2B

B2C companies have mastered **push notifications and in-app inboxes** to drive engagement and keep users informed. B2B, on the other hand, often treats notifications as transactional, missing opportunities to create seamless, user-friendly experiences.

**Airbnb and Starbucks** show how to do it right—using push to grab attention and in-app inboxes to provide continuity. Their approach offers a playbook for B2B companies looking to improve communication, ensure critical updates are seen, and build better user experiences. 

Let’s look at three ways we can learn from them

### A) Push for Immediate Action

Push notifications drive urgency and encourage quick responses.

**Examples from B2C Products:**

- **Airbnb**: Sends push notifications to alert users about high-demand properties, upcoming trips, or price drops.  
- **Starbucks**: Notifies users about limited-time promotions, double star days, or when their order is ready for pickup.

**How to Apply It for B2B:**  
Push notifications drive critical actions in business workflows:

* **HR & Workforce Management** *(Workday, BambooHR)* → Notify managers when a time-off request needs approval, or remind employees about an upcoming performance review deadline.  
* **Project Management & Collaboration** *(Asana, Jira, Monday.com)* → Alert team members about task assignments, urgent project updates, or approaching deadlines.  
* **Finance & Accounting** *(QuickBooks, Stripe, Expensify)* → Notify users of high-value transactions, failed payments, or invoice due dates.  
* **Procurement & Inventory Management** *(SAP Ariba, Coupa)* → Send alerts when inventory levels are critically low or when a purchase order requires urgent approval.  
* **Developer API Platforms & DevOps** *(Postman, Datadog, CircleCI)* → Push real-time alerts for API failures, security breaches, or system downtime.  
* **Customer Support & Help Desk** *(Zendesk, Intercom)* → Notify agents about high-priority tickets or customer escalations requiring immediate attention.

### B) Providing Organization and Depth

An in-app inbox stores important updates, providing users with a centralized hub to revisit key information.

**Examples from B2C Products:**

* **Airbnb**: Consolidates booking confirmations, itineraries, and host communications in its inbox, so users can access all trip details easily.  
* **Starbucks**: Tracks rewards progress, stores personalized offers, and organizes order history in the inbox, creating a consistent loyalty experience.

**How to Apply It for B2B:**  
A notification center serves as a persistent feed of important updates:

* **HR & Workforce Management** *(Workday, Rippling)* → Store performance reviews, benefits updates, and compliance announcements for easy access.  
* **Developer API Platforms** *(Postman, Auth0)* → Provide a log of API usage alerts, integration failures, and feature updates so developers can track changes over time.  
* **Procurement & Inventory Management** *(SAP Ariba, Coupa)* → Organize order approvals, supplier updates, and low-stock warnings to streamline purchasing workflows.  
* **Security & Compliance** *(OneTrust, Vanta)* → Maintain policy violation alerts, audit logs, and compliance deadlines in a centralized inbox for security teams.  
* **Project Management & Collaboration** *(Asana, Jira)* → Track task assignments, milestone completions, and team mentions in a dedicated notification center, making updates easy to review.

### C) Personalize Your Notifications

Tailored notifications make users feel valued and ensure messages are relevant.

**Examples from B2C Products:**

* **Airbnb**: Recommends properties based on user preferences and past bookings, creating a personalized search experience.  
* **Starbucks**: Sends offers based on users’ favorite drinks, purchase history, and regional promotions.

**How to Apply It for B2B:**  
Personalization in B2B notifications means delivering role-based updates:

* **HR & Workforce Management** *(BambooHR, Workday)* → Notify managers about pending approvals, team performance summaries, and policy updates, while employees receive benefits enrollment reminders and training deadlines relevant to them.  
* **Developer API Platforms** *(Postman, Auth0)* → Deliver alerts on API key expirations, unusual traffic spikes, and new feature availability specific to a developer’s usage patterns.  
* **Project Management & Collaboration** *(Asana, Jira)* → Surface task assignments, due date reminders, and team updates tailored to each user’s role and involvement.  
* **Finance & Accounting** *(QuickBooks, Stripe)* → Send customized invoice reminders, large transaction alerts, and monthly spend summaries relevant to finance teams.  
* **Risk & Compliance** *(OneTrust, Vanta)* → Notify security teams about compliance gaps, policy violations, and critical risk assessments based on the specific regulatory frameworks they manage.

## 3\. Why Not Build from Scratch?

Building a notification system from scratch is deceptively complex. Many teams start out thinking it’s just about sending messages, but the deeper they go, the more challenges emerge. It’s also not just about building it, once it’s built, you gotta maintain it.

Some of the biggest challenges include:

* **Backend Complexity:** Managing APIs, tokens, message queues, and multi-provider orchestration is a headache  
* **Maintaining Multiple Frontends:** Supporting iOS, Android, and web requires specialized skills and constant updates.  
* **Synchronization Issues:** Ensuring consistency across push, email, and in-app messages is hard  
* **Scaling Challenges:** As notification volume grows, complexity to maintain will increase.

## 4\. Building Developer First

At Courier, we set out to build an in-app notification platform that makes adding real-time notifications easy and fully customizable, ensuring they feel native to your app. Basically, what would we as developers expect. Here’s what we thought about when building Courier Inbox:

* **Cross-Platform SDKs:** Native support for iOS, Android, React Native, and Flutter along with Javascript for web.  
* **Real-Time Updates:** Push notifications and inbox sync instantly using websockets.  
* **Multi-channel Support:** Ability to send messages across multiple channels like email, Slack, and SMS along with push and in-app  
* **Offline Support:** Messages remain accessible without connectivity, syncing seamlessly when users reconnect.  
* **Customizable Design:** Easily tailor the inbox UI to your app’s branding and look native to the platform (eg iOS looks like iOS) 

## 5\. A Smarter Way to Build Notifications

That’s why we built [Courier Inbox](https://docs.courier.com/docs/inbox): to take the complexity out of notifications. Real-time updates, cross-platform SDKs, and full customization—without the overhead. Give users the notifications they need, when they need them. No missed messages, no unnecessary complexity. Just a seamless experience across every platform.

If you’re ready to build notifications that users love, Courier makes it easy.  


Push and In-app - Header

B2C apps like Airbnb use push + in-app to keep users engaged. B2B can learn from them to build notifications that drive action and improve user experience.

Push + In-App: The Notification Strategy B2B Needs to Steal from B2C

Push and In-app - Thumb

Rethinking Push and In-App Notifications: What B2B Can Learn from B2C

Courier Live Thumbnail

The Courier Team

Twilio powers communication for over 10 million developers and 300,000 businesses worldwide. As a leader in customer engagement, they’ve set the standard for seamless, scalable developer tools. But as their business grew, managing notifications became a challenge. Fragmented tools and workflows created inconsistencies and inefficiencies across teams. To solve this, Twilio turned to Courier—a platform designed to unify notifications and improve the developer experience at scale.

---

## Twilio’s Challenge: Scaling In-Console Messaging

Twilio’s in-console notifications are critical for keeping developers informed. Whether it’s product updates, feature launches, or system alerts, notifications help developers stay engaged and take action. But as Twilio scaled, teams started relying on different tools to manage notifications. The result? Fragmented user experiences, messaging inconsistencies, and time lost managing workflows.

For a platform of Twilio’s scale, these challenges added friction to what should have been a seamless experience. They needed a unified solution to deliver consistent, real-time updates while simplifying workflows for their teams.

---

## Why Twilio Chose Courier For Notifications

Twilio needed a notification platform that could scale with them and adapt to their complex workflows. Courier stood out for its ability to centralize notifications and streamline delivery across channels. Key factors in their decision included:

- **Web Inbox**: Delivered targeted, real-time notifications directly within Twilio’s console.  
- **Seamless Integration**: Worked effortlessly with existing tools like Segment and SendGrid.  
- **Customization**: Easy to customize so that you can create consistent, branded notifications across all channels.  
- **Efficiency**: Reduced engineering effort with straightforward implementation and centralized workflows.  
- **Security**: Included enterprise-grade security and role-based access controls to protect sensitive data.

With Courier, Twilio could unify their notifications while enhancing the experience for developers.

---

## How Courier Solved Real-Time Notifications for Twilio

Integrating Courier gave Twilio the tools to fix fragmented workflows and deliver better notifications across their ecosystem. With Courier’s **web inbox**, Twilio created a central hub for real-time, in-console updates that developers could rely on. Notifications were now consistent, actionable, and delivered exactly when needed.

Courier’s notification center also allowed Twilio to give developers control over their preferences, including digest schedules and message frequency. Customizable templates ensured that every notification matched Twilio’s branding, while real-time delivery powered by webhooks and WebSockets kept developers in sync.

By streamlining their workflows and centralizing notifications, Twilio saved engineering time and created a better experience for their developer community.

---

## The Benefits of Courier’s Unified Notification Platform

The integration with Courier brought immediate and measurable improvements:

- **Centralized Notifications**: A single, unified inbox for all notifications reduced friction and confusion.  
- **Enhanced Experience**: Real-time, actionable updates kept developers engaged and informed.  
- **Scalability**: Built to handle Twilio’s growing ecosystem of developers and customers.  
- **Time Savings**: Simplified workflows allowed engineering teams to focus on building core features.  
- **Personalization**: Developers could tailor their notification experience to match their needs.

These changes didn’t just address the challenges Twilio was facing—they elevated the experience for developers and reinforced Twilio’s reputation for delivering world-class tools.

---

## Outcome: Twilio’s Improved Developer Experience with Courier

The partnership with Courier helped Twilio transform how they manage notifications. Developers now have a consistent and intuitive in-console experience, making it easier to stay informed and take action. By centralizing notifications and improving real-time delivery, Twilio increased engagement and reduced friction for its users.

Internally, the benefits were equally clear. Engineering teams saved time by eliminating fragmented workflows, while Courier’s customizable templates ensured consistent branding without additional effort.

Twilio’s Product Lead, Kandyce Knight, summed it up: *“We at Twilio know how important it is to meet your customers at their preferred channels. Courier gives us the power to fully personalize our customer touchpoints in one easy-to-use, centralized tool.”*

For Twilio, the integration wasn’t just a solution—it was a shift that enabled them to scale their platform while staying true to their developer-first ethos.

---

## Conclusion

Twilio’s success with Courier highlights the importance of a unified notification platform. By solving fragmented workflows and delivering real-time, personalized updates, they improved engagement for millions of developers while saving valuable engineering time.

For organizations managing complex notification systems, Courier offers a proven way to simplify workflows, deliver better user experiences, and scale seamlessly.

Explore how Courier Web and Mobile Inbox can help you better engage your customers. [Learn more here.](https://www.courier.com/platform/inbox)  


Twilio and Courier Header

Discover how Twilio unified notifications for 10 million developers with Courier, improving real-time updates, engagement, and workflow efficiency

How Twilio Used Courier to Unify Notifications for 10 Million Developers

Twilio + Courier Thumbnail

📣 How Twilio Used Courier to Unify Notifications for 10 Million Developers

Anwesa Chatterjee

- [Part 1: Product Notification Experience](https://www.courier.com/blog/pm-product-notification-experience/)
- [Part 3: User Preferences Management](https://www.courier.com/blog/pm-guide-to-preference-management/)
- [Part 4: Omni-Channel Analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/)
- [Part 5: Optimized Automation Logic](https://www.courier.com/blog/pm-guide-automations/)

As a product manager, have you ever had to say no to improving your app’s notifications because of how complex the project seemed?

If yes, you’re not alone. At Courier, we frequently see product teams deciding not to work on notifications. And PMs aren’t making that decision because a good notification experience is not important for their SaaS product or service — quite the opposite.

The reason is that changing notifications, in their experience, requires a lot of work between engineering and product due to how closely the notifications are tied to the rest of the application. If PMs are tasked with adding a new email campaign that all new users of the app will receive, that can usually be done outside of the core app. But sending more unique notifications, like alerting a Slack channel when someone @-mentions their colleague in a shared file, can be complex and require significant engineering work. And still more work is needed when the text or the design of such a notification needs to be updated.

We believe that changing notifications doesn’t have to be so difficult. In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex and less risky for product teams.

## Why PMs believe notification projects are hard

![image1](//images.ctfassets.net/z7iqk1q8njt4/6kGqayxYctQyy0qkn5MolS/74f523a316788e845e22186ca06c979e/image1.png)

Usually, the task of improving an app’s notification experience — like adding or changing notifications, or connecting additional notification channels — falls to the engineering team that’s responsible for the main product. Such teams have lots on their plate, which makes it necessary to prioritize some tasks over others.

Notification projects tend to be high-value for product managers, as a bad notification experience can have a negative impact on a SaaS app’s customer base, while, conversely, a [good notification experience](https://www.courier.com/blog/pm-product-notification-experience/) can drive growth metrics and delight customers.

However, notification projects also score high on complexity and risk at most companies. That’s because different notification channels, which are quite different by nature (think email versus mobile push), require a lot of individual engineering.

With so much complexity involved, product managers have to make a tough call: is it really worth taking on notification work when there are easier projects to work on with more tangible benefits? Because task backlogs frequently have other items in them that don’t carry as much complexity or risk, it’s logical for product managers to postpone rather complex notification projects. And so notification projects get moved down the priority list, again and again.

## The limits of common engineering solutions to notification problems
To try and make notification changes less difficult to implement, engineering teams use open-source tools that are well supported within their framework or programming language of choice. For example, those working with Ruby on Rails applications often use Rails’ built-in email sending module, [Action Mailer](https://guides.rubyonrails.org/action_mailer_basics.html), which includes functionality for sending plain-text and HTML emails.

While tools like Action Mailer are convenient to use and well-maintained, they can’t handle more complex tasks like expanding beyond the standard notification channels. If you want to add Slack or SMS notifications, for example, choices like Action Mailer can become a limiting factor, rather than an enabler of new product functionality.

The next logical option for a software team running into tooling limitations is to go with a fully customized notification system — but such a system brings its own challenges.

## Even a custom notification system is a bottleneck for notification improvements
It may seem that the solution to the limitations of open-source tools is to simply build your own custom notification system. But a custom notification system is still code that implements notification logic, supported channels, and templates for specific notifications, and this code lives inside the application codebase in a version control system like Git. Any changes to this part of the codebase have to follow the steps of the software development process, which becomes cumbersome when making many small changes, as is the case with notifications. (Not to mention that engineering time needs to be allocated to the maintenance of such systems in the long run.)

For example, if the task is to update the wording or the design of a notification across all channels, the engineering team tasked with the work might have to:

* Change the HTML email template.
* Change the Slack notification template.
* Change the Microsoft Teams notification template.
* Test all three changes.
* Wait for code review on the changes.
* Once the code is reviewed, deploy all three changes to production.
* Hand off to the PM for a final confirmation.

And every time a PM wants more changes implemented for notifications, the process has to start over again, even for trivial content changes. The standard development process, which is totally reasonable for code changes, is too much overhead when working on notifications, and the additional overhead takes the engineers’ time away from working on more valuable things.

## The result: notifications rarely get updated
Because of the additional delays introduced by the development process, the friction for implementing notification changes ends up being so high that PMs often choose to not implement notification changes at all. 

Instead of focusing on building the best possible notification experience, they settle for the default notifications that are built into their application already, because anything else becomes too difficult to do. They might think “If it took two weeks to change the simple design on my notifications, we're just not going to change things anymore.” And so notification experiences stall out indefinitely.

## There is a better way: enable PMs to work with notifications without involving the engineering team
Courier’s point of view is that the way notifications are handled in most SaaS apps today — templates stored in code, notification functionality changes requiring code deployments, etc. — is outdated and, as we have seen in the examples above, ineffective.

Instead of having to go through the development process for each notification change, we need to give PMs and other non-technical stakeholders the right tools to work with notifications directly. Here are the core practices that act as enablers for non-technical audiences.

**Making templates accessible to non-engineers.** Notification templates in the form of text, HTML, or programming-language-specific template files need to be located outside of the application code, and PMs as well as other non-technical teams need to have access and be able to make changes.

**Making notification logic configurable without needing to re-deploy the app.** The logic involved in deciding which notifications to send when should not be located in the application code, but rather sit next to it and be configurable without needing to deploy the application. The configuration can live in a text file, a web interface, or another config format. PMs should ideally be able to change the configuration themselves.

**Enabling self-serve analytics.** Besides notification functionality, PMs need to be able to track how their changes are doing — and be able to follow the statistics without the need to ask engineering or data teams for the numbers. Analytics can be presented as a custom dashboard, but can also be an export of a business intelligence report, or even a dump of application logs that show which messages were sent, depending on which option is easier.

## What are the results of PM enablement?
To show that PM enablement works as a way to make notification projects easier, we want to share two examples from Courier customers that have experienced this change.

Bluecrew, a marketplace for hourly jobs, [has seen its business grow](https://www.courier.com/blog/courier-bluecrew-multi-channel-notifications/) after decoupling notifications from application code. The company was able to improve the onboarding experience for new users in part by taking advantage of notification templates and making them accessible to non-technical stakeholders.

Within Bluecrew’s notification system, “anyone can add a content block and insert a custom attribute like ‘shift start time’ or ‘cancelation reason.’ We also have the flexibility to add custom code anywhere in the notification,” says Cooper Newby, the Chief Product Officer at Bluecrew. 

Another company that’s been taking advantage of the enablement approach is [Expel](https://expel.com), a provider of security services. The Expel team has enabled its UX designers to use the template designer UI directly and make changes to the product in real time.

“We can get our UX designers working directly on the templates and we can make updates and have them live in seconds,” says Yousuf Ashparie, Principal Software Engineer at Expel.

Does enabling PMs to make notification changes sound appealing at this point? We hope it does — as we believe it’s a significant improvement over the current practices at most companies. Let’s look at how you can enable PMs to work with notifications in your own team.

## So, how can you enable PMs to work with notifications?
Looking to enable PMs to do more notification work, but not sure where to start? Here are our top recommendations for companies looking to get started on the PM enablement journey.

**1. Get analytics in place.** Having analytics for notifications is a key tool for PMs to measure any notification changes. While metrics can be difficult to come by for some notification channels, it is usually possible to have at least some numbers in place. Once the PMs get the data, they can use it to avoid accidentally making the notification experience worse, and to make sure the rest of the organization can see the benefits for larger changes to notifications.

**2. Make it easier to change notification templates.** While it’s ideal to make all notification channels and notification types configurable by PMs, it’s not always realistic. Instead, at least make it so that PMs can change existing notifications without much involvement from the engineering team. Even if that’s all you allow, you will still need to add functionality to adjust notification designs to fit the updated content, and likely implement internationalization and translation workflows if you’re interested in supporting multiple languages.

**3. Build guardrails to prevent notification issues from escaping to production.** Ideally, all notification functionality should be covered with automated and, possibly, manual tests so that the organization can be confident in the product’s notification experience at all times. The areas to check include: notification text fitting within the display area; possible internationalization glitches; technical issues like app crashes resulting from changes in notification text size; handling of unexpected characters if notifications include user input.

## Courier can help
Instead of building everything yourself, use Courier — and get our recommended steps 1–3 done almost instantly after some brief initial implementation work.

Using Courier frees up your team to focus on other valuable things in their backlog. For PMs, UX designers, and other non-technical stakeholders, Courier helps by:

* providing a drag and drop designer, including a staging environment, with the ability to make changes live without deploying the app
* offering a UI that allows users to add new notification channels without needing to update code
* including an Automation UI that allows users to build out notification workflows visually (no application code)
* Implementing the guardrails in point 3 above, so that you can reduce the effort involved in changing notifications without increasing the risk.


Courier is a notification service that centralizes all of your templates and messaging channels in one place which increases visibility and reduces engineering time. 

Start Routing Notifications Today!

pm-guide-2-header

In this article, we explain how decoupling notifications from your application’s codebase can help make notification projects less complex for product teams.

pm-guide-2-thumbnail

The Product Manager's Guide To Building Notification Systems: Decoupling Templates From Code

nica-headshot

Nočnica Mellifera

Or, how we’re destroying users’ trust, and how to get it back. Check out the first post in this series as well: *[Building a Great UX Outside of Your App](https://www.courier.com/blog/building-ux-outside-of-app/)*.

There is a direct connection between all the unnecessary notifications you get on your phone and the sub-prime financial crisis of 2008. The connection is human behavior in a large and anonymous marketplace where bad behavior is rarely punished.

In a recent [Hackernews post](https://news.ycombinator.com/item?id=32692884), I posited the same connection: that apps that send notifications are facing a systemic collapse where users will be so overwhelmed with mass notifications that most of them will opt out entirely. One user responded with a great synopsis of the problem:

> Unfortunately if it drives engagement of 2 people at the expense of becoming annoying to one person the app developers will keep over-using notifications.

I’d add one further sad corollary to this observation: as long as other app developers are over-using notifications, it’s irrational for you the app developer not to. As you compete for attention on users’ devices, you will fall behind your competitors if you don’t emit a few notifications a day. So even though your individual action hurts the user experience overall, it can be irrational for you to avoid doing so.

As any fan of financial crises can tell you, the subprime bubble, where lenders created AAA-rated securities out of extremely shaky mortgage lending, was not an evil scheme dreamed up by nihilists. Rather, it was the act of rational people acting in their own best interests. As long as other banks were selling junk securities at high markups, it wasn’t rational for one bank to stop, even when they knew the system couldn’t go on forever. As former Citigroup CEO Chuck Prince infamously said, “as long as the music is playing, you have to keep dancing.”

## What the crash would look like
Any time I start a discussion on Reddit or Hackernews about what users want in notifications, most commenters say that they want out of notifications entirely. It was only three years ago that most users got ‘do not disturb’ mode on their phones, and more and more users are deciding to stay in Do Not Disturb *forever*.

Can notifications ‘crash’ the same way that the mortgage market did? Absolutely. The sequence looks like this:

* Increased awareness of unnecessary notifications
* Government regulators request that OS producers limit unnecessary notifications
* All notifications become tightly restricted
* Contacting users via push notifications becomes unreliable 
* Application developers no longer invest the time in timely notifications
* With users no longer expecting notifications, developers are forced to go back to email and SMS to contact users at all

## The Prisoner’s Dilemma
John Cassidy in his illuminating book *[How Markets Fail](https://us.macmillan.com/books/9781429990691/howmarketsfail)* explains that this pattern is in fact a version of the prisoner’s dilemma. The multiple actors in the market aren’t able to coordinate and they end up choosing options that are individually beneficial, but collectively negative.

The sub-prime crisis nearly crashed the global economy and we still live in its shadow. In the world of notifications: every OS release on our phones further limits how apps can notify us, is a similar crisis coming in the market for user attention?

## How we break free
A dire situation, surely, but we can do something about it: collaboration. The prisoner’s dilemma doesn’t work nearly as well if the prisoners can communicate and see each other’s choices. In the case of notifications, all that’s required is that we the creators of applications agree to some simple principles for trustworthy notifications.

This move is not without precedent. Multiple industries decided on voluntary pledges of quality and trustworthiness rather than deal with public ire, choosing self-regulation over government regulation. Perhaps you remember this seal from the childhood newsstand:

![crisis-1](//images.ctfassets.net/z7iqk1q8njt4/2nsPqQwBpHIueEHCVrtoQl/82d7f10962cbd1731f1ee55036cc23e0/crisis-1.png)

Next to Captain America’s adventures and even Grant Morrison’s Swamp Thing, the Comics Code Authority seal was stamped on the cover of comic books for over 40 years. And perhaps you saw another sign of voluntary self-regulation in an air-conditioned theater this weekend:

![crisis-2](//images.ctfassets.net/z7iqk1q8njt4/1W7YN13dcLNuTHnGnir9Vv/433631f477614ba9671a680587009def/crisis-2.png)

Neither of these ratings and advisory boards are without their detractors, and as Comic book fans aged and concerns about violent comics diminished, the comics code has disappeared. However, these do show that a lack of public trust can be addressed by an industry-wide standard.

## A pledge for better notifications
Folks, I don’t want to be corny, but I do want us to get better. Here we get to the crux: I want us to agree to do better. Here are the principles that can guide better notifications.

*One caveat here: this pledge is not about dark patterns or dishonesty. Tricking the user into spending money unintentionally should be covered by generalized ethics, this is about good design principles for developers who want to build trustworthy tools.*

### 1. Be timely
We often feel bombarded with notifications, so a requirement that they come faster can seem counter-intuitive. But it’s critical that you identify when and with what precision your users expect to be informed. A notification that your web service is down needs to come sooner than the first angry call from a user. And a notification about breaking news needs to come before you say something mean about Queen Elizabeth on Slack. 

![crisis-3](//images.ctfassets.net/z7iqk1q8njt4/CskUDdiZMdgRl1RvZpzhi/3bf58dc29d3f3195aebd59a53df193d6/crisis-3.png)
*When the Steam Deck inspired a purchasing frenzy, many users complained they got inaccurate notifications, like this classic epoch failure for a user in the UK*

Timeliness also means not notifying too quickly. Notifications about how many people liked a cat picture don’t need to arrive at 2:00 AM, they can wait til morning. 

The required accuracy of notifications will vary a lot depending on your use case. A scheduling tool like Calendly will need its notifications to arrive on the exact minute we need them to arrive at a meeting on time. A more fun social app probably only needs to send notifications accurately within 30 minutes.

![crisis-4](//images.ctfassets.net/z7iqk1q8njt4/3jiPBK4MyEafiuSly0RPta/7f567998e084a0a5966b1e8036873f0b/crisis-4.png)
*This failure by YouTube may reflect a shift in usage patterns: where previously new and interesting videos didn’t need up-to-the-minute notifications, now users get breaking news and important premieres on YouTube.*

### 2. Be targeted
We may not want our applications to know everything about us, but targeting is a critical part of good notifications. If I ordered Pizza Hut for lunch, I don’t want them notifying me of dinner specials. Look at this not-ideal experience for a user of Accuweather that warned him of thunderstorms…3,000 miles from his current location:

![crisis-5](//images.ctfassets.net/z7iqk1q8njt4/3EZ0BStlnMusDD464RsorU/43052cf882848ee5430b53cc13944d12/crisis-5.png)
*The cut-off text makes the situation worse: it’s easy to assume this is happening in your town!*

Some things we’d ideally target in our notifications:
* Geography
* Time Zone
* User’s access level within our service
* Where they are in the user journey

### 3. Be brief
In the example above from accuweather.com, a slightly wordy notification meant the user didn’t see the area affected by the alert. This is one example of a larger problem: a failure to be brief and to-the-point with notification messages.

Since notifications are often shortened when viewed on different devices, be sure to put the most important information first. Journalists would call this the ‘inverted pyramid’ but I prefer to think of it as a special case of little-endian transmission: the least important information should come last.

A special case of the requirement to be brief is digests: ask yourself if your notifications are more meaningful in a group or one-at-a-time. Notifications of individual ‘likes’ on a post is a great candidate for a digest, as is a long conversation thread.

Ideally since you’re following rule 2 and therefore know the user’s timezone, you can dynamically generate digests when notifications would be sent in the middle of the night for the user.

### 4. Offer (the right amount of) control
Finally there’s control. If I posted every bad example of user preferences for notifications this article would resemble 2000’s Flickr. But:

![crisis-6](//images.ctfassets.net/z7iqk1q8njt4/7k9Yb2Js0xw1tAAvczkx9T/c71c080f37ae7249d22ff251d830428e/crisis-6.jpg)
*A classic example is Starbucks’ which, for a time, would only tell you order status if you also accepted spam*

So we want to offer users real fine-grained controls. But it is possible to get too fine-grained

![crisis-7](//images.ctfassets.net/z7iqk1q8njt4/AtDdpPBn2oT7fJTbbZEZI/fe645350138a19d7e5f892d3dc098c07/crisis-7.png)
*If you zoom in, this is every notification setting for Google Maps*

The solution when you have too many settings is to offer some grouping, so that users can turn off whole categories.
What unifies these needs?
The common thread between all of these requirements is that they all require technical lift. Timeliness, targeting, brevity (with digests), and user preferences all require that we go above and beyond with our notifications service. A simple bulk send email kicked off by a cron job can’t deliver these features without some very sophisticated and un-maintainable regex. The solution then is to have a notifications service that can offer these features in a lightweight experience for our product team.

In the last article of this series, we’ll cover how you can build a great notification experience *without* using Courier.


woman on red backdrop screaming in annoyance as she is inundated with too many notifications

sub-prime-crisis-header

There is a direct connection between all the unnecessary mobile notifications you get and the financial crisis of 2008: lack of accountability for bad behavior.

sub-prime-crisis-thumbnail

The Sub-prime Crisis of Notifications

shreya-headshot

Shreya Gupta

A swan pulls a ready-made nest out of a Courier box while a duck has to build one from scratch across the pond.

build-vs-buy-header

This post gets into the “7 C’s” that should be considered when deciding to build vs buy. Learn about how Apartment List implemented this process.

build-vs-buy-thumbnail

Build vs Buy: The “to be or not to be” of Tech

nick-headshot

Nick Gottlieb

As modern applications have become increasingly feature-rich and performant, user expectations are at an all-time high. Failure to communicate key information or displaying out-of-date information frustrates users and causes a loss of trust. Think about the last time you ordered something online: if you didn’t receive your order confirmation within seconds, you probably began to worry that something went wrong. Users require product transparency for consistent use.

Luckily for developers, a proliferation of new APIs have been developed to help provide features such as real-time order update emails, push notifications based on in-app activity, or live chat with sales and support. Communications APIs are becoming increasingly specialized, with each type being more or less suited to certain tasks.

If you’re an engineer who’s been tasked with planning out your application’s communication strategy, this post will help you map out the landscape. You’ll come away understanding the three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience. We’ll also show you how using the right APIs in the right places will streamline your own day-to-day work.

Let’s get into it! 

## Planning Your Communications API Strategy

The best outcome any engineer can hope for is that your communications strategy is so smooth, it isn’t even noticed. For the end user, it just works exactly when it’s supposed to work, the way it’s supposed to work. For your own internal teams, everyone has the ability to craft the messaging they need and send it when they need, without unnecessary bottlenecks that can often impact your own engineering time.

In a marketplace application, for instance, users need to get an automated push notification or email every time someone comments on an item they’re selling. The marketing department also wants to send email campaigns to everyone who has purchased an item in the past six months to let them know there’s a sale coming up. When a buyer’s checkout fails, they might need to message your sales or support team to get help and complete the transaction. 

All of these are very different examples that will need to use a different type of communications API to get the job done.

## Exploring The Three Types

Communications APIs are segmented not only by the functionality they provide and how immediately they need to respond to user actions but also often by which teams at the company will need to use them to send messaging. 

App-to-user APIs are highly customizable, instant communications sent by engineering as integral parts of the application experience, such as push notifications about likes or comments. Brand-to-user APIs collect data and give the company, particularly marketing and product teams, the ability to send users targeted messages individually or en masse. User-to-user APIs facilitate live chat either among app users or with someone at your company, such as sales or support.

Let’s discuss the strengths and weaknesses of the three types of APIs, and see some commonly-used third-party providers for each.

## App-to-user APIs

App-to-user APIs are transactional messages that are embedded into the application code. These APIs are often the most mission-critical of the three, as they form a core part of the application experience. For instance: your rideshare has arrived, your order was received, you have just been added to this chat room, here is your one-time password for login. These types of communications tend to be time-sensitive and are designed to send immediately when the trigger events occur.

A robust App-to-user API will provide multi-channel communication (email, SMS, and push notification), complex routing, and easy opt-in and opt-out for users. Most can be heavily automated as well. For instance, when a new user is created via Auth0, a welcome push notification can be automatically sent.

App-to-user APIs are typically instrumented and used by engineering teams. Companies who have the resources may choose to build their own App-to-user API infrastructure, which we have [a guide on how to do here](https://www.courier.com/blog/the-developers-guide-user-requirements). Courier also provides a ready-to-use App-to-user API infrastructure. 

## Brand-to-user APIs

Brand-to-user communication happens any time your company has a message for a specific group of users. Maybe the product team noticed that a user got partway through the sign-up flow but didn’t hit the “complete” button. Maybe marketing wants to tell everyone in New York about an upcoming in-person event.

Braze and Customer.io are two examples of out-of-the-box Brand-to-user APIs. Engineering implements API calls in the application code that log information about user behavior, which then gets sent to a separate dashboard other teams at the company can access. Anyone on those teams can then use that data to craft and send messages to specific subsets of users. For instance, users who didn’t complete the sign-up flow, or who live in New York. Brand-to-user APIs save engineering time because, once the initial API calls are instrumented, any team who needs to send campaigns or needs to access that data can do so easily and independently.

While Brand-to-user APIs make it easy for anyone at the company to send messaging to users, they typically aren’t configurable enough to power core parts of the application experience. Messages can go out minutes to hours after user criteria for the message have been met. There can also be implementation delays any time you want to send messages based on a different set of criteria than you were using before—new API calls in the app mean the data needs time to populate before they can be used. 

While this trade-off is often worthwhile for marketing and product communications, App-to-user APIs (discussed above) are a much better fit when you need fine control over messaging content or timing within engineering.

## User-to-user APIs

User-to-user communication APIs facilitate active conversations among two or more individuals—either between a user and someone on your own internal staff or from one app user to another. 

Support tickets, for instance, are a type of User-to-user API, as are live chat boxes that let customers have direct conversations with your support or sales teams. Likewise, two users in a marketplace might need to message each other to offer bids or send along shipping information. While these are possible services to build out in-house, most companies opt to save time by going with a ready-to-use SaaS solution, such as Intercom, Zendesk, or Sendgrid.

## Conclusion

Most applications will use more than one type of user communications API for different parts of the user experience. Your application may very well use all three! 

App-to-user APIs provide part of the application’s core functionality. These APIs are highly customizable and provide instant user communication that is tightly coupled with your application code. Marketing and product teams will often want a Brand-to-user API implementation that makes it easier to see user data and send updates to users. User-to-user APIs give customers access to back-and-forth communication either among each other, or with company support or sales teams.

When you’re thoughtful about your communications strategy, you can create a seamless experience for users while also enabling everyone on your team to save time and do their best work. 

Read on for more information on building user communication API infrastructure:

* [The Developer's Guide to Building Notification Systems: User Requirements](https://www.courier.com/blog/the-developers-guide-user-requirements)

* [How to Set Up Multi-Channel Notifications in Your AWS Stack](https://www.courier.com/blog/multi-channel-notifications-aws)

*Illustration by [Rebekka Dunlap](https://rrebekkaa.com/)*


Three different people using a computer, tablet, and smartphone look up as magic surrounds them indicating the ease of communication through apis.

user-communication-apis-header

This post describes three core types of user communication APIs and in which circumstances you should use them to create the best possible end-user experience.

user-communication-apis-thumbnail

3 Types of User Communication APIs and When to Use Them

*We recently had the opportunity to speak to a student audience at Serverless Days and came up with some insights that we felt were worth sharing with a wider audience. Please take a look and let us know your thoughts [@trycourier](https://twitter.com/trycourier).* 

Serverless architecture is relatively new, yet many startup developers prefer building their foundation on a Serverless framework. But what's with the hype? What makes developers trust Serverless to the point that companies are willing to spend their resources to rewire their entire backend infrastructure to host their products on platforms like AWS, GCP, or Azure?

At AWS re:Invent 2016, Neil Hunt, acting CPO at Vibrant Planet and previously at Netflix, spoke about how the rapidly growing global company relied on AWS to deploy servers and storage efficiently. Big name companies such as Netflix, Coca Cola, and Nordstrom as well as smaller startups like Courier are using Serverless to cut down costs and build scalable tech.

There are major advantages to Serverless that cause companies of any size to become dependent upon it. This dependency ultimately allows developers to save time, preserve resources, and lessen performance issues.

## Why Students Should Get Comfortable with Serverless
Often, cloud computing companies will visit schools and host workshops to introduce students to their software. However, there aren't many institutions that teach students specifically about Serverless architecture. Even after using these services for hackathons or class projects, few students have an in-depth understanding of how Serverless works and what it can be used for.

Many students working at startups after graduation will likely encounter one of the big three: AWS, Azure, or GCP. Serverless is increasingly becoming a technology that startup software developers and product managers will need to be proficient in, to help grow their products quickly, cheaply, and reliably.

### Time
Using Serverless frameworks allows developers to build and deploy their applications from zero to production speed. Any time a product needs to be released or updated, developers no longer need to worry about managing their backend and uploading code to the server. They can simply upload or update pieces of code to the Serverless computing provider in a fraction of the time.

### Resources
In addition to time, teams can save expenses on people and products by running their code from the cloud. They can save money on getting and running servers by purchasing cloud space from Serverless companies at a fraction of the cost.

### Reliability
By allowing Serverless computing companies to manage the servers, startup developers can avoid a large amount of risk. These Serverless companies are able to store massive amounts of servers that allow their users to scale projects in seconds. Developers no longer need to worry about their applications crashing since their servers have to take excessive loads. If an application does require more servers than anticipated, the cloud will automatically increase the number of servers provided to them. Depending on Serverless architecture massively decreases the chances of a product running into any software, hardware or human faults related to servers.

Bit Project is a student organization that tackles the deficit of shared information in tech by building and hosting free coding bootcamps to help students build key skills required to succeed in tech. One of these is the Serverless Camp, in which students spend four weeks learning about the services that Azure provides and how they can use them to build various applications. For the next four weeks, students work with professional mentors from the tech industry to find and resolve a world issue using Serverless technology.

## Example Projects to Build
Several students around the world built projects using Azure Functions for the Serverless Days: Student Edition Conference hosted by Bit Project in 2021. Each student had worked extensively with mentors in the tech industry, software developers, project managers, and developer advocates, to learn about the services that Azure provides and how to integrate databases and APIs to build bots and applications using those services to solve real world problems.

### Creating a Smart Teaching Assistant on Github with Serverless - Ganning Xu

High School student, Ganning Xu, was the first to complete the Camp course and took his head start as an opportunity to find and resolve issues in the program. The Camp curriculum itself was hosted on a in-house GitHub bot. For his final project, Ganning decided to improve the overall experience of the bot for both students and mentors by adding more features, bug fixes, and transferring the code to host the bot as a Serverless function.

### Building a Knowledge Base for Online Classes - David Tetreau

Another student, David Tetreau, was a military veteran and had shown a special interest in improving the online learning experience for new programmers. By using the Slack Bolt framework, Node.js, JavaScript, and Serverless web app hosting, David built a solution to save time and increase productivity.

His project, a Serverless Slack Bot, helps alleviate the stress of virtual team communication, and helps boost productivity. The bot maintains and updates a single knowledge base, monitors channels for keywords, and responds to inquiries with those words in threaded conversations with users.

### Go Eat! Meal Reminders with Serverless - Beatrix Cendana

Beatrix Cendana, originally a writer, wanted to build more technical skills and become a technical writer. While balancing a hectic schedule, Beatrix discovered a need for a product that can help generate random recipes for daily cooking and timely reminders for regular meals. She decided to create an SMS feature with the Twilio API that can remind people to eat based on a proper schedule and add the feature to help them get the random recipes.

Watch the full [Serverless Days: Student Edition 2021 Conference](https://youtu.be/l_1BhV-dtMk), where five of the students from the Serverless Camp present lightning talks including the inspirations behind their application ideas, journey to building it, and demo of the working application. Students also talk about their experience working with external APIs, databases, and their mentors.

These students are an example of how quickly programmers can pick up Serverless architecture, get started building their own applications, and become experts in the field. These skills can be valuable in various roles across tech that require extensive knowledge of cloud computing and deploying applications on providers like AWS, GCP, Azure, etc.


serverless-hype-header

Companies' dependency on Serverless allows developers to save time, preserve resources, and lessen performance issues during the engineering process.

Courier [Notifications Landscape]

Build your first notification in minutes

Build your first notification in minutes

Platform

Use Cases

Explore

Company