Tom Tunguz wrote an insightful blog recently comparing legacy software applications with the new, disruptive ones.
“A senior SaaS executive once told me, “Reports sell software.” In a top down sale, that’s absolutely true. The CEO wants better predictability of bookings so she’ll buy a CRM tool to gather the data. Classically, software has been built for that mantra.
In bottoms up sales, workflow sells software. And new SaaS companies who aim to displace incumbent systems of record will architect their products in a radically different way. They will be event-driven SaaS companies (emphasis is mine).”
I couldn’t agree more.
My start-up’s product is (was) event-driven
In the case of Bluenose, we were trying to help you unlock the value of user feedback (in the form of NPS surveys) and user behavior (in the form of product usage data).
This data should flow into your company continuously, and produces many valuable signals:
- As a signal about the health of your relationships with your users at a macro level
- As a signal about the health of your relationship with each user
- As a signal about where each user stands in their adoption journey
How can you use these signals?
The first signal unlocks the drivers of NPS, retention and churn in your business.
The second signal mobilizes your Customer Success team or guides your contact center agents.
The third signal enables you to target each user with relevant messaging on how to take their next adoption steps.
How does Tom’s thinking apply to your business?
If your job is to improve customer retention, “event-driven” is a provocative way to think about your customers and the events that should drive your engagement with them. The design of your customer-facing processes should be event-driven for sure.
If you’re in the role of designing products, it’s a clue about how to disrupt incumbent competitors (or fight off the upstarts if you’re being disrupted), by thinking about the events that should drive your app’s features.
If you’re in sales, it’s a way to frame your product as being different – and more valuable – than an incumbent product that doesn’t utilize events to drive a business process.
A final thought
One of the ways I like to think about customer events is how they drive scores.
You’re forecasting a customer renewal. Should the forecast probability (a score) be based on customer events?
- Sustained use of your app
- Survey responses
You’re scoring each customer’s health as part of a weekly Customer Success team meeting. Should the customer’s health score be based on events?
- Recent use of your app
- Recent responses to a survey
- Recent support tickets
- Changes in the customer’s team
Not only do events make for more accurate scores. They also pinpoint what’s changed in a score and make the next customer touch much more obvious.