Courier Manageris in the Logistics Tech Industry

Courier Manager

Notification preferences are important — especially if you’re building an application that sends dozens of notifications. Users want control over which kind of notifications they receive, and through what channels. That’s why it is essential to provide a well-designed preference experience that’s quick, intuitive, and guaranteed to respect your users’ chosen preferences. With Courier, you can build great notification infrastructure effortlessly. But until now, preferences were handled separately, requiring engineers to spend a significant amount of time on both the back-end logic and the UI where users could select which notifications they want to receive and how. As an engineer myself, I’ve had to build workflows like this several times in past projects & companies. But those days are over: we’re excited to announce general availability of Courier Preferences. With Courier Preferences, you can build a full notification Preference Center in no time. The clean interface, which comes with endless options for customization, lets users manage their preferences. Courier’s infrastructure will take care of the rest by integrating them into our core products that trigger sends. (Within the Preference Center, users can comfortably ) opt in and out of notifications by topic and channel Whether you want to build a bespoke notification experience with the Preferences API, embed our pre-built UI components, or use the hosted preferences page that Courier provides out of the box for faster time to value, is entirely up to you. , Senior Product Manager, "Courier turned something that takes months into days. We were able to unlock the ability for our users to opt in/out of notifications in a customized Preference Center within one day. It was easy." Guilherme Samora Sastrify In this post, we’ll look at how to implement the best preference experience for your users. We’ll talk about how Courier makes it easy to handle preference settings and logs, and how the new Preferences Designer makes preference management a walk in the park. But first, let’s briefly recap why it’s important to implement preferences for your users. Notification preferences are a vital feature of any app Aside from their core functionality of alerting your users to activity in the app that requires their attention, notifications can be used to increase users’ awareness of your product’s features, for marketing and other purposes. But getting all these kinds of notifications from different organizations can quickly become annoying for users. To make sure they remain in control of their own notification experience, and to avoid them turning off all notifications from your app, it is vital that you implement notification preferences that are fine-grained and easy to use. And it’s just as important that you respect those preferences and only send your users the notifications they really want. Building notification preferences for your app from scratch is hard, especially if you use more than one channel to communicate with your users. It requires a significant amount of time and engineering resources — and don’t forget the need for future maintenance. By letting Courier host your preference infrastructure, you can instead use those resources to focus on building your core product. Here at Courier, we have spent quite some time thinking about what the best preference experience looks like. It needs to be clean, customizable, and easy to use for the end users. It also needs to offer sufficient transparency for compliance and record-keeping purposes on the back end. Since these requirements align across products, there is no need for every company to build their own. Instead, Courier Preferences lets you set up the notification experience that you want for your users in just a few hours. How to design a good preference experience You can now use the in the Courier web interface to design the best preference experience for your users. (As an alternative to the Preferences Designer, you can use the Preferences API for a more native experience within your app — more on that later.) Preferences Designer Since most applications send out many different notifications, it can quickly become cumbersome for users to manually set preferences for every single option. For a better user experience, Courier groups notifications by (formerly called “categories”). In addition, business tier Courier customers can bundle several topics by sections: as an example, you could set up two topics named “Feature launch” and “Product update” and file them both under a “Product” umbrella section, for even easier preference management. subscription topics Turning notifications on and off is not all, however. Notifications can be sent via in Courier, such as email, SMS, and push notifications. Users can select which channels they prefer for each subscription topic. For instance, they might prefer to be notified via email about a new message or rating on a social media platform, but not about minor interactions such as likes. Conversely, they may want to activate multiple channels — like SMS, email, and Slack — if there’s an emergency, like a security breach. different channels As a developer, you can turn certain notifications on and off by default for different topics and channels. You can also set certain indispensable notification topics as required. By marking a notification topic as required (for example, "Reset Password"), it prevents your users from disabling notifications for that topic, while reassuring them that they’ll still receive such critical notifications even if they disable everything else. Voilà: a user-facing Preference Center In the Preferences Designer, you can preview how your users will see the Preference Center in their browser. The page is designed to be easily navigable: preferences for notification topics and channels can be turned on and off with the click of a mouse. All of these features are available in our free tier. For more functionality, like multiple sections or the ability to remove the Courier watermark from the user-facing Preference Center, use our . Business plan Your preference UI, hosted by Courier You can now direct users to their personal Preference Center through a hyperlink in your notifications to them. In newer Courier workspaces, your notification templates will include this hyperlink by default. Otherwise, you can . add the link manually By following the link, your users will be able to see and update their own notification preferences within the Preference Center. Note that this requires no login: by automatically encoding their in the Preference Center hyperlink, it will be personalized to that user, and their preferences will be saved in their profile in the back end. user_id And that’s it: the easiest way to create the best customized preference experience, with only a few clicks in the Courier Preferences Designer. Build your own interface via the Preferences API You don’t have to use the hosted Preference Center — you can build your own, or even integrate notification controls elsewhere in your application. Have a look at the to learn more. documentation for the Courier Preferences API Finally, you can choose the middle ground and embed in your own preferences UI. Courier’s prebuilt component A user-friendly unsubscribe experience Unsubscribing from unwanted notifications should be fast and easy — and you should make sure to respect your users’ preferences to avoid unnecessary frustration. Similar to the preferences hyperlink, you can easily in your notification template. By clicking on it, users can unsubscribe from topics that they’re not interested in. embed an unsubscribe link Keeping a digital paper trail of your users’ preference history Keeping is useful for debugging, compliance, and solving issues in customer support. Courier automatically logs all your users’ changes in notification preferences and lets you view them via the API or directly in the Courier web interface. logs of your users’ changes in preference settings Let’s say, for instance, that a user isn’t receiving your notifications, even though they were enabled in their settings. You can now simply check the logs to determine where the error occurred. Conversely, a user might complain that they’re still receiving unwanted notifications after they thought they turned them off. By looking at the preference logs, you can see whether they indeed turned notifications off, or if they accidentally enabled them. Get started with Courier Preferences today Being able to offer users a fine-grained and intuitive preference experience saves companies a lot of time and puts them further ahead on their roadmap. We’re excited to make preference management easy and smooth for businesses. To learn more and start designing the best preference experience for your audience, take a closer look at and the . We’re sure your users will love it! Courier Preferences docs

Design the Best Notification Preference Experience in the Fastest Time

Uso de las preferencias de Courier para diseñar la mejor experiencia de preferencia en el menor tiempo posible

Utilisation des préférences de messagerie pour concevoir la meilleure expérience de préférence dans les meilleurs délais

सबसे तेज समय में सर्वश्रेष्ठ वरीयता अनुभव डिजाइन करने के लिए कूरियर प्राथमिकताओं का उपयोग करना

Courier プリファレンスを使用して最速で最高のプリファレンス エクスペリエンスを設計する

Usando as preferências do Courier para projetar a melhor experiência de preferência no tempo mais rápido

Sử dụng tùy chọn chuyển phát nhanh để thiết kế trải nghiệm ưu tiên tốt nhất trong thời gian nhanh nhất

用快递员偏好设计最快时间最好的偏好体验

*Preference management is an integral part of a great notification infrastructure, which makes it a very important piece of the puzzle here at Courier. This also means that there was a lot of learning and experience-building opportunity for the intern on the project, Denis Tatar. Denis’ internship was only a few months long, but he was able to make an enormous impact as the product manager for Courier’s Preferences feature. We wanted to learn more about Denis’ experience, so we asked if he’d be willing to work on a write-up for us. Then what he came up with was so good, that we thought it would be a good idea to share it with all of you! This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team specifically. We’ll let Denis take it from here! What was the problem? The problem we experienced at Courier was that we’d offer Preferences (V3) to our customers, but the entire product feature’s strategy wasn’t fully fleshed out. I believe that V3 was a great stepping stone for V4, but fundamentally had flaws in certain parts of its strategy. Allowing only global opt-in/out is an example of this. Another problem was that V3 didn’t gain much traction, which I believe points back to the lack of a fully thought-out strategy. In May, Preferences (V3) would only allow users to opt-in and out of their preferences of choice globally. V3 of Preferences only allowed our customers (and their customers) to opt-in/out of notifications, and customers globally could also decide if certain notifications were required or not. V3 helped give our customers the ability to start playing around with the idea of having preferences. However, globally opt/in out is a problem because it constrains end users’ notifications options. It was either all or nothing, no in-between. Similar in theory to the Pokemon saying, “Catch one, catch them all.” A problem with this, though, is inbox flooding. Global opt-in would allow for the concept of the end users’ inboxes becoming flooded with every product notification which is problematic because it can easily drive users away from your product. Global opt-in/out was quickly resolved by allowing users to select what content they wanted to be notified of and the channels they’d prefer. This overall trend in the market is used by thousands of companies (B2B and B2C products), especially in the technology space. Visibility became a serious issue with V3. End users never had the option to select what type of content and channel they wanted. Users would be asked if they were interested in receiving notifications in general. Not offering options is problematic as it constrains visibility on what you’ll receive through notifications. End users also don’t like surprises when it comes to product notifications. Having clarity is key because it enables end users to have control over their notifications. With V4, we solved the visibility problem, which was the main “fail” from V3. Our customers and their end users now had the ability to control the content they received and the channels they would prefer. V4 was a good way to strategically notify end users. Plan There were three phases we followed as a team when building Preferences. In phase one, I spent a decent amount of time looking at what is currently available in the market in terms of preference centers. I would constantly ask myself the following two questions: Research “How does [insert company name] manage notifications? What does their preference center look like?” These questions were key. They helped me dive into necessary research which helped me pick up on many important market trends. Out of all the trends found though, there was one that stood out the most. Channel & content selection through a toggle/grid style layout for preference centers is a must-have. This trend became the backbone to our summer project. It was important to offer users preference options. Trend: During this phase, I read many case studies. I was surprised to see how many existed on this topic. Each one helped enlighten me with solutions for the problem we were tackling. I learned through other people’s mistakes, absorbing valuable lessons. Talking to customers was extremely helpful in this phase. I was able to hop on numerous calls with our customers and hear their perspectives on this problem. I would ask questions and show examples of what we had in mind for a solution. This helped tailor a POC. The better we understand our customers’ perspectives, the easier it is to start designing something that they would use. I really enjoyed this phase. Watching research become an actual POC was incredible, and so fun. We took all the feedback I had gathered, then created several iterations of designs. Designing a POC Once we created a POC, it was essential to go back to our customers and ensure that it was something they envisioned for Preferences. Our customers were also lovely people to work with, always there to provide their much-needed feedback. Often, I would have a decent amount of brainstorming sessions with Ian. We’d look at our research and what our customers had to say, and combine these sources into a POC. It was an insightful process to be a part of. This phase lasted several weeks until we finally landed on a POC that satisfied all of the customers we had spoken to since May 2022. Once we had a POC and fully completed designs, we began building our product feature. This phase taught me two vital lessons… Building an MVP Being organized is extremely important. and... As a product manager, you need to stay one week ahead of your team. While working at Courier and delegating tasks, I noticed that the more organized you were, the easier it was to work with others. My organizational skills would impact how clearly our designers and engineers understood our goals and individually delegated tasks. The more organized we were, the faster and more efficient we worked. Outlining the tasks our team needed to complete, and vocalizing why these tasks were necessary helped a lot. It brought clarity to everyone, including myself. The second lesson here was given to me by our CEO, Troy. He taught me how important it was to think about the current and following week. Troy brought this up because, as a product manager, you want to keep your team informed on what projects and tasks are in the pipeline.. A product manager that isn’t in this mindset can quickly become a hindrance to their team. Taking on this mindset brought clarity and made me less stressed about our project. I would spend time planning each week, and estimating where the team should be at the end of each week (cycle). These two lessons helped when we were building an MVP. We progressed through each week as a team, with each week’s tasks outlined, along with the weekly goals we needed to achieve. Working with the team at Courier was amazing, everyone was understanding and absolutely brilliant. What I loved the most was that everyone had an opinion. Engineers and designers would ask if specific tasks were priorities before building them, which allowed us to build the MVP and get it up and running quickly. These questions helped guide priorities and decision-making. Execution: What I did exactly Throughout this internship, every day was different. My week would involve speaking to customers, delegating tasks to our engineers and designers, and taking time to think ahead, two to three weeks ahead of the current week. I also worked closely with both engineers and designers, ensuring great synergy between both teams. There were four core responsibilities that I embodied throughout my product manager internship at Courier: Being the internal expert on what the market (customers & prospects) want within my realm of focus. Being the internal expert on what my product feature already provides (and thus the delta to the above core responsibility). The ability to prioritize the path that gets Courier from our current state to our desired state. The ability to educate the rest of the company on the current product, the product being built, and our ultimate product vision so that everyone can be on the same page without being experts. As the glue that ensures the team is working together on the right thing for the right reasons, their success is ultimately limited by my effectiveness in one and two. I cannot accurately educate teammates on what I don’t profoundly understand myself. Troy was a fantastic mentor throughout my entire time at Courier. He brought these four core responsibilities to my attention, which became an integral part of my internship. What resonated with me the most was being the glue between all teams. At first, I looked at this concept and was intimidated by it. But, I had a blast easing myself into becoming this glue-like figure between teams. It definitely wasn’t something easy to pull off, but I enjoyed the challenge. I managed to make a lot of great friends along the way too! What trade-offs did I experience? There were many trade-offs throughout my entire internship. The main ones I experienced were related to the following concept “make it work -> make it good -> make it fast,” which I often heard throughout my internship. There were many times when small features that could make our UI/UX stand out would actually slow down the team. Trade-offs like these were necessary. They had me questioning whether we focus on the nitty-gritty details, or do we put the feature aside and focus on making a product that functions and gets the job done? The latter part of that question was often chosen as our strategy. It’s tough to make these calls because you know the team can develop an outstanding product build with phenomenal UI/UX components, but our build must accomplish what it’s meant to do in the first place. The main goal was to release our MVP, ensure we have customer feedback, improve any core features, and then focus on minor priorities that affect the UI/UX of this product. What was it like working with the team? I had a blast working with the Lifecycle team on Preferences. Everyone was so kind, and offered fantastic feedback. I’ve mentioned this numerous times around the office, and on calls with coworkers. Working at Courier didn’t feel like work; it felt like I was working on a side project with close friends. I genuinely think this is why I was able to produce the work I did at Courier, because of the environment. Courier is easy-going, extremely friendly, and results-driven. Another thing I really loved about the team was that they always thought of me. If there were tasks that engineers or designers would do that were considered a ‘norm’ for them, they’d ask me if I’d like to give it a shot to see what it’s like. I have three examples of this. When designing a specific tooltip for a part of the Preferences project, Ian (Senior Designer) during one of our calls, asked if I wanted a shot at designing a tooltip. This involved working with Frames in Figma, a concept I never worked with. I really enjoyed creating that tooltip. It made me feel included. Every week the team would have our team Lifecycle planning meetings. We’d speak about tickets, and write them up. It was early on in my internship when Suhas (Senior Engineer) asked me if I wanted to try writing up several tickets on Linear. I was aware that this was something most PMs would normally do, but I had a lot of respect for Suhas for bringing this up, and was willing to teach me how to properly create tickets in Linear. Once the team had something solidified for Preferences, I began to ask around internally to learn if there were any companies that would be interested in hearing about my project. Nathan (Account Executive), reached out to me to let me know about a customer interested in this product feature. Nathan encouraged me a TON when it came to communicating with this customer. I was able to step outside of my comfort zone because of Nathan’s encouragement. I’ve never gotten to speak to a customer before in any of my previous internship experiences, and I learned a lot about customers and the way they perceive Courier. Note that these are just three examples of the many opportunities like this throughout my internship. I do want to give a big shoutout to Ian, Suhas, and Nathan. I appreciate you guys giving me opportunities to learn and grow, it means the world to me. How did I work with designers? I enjoyed working with Ian (Senior Designer). We’d have impromptu meetings through Slack’s ‘Huddle’ feature, (which was internally renamed to because of a typo I once made that stuck). These meetings were really great for brainstorming and product design. Sometimes, Ian and I would have calls later at night because it was easier to come up with more creative ideas.. We’d have one to two-hour sessions, and we’d come up with some really awesome UI/UX for Preferences. This is something I’ll never forget. ‘Huggle’ When working with Ian, I would try to make it as easy as possible. I would create a to-do list through Google docs or Slack, so both Ian and I would be aware of what needed to be completed every week. During our calls, Ian and I would also talk about a lot of different topics not always directly related to work, which was great. This really helped build our friendship, making it so much easier to collaborate and come up with a clean UI/UX for Preferences. I often do a decent amount of product design outside of work hours, and Ian would always give me phenomenal advice on product design and on Figma! How did I work with engineers? I briefly touched on this, but when working with engineers, I would help create tickets, and organize what each week would look like. I helped our engineers whenever they were confused about anything related to Preferences and would explain how I came up with specific names, why Ian and I would design certain parts of our product and the goals behind these designs. Many of these answers came from my extensive research process with customers that were interested in Preferences. While working with engineers, I learned a lot about how to properly break down tickets (eipcs) within Linear. I thought I had a firm grasp before working at Courier, but I learned a lot more after working with the Lifecycle team. The key to breaking down tickets is to be able to think about every single detail alongside engineers. Being in a small group while doing this was super important because each individual helped bring up a very important perspective on how to break down tickets. During my internship, Seth (Chief Technology Officer), Suhas (Senior Software Engineer), and Christian (Software Engineer) encouraged me to speak to the Developer Experience team at Courier and show them our project. The main goal behind this was to test to see if the UI/UX of Preferences was intuitive if the design made sense, and if the Developer Experience team understood the goal behind this product feature. I prepared a slide deck explaining our project in its entirety. This was a great experience because it helped me prepare for how to Giving insightful presentations about products and . Speaking to folks internally helped me practice and refine this skill, as well. sell Preferences to our customers. “selling” your product to customers is such an important and overlooked skill for product managers How did I solve the problem? Before V4 Preferences, customers weren’t given the option of choosing what content they’d like to hear about, and how they’d like to hear about it. With V4 Preferences, users now can voice their opinions on both of these matters. This new product feature makes it possible for customers to choose what they like, and want to hear about. Specifically through their channels preference. Gone are the days of inbox cluttering and customers becoming aggravated with the number of notifications they receive. Preferences minimize the frustration that end users experience with their notifications. Want to apply for a role at Courier? Check out . To check out what Denis helped build in action, request a demo and ask to see the Preferences feature. our careers page here

I Took Ownership of a Major Product Feature as a PM Intern

Tomé posesión de una característica importante del producto como pasante de PM

J'ai pris possession d'une caractéristique majeure du produit en tant que stagiaire PM

मैंने पीएम इंटर्न के रूप में एक प्रमुख उत्पाद सुविधा का स्वामित्व लिया

PMインターンとして主要な製品機能の所有権を取得しました

Assumi a propriedade de um recurso importante do produto como estagiário de PM

Tôi đã có quyền sở hữu Tính năng sản phẩm chính với tư cách là Thực tập sinh PM

作为 PM 实习生，我获得了一个主要产品功能的所有权

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. 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: Notification channels 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. 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. Transactional 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. Lifecycle While the boundary between these notification types can sometimes be blurry, the core concepts are defined quite specifically . in law 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. CHANNEL ADVANTAGES DISADVANTAGES BEST SUITED FOR NOT SUITABLE FOR Email Wide adoption. Can take days for the recipient to read an email. Possibility of hitting deliverability issues. Possibility of getting lost in the inbox. Important information that the user shouldn’t miss, like pricing changes, account updates, security alerts; marketing messages that are not time-sensitive. Time-sensitive alerts — as email is not designed to be read instantly. Mobile push Received quickly by the user; can take the user directly to the app to perform an action. Alert fatigue; limited settings on the user side. Timely alerts. (Arguably) marketing messages. SMS Wide adoption. Doesn’t work without a mobile connection. Length limitations. Timely alerts about appointments, events, etc. Most app notifications. Chat (Slack, Discord) Reaching chat app users with less interruption; giving users an opportunity to see messages in the app when browsing other activities. Can get lost in the chat. Possibility of not reaching the recipient if they are not checking the chat often. Context-specific notifications — for example, work conversations or gaming conversations. Time-sensitive notifications outside of chat hours. Security alerts. 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. 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 channels. 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 timing. 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! Right customizations and preferences. 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 when it makes sense, rather than using the basic text-only format and shoehorning various content types into that format’s limitations. Following platform best practices. various built-in “blocks” 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 feature for notifications can change how notifications work for time-sensitive events. Live Activities “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 . Send surveys to your users and ask them which notifications they find most valuable, and which they find annoying (if any). user research 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. Also published . here

How PMs Can Build a Great Product Notification Experience

Cómo los PM pueden crear una excelente experiencia de notificación de productos

Applications for logistics help collect and process data and control logistics processes. After a brief downturn caused by the COVID-19 pandemic, the logistics industry has returned to robust growth. By 2027, the global logistics market is expected to exceed 13.7 billion euros. The main competitive advantage in logistics is the speed of delivery. To some degree or another, all innovations and improvements in transportation and warehousing relate to reducing delivery times and improving the safety of shipping and storage. Software applications help make the logistics business more efficient. Our review focuses on logistics app development and the business benefits of implementing software solutions. Types of Logistics Applications Application types depend on the area of logistics in which they are applied. are designed to collect, process, and store data related to transportation. Routing and fleet management software applications App users can track the fleet location, analyze fuel consumption, repair costs, and distance traveled, and look through the vehicle maintenance history. Apps can remind users of scheduled fleet maintenance. Timely decisions based on data analysis allow the company to optimize routes, save resources, and increase business efficiency. are built to keep records of goods delivered to storage, track the location of assets, and monitor temperature, humidity, expiration dates, and other parameters. Asset tracking and warehouse applications A warehouse IoT system consists of devices equipped with humidity and temperature sensors. Gadgets transmit data via LoRaWAN to the AWS server. AWS Lambda, Amazon SNS, and AWS IAM services are used to store and process data. A cross-platform mobile logistics application receives and analyzes device data. Sensors' data-receiving process Many goods require strict adherence to storage conditions. The C++ application, developed using the Qt framework, displays the temperature and humidity of the warehouse in real time and notifies users in case of significant deviations from the set values. The app's functionality contains statistical time reports on fluctuations in temperature and humidity. A warehouse app pre-design This monitoring system allows companies to reduce storage costs and minimize raw material losses. Transportation and warehouse software can be integrated into a single system that covers the entire supply chain, from order processing to delivery of goods to the consumer, including return shipping. The world's leading suppliers of logistics management systems are the German company SAP and the American company Oracle. The HMI application displays information related to product placement and order priority. Warehouse process automation is growing along with the warehouse industry. The size of the warehouse automation market increased by $10 billion over the ten years from 2012 to 2022, with further growth of $12 billion by 2026 projected. Size of the warehouse automation market worldwide from 2012 to 2026 (in billions of U.S. dollars). Source: Statista The logistics industry is driving the growth of autonomous IoT and robotics markets as companies incorporate robots and drones into their workflows. Mobile logistics robots are expected to generate more than $9.8 billion in revenue by 2025. Revenue from logistics robots until 2025. Source: Statista The global warehouse robotics market is forecast to triple in dollar terms in the next ten years. Features Logistics App Devs Should Optimize For All software applications, regardless of their scope, need to possess shared features to be beneficial: Speed and efficiency, Reliability, Data security, A reasonable price, Easy to install and use, Integration with internal and external systems Logistics applications have unique features related to the scope. Mobile applications for the logistics industry have unique features. Truck Tracking Apps can get vehicle location information using real-time GPS location. The simple and effective system helps track vehicles, optimize delivery, and provide consignees with information about where their cargo is. The system consists of GPS devices installed on trucks and an application that stores the GPS coordinates transmitted by the sensors and displays them on a map. The Qt framework, its useful tools, and C++, QML, and JavaScript helped create a cross-platform app for iOS and Android, and the Kalman filter helped improve the accuracy of the GPS positioning of logistics vehicles. Best Routes You can plan the best delivery routes and save time, fuel, and overhead costs without having a bunch of reports and files, but only by installing a logistics application on your smartphone. Route planning and optimization support solving the “last mile” problem when consumers want fast and inexpensive delivery, although this is often the most expensive and time-consuming part of the logistics process. For example, a navigation system developed for a delivery service assists couriers in choosing the best routes. The manager assigns tasks to the courier through the web portal, indicating the delivery addresses on the map. He always knows the couriers' location by receiving GPS positioning data. Route optimization Couriers use mobile cross-platform applications that depict the shortest route calculated using mathematical algorithms. The application sends notifications to the company manager and the shipper when the courier marks the delivery. Multilingual Support Misunderstandings and translation errors can be troublesome when decisions should be taken quickly. Multilingual logistics applications are user-friendly and can attract more customers to your company. Offline Functions The web connection is not always stable. If the mobile app has offline functionality, app users can enter data, view saved numbers, and access reports even when the network is unavailable. Chat and Calls to the Driver Built-in messaging and calling can be useful communication channels between company managers, shippers, and drivers. Logistics managers can learn about car accidents or breakdowns on the road and adjust the route. Customers can obtain the necessary delivery data directly from the driver. Network Protocols and Technologies Support Logistics software solutions typically interact with IoT devices, robots, and sensor-enabled systems to obtain the GPS positioning, temperature, humidity, and other data. Applications can support various communication protocols such as Wi-Fi, Bluetooth, NFC, and BLE. The customizable GPS tracking platform is built for asset monitoring. The system consists of a GPS tracking device with BLE, Wi-Fi, and GSM/HSPA communication interfaces and a cloud platform that stores the location and status of assets and displays this data to users in real time through a web interface and a mobile app. An asset tracking system is a GPS tracking device, a server, a mobile app, and a web app for displaying the asset’s location and condition. A cross-platform application for iOS and Android with Google Maps allows employees to monitor the location of assets 24/7. Asset tracking not only helps with warehouse management but also extends to other related areas. For example, the plug-and-play solution can be applied to localized online advertising of shops, restaurants, and other places using a distributed BLE beacon system, a web server, and a mobile application. Using the Android Studio IDE, the developers have created an SDK that can be integrated into any Android application. The Android application uses the iBeacon protocol to receive data from beacons located in shops, restaurants, and entertainment venues. The application then sends it to the web server, which determines the user's location. Data related to discounts, sales, and promotions is stored on the server and can be sent to recipients using push notifications. Interaction of components in our Bluetooth Low Energy beacon system This system allows various businesses, such as small coffee shops, boutiques, or cinemas in shopping and entertainment centers, to effectively advertise their services and promotions to their target audience. Cross-Platform App Capabilities Cross-platform logistics applications can run on iOS, Windows, and Android operating systems on mobile and desktop platforms without any or minimal differences in the UI. Users can choose the most convenient way to use the app. Logistics Software App Benefits The implementation of logistics applications contributes to the diminishing of transport and storage costs and the reduction of human errors. There are other crucial benefits to developing transport and warehouse applications: Good company image The convenient interface of the logistics application captivates users and positively affects the company's image. Automated fleet tracking and management By automating fleet management, the company frees up labor resources and saves time. The manager receives real-time data on the state of the company's vehicles, corrects routes, and uploads data. Customer trust and confidence Senders and recipients are always aware of the cargo location and delivery times, thanks to mobile logistics applications. Customers are confident in the safety of goods because they control the logistics process 24/7 and can contact the driver on the way. If the delay does occur, the customer receives comprehensive data on the timing of cargo receipt and never remains in the dark. Fewer paper documents Reducing paperwork to a minimum saves time and resources. Benefits of having software apps for your logistics business Logistics App Development Outsourcing When entrusting the development of logistics applications or software and hardware complexes to an outsourcing company, you should state your wishes and requirements regarding the final product in as much detail as possible. Requirements may take into account the following points: application platform (mobile, desktop, or web version), operating system, application functionality, UI design, description and brief technical characteristics of the device with which the application will communicate, equipment communication protocols, certification requirements (if the project involves hardware development with subsequent certification). Software application development is not always beneficial. Sometimes software solutions turn out to be unsuccessful, inconvenient, or of little use. Also published here.

Logistics App Development Overview: An Essential Guide

95 Stories To Learn About Product Manager

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. Channel preferences influence how the notifications are sent — via email, 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. 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 number of notifications sent increases throughout the software industry, users are rarely given the control 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. 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 : you want the preferences to be powerful, but also easy to understand and use. balance between complexity and flexibility 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 the information on whether your users have provided consent to getting notifications, of what kind, and how that consent was provided. will have to collect and store 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 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 where users complain about this behavior in the Uber Reddit thread Eats app, or with a similar complaint about Instagram. this thread Ideally, applications should allow users to opt-out of notifications that they’re not interested in, while staying opted into 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 which email address to use for notifications. allows users to choose 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 mode. Do Not Disturb 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 out of the box — you also get: notification preference management 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

Preference Management for Notifications for Product Managers

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 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 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, can drive growth metrics and delight customers. a good notification experience 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, , which includes functionality for sending plain-text and HTML emails. Action Mailer 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. Handoff to the PM for 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. 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 templates accessible to non-engineers. . 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. Making notification logic configurable without needing to re-deploy the app 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. Enabling self-serve analytics. 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, 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. has seen its business grow 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 , 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. Expel “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. 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. Get analytics in place. 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. Make it easier to change notification templates. 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. Build guardrails to prevent notification issues from escaping to production. 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. Also Published here

Free-up Engineering Time by Empowering Product Managers to Build Push Notifications

If you’ve worked on a digital product, whether as a developer, product manager, or business leader, you know that the most common problems in software development are rarely as straightforward as “bugs.” The root of the problem tends to require a little more trial and error. Using Courier is no different. In this post, we will discuss example issues around Courier’s Gmail integration and API rate limits, an incomplete data profile, and an incomplete request with Inbox and Toast. We will delve into how such issues can present themselves and how to troubleshoot independently to fix any issues. Troubleshooting through trial and error Just because an issue is complicated doesn’t mean the solution can’t be simple. Developers are constantly bombarded with jargon and terminology that could frighten even those of us who are more technologically-literate. Despite one’s development experience, programmers have learned how to find solutions through trial and error, pattern matching, and dare I say it - googling. Needless to say, it’s almost seen as a rite of passage in one’s programming journey. In this post, we’re going to tackle some of the most common, yet crucial hiccups our developers and users come across when integrating Courier into their notification infrastructure. If you’ve come across a hurdle, there’s a good chance that someone else has already figured out how to get across. Gmail integration and API rate limits Congratulations, you’ve successfully signed up to use Courier and are on your way to sending notifications! Once you’ve gone through the sign-up process and authorized Gmail to send emails on your behalf, you’ll be able to integrate Gmail as a channel to your email notification templates. The issue One recurring issue that has come up with our developers is getting rate limited, i.e when sending bulk transactional emails with Gmail integration. It’s understandable, getting 400 response errors isn’t fun. However as developers, Google-fu is one of the many skills required in troubleshooting. 429 errors The fix There’s no workaround here. Gmail's API has based on per-method quota usage (250 per second with 100 quota points per SEND). Thus, Gmail is really intended for getting started fast, testing, or small-scale sending. This is a great way for you to get comfortable with using Courier and make your first couple of sends. limitations Our recommendation is to check out of email providers and choose the best one that will suit your needs depending on your use case. If your intention is to send bulk emails at once, it would be best to choose a provider that will not rate limit you. our full list Incomplete profile data It goes without saying - Courier has an extensive list of notification providers our users can integrate into their notification infrastructure. Each of these providers have their own requirements for the profile object in the response. Without a profile in the request, some of your notifications will not be delivered and tell you why in the response that can be accessed from the message logs. The issue You’ve integrated your provider and set a channel to your notification. However, the message logs show an ‘Unroutable’ / ‘MISSING_PROVIDER_SUPPORT’ error in the response. This is strange, since you’ve integrated a provider, created a template, and sent a test event. The fix This varies by provider and channel, but for some of our most common integrations, i.e - email, the fastest fix to the “unroutable” error is by adding an email recipient to the profile. Courier supports many providers, and you can find each providers’ profile requirements in their respective . Depending on whether you’re using email, sms, push, etc to send your notifications, you want to make sure to provide a profile that matches the channel’s needs. integration documentation In-app notifications require a more detailed profile in the request which will be touched on in the following section. Profile exceptions For argument’s sake, let’s say you’ve integrated to send out notifications for your system alerts. In this case, Pagerduty does not require a profile because an event is mapped to Pagerduty services and not to an individual. So in this case, you can leave the profile empty. Pagerduty Courier Inbox and Toast incomplete request So you’ve decided you wanted a more centralized feed of your notifications and implemented Courier’s Inbox feature in your application. Our certainly makes it look good, and with the additional to match the look of your app and brand, how can one resist. And for our developers using non-react builds, we have for you. demo app customization options embedded integration The issue Let’s say you’ve successfully implemented Courier Inbox and Toast in your frontend with the right dependencies, and both Toast and Inbox are children of the in your application. CourierProvider component Everything looks as it should, and even provided a clientKey as a prop. After being able to send a request and receive no errors in our logs, we see a toast notification pop up in our app, yet if we navigate to our inbox widget, it’s empty. The fix Before we dive into the answer, let’s take a look at a sample send request in this case. In order for inbox notifications to persist, we need to add to.user_id in the SEND request along with to.courier.channel. This is for two reasons: to.user_id is used by Inbox to persist notifications. to.courier.channel is used by Toast to display your notifications. Your request/test event should now look like this: message: {
  to: {   
    user_id: “user_id”, 
  courier: {
    channel: “user_id”,  
} Once our SEND request includes the above configuration, your inbox messages will persist. Side note on dependencies/packages Our team at Courier is constantly working on making improvements, adding support for new features, and fixing bugs. This includes npm/yarn for CourierProvider, Toast, and Inbox. packages If you wish to update your dependencies, you can update them simply by changing the package.json to the most current version, and running yarn/npm from the root of your project. We invite you to reach out to support should you have any other questions or if you feel like you hit a roadblock. Still have questions? It’s the nature of the business to always be asking questions particularly in our line of work. This article is merely designed to help answer some of the most common questions we’ve come across with our developers. With that said, we believe that in order to make software-to-human communication delightful, there needs to be an open line of communication with developers who have implemented Courier to handle their notification infrastructure. We want you to have as many support options as possible whether it’s self-serve through our and , or 1-1 with our engineers and support staff. We’re here to make your Courier experience as smooth as possible! If you’d prefer enterprise-level support, sign up for a now! docs articles demo request

COURIER MANAGER

couriermanager.com

-- employees

Since n.d.

COMPANY RANKING

COURIER MANAGER

EVERGREEN INDEX #3139

Representing this company? Click here to claim and customize this page!

Courier Manager WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

COURIER MANAGER

couriermanager.com

-- employees

Since n.d.

COMPANY RANKING

COURIER MANAGER

EVERGREEN INDEX #3139

RELATED COMPANIESRANK

STORIES ABOUT COURIER MANAGER

Representing this company? Click here to claim and customize this page!

Courier Manager WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!