Fazza Profile

Fazza Razaq Amiarso

## Background
A lot of open-source invoice management apps are built with Laravel. As a Javascript developer, I wanted to build the “React Solution” for devs that are familiar with React and Javascript.

A problem I found when building with services in Node.js is that there is no built-in mailer. So, I had to find a 3rd party service to do that for me. In this article, I will be integrating [Courier](https://www.courier.com/) to send emails for this project [https://github.com/fazzaamiarso/invoys](https://github.com/fazzaamiarso/invoys).  

## Pre-requisites
As this article isn't your typical follow-along (more like "please sit tight and see how I do it"), it's not mandatory to be familiar with all technologies used. However, familiarity with Typescript and Next.js will be beneficial for quicker understanding.

Technologies in this blog:
- [Typescript](https://www.typescriptlang.org/): type-safety and auto-completion are the best, right? 
- [Next.js](https://nextjs.org/): a production-ready framework to build a full-stack app, even for beginners.
- [Prisma](https://www.prisma.io/): a great ORM to work with databases. We use Prisma because of its type-safety and auto-completion, providing great developer experience with typescript added.
- [Trpc](https://trpc.io/): enable us to easily build end-to-end type-safety between our Next.js client and server.
- Courier API: a great service/platform to handle our notifications, such as email, SMS, and much more.

You can find the full [source code here](https://github.com/fazzaamiarso/invoys/tree/bc231301c92bb07692a3388bb50d76d61603a41f) for reference.

### Goals
Before building the features, let's define our goals.
1. Send invoice link to client's email.
2. Send a reminder a day before an invoice's due date.
3. Cancel an invoice due date reminder when the invoice is already paid.
4. Handling network errors.

### Part 1: Setup Courier Platform
Let's head over to the Courier Dashboard. By default, it's in a production environment. Since I want to test things out, I'm going to change to the test environment by clicking the dropdown in the top-right corner.

> We can copy all templates later to production or vice-versa.

Now, I will create a [**brand**](https://www.courier.com/docs/getting-started/courier-concepts/#brands) for my email notifications.

![go to brand](https://i.imgur.com/1Us0dzC.gif)

I'm just going to add a logo (beware that the logo width is fixed to 140px) on the header and social links on the footer. The designer UI is pretty straightforward, so here is the final result. 

<img src="https://i.imgur.com/sFrofll.png" alt="brand template" width="500px" />

Don't forget to publish the changes.

### Part 2: Send Invoice to Email
Currently, the send email button on the UI is doing nothing.

I'm going to create a `courier.ts` file in `src/lib/` to keep all Courier-related code. Also, I will use [courier node.js client library](https://github.com/trycourier/courier-node) which already abstracted all Courier API endpoints to functions.

Before I build the functionality, let's create the email notification design within Courier's Designer and set up the Gmail provider.

On the email designer page, we will see that the created brand is already integrated. After that, let's design the template accordingly with the needed data. Here is the final result.

<img src="https://i.imgur.com/qFhHvAP.png" alt="email template final" width="500px" />

<img src="https://i.imgur.com/B6vKjpH.png" alt="action button" width="500px" />

Notice the value with `{}` that becomes green, it means it's a variable that can be inserted dynamically. I also set the 'See Invoice' button (or action) with a variable.

Before I can use the template, I need to create a *test event* by clicking the preview tab. Then, it will show a prompt to name the event and set `data` in JSON format. That data field is what will populate the value of the green `{}` variables (the data can be set from code also). Since it's a test event, I will fill it with arbitrary values.

Next, I will publish the template so I can use it. Then, go to send tab. It will show the necessary code to send the email programmatically and the `data` will be populated with the previous *test event* that I created. 

<img src="https://i.imgur.com/PMGcVQq.png" alt="code snippet" width="500px" />

#### Backend
I will copy the test `AUTH_TOKEN` to the `.env` file and copy the snippet to `src/lib/courier.ts`.

```ts
const authToken = process.env.COURIER_AUTH_TOKEN;

// email to receive all sent notifications in DEVELOPMENT mode
const testEmail = process.env.COURIER_TEST_EMAIL;

const INVOICE_TEMPLATE_ID = <TEMPLATE_ID>;

const courierClient = CourierClient({
  authorizationToken: authToken,
});
```

Create a `sendInvoice` function that will be responsible for sending an email. To send an email from the code, I use the `courierClient.send()` function.

```ts
// src/lib/courier.ts

export const sendInvoice = async ({
  customerName,
  invoiceNumber,
  invoiceViewUrl,
  emailTo,
  productName,
  dueDate,
}: SendInvoice) => {

const recipientEmail = process.env.NODE_ENV === "production" ? emailTo : testEmail;

const { requestId } = await courierClient.send({
      message: {
        to: {
          email: recipientEmail,
        },
        template: INVOICE_TEMPLATE_ID,
        // Data for courier template designer
        data: {
          customerName,
          invoiceNumber,
          invoiceViewUrl,
          productName,
          dueDate,
        },
      },
    });
    return requestId
};
```

Define types for the `sendInvoice` function.

```ts
// src/lib/courier.ts

interface SendInvoice {
  productName: string;
  dueDate: string;
  customerName: string;
  invoiceNumber: string;
  invoiceViewUrl: string;
  emailTo: string;
}
```

Now that I can send the email, I will call it in the `sendEmail` trpc endpoint that resides in `src/server/trpc/router/invoice.ts`.

> Just remember that trpc endpoint is a Next.js API route. In this case, `sendEmail` will be the same as calling the `/api/trpc/sendEmail` route with `fetch` under the hood. For more explanation [https://trpc.io/docs/quickstart](https://trpc.io/docs/quickstart).

```ts
// src/server/trpc/router/invoice.ts
import { sendInvoice } from '@lib/courier';
import { dayjs } from '@lib/dayjs';

// .....SOMEWHERE BELOW
  sendEmail: protectedProcedure
    .input(
      z.object({
        customerName: z.string(),
        invoiceNumber: z.string(),
        invoiceViewUrl: z.string(),
        emailTo: z.string(),
        invoiceId: z.string(),
        productName: z.string(),
        dueDate: z.date(),
      })
    )
    .mutation(async ({ input }) => {
      const invoiceData = {
        ...input,
        dueDate: dayjs(input.dueDate).format('D MMMM YYYY'),
      };

      await sendInvoice(invoiceData);
    }),
```

For those who are unfamiliar with trpc, what I did is the same as handling a `POST` request. Let's break it down.

1. Trpc way of defining **request input from client** by validating with Zod. Here I define all data that are needed for the `sendInvoice` function.

```ts
.input(
      z.object({
        customerName: z.string(),
        invoiceNumber: z.string(),
        invoiceViewUrl: z.string(),
        emailTo: z.string(),
        invoiceId: z.string(),
        productName: z.string(),
        dueDate: z.date(),
      })
    )
```

2. Define a `POST` request handler (mutation).

```ts
// input from before
 .mutation(async ({ input }) => {
      const invoiceData = {
        ...input,
        // format a date to string with a defined format. 
        dueDate: dayjs(input.dueDate).format('D MMMM YYYY'), // ex.'2 January 2023'
      };

      // send the email
      await sendInvoice(invoiceData);
    }),
```

#### Frontend
Now, I can start to add the functionality to the send email button. I'm going to use the `trpc.useMutation()` function which is a thin wrapper of `tanstack-query's `useMutation`.

Let's add the mutation function. On successful response, I want to send a success toast on UI.

```tsx
//src/pages/invoices/[invoiceId]/index.tsx
import toast from 'react-hot-toast';

const InvoiceDetail: NextPage = () => {
// calling the `sendEmail` trpc endpoint with tanstack-query.
  const sendEmailMutation = trpc.invoice.sendEmail.useMutation({
    onSuccess() {
      toast.success('Email sent!');
    }
  });

}
```

I can just use the function as an inline handler, but I want to create a new handler for the button.

```tsx
//src/pages/invoices/[invoiceId]/index.tsx

 // still inside the InvoiceDetail component
 const sendInvoiceEmail = () => {
    const hostUrl = window.location.origin;

   // prevent a user from spamming when the API call is not done.
    if (sendEmailMutation.isLoading) return;

    // send input data to `sendEmail` trpc endpoint
    sendEmailMutation.mutate({
      customerName: invoiceDetail.customer.name,
      invoiceNumber: `#${invoiceDetail.invoiceNumber}`,
      invoiceViewUrl: `${hostUrl}/invoices/${invoiceDetail.id}/preview`,
      emailTo: invoiceDetail.customer.email,
      invoiceId: invoiceDetail.id,
      dueDate: invoiceDetail.dueDate,
      productName: invoiceDetail.name,
    });
  };
```

Now I can attach the handler to the send email button.

```tsx
//src/pages/invoices/[invoiceId]/index.tsx

<Button
   variant="primary"
   onClick={sendInvoiceEmail}
   isLoading={sendEmailMutation.isLoading}>
   Send to Email
</Button>
```

Here's the working UI.

<img src="https://i.imgur.com/ush8wdI.gif" alt="working ui" width="500px" />

### Part 3: Send Payment Reminder
To schedule a reminder that will be sent a day before an invoice's due date, I'm going to use [Courier's Automation API](https://www.courier.com/docs/automations/). 

First, let's design the email template in Courier designer. As I already go through the process before, here is the final result.

<img src="https://i.imgur.com/4l6shqK.png" alt="payment reminder template" width="500px" />

Before adding the function, define the types for the parameter and refactor the types.

```tsx
// src/lib/courier

interface CourierBaseData {
  customerName: string;
  invoiceNumber: string;
  invoiceViewUrl: string;
  emailTo: string;
}

interface SendInvoice extends CourierBaseData {
  productName: string;
  dueDate: string;
}

interface ScheduleReminder extends CourierBaseData {
  scheduledDate: Date;
  invoiceId: string;
}
```

Now, I add the `scheduleReminder` function to `src/lib/courier`

```tsx
//src/pages/invoices/[invoiceId]/index.tsx

// check if the development environment is production
const __IS_PROD__ = process.env.NODE_ENV === 'production';

const PAYMENT_REMINDER_TEMPLATE_ID = '<TEMPLATE_ID>';

export const scheduleReminder = async ({
  scheduledDate,
  emailTo,
  invoiceViewUrl,
  invoiceId,
  customerName,
  invoiceNumber,
}: ScheduleReminder) => {

  // delay until a day before due date in production, else 20 seconds after sent for development
  const delayUntilDate = __IS_PROD__
    ? scheduledDate
    : new Date(Date.now() + SECOND_TO_MS * 20);

  const recipientEmail = __IS_PROD__ ? emailTo : testEmail;

   // define the  automation steps programmatically
   const { runId } = await courierClient.automations.invokeAdHocAutomation({
     automation: {
       steps: [
         // 1. Set delay for the next steps until given date in ISO string
          { action: 'delay', until: delayUntilDate.toISOString() },

          // 2. Send the email notification. Equivalent to `courierClient.send()`
          {
            action: 'send',
            message: {
              to: { email: recipientEmail },
              template: PAYMENT_REMINDER_TEMPLATE_ID,
              data: {
                invoiceViewUrl,
                customerName,
                invoiceNumber,
              },
            },
          },
        ],
      },
    });

   return runId;
};
```

To send the reminder, I will call `scheduleReminder` after a successful `sendInvoice` attempt. Let's modify the `sendEmail` trpc endpoint.

```tsx
// src/server/trpc/router/invoice.ts

sendEmail: protectedProcedure
    .input(..) // omitted for brevity
    .mutation(async ({ input }) => {
      // multiplier for converting day to milliseconds.
      const DAY_TO_MS = 1000 * 60 * 60 * 24;

      // get a day before the due date
      const scheduledDate = new Date(input.dueDate.getTime() - DAY_TO_MS * 1);

      const invoiceData = {..}; //omitted for brevity

      await sendInvoice(invoiceData);

      //after the invoice is sent, schedule the reminder
      await scheduleReminder({
        ...invoiceData,
            scheduledDate,
      });
    }
```

Now if I try to send an invoice by email, I should get a reminder 20 seconds later since I'm in the development environment.

<img src="https://i.imgur.com/MfwQ6F0.png" alt="with payment reminder" />

### Part 4: Cancel a reminder
Finally, all the features are ready. However, I got a problem, what if a client had paid before the scheduled date for payment reminder? Currently, the reminder email will still be sent. That's not a great user experience and potentially a confused client. Thankfully, Courier has an automation cancellation feature.

Let's add `cancelAutomationWorkflow` function that can cancel any automation workflow in `src/lib/courier.ts`.

```ts
export const cancelAutomationWorkflow = async ({
  cancelation_token,
}: {
  cancelation_token: string;
}) => {
    const { runId } = await courierClient.automations.invokeAdHocAutomation({
      automation: {
        // define a cancel action, that sends a cancelation_token
        steps: [{ action: 'cancel', cancelation_token }],
      },
    });

   return runId;
};
``` 

What is a cancelation_token? It's a unique token that can be set to an automation workflow, so it's cancelable by sending a `cancel` action with a matching `cancelation_token`. 

Add cancelation_token to `scheduleReminder`, I use the invoice's Id as a token.

```ts
// src/lib/courier.ts

export const scheduleReminder = async (..) => {
  // ...omitted for brevity

  const { runId } = await courierClient.automations.invokeAdHocAutomation({
    automation: {
      // add cancelation token here
      cancelation_token: `${invoiceId}-reminder`,
      steps: [
        { action: 'delay', until: delayUntilDate.toISOString() },

  // ... omitted for brevity
``` 

I will call `cancelAutomationWorkflow` when an invoice's status is updated to `PAID` in the `updateStatus` trpc endpoint. 

```ts
// src/server/trpc/router/invoice.ts

 updateStatus: protectedProcedure
    .input(..) // omitted for brevity
    .mutation(async ({ ctx, input }) => {
      const { invoiceId, status } = input;

      // update an invoice's status in database
      const updatedInvoice = await ctx.prisma.invoice.update({
        where: { id: invoiceId },
        data: { status },
      });

      // cancel payment reminder automation workflow if the status is paid.
      if (updatedInvoice.status === 'PAID') {

        //call the cancel workflow to cancel the payment reminder for matching cancelation_token.
        await cancelAutomationWorkflow({
          cancelation_token: `${invoiceId}-reminder`,
        });
      }

      return updatedStatus;
    }),
```

Here is the working UI.

<img src="https://i.imgur.com/jnLk4Tg.gif" alt="cancel log" width="500px" />

### Part 5: Error Handling
An important note when doing network requests is there are possibilities of failed requests/errors. I want to handle the error by throwing it to the client, so it can be reflected in UI.

On error, Courier API throws an error with `CourierHttpClientError` type by default. I will also have all functions' return value in `src/lib/courier.ts` consistent with the below format.

```ts
// On Success
type SuccessResponse = { data: any, error: null }

// On Error
type ErrorResponse = { data: any, error: string }
``` 

Now, I can handle errors by adding a `try-catch` block to all functions in `src/lib/courier.ts`.

```ts
try {
  // ..function code

  // modified return example
  return { data: runId, error: null };

} catch (error) {
  // make sure it's an error from Courier
  if (error instanceof CourierHttpClientError) {
      return { data: error.data, error: error.message };
    } else {
      return { data: null, error: "Something went wrong!" };
    }
}
```

Let's see a handling example on the `sendEmail` trpc endpoint.

```ts
// src/server/trpc/router/invoice.ts

  const { error: sendError } = await sendInvoice(..);
  if (sendError) throw new TRPCClientError(sendError);

  const { error: scheduleError } = await scheduleReminder(..);
  if (scheduleError) throw new TRPCClientError(scheduleError);
```

### Part 6: Go To Production
Now that all templates are ready, I will copy all assets in the test environment to production. Here is an example.

<img src="https://i.imgur.com/Mr3bmuH.gif" alt="copy assets to production" width="500px" />

## Conclusion
Finally, all the features are integrated with Courier. We've gone through a workflow of integrating Courier API to a Next.js application. Although it's in Next.js and trpc, the workflow will be pretty much the same with any other technology. I hope now you can integrate Courier into your application by yourself.

Get started now: https://app.courier.com/signup

## About the Author
I'm Fazza Razaq Amiarso, a full-stack web developer from Indonesia. I'm also an Open Source enthusiast. I love to share my knowledge and learning [on my blog](https://fazzaamiarso.me/). I occasionally help other developers on [FrontendMentor](https://www.frontendmentor.io/profile/fazzaamiarso) in my free time.

Connect with me on [LinkedIn](https://www.linkedin.com/in/fazzaamiarso/).

## Quick Links

🔗 [Courier Docs](https://www.courier.com/docs/)

🔗 [Contribute to Invoys](https://github.com/fazzaamiarso/invoys)

🔗 [Invoys Motivation](https://fazzaamiarso.me/projects/invoys)

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!

Abstract bank vault with gold coins and locked up boxes guarded by Courier's logo.

Invoys Header

Invoice management tutorial by Courier community developer

Invoys Thumbnail

How to Send Invoice and Add Payment Reminder in Next.js with Courier API

Aman profile pic

Aman Kandola

How do you fairly compensate your employees for a job well done? It’s a question that often gets ignored in favor of the bottom line and one that not enough companies talk about. 

We’ve never been shy about discussing some of the perks and benefits that come with being a Courier employee, but we’ve never detailed our approach to compensation. It’s time we changed that.

We recently received another round of funding and plan to grow our team quite a bit in the near future. And our compensation policy needs to be organized and fair in order to reach that goal. 

We’ve also officially become a fully remote company. This affects how we fairly compensate employees—do we offer the going rate where our employees live? The going rate of the area where our headquarters is located? Every remote team approaches this issue differently.

Our compensation policy and leveling framework are critical for Courier’s success. Here’s how we make it work. 
## Salaries Stay in the 90th Percentile
Everyone wants to know how much a job pays before anything else. That’s probably never going to change. 

At Courier, we know our employees make this organization a success. And salaries allow our employees to live and enjoy their lives. We also want to attract and retain top talent, so we offer new employees salaries in the 90th percentile of San Francisco’s local market rates. We also keep current employees in the same range to keep turnover low and retain our incredible people.
Our compensation philosophy at Courier has historically been to target the 90th percentile of market rates. That sounds great, but determining exactly what that means isn’t easy. It can be a complicated process, so we’ll walk you through the factors we consider. 
First, market rates vary by location. The 90th percentile for a software engineer in California is different from Kansas. So, even though we’re now a fully remote team that hires employees around the globe, we had to choose a location to base our compensation on. Since we originated in the Bay Area, our employees are compensated based on San Francisco’s local market rates. 
We also consider more factors like the job title and level, as well as our company’s stage—for example, small startups obviously don’t usually pay the same as large enterprises. We are currently in between these two stages, so we need to factor that in while we’re building out our team. We use datasets from our own company history to make comparisons against going rates for similar roles at other organizations.
Obviously, there’s room for error here, and the datasets we use from our own employee history are small. But we find that these factors help us keep the most important elements in mind as we decide on compensation going forward. 
## Salary Bands Help Us Reward Top Performers 
When it comes to employee development and advancement, we want employees to be empowered at Courier. And we want everyone to pursue the track that works for them. Promotions are largely determined by individual performance but not just individual performance. The needs of the team and business as a whole are also large factors in our employees leveling up.
We review compensation for each level and role during the second quarter of each year. And every time we hire for a role, we try to review our compensation banding and update it to ensure we’re truly offering our candidates the 90th percentile of the market rate.
Many of our employees increase their level without becoming managers. We believe that excellence should be rewarded and that not every employee’s career path looks the same. There are many ways to contribute and develop as part of the team at Courier. That’s why we don’t require employees to be on a management track to get to a new compensation level. 
Specific titles and expectations for each employee are decided by each team rather than at the company level. There are some nuances to each role and performance that only a supervisor or other co-worker involved in the day-to-day work can effectively evaluate. That’s why we leave the final say to the supervisors running the team. 
## Additional Benefits Sweeten the Deal
While salaries are very important—we all need to eat—we know it’s not the only aspect of compensation that matters to employees. Other benefits play an important role in attracting and keeping employees. 

We offer unlimited paid time off (that includes vacation time as well as sick days). Of course, we also offer robust medical insurance benefits for employees, including vision and dental. For parents who’ve just welcomed a new child into their home, we offer 14 weeks of fully paid parental leave.

As we mentioned above, we have shifted to a fully remote company, so our employees can work from anywhere. That’s a major benefit that can attract serious talent. The most recent Gallup survey on the issue of remote vs. onsite work found that [34% of employees prefer to be fully remote](https://www.gallup.com/workplace/397751/returning-office-current-preferred-future-state-remote-work.aspx), yet many organizations are still pushing their employees to return to shared offices. As a remote-first company, our potential employees know that we will never force them to go to an office.

To ensure our employees have everything they need in their respective office spaces, we offer a home office stipend. We also pay for a DashPass for all employees to make ordering lunch throughout the week a little more affordable. And on Fridays, we buy our employees lunch just to say thank you and start their weekends on a high note.   
## Company Culture Plays a Big Role in Our Compensation Philosophy
As we define compensation for roles and work to recruit the best employees for those roles, our philosophy keeps us focused on fair compensation and benefits. But we also want to acknowledge that there will always be a subjective element to salaries and the promotion process. This fact often makes people uneasy because it can easily lead to favoritism and competition between teams. In our experience, the best way to avoid that problem is by building a healthy, inclusive work culture. 
Attracting the best employees to your organization and keeping them around requires a space where support and collaboration are normalized. We lead by example and share our leadership's decision-making process when we make big decisions.
What we’ve shared with you is an early framework for Courier. We will continue to iterate on this just like we do with everything else. Expect this to evolve as we grow.
And if you’re interested in learning more, you can read about what it’s like to work at Courier by visiting our [careers page](https://www.courier.com/careers/). 


Abstract illustration of people in tech working together remotely.

Compensation Header

Courier's approach to hiring and compensation.

Compensation Thumbnail

How We Attract Top Talent at Courier

Anwesa Chatterjee

Notifications are an essential building block of every modern application and are now a core part of the user experience. They let you interact with your users by, for example, alerting them to potential risks, informing them about new product features, or simply engaging them through friendly check-in messages. Care must be taken, however — from the user’s viewpoint, the line between being engaged by relevant, timely notifications and feeling harassed can be thin. That’s why it’s so crucial to customize your [notification experience](https://www.courier.com/blog/pm-product-notification-experience/) to your users’ individual needs. 

Using automation tools, developers can implement the kind of thoughtful, tailored notification experience that your users want. In this post, you will learn the different ways in which low-code and no-code automation tools help you build a better notification experience, while taking the burden of implementing the complex logic off your engineers’ shoulders. 

## Customization through automation
Automated functionalities like audience filters, complex workflows, and channel routing help you craft notification experiences that your users will happily engage in. Historically, these features come at a cost — the more customizability you want to include in your notification experience, the more resources are required to implement and maintain those features in your code base. 

As a product manager, you need to think about how you can enable your developers to set up a notification logic that provides your users with a bespoke and smooth notification experience — without having to significantly rework your code base to support every customization you’ll potentially require. To achieve this, integrating existing tools with robust automation is key.

The first step towards automated customization is to understand what your users want and need. To that end, it’s useful to analyze how your users perceive the messages you send them — both through data [analytics](https://www.courier.com/blog/pm-guide-omnichannel-analytics/) and by asking your users directly. You can then use that knowledge to send them helpful tips at the right time, as opposed to just sending out blanket notifications.

![pm-guide-automations-1](//images.ctfassets.net/z7iqk1q8njt4/73USDva4STQ0TQE6ywG9ug/c2fe456c7449be4b02a889a67ef1702c/image1.png)

Once you have established your requirements, you need to choose and implement the right tools. Automation tools come with dynamic configuration capabilities that let you tailor your notification experience to the individual needs of different users. By integrating finer-grained customization into your notification logic, you can ensure the relevance of your notifications to your customers. Here are a few examples of a customized notification experience:

* **Targeted announcements:** Rather than sending out feature announcements indiscriminately, they only arrive in the inboxes of customers whose user profile signals that they might have an interest — and who are not already using said feature. 
* **Multi-channel notifications:** Critical alerts should reach the right person at the right time — with multi-channel notifications, the notification logic picks the most suitable channel and sending time to ensure that users see the message and can react accordingly
* **Tailored content:** To avoid spamming users with content they have no interest in, organizations can tailor the subject matter, channel, and timing of their digests so that the people who receive them will actually want to engage with them.

## Strategies for automation
To make sure that your users get the best notification experience possible, your developers should employ multiple customization strategies in a way that will result in a much more personal feel. Let’s have a closer look at the three core strategies behind user notification customization:

### Audience
Many notification systems use lists to organize their user data. Lists allow you to put user profiles into cohorts, according to different criteria — for instance, their profession or their place of residence. You can then use these lists to send out notifications that are targeted towards a specific group and thus feel more relevant than a one-for-all message. But do you know what’s even better than lists? Audiences!

With [audiences](https://www.courier.com/docs/reference/audiences/), you can define user cohorts dynamically based on a set of criteria. Rather than working with static lists of users, you can quickly filter your users’ profiles to assemble an audience. For instance, you’d only want to send out notifications about a holiday-related sale to people located somewhere where that particular holiday is celebrated. Since your users’ location data is subject to change, it makes sense to use a dynamic audience filter rather than a static list.

![pm-guide-automations-2](//images.ctfassets.net/z7iqk1q8njt4/1s1Tk6e0hlH6q5VpqsJFtA/60a044a826f14ea5de9ba86b2966fbc5/image3.png)

Another useful basis for filtering is usage data: Let's say you want to distribute instructions on how to set up video calls faster. Getting this information in your inbox may seem like a godsend to those users who have been using a time-consuming call setup process up until now. On the other hand, it's useless for those who either already use your feature or haven't shown any interest in video calls in the past.

Audience filters are a prime example of how user data, when collected and stored in a safe and [GDPR-compliant manner](https://www.courier.com/blog/gdpr-communications/), can be used to improve your users’ lives by offering them a more tailored and meaningful notification experience. 

### Multichannel routing
*When* and *where* are two factors that contribute immensely to how a user perceives the notification experience. As we’ve highlighted throughout this series, receiving a message at the wrong time or through the wrong channel can create a lot of frustration for users. Choosing the right channel and time, on the other hand, can go a long way towards providing a satisfying notification experience that integrates seamlessly into your users’ lives.

[Preference management](https://www.courier.com/blog/pm-guide-to-preference-management/) with high customizability is extremely important, as it gives your users a sense of control over how and when they are notified. Additionally, your organization may apply its learnings about which channels work best under which circumstances towards building a complex routing system. 

With [multi-channel routing](https://www.courier.com/docs/guides/tutorials/how-to-configure-multi-channel-routing/), you can specify a ranking order for notification channels. For example, you can show a notification in the browser first, and if the user isn’t online, or has disabled in-browser notifications, you can send them a push notification to their phone.

### Complex workflows
Notifications should rarely be statically defined. Rather, you should identify where your users are in their product journey, and send them messages that support, help and encourage them. Workflows help you respond to the different paths a user’s journey with your product might take. 

As an example, let’s take someone signing up as a new user to your service. You’ll probably want to send them a friendly welcome message through their preferred notification channel. Then, if your new sign-up doesn’t interact with your application within a certain time-span, you might want to opt for a gentle reminder by sending them a [push notification](https://www.courier.com/blog/perfect-mobile-push-notification/) or Slack message that details some first actions they could take. Finally, you could reach out to them via email (perhaps after a week or so of inactivity) and suggest that they schedule an appointment with a team member to address the issues that are keeping them from using your product. This gentle escalation encourages your new user to engage without bombarding them with alerts.

![pm-guide-automations-3](//images.ctfassets.net/z7iqk1q8njt4/3bqnv3dUpR30ttUbAPXJSs/5778fbeaa848dec09ec754bf714c71ba/image2.png)

Thanks to [triggers](https://www.courier.com/docs/automations/triggers/) and other notification logic, you can build complex workflows that allow you to match the different experiences your users might have with your product. Such complex workflows are an example of how automation can actually provide a more personalized feel than mainly static notification procedures that were implemented manually.

## When does it make sense to send notifications manually?
Automation should be at the core of your notification functionality. As the number of users grows, it becomes much harder to manually implement the notification logic required to cultivate a steady and happy user base.

Nevertheless, there are cases when it makes sense to send notifications without the help of an automation tool. You primarily need manual notifications for one-time events — such as device login notifications, password resets, product updates, and company announcements.

Notably, such notifications are relatively independent of your users’ actual product journey, as they are determined by what your organization needs to communicate to its users regardless of their notification preferences. For example, a user must be made aware of a potential data leak irrespective of their notification preferences. However, this type of notification should be few and far between. The focus of notifications should always remain the user’s experience with the product — and everything related to that can actually be automated. 

## To automate or not to automate?
We now have a strong case for automating your notification logic. Automation benefits your users by giving them a more customized and satisfying experience. It also benefits your developers, who can go back to focusing on your product’s core features, knowing that the notification logic is taken care of.


pm-guide-automations-header

Tailored notifications are essential for a positive user experience. Learn how automation tools make it easy to customize user notifications.

pm-guide-automations-thumbnail

How to Optimize Your Notification Logic with Automations

Web analytics are a standard for online businesses, and product managers rely heavily on web analytics data when making product decisions. Stats like website traffic, conversions, in-app events, or unique users are frequently used as indicators of business health, because they help identify if the product is moving in the right direction or not.

With notifications, however, analytics are a different story. While the notification experience tends to be one of the key parts of product functionality, notification analytics are rarely available — and even when they are, it’s usually not so straightforward to get relevant insights out of the data. But without notification analytics, most companies are “flying blind” on their notification experience and don’t know how to improve it over time.

In this article, we talk about omnichannel analytics, why analytics are hard for notifications, and what we believe is needed to empower PMs. We’ll also share some specific tips on making the best of analytics data to design a more informed notification experience for your users.

## What is omnichannel analytics?
Single data points on their own are not very informative, but in aggregate, they can tell a powerful story. Analytics is the art of assembling raw data from your product in a meaningful way. For instance, you could aggregate event data collected in an app, and infer from it which of the app’s features are most popular among your users. You can then use those insights to propel your product further by expanding the features that your users like, and retiring those they don’t. In short, analytics helps you forecast and shape the future by understanding the past and present.

These days, most businesses communicate with their customers through multiple channels: email, push notifications, SMS, and messages on social media complement more traditional means of communication like phone calls and letters. With that many options for reaching out to your customers, it’s insufficient to look at only one channel if you want to gain insights about how a specific communication strategy is working. 

If you use a multi-channel strategy to communicate with your customers, it’s typically not helpful to look at those channels in isolation. Your customers might ignore your newsletters in their email inbox, but perhaps that’s because they have already seen and liked your announcements on a social media platform? So the most sensible way of doing analytics is to group messages by content, rather than by channel. So in omnichannel analytics, you look at your users’ interactions with your product holistically, across channels. 

![single-channel-vs-omnichannel](//images.ctfassets.net/z7iqk1q8njt4/2mRenvWGbkuJRYHdnXqUTL/857b5011db4a2bfb924164145d6722f4/image2.png)

## Analytics for notifications
Notification data means specifically how your users interact with your notifications. Do they click on an email as soon as they receive it? Do they swipe your push notifications away from their home screens? By doing analytics on notification data, you can understand which communication strategies work well, and which don’t.  

The notification experience that your users have with your product can have a huge influence on whether or not they will continue to use it. Sending too many notifications through unsuitable channels or at the wrong time can cause such a bad experience for users that they start looking for better alternatives. A good experience, on the other hand, will go a long way towards a happy and sustained user base.

A central metric in notification analytics is the open-rate: it quantifies how many users opened a notification within a certain time span of sending it. A low open-rate means that you’ll have to think about changing your strategy — perhaps by sending fewer notifications, using different channels, or updating your content. As outlined earlier, an analytics strategy that takes multiple channels into account can deliver more insights. But before we talk about that, let’s quickly have a look at the specifics of notification data.

### The difficulties of obtaining notification data
Data is the basis for all analytics — but it can be hard to get our hands on the kind of data we need to perform analytics on notifications. Apple’s iOS, for example, doesn't allow developers to precisely track impressions of push notifications on their users’ devices. With SMS messages, there is no analytics at all: you can know what messages you sent, but you don’t have any guarantee that users received them.

## What we really need for PM empowerment: omnichannel analytics
To get a holistic picture of their customers’ notification experience, PMs need to know how different notifications fare across channels. 

This is especially true given that the future will bring [more notification preferences](https://www.courier.com/blog/pm-guide-to-preference-management/) and flexibility for each user. As everyone’s notification experience becomes more personal, PMs will need to move to analytics that are grouped by notification content, rather than by channel. For example, all notifications about new mentions in a document app should be presented together in an analytics dashboard, regardless of whether the notifications were sent via email, Slack, or mobile push depending on each user’s preferences. But in order to enable omnichannel analytics for notifications, PMs have to overcome a few hurdles.

![pm-guide-omnichannel-analytics-2](//images.ctfassets.net/z7iqk1q8njt4/3NjBPbLLPiweXq496G9Tse/d4e6094413b211492430dbd0e92b7a02/image1.png)

For channels where notification data is hard to obtain, developers can use reliable proxy data points, which help them approximate the data they’re really looking for. Read on to learn more.

## How to get omnichannel analytics in your application
To be able to get omnichannel analytics, you will need to have the right data in place and be able to pull reports in the right format. Here are the steps that we recommend following to get there.

### Implement analytics for each channel — as much as possible
Of course, the first step is to collect whatever data you can reasonably collect around notification usage, while respecting relevant privacy regulations and creating as little inconvenience to the user as possible. For example, when sending emails via a third-party email platform like SendGrid or AWS SES, the following are a few of the data points that you should consider collecting:

* For each email notification sent: recipient, date, subject, attachments
* Open and click metrics
* Statistics on unsubscribes
* Statistics on complaints

Note that not all of this data will be available from every platform, and different platforms might use different terms to describe the same metrics.

For some channels, it will not be possible to collect direct data for notification interactions. In such cases, you will need to come up with proxy data points: that is, data that may not be directly what you need but that can be used to infer the metrics that you care about. For example, in the case of SMS messages that have no analytics at all, you can assume a specific open rate based on industry benchmarks, or insert a link which you can track clicks on. You can then calculate an approximate open rate throughout your customer base.

Some channels have well-established workarounds for tracking. In emails, for example, it’s common to use web beacons, also known as tracking pixels. These are usually implemented as tiny images hosted on a third-party web server, and when a user opens the email, the email client loads that resource from the third-party server, which indicates to the sender that the recipient has opened the email. Such solutions don’t always work, however: users can disable images in emails, and iOS’s built-in mail application has a setting that prevents such tracking from working. There are other tracking techniques, like adding user-specific information to all links in the email, so if a link is clicked, it is straightforward to know which user the interaction came from.

### Ensure data quality
To generate trustworthy reports about notifications, you will need to be confident in the data the reports rely on. Even though some data might be based on proxy metrics, as we discussed above, you need to be convinced that those are the best proxy metrics to use in your specific situation.

In addition, spend some time to understand possible limitations of source data — maybe there is a delay in the stats that some systems give you, or maybe there are sometimes empty rows in the data. You need to account for that ahead of time so you don’t run into issues later.

### Identify how you’ll cross-reference stats between channels
The implementations of notification channels like email, chat, or SMS don’t know anything about the content of the notification you’re sending.

To be able to cross-reference the same kinds of notifications across channels you’ll need to create an identifier — for example, a unique ID number — for each notification. Such IDs need to be the same across multiple channels so that you can group them together later when generating reports.

### Transform all data to a common format
In order to look at multiple channels together, you must have all the data available in a single report, dashboard, or spreadsheet, but that’s not that straightforward because different providers present data differently in their statistics. To be able to look at all data points across channels together, you will need to transform all data into a standardized format, for example, through an ETL [pipeline](https://en.wikipedia.org/wiki/Extract,_transform,_load).

Once the data is transformed, you can use any reporting or business analytics system that you already use — for example, Looker, Tableau, or Excel — to look at all the data points together.

### Group by notification identifier — or eventually topics or notification types
Now that you have all the data in a single place and in the same format, and you also have a way to cross-reference notifications across channels, you can group data points by notification ID (or a similar identifier) across channels. You can then group this data across topics or types of notifications. For example, you might want to see all lifecycle notifications on one dashboard, and all transactional notifications on another dashboard.

## Next step: use analytics to make better notifications
Having access to analytics for notifications is an achievement in itself, but remember that you’re doing it with an end in mind: to make your notifications better.

Now that you have data on notifications across channels, here are a few ways you can use the omnichannel data to identify opportunities to fix or improve your notification experience.

### Identify opportunities for improvement
Consider which existing notifications have a lot of engagement. What can you learn from this? Is there any way you can replicate the success of such notifications in other parts of your notification experience?

In contrast, which notifications currently have little engagement from users? Maybe that’s a sign that these notifications need to be reworked or removed, or that you’re sending too many notifications.

Another question that can help identify opportunities is which notifications do your best customers receive the most? The “best” part here is up for interpretation according to your business goals — maybe it’s top customers by revenue, or by their level of engagement, or by another metric. Is there a connection between receiving these notifications and the value they get from using your application? If yes, how does that translate to the rest of your user base?

### What trends can you monitor?
In addition to looking for specific answers in your notification data, sometimes it may be helpful to monitor trends so that you proactively see if things start to change. A few trends that you can look out for are:

* **The relationship between notification interactions and user growth.** If you add more users but they interact less with notifications, it might suggest that the users are less engaged, or that the notification experience is no longer a good fit for your newer customer base.
* **Cohort analysis.** Are newer users responding to notifications better or worse than users that have been around for a while? By looking at notification stats in the context of user cohorts, you can quantify the effect that notification changes have on new user onboarding.

## Don’t have time to build notification infrastructure yourself? Try Courier
Omnichannel analytics are an enabler for doing great things with notifications, and we believe getting such analytics to work in your product is key to long-term improvements in the notification experience.

It can be a lot of work to build all the required infrastructure for omnichannel analytics, though. And if you don’t have the required resources to commit to implementing it all yourself, consider using Courier.

One of the key features Courier offers is [an Analytics dashboard](https://www.courier.com/docs/guides/business/analytics/) which helps you see traction across notification channels out of the box. Need something more custom? With the [Logging](https://www.courier.com/features/logging/) feature, Courier can export the details of all notifications sent, across channels, into a system of your choice so that you can run more detailed reports.

pm-guide-omnichannel-analytics-header

In this article, we talk about omnichannel analytics, why analytics are hard for notifications, and what we believe is needed to empower PMs.

pm-guide-omnichannel-analytics-thumbnail

Omnichannel Analytics: the Key to Building Better Notification Experiences

Notifications are a crucial component of most products, but they come with a catch. None of us likes to be interrupted, yet we want to see new information — like direct messages, time-sensitive tasks, or attractive product updates — as soon as it’s available. How can you balance these two needs?

It can be frustrating for users when a product or service doesn’t allow them to control their notification experience. Perhaps you’ve encountered it yourself: for example, when you get a distracting notification on your phone that turns out to be irrelevant.

Productivity apps, like Slack or Microsoft Teams, whose core functionality involves notifications, offer several options for users to configure their notification experience. From choosing notification channels (like email or mobile push), to configuring out-of-office hours, those apps try to make their users’ lives less distracted and more productive by letting users control which notifications they want to get when and where. There’s a lot we can learn from such applications!

In this article, we’ll cover notification preferences — what they are and which preference options you should consider including in your app — and share some tips on which more advanced options you could build to delight your customers.

## What are notification preferences?
Notification preferences are a way for users to configure how and when they would like to be notified of anything important happening within the product or service. For example, an event app may offer its users to configure whether they want to periodically see all upcoming concerts in their area, or only want to be notified when their favorite artists are playing.

At Courier, we like to break down notification preferences into two categories: notification logic and notification channels.

Preferences related to notification logic influence when the app notifies its user. For example, a user of a local marketplace app might want to get notified about each new offer in their area, or just receive a summary of all offers at the end of the day — or not get any notifications at all about offers, perhaps because they are only selling and not buying at the moment.

![what-are-notification-preferences](//images.ctfassets.net/z7iqk1q8njt4/26esUMLdsmqcKzPyI0kGln/f4a04759341a692f8821da6c2f17f1b5/image2.png)

Channel preferences influence how the notifications are sent — via email, through Slack or Discord, via an SMS message, or otherwise. Using the marketplace app example from above, a frequent seller might want to get instant push notifications for any new messages, while an occasional buyer might prefer to be notified via email only.

![how-notifications](//images.ctfassets.net/z7iqk1q8njt4/5rZXRJUysU9umN1h7SfsSw/194989bff3fe44c20f0194f80bc24473/image1.png)

In our experience at Courier, it’s important for users to be in control of both the notification logic and the channels used. So as the provider of a product or service, you need to make sure that your users can configure both if you want to offer them an optimal user experience. 

## Why adding notification preferences is a worthwhile investment
As the amount of notifications sent increases throughout the software industry, users are rarely given the controls over what they want to be notified about and when. Customers increasingly resort to extreme measures — disabling all notifications for an app or service, or even deleting their accounts.

Product managers tasked with improving notifications sometimes believe that it’s possible to build a standard notification system that suits most users. And while this might be true for occasional notifications, the one-size-fits-all approach is no longer suitable when notifying users frequently. Additionally, the power users of your product or service will likely be the ones most affected by an inflexible notification experience — and those are the users that you most need to keep.

![likelihood-of-getting-annoyed](//images.ctfassets.net/z7iqk1q8njt4/2Px3YfYW63MSa7gatOL82u/d28b0f71a92556c7455f4af6e251b079/image3.png)

When you give users the control over notifications they want to receive, they are much more likely to want to continue receiving your notifications and be engaged with your app.

## Best practices for notification preference management
Before adding notification preference management to your product or service, you’ll need to identify the preferences that would have the most impact for your users. The main challenge when determining which preferences to include is the *balance between complexity and flexibility*: you want the preferences to be powerful, but also easy to understand and use.

Let’s look at the best practices for preference management which we identified over the years of building Courier.

### Comply with GDPR and CCPA regarding consent
Compliance with regulations like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) is a requirement for the vast majority of B2B software companies today, and notifications need to be compliant too. As part of notification preference management, you [will have to collect and store](https://law.stackexchange.com/a/29191) the information on whether your users have provided consent to getting notifications, of what kind, and how that consent was provided.

In order to stay compliant with laws like GDPR and CCPA, you will need to make it possible for users to view their consent settings and withdraw consent in the future, if they prefer.

### Store notification preferences and let users see the preferences they chose
Depending on the number of users you have and the number of notification settings you’ll be implementing, you’ll need to consider how the user preferences will be stored. Because the settings need to be taken into account for every event that’s potentially relevant to a user, simply adding a database table for notification preferences might not be sufficient.

Work with your engineering team to understand how and when notification preferences will be accessed within your app and choose a data store for the preferences that is suitable for the task. Learn more about the technical side of implementing notification preferences in our article *[The Developer's Guide to Building Notification Systems: Routing and Preferences](https://www.courier.com/blog/routing-and-preferences/)*. 

### Allow users to opt in and out of notification types
One of the largest sources of annoyance for users is getting both lifecycle (marketing) notifications and transactional notifications within the same channels and with the same settings. As an example, have a look at this [Reddit thread](https://www.reddit.com/r/UberEATS/comments/lq71yi/how_do_i_disable_promo_notifications/) where users complain about this behavior in the Uber Eats app, or [this thread](https://www.reddit.com/r/Instagram/comments/q6ijfq/how_to_turn_off_notification_account_3_others/) with a similar complaint about Instagram.

Ideally, applications should allow users to opt out of notifications that they’re not interested in, while staying opted in to the ones they do want.

### Allow users to opt in and out of specific channels
The next step is to allow users to set their preferred channels for getting notifications. Some users will want to only get emails from your service; other folks will want more timely notifications through push. It’s ideal if you allow them to set preferences on channels for various notification groups — so that, for example, in a collaboration tool a user can get push notifications for mentions of their username, but get an email summary for all notifications that don’t involve them directly.

In the examples above, it’s possible that the users actually wouldn’t mind receiving an Uber Eats special offer — but probably not through a push notification, which is usually reserved for time-sensitive notifications.

### Allow users to configure frequency, including digests
A common mistake when implementing preferences is to offer only two choices for a particular topic: all notifications or none at all. Frequently, users need a middle ground. For example, a member of a Discord community might not want to get notified of every new message, but they potentially wouldn’t mind a summary of messages.

A common solution in such situations is to offer periodic digests — often via email. Users can configure the time period they would like to get a summary for, most frequently daily or weekly. The service then collects all notifications generated during that period and sends them as a single overview.

### Allow users to configure topics — all notifications versus critical notifications
There is more nuance than the basic distinction between lifecycle and transactional notifications. Each reasonably complex application or service will likely have various kinds of lifecycle and transactional notifications, and your users might be interested in only some of them.

We recommend letting your users configure topics they are interested in getting notified about via a given channel. These topics can be as broad as “time-sensitive notifications” or “urgent account-related messages,” or more specific like, “timely special offers,” and ideally users would be able to choose the most suitable notification channel for each topic.

## Additional preferences are a way to delight customers 
With the basics of notification preference management covered, let’s have a look at a few more advanced options. Such advanced settings can be more difficult to implement, and they might not seem so critical compared to the basic notification functionality. However, if the advanced settings closely match what your users need, they might create some positive differentiation for you versus any competitor solutions — and delight your users. Here are a few ideas that hopefully will get you interested in building more advanced preference management functionality.

Allow users to specify multiple email addresses
Most services operate under the simplistic assumption that users have only one email address, but frequently that’s not the case. For developers, for example, the email address associated with their GitHub account can be their personal email, while they also have a company-issued email address. Because of this, GitHub [allows users to choose](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/adding-an-email-address-to-your-github-account) which email address to use for notifications.

If your application can be used in both work and non-work contexts, consider letting your users pick which email address, device, or phone number they want to use for notifications — it will make their experience more enjoyable.
### Redirect notifications to another user
While you are on vacation, you might want someone on your team to periodically check for any critical notifications in your area of responsibility and escalate to someone else if needed. That’s easier said than done, however: while it’s possible to redirect emails with rules and filters, notifications that get sent to other channels like mobile push can’t often be redirected to another user.

Does your product involve collaboration in a business context? If yes, a feature for redirecting notifications might be a good fit for your user base.
### Silence notifications at night
Many business communication apps try not to disturb users at night. If you decide to implement this feature in your notification system, don’t forget about timezone support!

And some folks' biological clocks might work differently, so giving them an option to configure their own hours without notifications can be handy. Slack, for example, achieves this using its configurable [Do Not Disturb](https://slack.com/help/articles/214908388-Pause-notifications-with-Do-Not-Disturb) mode. 

## Don’t want to build the preferences engine yourself?
Regardless of the preferences you want to add for your users, try to create a solution that balances complexity and functionality and, ideally, keeps notifications flexible while also being easy to use for all users.

Excited to add notification preference management to your app but don’t want to build the infrastructure for it? Consider using Courier.

With Courier, you not only get [notification preference management](https://www.courier.com/features/preferences/) out of the box — you also get:

* Built-in storage for your users’ notification preferences
* Support for internationalization for notification text — including a workflow that you can use with translators within the service
* Automations and workflows that connect to other business apps
* Notification templates that non-technical stakeholders can manage through a user-friendly UI


pm-preferences-header

In this article, we’ll cover what notification preferences are and which ones you should include in your app. Read tips for advanced options you could build.

The PM’s Guide to Preference Management for Notifications

pm-preferences-thumbnail

The Product Manager’s Guide to Preference Management for Notifications

shreya-headshot

Shreya Gupta

## Before Starting
GitHub Repository: [https://github.com/shreythecray/infiltration](https://github.com/shreythecray/infiltration)

**The hackathon ends soon,** and we are giving away over $1K in prizes! Join us in building a cool project and winning any of the following prizes. 🏆

- **Courier Hacks 1st Place:** Top submission for use for notifications and demonstration of proper app-to-user notifications with the Courier API will receive $1000 via Zelle or PayPal.
- **Courier Hacks 2nd Place:** 2nd Place submission for use for notifications and demonstration of proper app-to-user notifications with the Courier API will receive the Apple AirPods Pro.
- **Public Favorite:** Public favorite winner will receive a Keychron Keyboard.
- **Runners-Up:** Runners-up submissions will receive a Hydro Flask.

Additionally, everyone who submits a project successfully integrating the Courier API will receive a $20 Amazon gift card! Submissions close on **September 28th**. Register now to submit this project for a chance to win some cool prizes.

Register for the Hackathon: [https://courier-hacks.devpost.com/](https://courier-hacks.devpost.com/)

Not sure where to start? In this tutorial, we will create a Discord bot that sends daily automated messages encrypted in Morse code with Node.js and the Courier API.

## What is Going On?

### Recap
We are secret agents, and we previously built an application to send secret messages encrypted in Morse code to communicate with our spy network. [Learn more >](https://www.courier.com/blog/hackathon-courier-api-nodejs/)

Last time, headquarters told us that one of our spies had leaked sensitive, top-secret information to our enemies, so we built a lie detector that alerted our spy network when we identified the mole. We used Azure's Cognitive Services to perform facial recognition on everyone on our team and Courier to broadcast the identity of the mole to our spy network. [Learn more >](https://www.courier.com/blog/serverless-lie-detector-facial-recognition/)

### What’s Next:
We have successfully identified the mule and have alerted our spy network! In an unfortunate turn of events, the mule happens to be our partner, Agent X, and now we are being suspected as a traitor as well. Since we are highly skilled, Headquarters knows that the Lie Detector won’t work on us, but we have been placed off-duty until we can prove that we are innocent.

Before we were removed from duty, we were able to use the Lie Detector to find out that the enemy had thousands of civilians under control in a secret Discord server. The civilians are being brainwashed with enemy propaganda every day. To prove our innocence, we decide to go undercover and infiltrate the enemy’s Discord server. With the help of Agent X, we have been added to the server as an administrator. Our plan is to create and install a Discord bot that automates encrypted messages to the civilians and alerts them about the situation so that they can escape.

## Let’s Build

### Pre-reqs:
- Admin access to a Discord server
- A cool undercover Agent name for our Discord bot
- Optional: a cool undercover Agent profile picture for our Discord bot

### Part 1: Set Up Node.js Project
Today, we will be building this with Node.js. If you’re curious about how to build this project using Ruby, cURL, Powershell, Go, PHP, Python, or Java, let us know: `https://discord.com/invite/courier`. You can also access code for these within our [API reference](https://www.courier.com/docs/reference/automation/invoke/). Let’s get started:

- Create a new project folder.
- Create three new files: “index.js”, “.env”, and “.gitignore”.
- Install [dotenv npm package](https://www.npmjs.com/package/dotenv) to store variables: `npm install dotenv --save`

    Import and configure dotenv by adding to top of index.js: `require("dotenv").config();`

- Similarly, install [node-fetch npm package](https://www.npmjs.com/package/node-fetch) to make API calls: `npm install node-fetch@2`

    Import and configure node-fetch by adding to top of index.js: `const fetch = require("node-fetch");`

### Part 2: Create a Discord Bot
- [Sign up for (or log into) Courier >](https://courier.com/hack-now)
- Open Discord provider in Channels. Here we will need our Discord bot token to continue.
- In order to access a Discord bot token, we’ll create a Discord application and add a Discord bot.
    - Click on “New Application” within the [Discord Developer Dashboard](https://discord.com/developers/applications).
    - Type the app’s name and click “Create”.
    - In the left menu, open the “Bot” page and click “Add Bot”. We can update the icon and username (bot icon file can be found in the GitHub linked above).
- Once the bot has been created, copy the bot token provided and paste it in Courier (make sure to keep this token private).
- We will need to give this application permission to post as the bot within our server. Check out the [Bot permissions documentation](https://discord.com/developers/docs/getting-started#adding-scopes-and-permissions).
    - Within the application, head over to OAuth2 and click on URL generator
    - Select the `bot` scope
    - Select the following permissions: `View Channels`, `Send Messages`, and `Read Message History`
    - Go to the generated URL below. This URL will invite the bot to the server and authorize it with the permissions chosen.
- On Discord, click on User Settings (next to username on the bottom left). Access the Advanced settings page and enable Developer Mode ✅.
- Back in the Discord server, right click on the channel and copy the channel ID (bottom of list). Add this as the value of `channelID` in the .env file within the project and save it as a variable within the index.js file:

    ```json
    const channelID = process.env.channelID
    ```

Now, Courier has access to sending messages to this server as the bot.

### Part 3: Send Messages
- Create a new notification within the [Notification Designer](https://app.courier.com/designer)
- Add the Chat notification channel with Discord as the provider
- Select on the Chat channel on the right to edit the message

![image6](//images.ctfassets.net/z7iqk1q8njt4/5VaUY0gl7ILbrIf5I6ib3x/c579d27b7ec6c0f0782ffbc71bd3c25f/image6.gif)

- Write and publish the message. We need to create a clear message that will indicate to our civilians how to escape. Our message will be: `Run while you can. You can find shelter here: https://discord.com/invite/courier.`
- Copy the notification template ID from the notification’s settings and add it as the value of `templateID` in the .env file within the project and save it as a variable within the index.js file:

    ```json
    const templateID = process.env.templateID
    ```

![image3](//images.ctfassets.net/z7iqk1q8njt4/3uNICG76LUrNFmJ8XWzkfw/6774fa85e51e866436c82957ad6353ce/image3.gif)

- Create a test event and replace the `channel_id` in the JSON with the `channel_id` we received from Discord earlier.

    ```json
    {
      "courier": {},
      "data": {},
      "profile": {
        "discord": {
          "channel_id": "768866348853383208"
        }
      },
      "override": {}
    }
    ```

- Test a message to ensure that the Discord provider integration is working correctly.

![image4](//images.ctfassets.net/z7iqk1q8njt4/5GfnsGxTYn4iEAhKnheqIb/41c562b0811dbac8dae8bf3bfe7f60ec/image4.gif)

- Replace the message with a variable `{secretMessage}` so that, later, we can edit the message from our code directly.

![image2](//images.ctfassets.net/z7iqk1q8njt4/RBa7sDpfdeamGi1b2WpoV/57ccc96254356889c55da8676b732d15/image2.png)

### Part 4: Encrypt Message with the Morse API
- Create an asynchronous function called `encryptMessage()`, which takes `originalMessage` as a parameter. This function will call the Morse API, which will allow us to translate any message from English to Morse code. The enemy will have to spend more time and resources into decrypting our messages, which will give our civilians time to escape from the server.

    ```jsx
    async function encryptMessage(originalMessage) {
    }
    ```

- Let’s define the GET API call options:

    ```jsx
    const morseOptions = {
    	method: 'GET',
    	headers: {
    		Accept: 'application/json',
    		'Content-Type': 'application/json'
    	}
    };
    ```

- We need to attach the `originalMessage` function parameter to the Morse API endpoint:

    ```json
    const morseEndpoint = "https://api.funtranslations.com/translate/morse.json?text="+originalMessage
    ```

- We need to be able to access the translation from this API call in the body of the Courier API call. To call the API, we can use node-fetch as we did before.
    - Create a variable called `morseResponse`, which will hold the entire response from this call.
    - Convert the JSON object into a JavaScript object `morseResponseJSON` so that we can read it within our code.
    - Get the translated message out of that object and save it in a new variable called `encryptedMessage`.
    - Return `encryptedMessage` so that we can call this function to access it elsewhere.

    ```jsx
    const morseResponse = await fetch(morseEndpoint, morseOptions);
    const morseResponseJSON = await morseResponse.json();
    const encryptedMessage = morseResponseJSON.contents.translated;
    console.log(encryptedMessage);
    return encryptedMessage;
    ```

![image1](//images.ctfassets.net/z7iqk1q8njt4/3xp8SErhajuhxiMVB2iX2W/43ce98adc0c2c64ca833e46e304b7779/image1.png)

*NOTE: The Morse API has a rate limit, which may give you an error if you run it too many times within the hour. In this case, you will have to wait for some time before continuing.*

### Part 5: Automate Messages
[Learn about Automations >](https://www.courier.com/docs/automations/)

[Check out the Automations API reference >](https://www.courier.com/docs/reference/automation/invoke/)

- Create a new asynchronous function called `runDiscordAutomation()`, which will call the `encryptMessage()` function to translate a message and use the Courier API to automatically send messages to the enemy Discord server everyday.

    ```
    async function runDiscordAutomation() {
    }
    ```

- Before we can run our message through the Morse translation API, we need to ensure that it is in the correct format, with all spaces converted into their URL encoding, `%20` as shown below. We can call `encryptMessage()` with `originalMessage` as a parameter to translate it. `encryptedMessage` will evaluate as the translated message.

    ```jsx
    const originalMessage = "run%20while%20you%20can%20you%20can%20find%20shelter%20here";
    const encryptedMessage = await encryptMessage(originalMessage);
    ```
- Add the link to the safe server in the notification template within the designer: “[https://discord.com/invite/courier](https://discord.com/invite/courier)”

- Let’s define the Courier Automation endpoint and options. Here we will need access to our Courier API Key, which can be found within the [Courier Settings page](https://app.courier.com/settings/api-keys). Save the first value in the .env file as apiKey and access it in this file as process.env.apiKey.

    ```jsx
    const automationsEndpoint = "https://api.courier.com/automations/invoke"

    const courierOptions = {
    	method: "POST",
    	headers: {
    		Accept: "application/json",
    		"Content-Type": "application/json",
    		Authorization: 'Bearer ' + process.env.apiKey
    	},
    	body: JSON.stringify({
    		//next steps
    	}),
    };
    ```

- The body object within the options will encompass two objects: `automation` and `data`

    ```json
    body: JSON.stringify({
    	"automation": {
    	},
    	"data": {
    	} 
    }),
    ```

    - The `automation` object will include a `steps` array, which will consist of all steps required for the automation. Our automation consists of reminders that are sent once a day - in this case we will be adding three steps: a send step, a delay, and another send step (so on).

        ```json
        "automation": {
        	"steps": [],
        },
        ```

    - Each step will need to be defined with two objects: the type of `action` (send, delay, cancel, etc.) and `message`. The `message` consists of the notification template ID (we saved this in the .env file earlier) and information about where this message is being sent. A Discord message requires either a `user_id` or a `channel_id`. In order to reach as many innocent civilians as possible, as quickly as possible, we will directly send messages in a channel.
    - This is what the send and delay steps would look like:

        ```json
        {
        	"action": "send",
        	"message": {
        		"template": templateID,
        		"to": {
        			"discord": {
        				"channel_id": process.env.channelID
        			}
        		}
        	}
        },
        ```

        ```json
        {
        	"action": "send",
        	"duration":"1 day"
        },
        ```

    - The data object would need to contain the `encryptedMessage`:

        ```jsx
        "data": {
        	"secretMessage": encryptedMessage
        }
        ```

    - [Learn more about sending to a channel via Courier >](https://www.courier.com/docs/guides/providers/direct-message/discord/#sending-a-message-to-a-channel)
- For testing purposes, it’s easier to either remove 1 delay step or keep it at a short period like `1 minute`
- Finally, we can use node-fetch again to call the Automations API and trigger this automation

    ```jsx
    fetch(automationsEndpoint, courierOptions)
        .then((response) => response.json())
        .then((response) => console.log(response))
        .catch((err) => console.error(err));
    ```

![image5](//images.ctfassets.net/z7iqk1q8njt4/DToIls5IJymsGD2WVpqNr/1eff78ca95f8a643f6bfbcab2cfc3cdc/image5.png)

## Conclusion

Our Discord bot is ready to save some civilians. Try building a Discord bot of your own and tweet a screenshot of your Courier automated messages in action, and we will send a gift to the first three Secret Agents to complete this task! Head to [courier.com/hack-now](http://courier.com/hack-now) to get started. Don’t forget to submit your project to our [Hackathon](https://courier-hacks.devpost.com/) for a chance to win over $1000 in cash and prizes!

### Quick Links

🔗 GitHub Repository: [https://github.com/shreythecray/infiltration](https://github.com/shreythecray/infiltration)

🔗 Courier: [app.courier.com](https://bit.ly/3QPiFg3)

🔗 Register for the Hackathon: [https://courier-hacks.devpost.com/](https://courier-hacks.devpost.com/)

🔗 Discord Application and Bot Guide: [https://discord.com/developers/docs/getting-started](https://discord.com/developers/docs/getting-started)

🔗 Courier Discord Provider Docs: [https://www.courier.com/docs/guides/providers/direct-message/discord/](https://www.courier.com/docs/guides/providers/direct-message/discord/)

🔗 Courier Automations Docs: [https://www.courier.com/docs/automations/](https://www.courier.com/docs/automations/)

🔗 Courier Automations API Reference: [https://www.courier.com/docs/reference/](https://www.courier.com/docs/reference/)


Brunette woman (spy) sits at a desk, hacking a computer.

serverless-lie-detector-header

Our plan is to create and install a Discord bot that automates encrypted messages to the civilians and alerts them about the situation so that they can escape.

serverless-lie-detector-thumbnail

Create a Discord Bot that Automates Secret Messages with Node.js

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.


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

How Decoupling Notifications from Your Application’s Code Empowers Product Managers

Your product’s notification experience can make or break how your users perceive your application. That’s why getting the notification experience right should be at the forefront of product managers’ minds. But what, exactly, is a great notification experience for a mobile or web app? Here at Courier, we often hear this question from product managers.

In this article, we’ll do a deep dive into what contributes to a great notification experience. We’ll talk about various notification types, which notification channel is best suited for what kind of message, and how to make sure that your users don’t leave your product due to wrongly timed notifications. After reading this article, you’ll have the confidence — and the tools — to set up a notification system that delights and doesn’t annoy.

## What is a notification experience?
In this article, we use the term “notification experience” to include everything your users see, hear, do, and feel when they interact with notifications from your app or software service — from emails to push notifications to Slack messages and beyond.

![pm-1-1](//images.ctfassets.net/z7iqk1q8njt4/7EK4zCoBASw1pcFUTJcCfc/eeaa0911f8533e864f0642d7b76d34ee/pm-1-2.png)
*Image: email, push, and Slack notifications for an HR application.*

**Notification channels** are a central component of a notification experience. Each channel is a way to reach the user through a particular technology, platform, or service that is able to deliver notifications. Here are some examples:

* Mobile push (including banners, badges, sound alerts)
* Email
* Chat (like Slack or WhatsApp)
* SMS
* Phone call
* In-app notifications

In many cases, it’s not sufficient to only use one notification channel, so most notification experiences would also include notification logic. In addition to defining which channels to use under which circumstances, the logic would process user preferences, pick the right language based on the user’s profile, and so on.

## How different notification types contribute to the overall notification experience
There are two broad types of notifications used by software products and services: transactional notifications and marketing notifications.

**Transactional** notifications are directly relevant to a specific action, like creating a post or placing an order, that a user takes within your app. Examples can include a delivery app that sends them an immediate confirmation of an order, or a marketplace app that notifies them of a new message about a product they’re looking to sell.

**Lifecycle** notifications are designed to encourage your users to return to and interact with the product itself. An example is sending a user who hasn’t been in the product for three weeks a reminder email that their work in the app is waiting. Or sending a weekly digest of statistics to a user by email and having them return to analytics within the product for more details.

While the boundary between these notification types can sometimes be blurry, the core concepts are defined quite specifically [in law](https://www.law.cornell.edu/uscode/text/15/7702).

![pm-1-2](//images.ctfassets.net/z7iqk1q8njt4/5MDpTUst0073rooipedWJy/68594b245d11bace5ce954bca397ab42/pm-1-1.png)
*A transactional push notification and a marketing push notification. Similar format but different purposes.*

In general, you could use any notification channel for both transactional and marketing purposes, but some are more suited to one or the other. We offer some examples in the table below.

<table>
  <tr>
    <th>Channel</th>
    <th>Advantages</th>
    <th>Disadvantages</th>
    <th>Best suited for</th>
    <th>Not suitable for</th>
  </tr>
  <tr>
    <td>Email</td>
    <td>Wide adoption.</td>
    <td>Can take days for the recipient to read an email. Possibility of hitting deliverability issues. Possibility of getting lost in the inbox.</td>
    <td>Important information that the user shouldn’t miss, like pricing changes, account updates, security alerts; marketing messages that are not time-sensitive.</td>
    <td>Time-sensitive alerts — as email is not designed to be read instantly.</td>
  </tr>
  <tr>
    <td>Mobile push</td>
    <td>Received quickly by the user; can take the user directly to the app to perform an action.</td>
    <td>Alert fatigue; limited settings on the user side.</td>
    <td>Timely alerts.</td>
    <td>(Arguably) marketing messages.</td>
  </tr>
  <tr>
    <td>SMS</td>
    <td>Wide adoption.</td>
    <td>Doesn’t work without a mobile connection. Length limitations.</td>
    <td>Timely alerts about appointments, events, etc.</td>
    <td>Most app notifications.</td>
  </tr>
  <tr>
    <td>Chat (Slack, Discord)</td>
    <td>Reaching chat app users with less interruption; giving users an opportunity to see messages in the app when browsing other activities.</td>
    <td>Can get lost in the chat. Possibility of not reaching the recipient if they are not checking the chat often.</td>
    <td>Context-specific notifications — for example, work conversations or gaming conversations.</td>
    <td>Time-sensitive notifications outside of chat hours. Security alerts.</td>
  </tr>
</table>

There is no single channel that is perfect for all uses. A good notification experience should take advantage of each channel's strengths.

## A bad notification experience can frustrate users
Based on our experience speaking to Courier customers and prospects, product managers understand that notifications matter, but sometimes they don’t see how much they matter. In reality, lots of bad things can happen if the notification experience for your app or service is not good. For example:

* You could lose users due to incorrectly using notification channels, like sending marketing notifications via channels like mobile push which are normally only used for time-sensitive, transactional alerts. Such application behavior can feel unprofessional and spammy, causing users to lose trust in your product or service.
* You could upset users due to sending notifications at the wrong time. For example, someone who gets an avalanche of notifications might decide to completely block them for your app. This means that even your important messages can’t reach them. Also, needlessly sending out notifications at night could cause users to literally lose sleep. Who would want to do that to their customers?

## What does a good experience look like, in contrast?
Let’s contrast the potentially serious consequences of a bad notification experience with the more positive aspects of a good experience. Based on what we see at Courier, here are the key aspects that contribute to a good notification experience.

**Right channels.** Choosing suitable channels for your notifications makes it more straightforward to build and improve your notification experience later on. For example, in a banking app, using mobile push for transaction notifications would likely be a good fit due to this format’s timeliness, while email wouldn’t be so suitable. However, if there is a suspicious transaction, it might be better to send an SMS, or even escalate to a phone call to make sure the customer doesn’t miss the notification.

**Right timing.** It’s better to avoid sending some notifications like mobile push at night, as that might wake your customer up unnecessarily if they don’t have the right alert settings. A local marketplace app, for instance, should thus try to avoid sending mobile push (or other intrusive) notifications at night. Instead, it could send a summary email in the morning. On the other hand, mobile push notifications could be totally right for a security-related alert.

**Right customizations and preferences.** In addition to allowing notifications to be fully on or fully off, applications should offer ways for users to customize notification settings to their needs. For example, a weather app might offer a separate setting to turn rain notifications on or off independently of low temperature notifications. Some of us dislike rain less than others! 

**Following platform best practices.** A notification experience that seamlessly fits into the platforms you use for notifications, like iOS push, in-app notifications, or Slack, will add delight into your customers’ day. An HR app like the one we showed above, for example, should make use of Slack’s [various built-in “blocks”](https://api.slack.com/reference/block-kit/blocks#section) when it makes sense, rather than using the basic text-only format and shoehorning various content types into that format’s limitations.

## Common objections to building a good notification experience
At Courier, we frequently talk to product managers as part of our support, solutions, and sales conversations. We’ve noticed over time that there are a few key issues that are blocking PMs from improving their product’s notification experience. Below, we list some of the most common concerns. Have a look if any of those resonate with you!

### “I can’t control the notification experience the same way as I can control the app experience.”
Yes, it’s true that you don’t have as much control over how the notifications in your product look and feel, compared to the app itself. This is because the notifications on platforms like iOS and Android need to look like iOS and Android for consistency, rather than your brand colors and font face. Your app can only customize parts of the notification experience on these platforms.

Another way to look at this limitation, however, is to recognize that there is a smaller UX hurdle for users to overcome when relying on an existing notification system, where users already know how notifications look and feel. Moreover, modern notification systems on iOS and Android, as well as other channels like Slack, Discord, and email, are flexible enough for companies with such unique products as Uber, Airbnb, and LinkedIn to offer a good notification experience — so you can do a good job too despite platform limitations.

Our advice is to explore what different notification platforms have to offer: Slack, for example, has multiple message “blocks” that your application can send, and you might find exactly what you need in one of the pre-built blocks. And in iOS 16, the new [Live Activities](https://9to5mac.com/2022/07/27/ios-16-live-activities-api-available-beta-4-developers/) feature for notifications can change how notifications work for time-sensitive events.

### “I don’t know what a good experience for my users looks like.”
It can be challenging to identify exactly which notifications need improving for an optimal app experience, or how you can make a notification’s content or format more valuable to your users — and lack of in-depth notification analytics can be a contributing factor. While it’s straightforward to measure engagement on a website with tools like Google Analytics or Matomo, analytics of users’ notification experiences are harder to get.

Our recommendation is twofold:

Try to get quantitative data on notifications — for example, open rates and clicks across channels. On some platforms, like email, this is easier; on platforms like iOS this is more challenging but still possible.
Support the quantitative data with [user research](https://productschool.com/blog/product-management-2/product-management-skills-user-research/). Send surveys to your users and ask them which notifications they find most valuable, and which they find annoying (if any).

For inspiration on good notification experiences, consider apps that you use frequently yourself. Are there any apps where the notification experience feels “just right” — delivering messages at the right time and pace, with relevant and engaging content? 

### “Designing a good experience is too hard.”
Because there are so many different platforms involved in a notification experience, PMs can feel overwhelmed by the number of decisions they have to make when it comes to designing the notification system.

Our advice is to focus on fixing aspects that are wrong and getting the basics right, rather than trying to implement advanced notification techniques from the start.

For example, the basic steps can include:

* Getting basic analytics on notification interactions to better understand how your notifications are used by your users
* Making sure notifications don’t crash the app
* Allowing users to customize their notification experience using basic preferences
* Adding relevant channels — as outlined in our table above — so that users can receive the kinds of notifications they need

Each of these items should be small enough to be able to implement with your team. By focusing on smaller, tangible deliverables you can slice the ambiguous “notification problem” into manageable chunks.

## Tips for building a great notification experience
To summarize, the way to build a great notification experience is to consider notifications a core part of your product and treat them accordingly.

Apply user research, design thinking and other product techniques to notifications too, not just your application. Test your notifications the same way as you test the rest of your product, to ensure that they are functional and look good. Measure the impact of notifications on user behavior via analytics.

pm-guide-1-header

After reading this article, you’ll have the confidence and the tools to set up a notification system that delights and doesn’t annoy.

Welcome to the Courier Blog

Build your first notification in minutes

Build your first notification in minutes

Product

Developers

Resources

Company