For technology companies, notifications is a core service for user communication. Notifications are essential in informing customers about important alerts and updates, sending reminders, retaining via recommendations, informing about new product launches, allowing users to communicate with each other (both in real & non real time) and much more. However, for notifications to be truly effective, the users need to be targeted with the right content at the right time, and for the right amount. Anything less, the user experience gets broken, and anything more, users start unsubscribing and complaining.

To achieve this, companies have to spend dedicated time and resources repeatedly as they build their product. Most of the companies start with simple channel based services, and they keep on adding more channels subsequently (channels refers to SMS, email, push, slack, app inbox, whatsapp, calls, etc). However, they run into limitations quickly as they scale and need to handle more usecases. Consequently, a sound central notification service becomes a necessity for all new age technology companies, irrespective of their product offerings.

In this blog, I am going to highlight what are some challenges with respect to notifications, and why building notifications is so taxing for any company.

Challenges with notifications

1. Complex process for trivial tasks

Notifications in itself are not complex in nature, however, they require multiple iterations to find that perfect logic, content and time to send. For transactional notifications triggered on an activity, as well as for scheduled tasks, product managers want to iterate fast, but the control lies with developers. This repetitive and not-so-engineering heavy task is either de-prioritised in sprints or it ends up eating bandwidth that should have gone in solving core business problems. Additionally, the development effort further increases as new channels for the same notification are added. Creating and editing notifications should be easy for PMs to experiment with, with minimal engineering efforts involved, and should not wait till the end of sprint to deliver.

2. Managing notifications

At multiple times during a company's journey, teams need to go through notifications that are already live. This could be for any of the reasons: - To go through legacy notifications before making new ones - To make changes in content/ logic - To check their performance; There could be any reason, but to see details of what is live requires either managing a strictly updated document, or going to the engineering team to look into the code and note what is live. Doing this exercise becomes even more difficult when there are multiple PMs working on notifications, and documents maintained become obsolete very quickly. Because of this, the legacy notifications continue as they are, or they are handled as a big project once or twice a year.‍

3. Testing notifications

Though notifications are simple, they can end up consuming testing bandwidth like any other complex tasks. The issue is again not complexity, but the time spent in coordination between teams. There are some basic infra requirements for testing notifications. Engineering teams have to setup platforms for all channels where test notifications will be triggered, which is almost always a very makeshift arrangement. In most cases, test notifications are routed to single testing device/accounts that not everybody has access to, requiring coordination or creating delay. Furthermore, for testing notifications that are scheduled tasks, often developers have to trigger them manually, as and when QAs and PMs test them - another process that breaks work continuum.
‍

4. Scaling notifications

As companies grow, they are required to keep an eye on successful delivery of communications. For a company that did not invest in robust communication architecture early on, communications start causing trouble as they scale:

• Different communications have different priority, there are some important notifications that require immediate user attention, and others that are promotional in nature. In case there is no distinction between them, if the pipeline is queued with low priority notifications, the high priority ones will simply be delayed. In case this service is scaled up to ensure timely delivery of all notifications, it would lead to higher infra cost. Ideally, companies look at no-delay delivery of certain notifications (transactional), and staggered delivery of others (promotional) while optimising for infra costs.
• If the API based service is down, notifications queued do not get delivered, leading to important communication being missed out. A better system requires setup of fallback option and retries for robust delivery.
• In case of delays or failure, there is no system to inform about it. It is often highlighted from the business teams or customer facing portals if notifications are not delivered. In worst case scenarios, team might never know about the failure. A good communication system should have an alert system in place, just like how server downtime instances are reported.
• There are also instances where notifications delayed earlier are suddenly delivered to users later when the context is already lost (imagine payment debited notification getting delivered 2 weeks later). This appears like a rare issue, but it leaves a poor impressions on the customers.

5. Non-comprehensive analytics

Analytics is probably as crucial as notifications itself.

• Although individual vendors provide analytics on their own dashboards, it is not the best way for teams that want to analyse all the channel notifications together (eg. comparing delivery rates, click rates by channels)
• Analytics at user level is another crucial element which, unfortunately, is hardly looked into. It is in the best interest to know how many notifications a user is getting in a certain time frame, whether multiple communications are getting triggered together, and how a user is perceiving all the communications holistically. If this analytics is a blindspot, users are either not engaged properly, or are bombarded.

6. Multiple channel strategy is like walking on tightrope

This one particularly is a multi-dimensional issue that is a double-edged sword:

• Teams want to ensure that their users get the communication, so they integrate multiple channels into their service. But targeting users on all available channels, though increases the conversion, leads to bombarding the end users and them unsubscribing from notifications.
• Sending communications on multiple channels is a costly affair for companies as well, and it is incurred in vain when a user has already seen it on one channel. To solve this, companies need to invest in building an intelligent communication delivery system, which while taking into account user past behaviour as well as the nature of communication, delivers them to multi channels in a staggered manner, therefore, saving cost to the company as well as preventing bombarding.

7. Reaching out on inactive channels

There are cases when users' contact details become inactive (a user left his company, changed his number, etc). When communication is sent out on such contacts, unnecessary cost is incurred. For emails, high bounce rates affect the domain reputation. A low domain reputation risks the subsequent emails being classified as spam. There are many solutions in the market which tells if an email has bounced, but it is only after the email is shot. It makes sense to know in advance about the inactive channels, and filtering them out so that cost is not incurred, and database is kept clean.

8. Multi-lingual communication

For companies that have presence in non-English speaking geography, multi-lingual communication becomes a necessity. Whether it is expanding to new countries or making product for next billion users, ability to send communication in multiple language asks for a lot of development effort. It requires storing user language preference, and managing as many templates.

9. Giving power to users

For certain type of communications, letting end users choose what they want to be buzzed about, and what they are not interested in, makes a good engagement strategy in itself. In absence of this system, some users unsubscribe from all the communications, which is a direct blow on engagement and potential sales.
‍

10. Endless notifications

Engagement notifications are designed in one size fits all approach. It is not by choice but by design restriction. It is humanly not possible to design custom frequency for each user. This often triggers unending notifications on offers and reminders to some users who might not be interested in them. A smart system should tailor notifications based on how user are reacting. If users are interacting more, increase the frequency, if users are not responding after a while, leave them alone and re-engage them in a different way. Startups and growth phase companies are hardly in a position to invest in building this kind of complex system, which requires data processing for each user, and pulling the insights back in the delivery pipeline. Hence, companies resort to simple notifications with some level of personalisation, with a cap on how many notifications a user can get within a timeframe. This sub-par solution eludes companies precious engagement with their users, and burn holes in the pocket.

11. Multiple vendor integration

Last but not the least, as much as company's internal system can be at fault, external systems can become unreliable too. No vendor can guarantee 100% uptime. And when they go down, they give poor experience to end users. In scenarios like these, a company that has time sensitive communication for its customer base (eg. OTP), needs fallback option, and hence multiple vendor integration. But given each vendor has its own api integration guidelines, it requires the same amount of engineering bandwidth for integration with each vendor. Because of this, unless a decisive moment comes, companies stick with one vendor per channel, or look out for vendors that can provide multiple channels - which might not be the cheapest solution.
‍

We are building SuprSend keeping all these issues in mind, so that engineering teams do not have to invest their bandwidth in reinventing the wheel. They can focus on solving their core business problems, and unlock the true potential of communications.

If you resonate with these issues, give SuprSend a try! Even so, do let us know what you think. How do you solve communications at your workplace?