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.
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.
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.
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.
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:
Analytics is probably as crucial as notifications itself.
This one particularly is a multi-dimensional issue that is a double-edged sword:
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.
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.
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.
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.
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?