This was originally posted on the Knock blog.
Notifications used to help us. They were a signal for what to read and what to do next. They sought to surface what mattered where we needed it most.
But notifications failed us. They became a mess of marketing and noise. They left us to block and tackle and search for value on our own. Now we live in a daily struggle, sifting through information and managing attention across tasks—both personal and professional.
Despite this, notifications can still have value. The decision that unblocks a teammate. The mention that clarifies a top priority. The message that puts us back in touch with a friend.
At Knock we want to help software deliver that value to its users. That starts with giving product and engineering teams the tools they need to deliver great notifications.
What makes a great notification
A notification has one goal: to deliver value to the user on the right channel at the right time. To accomplish this goal, notifications should be designed and sent with the following principles in mind.
- Contextual. A great product understands its users. It knows when they want to hear from it and when they don't. It knows which notifications should be sent outside of working hours (high-priority alerts) and which shouldn't (comments, replies, mentions.)
- Relevant. Advanced notification systems take in multiple inputs to determine whether a notification is relevant for a given user. They evaluate what a given user has engaged with, on which channels, at which time, and use that context to send better notifications to the end user.
- Actionable. When a notification asks a user to act, it should give them the clearest path possible to do so. The gold standard is to let the user act within the notification itself. If that's not an option, the notification should direct the user to where they can complete the action.
- Configurable. A great notification puts its users in control. Whether it's in-app, email, or push, a notification gives the user the ability to close the loop and tell the system they no longer want to receive notifications about that topic. This includes per channel preferences, as well as do-not-disturb and snooze modes.
- Reliable. Notifications need to be 100% reliable. A high-value notification is only valuable to a user when they know they're going to get it every single time.
It's easy to agree on the qualities above as things we'd like to see in the notifications we receive, and we can all point to a few tools that do these things well. But most products don't put these principles into practice.
This doesn't happen because teams knowingly build products that send redundant or spammy notifications. It happens because building and maintaining the systems that power these notifications is (i) a hard problem to solve and (ii) a problem that most teams don't get the time to solve in the right way.
Notification systems are hard
We know this because it happened to us. When we met in our prior roles at Frame.io, we knew notifications were a key part of the product experience. For a time, the most common pain point we heard from NPS detractors was that we sent too many notifications. To solve the problem we built notification batching, smarter digesting, and better email threading to move things in the right direction, but we always knew there was more we could have done for our users.
It's a story we've heard again and again as we've spoken with customers. Teams know they're leaving a better customer experience on the table, but can't devote the time it takes to deliver great notifications.
All of these companies are caught between time spent on their core, differentiating product and the underlying utilities that support it, such as payments, search, authentication, and, yes, notifications. There have been 3rd-party services to help us with most of these utilities—Stripe for payments, Algolia for search, Auth0 and WorkOS for authentication—but as engineering and product teams, we've been left to fend for ourselves when it comes to notifications. Not anymore.
Knock helps product and engineering teams send great notifications to their users.
Here's how it works. We give our customers an API to tell Knock what's happening in their product. One notify call gives Knock what it needs to power digests, batching, and channel sequenced delivery.
With that context available in Knock, product managers and others can use the dashboard to build, design, and send notifications, without taking valuable time away from engineers. For in-app feeds, we offer pre-built components and SDKs that teams can use to power real-time, fully featured experiences in their frontend. For out-of-app channels, such as email and push, we integrate with the platform providers you already use today.
We handle the basic plumbing of sending notifications for our customers. But as with most 3rd-party APIs, teams get other benefits by outsourcing a utility to a provider that devotes 100% of its time and focus to that problem.
- Ship the notifications you wish you had time to build. Because notifications is our core business, we can obsess over notifications to a degree that wouldn't make sense for anyone else. From handling dark mode variants to sequencing channel delivery to powering dynamic emails that update in real-time—these are the things we can afford to focus on at Knock, because notifications is all we do.
- Empower people who don't code, give time back to people who do. Knock makes notifications self-service for non-developers. Instead of writing Jira tickets and taking valuable time away from engineers, product managers can update notification templates and workflows in minutes instead of days.
- Visibility and quality control for every notification. As a product team grows, its inventory of notifications sent to the customer often gets lost in the shuffle. Siloed teams introduce their own notifications at will, unknowingly degrading the user experience as a result. A system and dashboard in place from day one keeps visibility into what's sent to the customer.
At Knock we enable our customers to bring forward their entire notifications roadmap and ship it to their users in a day. Once it's shipped, we give them the tools to understand the efficacy of those notifications and move them towards a better experience for the customer.
What about X?
There are already a lot of tools that exist today to help send notifications. Here's where we fit in.
Today developers can send a message across any channel—email, SMS, push—with an API call. Notification delivery is a hard problem, and it's been solved by platform providers such as Twilio and MessageBird. Now the hard part isn't the API call to a specific channel, it's everything that comes before it. It's the orchestration of notifications across multiple channels.
Ten years ago the hardest part of notifications was delivery. Now it's avoiding over-delivery. That's where we come in.
Our mission is to help software communicate with its users.
This starts with giving every company the tools they need to send great notifications. It ends when every product can send intelligent, contextual messaging to their customers.
Notifications don't need to be a nuisance. When done right, they should help us manage our work, stay in flow, and make the most out of the tools we use every day.
We're hiring an incredible team to help solve this problem for engineers, product managers, and end users of software everywhere.
Come join us and let's send notifications that matter.
Sam + Chris