Interested in marketing, product management, customer support, design and startups? Intercom is the first to bring messaging products for sales, marketing & customer service to one platform. On our blog the Intercom team share thoughts, tips and lessons learned from five years of product building.
These days, many companies offer a knowledge base for their customers to use. The self-service aspect of knowledge bases makes them natural time-savers for users and businesses alike.
But a knowledge base – or, as we call it here at Intercom, a help center – shouldn’t stand alone as your only support option. Nor should it be viewed as a detour on the way to talking to a human being. It should be part of a larger customer success game plan to help your users achieve their goals through expert use of your tool.
Show your customers you care about their success by providing a well-managed knowledge base – one that solves problems, saves them time, and ultimately reduces the risk of churn. Here are some of the best practices we use here at Intercom to efficiently manage our help center.
The business impact of great knowledge bases
Customers need online knowledge bases to find answers to questions, to learn more about your product, or to make the process of teaching someone else (like a teammate) a little easier. The benefit of these knowledge repositories isn’t just on the customer side, though.
1. Self-help methods reduce costs
A well-built knowledge base allows you to keep your support team lean, even as you scale. Research shows that automated support interactions – like help centers and chatbots – can cost pennies whereas support interactions that require input from a human – like phone or email support – can cost more than $13 per interaction.
“Your support team can spend more of their time helping customers with complex issues”
This data shouldn’t deter you from providing human support, which has plenty of benefits. What it really highlights is just how much money you can save by pairing human support with a self-service knowledge base as well. You won’t have to hire additional team members to answer basic questions, and your support team can spend more of their time helping customers with complex issues, sharing feedback with product teams, or creating true customer delight.
2. Knowledge bases reduce churn
Difficulty understanding how to use and find success with a product is a top reason for churn. You should do everything in your power to address this potential for churn, and that includes creating and updating a knowledge base.
The guidance found in your help center unblocks confused or struggling users, making them less likely to abandon your product for a different solution. Your articles also turn novice users into knowledgeable pros who feel confident continuing to use your product, even if they face new questions or challenges. By giving customers the information they need to become expert users of your product, a knowledge base becomes a critical retention tool.
Knowledge base best practices: 6 tips for customer success
By following a few knowledge base best practices, you’ll make a big impact on how your customers find and use information in their time of need. Here are some practical tips based on our own experience and what we’ve observed elsewhere.
1. Make navigating your knowledge base easy
You may have a thousand useful articles, but if customers can’t find what they need, they’re likely to get frustrated.
Internal search, breadcrumb navigation, links to related articles, and consistent on-page navigation options (like menus or back and forward links) are all ways that you can improve your help center’s navigation.
Additionally, if you have a lot of articles, breaking down your content into logical groupings – like areas of your product, or the different jobs people will be doing with it – can help you further organize it in a sensible way in menus. Many support teams use a card sorting exercise to guide this process.
Article collections in Intercom’s Help Center
2. Make your help articles easy to follow
Large blocks of text will likely make your users’ eyes glaze over. Help them easily find the info they need in your articles by using bullet points and lists, images (including GIFs and emoji), and videos to explain tricky concepts and break up space.
Consider breaking your help center articles into smaller, “bite-sized” chunks of information. Not every detail about a certain aspect of your product or service needs to live on the same page: you can create a “how to set up” article, “how to customize,” “how to integrate,” and so on.
Along with being easier for existing customers to read and digest, this approach can help you rank highly in searches for specific phrases, helping you attract new customers. For example, ProfitWell’s knowledge base article on understanding delinquent churn ranks highly in Google searches for phrases like “delinquent customer churn,” which leads prospects to their product.
By breaking down their knowledge base into multiple smaller articles, ProfitWell helps current and potential customers more easily find the exact information they need.
3. Define any new or potentially confusing terms
Before you publish a new knowledge base article, look it over for any confusing terms, industry-specific terms, and acronyms. Explain the meaning of special terms or spell out acronyms the first time you use them, even if you think your audience already knows what they mean. You could also dedicate some space at the start of the article to defining common terms, or link to a glossary – like our own Intercom Glossary – where you’ve defined these phrases in detail.
“Take a look at conversations you’ve had with your customers in the past to see what they had questions about”
When you know something inside and out, identifying what others may find confusing can be a challenge. Take a look at conversations you’ve had with your customers in the past to see what they had questions about. Additionally, if you had beta testers for your product, they may have provided direct feedback on in-app language they found confusing, so don’t forget to look over their thoughts, too.
4. Keep your articles accurate and up-to-date
Customers prefer using an online help center, but finding incorrect, out-of-date, or even misleading information can sour the experience.
Update and publish help articles as soon as you launch new features. It’s immediately after a feature release that your customers will be most curious, and therefore have the most questions. Ultimately, publishing timely how-to articles and best practice guides will greatly improve your feature adoption rates.
To produce and maintain articles that meet your customers’ needs, work closely with your product management (PM), product marketing (PMM) and customer support (CS) teams.
Our Product Education team members strive to maintain an encyclopedic knowledge of our products. But true encyclopedic knowledge is never static. So we stay close to the source of knowledge at all times: our product managers. As their teams plan, build, and release in six-week cycles, we sync with them three to five times each cycle to understand the upcoming changes and prepare for these releases with new help center articles.
Understanding why something is being built is especially important, as it’ll allow you to explain why customers need a certain feature. As the cycle progresses, we’ll try out new features, document its functionality, and develop best practices for it. Finally, when we’re closer to a release, we’ll write and share a draft of the knowledge base article so they can review its accuracy and help us fine-tune the smaller details.
5. Link to other support options
Some support teams see knowledge bases as tools to deflect customers. This is not our experience. In fact, we’ve learned through user testing that if customers know they can get help when they need it – via phone, email, live chat, and so on – they’re actually more willing to look for an answer on their own first.
“The best way to think about a knowledge base is as one part of your support ecosystem”
The best way to think about a knowledge base is as one part of your support ecosystem. Your articles may not have all the answers a customer needs, or may not be easily accessible to all visitors. So linking from your knowledge base to the rest of your ecosystem, like your help desk and live chat, allows customers to get the help they need no matter when they need it.
Analytics app Baremetrics does this well, allowing their knowledge base visitors to immediately click over to live chat if they can’t find what they need or if they have a complex question that needs a human touch.
By using Intercom, Baremetrics puts multiple support options – like their knowledge base articles and live chat – right within reach.
6. Utilize your articles everywhere
One final thing to think about: one of the biggest mistakes a company can make is creating incredibly useful knowledge base content and linking to it from a single spot in their website header or footer. While you definitely want your help center to live in its own special location, you don’t want the content to be so siloed that your team forgets the articles exist and customers never use them.
Look for opportunities to surface your knowledge base articles at relevant times and locations. These include in-app tooltips or UI prompts, links from relevant landing pages or blog posts, drip email campaigns to new or upgrading users, and even conversations with your support team.
It’s even easier to surface the information inside your knowledge base if you’re using Intercom. You can:
With Intercom’s Messenger and Articles working together, your customers can effortlessly find the info they need, no matter where they are in your product.
Manage your knowledge base efficiently
If your product’s constantly changing, help articles can quickly become unhelpful, and even misleading, if you don’t review them often enough. But you don’t need to staff a large team to keep your knowledge base up-to-date. The following tools and processes can help you quickly identify changes needed and efficiently make updates.
1. Create templates for common topics
Your support team members shouldn’t have to build every new article from scratch. With multiple people working on your team – especially as your company grows – you might start spotting inconsistencies between your documentation that have a real impact on the customer experience.
Building a template for your knowledge base documentation – even if it’s just a simple sketch or document – will help your team understand what a successful article should look like. A sample template might look something like this:
2. Create a feedback loop with your support team
Even with a team of writers, broken articles will nearly always be noticed first by the people reading them – your customers. They’ll notice if an article is out of date, if it doesn’t explain a process clearly enough, or if there’s a knowledge gap in your help center.
“Keeping your ears close to your customers is one of the most impactful ways you can keep your help center fresh”
How do you get feedback from thousands of eyes instead of dozens? By building a feedback loop with your support team. Keeping your ears close to your customers is one of the most impactful ways you can keep your help center fresh. If you create a feedback loop with your customer support team and implement your customers’ suggestions, your help center will become a much more valuable resource in a matter of weeks.
If a customer finds something out of date on Intercom’s Help Center, our support reps can easily contact the team that works on our help center – the Product Education team – through the Messenger. Reps are asked to send a link to the article, a screenshot of the specific issue, a brief description of the problem, and a solution. Our education team reviews their request, gathers any missing information, and makes the update.
A feedback loop allows our team to quickly surface – and resolve – issues with our knowledge-base docs.
Many of the updates we make to our articles are surfaced by our Customer Support team. Our close relationship with them is crucial to keeping our Help Center as accurate as it can be. Instead of relying solely on our own audits, we can instead utilize our customers’ valuable feedback through this channel and gather quality feedback at scale.
3. Prompt your customers for feedback
Of course, the key to a successful feedback loop is input from your customers. If customers don’t know how to give your support team feedback on your help center, or if that feedback option is too hard to use, they won’t be able to point out anything that’s broken or unhelpful.
For example, one of our customers, Productboard, allows their customers to rate each article in their knowledge base. If a customer adds a negative rating to an article, a bot will immediately send a message letting the customer know that they can ask a human for help.
If a customer doesn’t get the information they need from the Productboard knowledge base, the Intercom task bot will immediately connect that customer with the support team.
When you ask, you might find that you only need to make small improvements to truly help your customers succeed. So don’t be afraid: getting this honest feedback will tell you what needs to be changed, where, and how you can help more people long term, and it will ultimately take a bigger load off of your support team.
4. Prioritize your updates
Managing help articles is a process of constant prioritization. Depending on how often your product teams ship new features, you might have to be comfortable with a certain level of out-of-date material while you focus on the most important changes.
“A greater level of prioritization will help you keep your knowledge base articles helpful”
Not all inaccuracies in your knowledge base are created equal. If you’ve changed the color or style of a button, but it’s still in the same place and does the same thing, there’s probably not an urgent need to update the screenshots in your docs. But if the button has changed locations, or there are now three buttons instead of one, make it a priority to update those images.
If you’re having trouble deciding what to update, and when, ask your yourself: Is this article fundamentally broken, and is it confusing customers? Or is the inaccuracy cosmetic, and one that doesn’t harm customers’ understanding of the product? If you’re in a company with a high volume of product changes, a greater level of prioritization will help you keep your knowledge base articles helpful.
A strong knowledge base is just one piece of the customer support puzzle
An easily accessible, searchable, and readable knowledge base tells your users that you care about their success. To make it as impactful as possible, consider how well it fits into your full support offering. Ideally, your prospects, trial users, and paying customers should all be able to flow from one support channel to another with zero difficulty finding the information they need.
As long as your knowledge base fits neatly into that whole puzzle – and makes it just as easy for customers to jump in and find information as it is to start a live chat session for more help – you’ll keep your churn risk low and customer happiness high.
Almost every software company today has some kind of incident response process to help them navigate major service outages. Intercom is no different, and up until mid-2018, our incident response process had worked successfully.
We had many experienced engineers who had been part of on call rotations at other companies, we ran basic postmortem exercises and overall our frequency and duration of outages was pretty good for a company of our size.
However, after a particularly complicated and long-running incident (known internally as “The SpamHaus event”) we realized that we needed to significantly up our game. As our business has grown, so too has the potential customer impact of any incident. Our engineering organization has also grown, and there are now significantly more stakeholders who needed to know what was going during an outage. Our incident response processes for smaller events was solid, but for particularly critical issues, it was clear there were many opportunities for improvements.
Over the past few months, we’ve been working on solidifying our incident response process and documentation. We’re sharing it now in the hopes that it will help others adopt a better incident management process quickly and painlessly.
Defining the different stages of an incident
To establish a successful incident response process, the first thing to do is to take a step back and look at what happens in most incidents as they unfold. Of course, incidents come in all different shapes and sizes. For example, a relatively common type of incident might be a brief outage of Intercom due to a database failover.
However, based on our experiences in mid-2018, we were particularly interested in solving for the more serious outages that would require a more formal incident management process. These are situations where there is no clear fix to the problem, the duration of the problem is prolonged, or the customer impact is grave.
The first step was to define the different stages of an incident:
Identification: The outage is identified, usually by an on call engineer, and a priority is assigned, which can later change as we understand the full impact.
Triage: An incident response team will investigate, following procedures that can change as the event evolves. This is usually managed by an experienced engineering leader.
Communication: When needed, communication with customers, support, sales and leadership can occur. This can be done by the Customer Support team or through informal channels.
Resolution: The incident is resolved, and follow-up actions like an incident review occur. This was managed by engineers with some oversight from engineering leadership.
We also worked to clearly classify the severity of incidents. For example, some of our team had an incorrect assumption that a P0 was always security related, so we invested in education on this in addition to providing more examples of what we classify as P0 (a large event that puts the public reputation of the company at risk) through to a P3 (a minor defect or bug that should be fixed). We further offered guidelines on how something is escalated from a P1 to a P0 (such as extended incident duration, or catastrophic customer impact such as data loss), which helps in especially complicated situations.
Previously, there had been different people involved at different stages, working off their own mental models of what needed to be done, and with no clear guidance on what to do, especially when things aren’t going to plan. While this can work for smaller companies, for an operationally mature company like Intercom there needs to be some semblance of clarity and accountability as to who is doing what at any given stage.
Which brings us nicely onto our next point…
Incidents can be stress-inducing enough as it is, so the last thing the team needs is uncertainty as to who they need to help out, and who needs to communicate with whom. By defining clear roles in advance, you create an environment which makes easy, clear communication between your teammates all the more simple.
Firstly, we introduced a formalized Incident Commander role. In times gone by, we generally did have somebody managing the event, but this was done informally and without explicit responsibilities. With an Incident Commander, we now have someone who can act as a single source of truth and take responsibility for managing the technical resolution of the incident, end to end. This was not a role that we invented out of thin air. It’s a commonly used role across our industry (and beyond), though with a variety of different titles and responsibilities.
In addition to managing the event itself, the Incident Commander is also accountable for all technical communication that occurs. Unlike other companies, we made a deliberate decision not to spin up a separate “Technical Lead” role as well. Given the scale of our organization, separating the roles of Incident Commander and Technical Lead was not fully justified, though we decided that for a particularly complex event, the Incident Commander has the ability to nominate a Technical Lead.
The second role we created was Business Lead and this was designed to solve for how we communicate with people outside the engineering org. To do this, we created the role of what we refer to as the Business Lead. This is the person responsible for coordinating all communication outside of the incident response room. That means communicating with our customers, our Customer Support team and sometimes all the way up to our leadership team.
We already had a lightweight process for partnering with our Customer Support team (for example, updating Intercom’s status page for lower priority incidents), but when a particularly high severity incident occurs, the Business Lead can help to communicate more frequently and proactively to customers, and ensure the sales, leadership and Customer Support team are aware of the potential business impact.
At Intercom, we generally like to work from first principles whenever possible. Principles are especially relevant during fast-moving events like outages. Even with the best documentation and the most robust processes in place, the reality is that outages are inherently unpredictable events where it is impossible to anticipate every situation you may find yourself in. That’s why it’s important to have a set of guiding principles to help people make autonomous decisions when no explicit steps have been defined.
Here a few examples of our incident management principles we created:
Do one thing at a time
Changing two or more things at the same time is risky and can be harmful. It creates more work to keep track of what’s going on, there’s more things that can go wrong at the same time and you may not be sure exactly what just made things better or worse. Do things sequentially, unless there is very good reason to do otherwise. Verify the impact of each change made before moving on to the next.
Try the easy stuff first
There are common recovery strategies that can work in a variety of situations, sometimes even if you don’t have anything to precisely associate it with what you’re seeing. Rollback the app. Failover a database. Toggle a feature flag. Clear a cache. These actions are common things that happen regularly, are quick and safe to execute. Code or infrastructure changes can be slower to implement and may depend on a healthy build and deploy pipeline. Asking the team “what can we quickly try out?” and ruling things quickly and safely can result in a fast resolution before a precise diagnosis of the problem is made.
Wrap things up quickly
It’s common to let things drag on a bit before closing out an incident. Don’t do this. Remove people from the room and shut things down promptly as soon as it’s clear that things are stable, and you are no longer in a crisis mode. Make sure the owner(s) of follow-up actions know they have work to do and what expectations we have of them. The quicker we get back to normal business, the smaller the impact.
Training and documentation
Documentation is one of the most critical aspects of a solid incident management process. In the tinderbox environment of a major incident, the last thing you want is people sitting down to a blank page or reinventing the wheel and creating new processes from scratch. During critical incidents, every second counts and documentation will give your team an all important headstart to ensure you recover as quickly and seamlessly as possible.
The documentation we’re most proud of is a fun training video we created for people who are interested in being an Incident Commander. We trained four commanders in both our Dublin and San Francisco offices and set up a PagerDuty rotation that aligns with our office hours, since that’s when most of our incidents occur. But we also wanted to democratize the process and make sure everyone had access to our incident management tools and resources.
We also wrote plenty of traditional documentation, such as incident checklists and onboarding guides.
Excerpts from our documentation for Incident Commanders
As a result of this work, we’re in a much better position. When something goes wrong, we have the right people available online restoring service to our customers. And when we need to tell our customers or internal stakeholders about what’s going on, we’re doing so far more effectively.
Putting it into practice
In the same way you wouldn’t ship a new product without having run it through a beta, it was important for us to test our incident management process in action before rolling it more widely throughout the company.
One of our most worthwhile exercises was to get people to brainstorm potential scenarios that could hurt Intercom and our customers in a variety of ways, and then use those scenarios to pressure test our new processes to see if they were up to scratch. This was, quite frankly, a bit terrifying, but it was a really useful exercise for us in both raising awareness with leadership teams and reassuring us that our processes would work.
We were also soon given a real-life incident to put our processes to the test, during a major outage of our search infrastructure. The event was complex and required multiple streams of work to resolve. Our principles-based approach to the event gave a shared understanding of how to operate and meant that the Incident Commander during the event was confident in splitting up the response team into multiple groups to take on different work to set us on the road to recovery. Our customer communication was accurate and timely, as was our internal communications. Had this happened three years ago, I’m not sure we would have been equipped to handle the situation as successfully.
We know our new incident management processes are just the first step in a long journey ahead. As Intercom continues to scale, we’ll have to continue to invest in how we respond to bigger and even more serious incidents. However, we feel like we’ve put the right foundations in place to be able to able to respond to major incidents without chaos and stress, and with a proactive communication style that keeps our customers, and our stakeholders, aligned.
In a company’s early days as a lean, mean, business machine, it’s fairly easy for leadership to stay in sync with their users. You might say it’s one of the strongest advantages a startup has.
But as the business becomes more successful – and there are resources to build a support team – additional layers begin to separate executives from their customers. It becomes harder for the folks running things to make time to be inside their customers’ minds.
Michael Redbord has an answer for that. If you’re a leader, he says, don’t try to scale your job. Even as the company begins to expand, it’s important to prioritize these one-to-one conversations because understanding how your users interact with your product is actually the key to healthy growth.
As the General Manager for HubSpot’s Service Hub, Michael knows a thing or two about keeping customers close. Since 2010, he’s helped the company grow to more than 40,000 customers and helped scale the support team to more than 500 employees to assist those users.
He joined me on one his regular visits to Dublin for a chat that ranged from seeing customer support as a model for growth to how to say focused on your customer in an automated world.
Short on time? Here are five quick takeaways:
Most sales and support teams talk about their jobs as a funnel. Move away from this concept and toward the idea of a flywheel instead: feeding energy back into the system instead of success rates diminishing over time.
Speak the customer’s language. If you’re a company that can be really customer-centric and can have your entire executive team talking to and understanding the voice of the customer, you will thrive.
As automation becomes increasingly popular, it’s essential to stay uncompromisingly focused on the customer. The more you can replace repetitive support tasks with bots, the more time you free up for your human reps to operate at a higher and more intimate level with users who truly need them.
Support and success are siblings. The more you can keep them together so the customer experience is contiguous across the two, the better it is for your company.
If you enjoy our conversation, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Kaitlin: Michael, welcome to the show. It’s great to have you in Dublin. What brings you over here, and what have you and your team been up to recently?
Michael: Thanks, Kaitlin. So I’m actually here to talk at The Next Web over in Amsterdam later in the week, but I’m pretty excited to be here with you guys today with Intercom. We’re almost halfway through the year, and we’re trying to make sure we’re going at the right pace and delivering for our customers. It’s been a cool week and I’m really excited for The Next Web in a couple of days.
Kaitlin: You’re the General Manager HubSpot’s Service Hub. Could you give me a bit of background on why HubSpot built Service Hub in the first place and the philosophy behind it?
Michael: Most people listening probably think of HubSpot as this inbound marketing company. We coined the term way back in 2006 when we founded the company, and a lot of our story, historically speaking, has been around marketing. We really popularized content marketing and how to generate traffic and leads and turn that into customers. That was really the beginning of our story. Then a few years back we started building a CRM, which has done really well in the market. Once you start moving from building marketing software just for marketers – which is the tip of the spear in your go-to market – and you begin getting a CRM and then more salespeople involved, all of a sudden you realize: “Man, there’s a lot more that we could be doing for our customers. And they’re actually starting to demand it from us.”
So it was a combination of continued growth and customer demand. We said, “Oh, we could build a service component in here,” and now we have a marketing hub, a sales hub and a service hub. Those three together really comprise the entirety of the front office for the SMB. We’re pretty happy with the way that it’s been going, and our customers have enjoyed us being able to offer them more across the entirety of the customer experience.
Customer service as a model for growth
Kaitlin: It makes a ton of sense. What’s interesting to me about Service Hub is that it seems to be less about, say, ticket deflection or resolution and more about using customer service as an untapped revenue or growth opportunity. Why do you think customer service is an effective model for growth?
If you can make your customers rabidly happy, they turn into your best marketers.
Michael: When we started HubSpot, we had this metaphor of a funnel, right? Everybody in marketing and sales and probably even customer service uses the concept of a funnel. You bring folks in at the top, and they have certain rates as they move through some process. So if you bring folks into your website, you have a conversion rate. If you bring folks into support, they have a rate at which they maybe close their case the first time or open a case a second time or something. There’s a funnel concept. That concept was really, really powerful for us. But we’re moving away from that funnel concept and toward what we call the flywheel, which involves feeding back energy into the system as opposed to a funnel where your rates of success diminish as you go on.
What we’re seeing with Service Hub is that it’s really a way for folks to take their customers and turn them into their best marketers. It flips where we came from, which is nice just from a company genetics perspective and messaging. But more importantly it also happens to be real and true. And in fact, if you can make your customers rabidly happy, they do turn into your best marketers. So the aim of this product is to enable that virtuous cycle, where your customers become your best marketers. So far, we’re seeing that for small and medium size businesses, that’s actually really, really powerful to help them compete with the bigger players in their space.
A tight handshake between support and success
Kaitlin: I think that makes a lot of sense. There’s so much out in the market about this, and we talk about customer delight and net promoter, and it’s really interesting to get HubSpot’s view on all that. If customer support can be an efficient driver for revenue, do you think that sales and support should actually sit under the same umbrella from an organizational standpoint? I’ve seen other companies package these all together.
The thing that matters most is customer-centricity and how well our executive team speaks the customer’s language
Michael: It’s super interesting because you see all sorts of different models and org charts. And actually I would include a third thing: cultures out in the world, right? I think the culture is actually the most important thing. If you’re a company that can be really customer-centric and can actually have your entire executive team talking to customers, understanding the voice of the customer, there are a lot of ways to do that. Some folks will organize support in a product function, and then they’ll have CSM over in a sales function.
You could also group support and success together under one person. That’s actually my preference, because I think the functions are so intertwined that you really need a very, very tight handshake between the support (as the reactive function) and success (the proactive function). Then the sales function, depending on the kind of company, could even sit with it if it’s a relationship where the salesperson is intimately involved in the customer lifecycle and customer experience. Or it could sit a little farther away if your sales are more transactional. There are a lot of ways to organize the org chart. I’m a fan of putting support and success together as a first-order principle. But the thing I’ve seen actually matter the most is customer-centricity and how well our executive team “speaks customer”. If they really, really are great at that, then a lot of it matters less, because the whole organization becomes really customer-centric.
Kaitlin: “Speak customer.” I love that. I’ve not heard it articulated that way, and it makes a ton of sense. One big challenge for a lot of support leaders today is this concept that customer service is a cost center. Even at customer-centric companies like Intercom and HubSpot, there’s always pressure – maybe not to keep costs down – but to be responsible with how you’re scaling your customer support experience. How do you guys think about communicating the ROI of customer support?
Companies are fundamentally misunderstanding where their growth comes from
Michael: This is a really tricky conversation, because it works differently for different companies and different types of customers. Taking HubSpot or maybe Intercom even for example: relatively well funded companies with a relatively happy history when it comes to financing and stuff like that. You get less pressure then. But when things start going less well, and your CFO starts looking for places to cut, they typically will go to support first and not to sales, because sales is the growth engine. But if things continue going poorly, then they’ll go to sales, and the pressure will come for everybody. So I view it as the fact that everybody’s subject to the same pressure: sales, marketing, service, support, whatever.
And support tends to be the first one to get cut. What that tells me is that they believe sales is what defines growth because they produce a quota every month or every quarter or every year. Of course, in a certain way on a spreadsheet, that’s true. But again, it’s a fundamental misunderstanding, because where the engine that drives your business – and where your success actually comes from – is your customers. When you think about it and flip the script a little bit, you start to break down the customer experience in terms of what’s important, right? You’d map out their experiences, and you’d do journey mapping or empathy sessions, and you’d understand what customers value.
They’re probably going to value your product first – the thing you actually sell, the noun – right? But then they’re going to value the verb: an experience likely marked by key support in human interactions along the way. Often, support gets this bad rap of cost pressure, especially when things get tight. But if you really sit back and think critically, and you’ve used maybe the cost-cutting as just a near-term thing, in the long run things are going to get better, right? If you’re optimistic about the state of the business, then I would say you probably shouldn’t cut support to the bone when things get rough, right? You should spread those kinds of cuts more evenly and try to then invest in your customers, so you can come out of that downturn a little bit better.
Support in its current state often just negotiates the worst. It’s the short end of the stick, and because it’s the longterm play, it gets cut the most in the near-term. That’s disappointing for me to see, because I feel for the people, but I also feel for the customers that have to deal with the results of that action.
Kaitlin: When thinking about how we’re using those costs in the right way, my mind turns to automation. So often, when we think about investing in a support team, sometimes the conversation becomes about getting the headcount higher, higher, higher. But where else can you be investing outside of headcount to maintain that customer centricity?
Michael: For sure. This debate is not actually a new one, right? When the internet started, somebody took what was formerly a paper manual (“Turn to page 390 for how this part works…”), and they put it on the internet. And that was the world’s first example of self-service in action. There’s just been this explosion in the number of ways that we can automate and the creativity we can have with them. It’s not a new narrative. It’s been going on for forever. And you could have methodologies like knowledge center support and stuff like that.
Today, it’s not fundamentally different, but it puts the importance in a different place. In particular, it puts a lot of weight and a lot of power with the support operations team. In a normal support organization, you’ve got a couple of different groups; in the smaller ones, everybody does everything. But as you start to grow, you end up having some folks that are focused on just knowledge management. And over time, you have the support operations group that’s trying to tune the machine. That team, to me, has gotten a lot more interesting over the last three or four years because of that explosion of automation technology. You now have people whose entire job is to work on the knowledge bot or on a positive way of moving tickets and demand around.
That job didn’t exist three or four years ago, and there’s going to keep being new jobs like that in support operations. It’s super, super exciting, because it diversifies the skillset that’s housed in what we call support. It’s not just this old-style image of an agent on a headset. It’s now the ability to almost growth-hack your entire support experience and fundamentally change the fabric of the way customers work. I get really excited about all this stuff. Maybe interestingly to listeners, I don’t get excited about any one of them in particular. What I get excited about is that trend and the pace at which we’re expanding the number of ways that we can play this game. It’s no longer just taking a manual and putting it on the internet. That was really slow, and companies maybe did it once a year. Now companies can roll out new tools five, six, seven times a year and they can be really, really agile and creative in the way they build their customer experience.
Kaitlin: I couldn’t agree more, particularly with the point about the growth and the emergence of the support operations team. Something that can be great for so many organizations is the career pathing opportunities that present themselves to your team. When you’re able to focus on bringing less new talent in, and instead bringing in the right talent, it makes for an exciting career path.
Michael: I think there’s actually a super cool dynamic here. This also existed for a long time, but again, we’re going to see it happen faster – the replacement effect of some of the more basic work we all do in support, right? Where it’s that same question you get over and over, but it also happens to be the most common question, because that’s just how the math works. The more we can effectively replace that with automation and bots – I just think the career pathing is a really big deal. But also the level of work – and the intellectual interest of the work we do – will just go up. Over time, certain things will get replaced and the support reps will be able to elevate their work.
It’s actually happening a lot faster nowadays than it was a few years ago because of the explosion in tech. It’s really pushing the rep upwards, and that’s forcing companies to do things that maybe they didn’t do before, liking hiring different types of folks and paying them more, building career paths that are actually sustainable because they give people longterm careers and support. None of that really existed 10 years ago. And it’s just really hastening the pace of those kinds of movements from companies in a response to what’s going on with technology.
Scaling support as you grow
Kaitlin: In 2017 you wrote an article in Harvard Business Review that has been hugely helpful for us in thinking about how we take our support experience to the next stage. In this article you talk about five phases of customer service as a startup grows and what companies should or should not be focusing on at each stage. Can you bring these different stages to life for us?
Small companies tend to be very, very in touch with their customers. It’s part of why they win
Michael: That article was a labor of love. I don’t know how many words it was, but it’s long. We’re not going to do the whole thing, but it was really just built off of my experiences in terms of scaling HubSpot support. The observations here are not super complicated, but some of the dos and don’ts are a little more directive. But the observations go like this: At the beginning when you’re two founders and a developer, and you’ve got an idea, and you’re trying to make stuff go, your entire company is your support team, right?
That’s just a necessity, because you don’t have money to hire a support person. And why would you, anyway? You’d probably hire another engineer first. So everybody does support and you end up very, very close to the customer. Small companies tend to be very, very in touch with their customers. It’s part of why they win. It’s part of why they can compete against bigger companies who aren’t – who hired giant teams and can’t do a good job with the customer experience. This is at the beginning.
And then at the end as you scale up, some of the topics we were talking about earlier come into play. How do we get the entire executive team to talk to customers? How does the CFO understand and speak customer, right? And that’s a spectrum. At the beginning, everybody’s close to the customer. As you go from a startup to scaling up, people pull away. Their jobs become more specialized. It’s a very natural thing.
In the article, I talk about ways to balance that natural tension and stay close to the customer and tweak your operation in critical ways to make that happen. For instance, the more you can think about support and success as siblings and keep them together so the customer experience is contiguous across the two, the better it is for your company. The more you can have your executive team engaged in voice-of-the-customer exercises and use tools like NPS, that also helps to do this stuff. I’ve used small companies as just a very, very special time for the customer. And then the key is: as you grow, don’t lose it.
Kaitlin: As you’re moving through these different stages, the metrics you need to be tracking at each stage change as well. Any interesting lessons learned along the way?
Michael: I suppose there are two inflection points in the growth of the company that are interesting for this discussion. The first is when you’re that primordial soup of a startup and everything’s super customer-y right? You don’t have that many metrics. What tends to then happen is you do grow, things do go well, and you start hiring people to do certain functions. One of the first functions you tend to hire is somebody to own the customer and own support, right? But even then, they probably don’t have a ton of metrics; they’re just getting the queue under control. And the CEO knows whether customers are roughly as happy to as they were before or more or less. So that becomes a barometer.
At some point, though, you do get to the point where you’re going to start wrapping some metrics around support. Typically, it’s really simple stuff, because at this stage companies aren’t super complicated. It’s response time and maybe quality of resolution, like a CSat score or something like that. Simple stuff.
If we think of speed and quality resolution as a baseline and go from there, a couple of things happen. The first is that those metrics are super operations-focused and not very outcome-focused. As you start building customer success teams or implementation teams or teams that are more focused on customer outcomes as opposed to just getting through a case, you need a different set of metrics. So the first key pivot point for a company is going from just being reactive and measuring the reactive stuff in a very transactional way to really measuring proactive work — in the way you work with customers through different functions and stuff like that. That tends to have metrics that are maybe tied more closely to the product: things like usage, adoption, retention, etc. It’s not dollar retention, but how long people actually keep using the product? You work in things like upgrade numbers, downgrade numbers, customer retention and renewal rates, and you start to get into this world where you’re marrying reactive and proactive at the mid stage of a company. I’m a big fan of that.
That’s actually a pretty sustainable model for quite some time as you scale up. But the next key moment after that in the company’s journey here is to get to the point where multiple functions start to really touch the customer in new ways. Maybe you had to build a big renewal organization, or your product line got big enough that your sales reps are selling back into the base more. There’s some fundamental change in the business process. And at this stage, the customer success team (including of support) can’t just keep measuring only its own stuff. You need to measure the whole thing in some other way. I’m a big fan here of measuring total lifetime value and thinking about churn and upgrade and the net retention of that as a shared metric. You tend to then spread responsibility for that across the business. And that’s a really nice way to drive customer..
These days, great customer support isn’t a nice to have – it’s table stakes. Giving your customers fast, personal support is essential to customer retention, transforms customers into advocates for your business and delivers a competitive advantage. Live chat has been instrumental in helping businesses achieve this, allowing them to build better relationships by delivering fast, highly personalized support.
But there’s a problem.
As a business grows, so does the number of inbound conversations they receive, often exceeding their real-time capacity to support. For businesses who get thousands or millions of people visiting their website every year, delivering prompt, personal support to their customers quickly becomes a daunting task.
Moreover, growth challenges aren’t always just about volume. Supporting customers on a global scale brings additional complexity. A worldwide customer base is diverse, as are their questions, needs, and requests. Offering real-time support in multiple languages and across time zones can become costly, whether that’s by hiring a team of polyglots, or outsourcing your support to a translation service.
We’ve witnessed these challenges first hand in our own growth, so we thought it was high time someone built a product that delivered the fast, personal customer support that all customers now expect, but that works at the scale that your business wants to reach.
So today we’re launching three important features that we think will do exactly that.
Increase self-service with Articles Pro – a multilingual knowledge base
Did you know that close to 75% of people search online using their own language? And that 42% of people would never buy a product or service in a language other than their own? It goes without saying that restricting your customer support to a single language won’t help your business grow.
The fact is, as your business grows into new markets and geographies, you’ll need to engage with customers across different time zones and languages. The blunt force solution is to hire dozens of multilingual reps to work across time zones, but you’ll quickly blow your support budget.
We think we’ve found a better way..
Using Articles Pro, you can build a multilingual knowledge base to provide self-service support that’s available 24/7 in 38 languages without having to hire a single extra rep. In a few easy clicks, you can create and serve up help content to customers in their native language, wherever it’s needed.
Multilingual articles are also accessible in the Intercom Inbox making it easier for your team to resolve questions from different audiences, faster. Because Articles Pro fully integrates with our Inbox product, teammates can provide consistent, real-time answers to customers of all different shapes and sizes – paid users, visitors or those speaking another language. When chatting to customers, teammates can add multilingual or private articles to conversations, without leaving their inbox.
Additionally, a common refrain we’ve heard from other fast growing companies is that there are instances where you don’t want your help content to be visible, especially to visitors or competitors. Articles Pro lets you publish private articles for logged-in users, and serve it to them in product, on your Messenger, Help Center and more.
Automatically triage customer issues for faster resolutions with Custom Bots
While a knowledge base is great for helping customers to get their answers in real-time, on-demand, the reality is that there are always going to be situations where a customer needs to talk to a human.
This is especially important as you scale. As your customer base and product suite grows, you will have an ever-widening range of queries and customer issues to resolve. A system that helps you triage these conversations is of fundamental importance.
That’s where automation comes in.
We’ve built our latest addition to Custom Bots to help support teams handle incoming conversations as efficiently as possible. One area in particular we see inefficiencies is at the start of a conversation. When customers first write in seeking support, your reps often need to draw out more information to understand the issue and gather the information necessary to support them. This lengthy back and forth wastes time for your support team and your customers.
Now Custom Bots can help you resolve customer issues faster. They act like an extension of your support team, asking your customers the right questions to automatically prioritize and route new conversations for more efficient support. Custom Bots surface high priority requests right away, route conversations to the right teams, and ensure teammates have context when they jump in to help. As your business scales, automatically triaging inbound conversations is a key piece of the puzzle.
Additionally, Custom Bots can now be targeted specifically to your mobile app users. Whether your customers need support on the web or mobile, Custom Bots now work cross-platform to automate and accelerate growth.
Deliver consistent support at scale with powerful Inbox workflows
In the early days of your business, delivering world class customer service is one of the best ways to help your business grow. But once you start scaling, how do you ensure that you don’t sacrifice the standards that made you successful in the first place?
One of the best ways to do that is with intelligent workflows, to help your team be more efficient without sacrificing the high quality support that customers love you for. Our two brand new workflows – SLAs and workload management – will help you do exactly that.
SLA (service-level agreement) rules let you consistently provide specific types of customers with the support they expect. In other words, ensuring a baseline level of quality to your customers – free or paid, big or small. With Intercom’s new SLA rules, you can easily monitor and report on different SLA targets for your customers, like first response time.
Of course, no two customers are alike, and customers in one region may have different expectations for support than in another. Using SLA rules, you can set different targets for replying to customers based on language or criteria that’s important to your business.
SLAs are most useful when they become a commitment everyone can stick to. So as your team works in the Intercom Inbox, they’ll see a real-time view of SLAs that are about to be breached so they know exactly how to prioritize their queue. You can also use our SLA reports functionality to further optimize your support workflows by seeing which targets have been met or missed.
For any growing customer support team, it’s natural to have times when the sheer volume of conversations can feel overwhelming for your team. To help you manage conversation volume effortlessly, your team can leverage workload management, a new feature that automatically sends new conversations to your available teammates only.
You can set limits to how many conversations can be assigned to a rep at one time, and once a teammate hits that limit, they’ll be removed from receiving more conversations. Better yet, the workload management workflow is deeply integrated with Intercom’s other support features, like SLAs, so you won’t have to worry about affecting the quality of your support.
If your business is growing, the burden on your customer support will grow, whether or not you intend it to. The real question is how you manage this scaling process. With the right mix of self-service, automation, and intelligent workflows, you’ll be able to deliver a world class customer support experience to customers no matter where they are in the world, 24/7.
To get started weaving these support tools into your growing business, head this way.
In 1898, American sales pioneer E. St. Elmo Lewis created the AIDA model to describe how customers buy.
The AIDA model described four cognitive phases that buyers follow when accepting a new idea or purchasing a new product:
A problem comes to the customer’s attention.
This creates interest in the benefits of a product or service.
The customer decides to buy the product.
They take action to complete the purchase.
Today, Lewis’ AIDA model is featured everywhere: from Marketing 101 courses to Alec Baldwin’s famous scene in Glengarry Glen Ross. This acronym has endured because of its simplicity and accuracy. Now, AIDA describes how most things are bought – groceries, apparel, cars, you name it.
But AIDA originated before the birth of digital products. Today, signing up for a social network or SaaS product requires little or no purchase commitment from the buyer. Many products offer a free trial, require a minimal month-to-month commitment or are completely free.
Digital businesses change how customers buy
Gone are the days of long feature lists and spec sheets. Instead, marketing websites describe a product’s key differentiators and benefits, offer a few case studies and encourage a prospective customer to evaluate the product by using it. Marketers today use their websites to generate just enough interest for a prospective customer to start a trial.
For digital products, it’s no longer A-I-D-A, it’s become A-I-A-D. Users take the action of signing up for your product before they make the decision to buy it.
This means that while some users who start a trial will be intent on purchasing your product, many more will be early in the buying process and are using the trial to both understand their own needs and whether your product can help them.
“At Intercom, three core principles help us create a first use experience that converts lower-intent buyers into loyal customers”
If you’re going to convince these early-in-the-process buyers to stay beyond their first use, the experience needs to get them hooked. The first use flow should help them experience the value your product can offer them. But it has to do this while asking very little in return. After all, these prospective customers are not invested in your company or product – yet.
At Intercom, three core principles help us create a first use experience that converts lower-intent buyers into loyal customers:
Focus on the job customers want to do.
Show rather than tell.
Remove all non-essential steps.
Focus on the job your customers want to do
First, we use the Jobs-to-be-Done (JTBD) framework to understand the value our customers seek to get out of a product. JTBD highlights how customers buy a product to solve a problem. Great onboarding starts with a clear understanding of what problem your customers buy your product to solve. The first use experience should help trial users solve their problem.
For example, when someone fires up a video game after a long day, their Job-to-be-Done is to be entertained and distracted by their pursuit of success. Video games lead the way in great onboarding, guiding first time users to early success, and highlighting the fun of the game in a lightweight way.
“Showing customers how to find and use every feature is an important part of onboarding, but it’s best saved for later”
With the customer’s Job-to-be-Done as a baseline, structure your first use experience around highlighting the features in your product that deliver on this job.
It’s unlikely that your product’s navigation or UI is organized in this way: features and screens in your product don’t typically map neatly to user benefits. While it’s important to explain the hierarchy and organization of your product, dragging low-intent buyers through all this puts the cart before the horse. Showing customers how to find and use every feature is an important part of onboarding, but it’s best saved for later.
Show rather than tell
A great first use is one in which the user gets an “aha” moment: the point of delight where the product proves to a user that it offers them real value. There are lots of ways to prove value, but most fall into doing, showing and telling. If you can actually deliver on the value, that’s best. Consumer products tend to focus on this: getting a new user to add friends, pin content or take their first ride.
For products with a long path to value, this is often difficult. In this circumstance, it’s critical to get as close to the experience of value as possible. Make it as realistic, specific and tangible for new users as you can.
Airbnb might not be a complex piece of business software, but it does have a long path to value for the people who list homes on their website. A new user has to upload a long list of details about their home, take photos, set prices and availability.
To motivate new users through this process, Airbnb focuses on the user’s Job-to-be-Done: make money from my empty house or room. Right on its initial signup screen, Airbnb display “estimated monthly earnings” based on your location and home type. This very specific estimate makes the benefit of its service feel real to new users, and helps motivate them to complete the signup flow.
Remove all non-essential steps
Once you’ve identified what value looks like, the next step is to find the shortest path to get new users to experience it. Unlike customers who have already decided to buy, most new users are still evaluating your product, and the competition is only a few clicks away.
“To deliver the most effective first use experience, remove all barriers that get in the way of new customers experiencing value”
Scott Belsky, Chief Product Officer at Adobe, puts it bluntly: “In the first 15 seconds of every new experience, people are lazy, vain and selfish.” He means that new users aren’t invested in your product, so it’s critical that you show them value immediately in their first use.
To deliver the most effective first use experience, remove all barriers that get in the way of new customers experiencing value. This minimum viable flow will vary by customer segment and use case, so make sure you customize your onboarding for each segment.
Common and effective patterns for removing effort from setup are:
Templates that reduce many configuration options to a few simple choices.
Presumptuous defaults that eliminate steps entirely.
Typeform, an online survey product, goes so far as to remove the account creation step from their first use experience. When new users click “Get started,” they’re encouraged to create a survey right away. Only once they opt to save their work are they’re prompted to create an account, after they’ve experienced the value of the product.
Provide maximum value with minimum effort
The goal of a first use experience is to set prospective users on the path to being happy, retained customers. In the era of A-I-A-D, most new users are yet to decide whether or not they’ll buy your product. So your first use experience needs to convince them that your product will provide value to them, and to prove this with minimal effort.
Achieving this demands a first-use experience that’s not a walk through of the settings screen, but a detailed and compelling tour of a new and better world. By helping help new users to quickly understand, visualize, and experience the better world your product promises, you’ll see more of them stay, and then return. Again, and again, and again.
Businesses put the Intercom Messenger on their websites because they want real-time communication with their users. To help the Messenger load as quickly as possible on the web, we recently worked on reducing the bundle size of our Messenger.
A fast load time is important because it makes the Messenger feel like a natural part of the websites they’re on, rather than an add-on. It also helps with the overall speed of the site which is important for the user experience and Google search performance. Most importantly, a fast-loading Messenger helps businesses connect with their customers the instant they land on their website.
More features = larger bundle size
Since we ship features to our codebase every day, we knew this problem would only increase over time.
What’s in the Messenger?
The first step toward reducing the size of our bundle was to see what took up the most space in our codebase. Here’s a visualization of all the code that was in frame.js, generated by webpack-bundle-analyzer:
As you can see, three main parts make up the Messenger bundle.
Node_modules, which are vendor libraries we use like React, Redux, and Lodash.
App, which contains our application code, mostly react.js components
Stylesheets, which comprise sass compiled styles
Optimizing the Messenger bundle
Understanding the different parts of the Messenger bundle and their respective sizes helped us identify the changes that would make the biggest impact. In particular, we looked for code that was being duplicated or rarely executed, as well as code that could be loaded asynchronously. Here are the major changes we made.
1. Split out vendor packages
At Intercom we deploy dozens of new versions of our Messenger every day. Every time we deploy, we generate a new Messenger bundle that website visitors have to re-download.
Since vendor packages make up around 40% of our bundle, and they don’t change very often, the first step we took was to split them out into a separate bundle.
Webpack supports bundle splitting out of the box. Configuring it to split vendor packages into a separate bundle looks like this:
If you have multiple entries in your webpack config, you can target a single entry with this code:
chunks: chunk => chunk.name === [your entry]
With this change, we now load our application bundle (frame.js) and vendor bundle (vendor.js) separately when people visit websites using the Messenger. The vendor bundle gets cached by the browser and returning visitors no longer re-download the bundle if it hasn’t changed.
2. Split our application by routes
After reducing the size of the vendor bundle, we took a closer look at our application bundle and decided to try splitting the application by routes.
To do this, we introduced a slightly modified Loadable component. This component lets us show a loading state for the Messenger while we load the vendor bundle. If the network request fails, the component will take care of retries and show an error state if needed.
This is what our simplified App component looks like:
Code splitting the Messenger component using Loadable looks like this:
Since splitting the Messenger into separate bundles has a latency cost, we’re now pre-loading the Messenger bundle the moment a user hovers over the Messenger launcher, instead of waiting for them to click the launcher. This removes most of the unwanted delays when the site performs additional network requests.
3. Refactoring the stylesheet
With the vendor packages and our application code optimized, it was time to look at our Sass stylesheet, which made up half of the frame.js bundle.
Styles in our Messenger were historically done via classic CSS files, with a Sass preprocessor. We couldn’t tell which styles belong to which component, so it wasn’t easy to bundle split them. This meant we had to mount the whole stylesheet, even if we were rendering just the launcher.
Our Sass stylesheet had over four thousand rules that browsers had to download and parse all the time, even when most of the stylesheet rules were not being used.
“People who never interact with Messenger won’t be required to download extraneous code that might slow down their site experience”
With this change, website visitors no longer download the Sass stylesheet before they open the Messenger. People who never interact with Messenger won’t be required to download extraneous code that might slow down their site experience.
For now, we’ve migrated just our launcher to Emotion since refactoring whole codebase will take some time. Once we convert the whole codebase to Emotion, the Sass stylesheet can be removed. In the meantime, we’ve split the Sass stylesheet into a separate bundle and load it only if a render component hasn’t been converted to Emotion yet.
4. Further optimizing the vendor bundle
Our vendored dependencies were now in a separate bundle, but within the vendor bundle, there were still opportunities to reduce the size of various packages.
We found several instances where we were importing whole libraries rather than the subset of functions that were actually being used. By implementing dynamic imports and other code changes, we’ve been able to reduce the size of various vendor packages. For example:
Intercom-translations package: This package is our internal library that generates translations for all the supported locales. The whole library is almost 60 kb, but 95% of that library is unused most of the time as we can show only one locale at a time. By using dynamic imports to include only the English locale by default, we were able to reduce the size of the package by 55 kb gzipped.The logic for importing those translations looks like:
PSL: This package is a list of all public domain name suffixes and we were using it to determine the best domain for setting cookies. But since top level domains have many edge cases due to non-standard domains like co.id, we recently decided to add a list of all possible TLDs to the server and check the logic there. As a result, we were able to remove the PSL package and save 36 kb of gzipped data.
Sentry: This package is used to collect errors in our app, but since errors are pretty rare for us, we decided to stop bundling this client by default and save 25 kb of gzipped data. If you are using redux-raven-middleware, you’ll need to remove it, as it will always includes the Sentry client. However, you can create your custom middleware to store actions and populate breadcrumbs when errors pop up.
Lodash: We were bundling the entire Lodash module, but in reality only using a subset of Lodash functions in our Messenger. So we reduced the size of the Lodash package we were using from 25 kb to 11.7 kb using babel-plugin-lodash to pick out the specific modules we use. It required us to do small refactor as chain sequences aren’t supported.
CSS package: We were loading this entire package to parse and stringify CSS. However, we were really only using the parse API. Tree shaking doesn’t work in the CSS module because it doesn’t have the sideEffects property in package.json. After changing our import from CSS to CSS/lib/parse, we reduced the gzipped size of the file from 10 kb to 1.7 kb.
Underscore: We were using Underscore to import throttle, which was unnecessary since we already use Lodash and can import throttle from Lodash. A new Eslint rule will prevent Underscore from being accidentally imported moving forward.
Future-proofing the Messenger bundle size
As a result of these changes combined together, we’ve been able to deliver a faster Messenger experience to our customers. Visitors to websites using the Messenger no longer need to download the entire Messenger bundle multiple times a day. By splitting the large Messenger bundle into smaller bundles, we reduce the files that visitors need to load to just the ones they truly need.
It now takes only 240 kb to load the Messenger on the web, down from nearly 600 kb. On mobile, the savings of 400 kb shaves off up to five seconds of loading time on a fast 3G network and up to 11 seconds on a slow 3G network. That is a massive improvement for mobile users!
According to Google Lighthouse, our site now has a score of 100, up from the previous score of 59.
Messenger score in Google lighthouse by the end of 2018
Messenger score in Google lighthouse now
Our engineering teams also benefit from this change since they can now safely add new features to different parts of the codebase without impacting the initial size of the Messenger bundle.
Deciding what your engineers should do next can be a lot like climbing a ladder. On the lowest rung is a problem to be solved. At the top is an impact on the business, a change in the bottom line.
But the rungs in between can often be quite flimsy. Instead of trying to jump straight from the theoretical business impact to a directive for your R&D teams, it’s essential to stop for a moment and consider: “What is the desired outcome? If we implement a new feature, how will customer behavior change in a meaningful way?”
At Intercom, we’re in the thick of working through how to help our teams become more outcome-focused. That’s why we asked Josh Seiden, a well-known product consultant and author, to join us on the podcast. He’s just released a new book called Outcomes Over Output.
We wanted to jump into this hot topic to see if we could marry our practical experience with Josh’s framework. In this episode, we cover everything from how to properly scope problems to why change is sometimes harder for leaders than it is for teams.
Short on time? Here are five quick takeaways:
Narrow your definitions. You want to reduce the scope of your question to: “What are the things we can change in our behavior or our users’ behavior that might make our customers more satisfied?” Scoping down to a tight focus clarifies what teams should be working on.
When developing a new feature, the first question you should be asking is, “What will people be doing differently as a result of this feature?” Too often, we just build a feature and move on without analyzing how it’s performing.
Change is much easier for teams and much harder for leaders. Leaders have to get out of the business of saying: “I have this solution in my head. Go do it.” Instead, they have to do the work of saying, “Actually, what problem am I asking people to solve?”
Change starts small. Pick one project or one set of stories where you’ll use the language of agile. Expect it to go okay, not great. Expect to use retrospectives and to continuously improve your process as you try to implement this, because you’ll learn a lot.
If you enjoy our conversation, check out more episodes of our podcast. You can subscribe on iTunes, stream on Spotify or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of the episode.
Brian: Josh, welcome to Inside Intercom. Thanks for joining us on your book tour. Outcome versus output: it’s a hot topic in the industry these days, and it’s actually a hot topic for us in R&D to Intercom. Let’s start by hearing about your background and what made you write this book in the first place.
Josh: I’ve spent about 30 years in the technology industry, most of that time working as a user experience designer. In the last 10 or so years, I’ve spent a lot of time writing about design and about how product teams can be more effective together. With my co-author Jeff Gothelf, I wrote a book called Lean UX, which was a book about how product teams can work together in a more agile way. I wrote a second book with him called Sense and Respond, which was a book for business leaders to understand the importance of re-organizing around software as the beating heart of our businesses. One of the topics that has come up recently in my consulting is this idea of outcomes. It just was a useful idea in so many contexts that I felt like I had to write down and share what I had been learning.
An outcome is a change in human behavior that drives business results
Brian: It seems like it’s one of these things that’s definitely bubbling up in so many different places at the same time. First of all, I wanted to just thank you for writing a short business book. You’ve got to be applauded for that. Instead of figuring out how to beef up a book and turn it into 300 pages so it lands with a thud on your desk, you kept it concise. It was about an hour to read. When it’s short, you give yourself permission to stop and think, which is half the value of these things, to digest it. Did you have to actively resist the temptation to write a longer book here?
Josh: The book is published by Sense and Respond Press. Full disclosure: I’m a co-founder of that also with Jeff. One of our value propositions was that we’re a press that publishes short, practical business books. When we did our user research before we started the press, we met all these people — busy leaders who had stacks of what we came to call aspirational books, books that were sitting on the corner of their desk that they wanted to read, that they knew they should read, but that were just too long. We’ve all had the experience of reading a book that should have been an article or reading an article that should have been a tweet, right? We thought this was an opportunity for us to publish the heart of the idea and not fill it out with fluff. That’s been very successful for us.
Narrow your definitions
Brian: On the surface of it, outcome versus output almost seems self-explanatory. It’s not about what you ship so much as about the value you create. Let’s cut straight to the TLDR here: what’s the main thing you’re trying to say about this?
Josh: Yeah, I think you’re right. I think the notion is kind of self-explanatory. That’s made it almost a slogan for people, but my opinion in working with teams has been that it’s actually really hard to get beyond the slogan. Conceptually, yeah, there’s nothing to disagree with there, but how do you make it practical? The main premise of the book is that by defining outcomes really, really precisely – and in the book, I say an outcome is a change in human behavior that drives business results – you can use that really narrow definition of outcome and start to make it possible to really apply this idea of outcomes in our work.
Brian: I think that definition was probably the biggest aha moment for me, reading through this. What do you think this was in contrast to? Why do you think that narrow definition is helpful here?
Josh: For me, a lot of this got unlocked. There’s a paper from the late ’90s that was published by the Kellogg Foundation, which describes this thing called the Logic Model Framework. I talk about that a little bit in the book, but basically, they break down program planning from the resources and the activities you do, the outputs you create, the outcomes that those create, all the way up to the impact they create. By having all of those different levels in the model, it helps you specify the thing you are working on more precisely. I think a lot of times, we use the word outcome. We just mean result. That’s fine in casual conversation, but it’s really hard when we’re actually planning work, when we’re trying to write user stories, for example, to just say, “What is the result we want?” It’s a super open question. To have to have the answer for every story is really difficult. You ask, what’s it in contrast to? It’s in contrast to a really broad and undefined definition.
The Project Logic Model, adapted from Kellogg Foundation
Brian: That resonates a lot. Paul, one of our design managers here, was writing a document and referencing that model you mentioned. I was actually struggling to differentiate. Outcomes, impact – aren’t these the same thing? What’s the difference? In your book you discuss the narrowness of that definition. Definitions are arbitrary. Let’s accept that, but they’re helpful when they’re arbitrary. The aha moment for me was separating the customer outcome, the business impact, etc. Talking about it here internally, what has really resonated is saying, “Business impact is at the top.” Of course, that’s what we all want to do, but we’ve got to map it down to a lower level for what the teams can focus on.
By focusing on customer outcome, that’s where this starts to get achievable. Making customer outcome measurable is the key to actually being able to translate business impact into something that’s more relevant for the teams and something they can actually hope to directly change.
Josh: I’ll tell you: my first aha moment with this was a couple of years ago. I write a little bit about this in the book, but I was working with a team whose mission for the year was to increase net promoter score on their service, which is very clear and also left them with this giant set of questions like, “How in the world are we going to do that?” In working with them to ask and answer that question, we understood what increasing net promoter score means, but how would we do it? That “how do we do it” question led to us asking, “What are we going to do to make people more satisfied and more likely to recommend us?” The next question was, “What are the things they’re doing or that we’re doing that make them satisfied or dissatisfied?”
What are the things we can change in our behavior or our users’ behavior that might make our customers more satisfied?
When you just start asking that series of questions and really focusing it down to “What are we doing, and what are they doing?”, you reduce the fuzziness of the question from net promoter score — which, by the way, is something that no single team can change. It’s a scoping problem at that point. You reduce the scope of the question to, what are the things we can change in our behavior that might make our customers more satisfied or what are the things we can do that will help our customers change their behavior so that they’re more satisfied? Just by scoping down to that very tight focus, for me, it really clarifies for teams what they should be working on. I think that’s the advantage of having this very specific definition.
Moving the focus from problems to outcomes
Brian: That totally makes sense. When we’re trying to map that down to customer outcomes, how confident do you think teams need to be about that mapping? How much is that speculative versus saying, “We’ve got some solid data here that really backs up this claim”?
Josh: You need to at least have a hunch that if we change this it will positively change customer behavior, but you don’t have to know for certain. All of this work is set in the context of the complexity of making software products and the uncertainty that complexity brings. We don’t know. If we ship a new feature, is it going to create value for the customer? Sometimes we know, and sometimes we don’t know. If we know for certain, then there’s really no reason in even using an outcome focus to begin with.
For example, I want to get customers to visit my site more often. How do I get them to visit my site more often? I might have a dozen ideas. I might have 100 ideas. How do I know which one I should be working on? All of this, then, comes back to the lean startup notion of having a hypothesis and testing your hypothesis with an experiment or a minimum viable product or something like that. Teams can say: “We think that if we make this feature, it will generate this outcome. Honestly, we’re not sure, so our next step is not just to go all in and make the feature, our next step is actually to test our hypothesis by running some experiment.” That experiment might be to make a minimum version of the feature. It might be to talk to people. It might be some kind of research. I don’t think you can ever be 100% certain, but you want to make an effort. This is specifically a technique that, when you mix it with hypotheses and experiments, lets you work your way through that uncertainty.
Brian:Uncertainty is such a powerful way to frame this. I think this is another aha moment: it’s not all or nothing. Sometimes, just building the damn feature is the right thing to do because there’s sufficient certainty of the value. It’s well enough understood. The risk, of course, is that Product Management 101 says that shipping a feature without understanding the problem is pretty risky. Normally, you try to go over to the problem space and really get more confident in it, and then you can start to progress with more confidence in solving it.
What’s interesting here — and I’m keen to get your perspective on this — is a problem-focused approach versus an outcome-focused approach.
At Intercom, 40% of our time is spent defining the problem before we start designing anything.
Let me use one example we’re literally working on right now, which I think hopefully is easy for anyone to get their heads around. We’re improving Inbox search. We’ve got a team inbox, which Intercom customers use to respond to their end users. There are a bunch of people working in this inbox. For years we’ve had a really basic search option, and we’ve got heaps of years of feedback of people telling us of how it’s not doing the job. They can’t find the conversations they’re looking for. We’re pretty dialed in on the problem we’re trying to solve.
But when we move to the outcome, it gets a little shakier. It gets less certain. We could say we’re trying to get people to do more searches, maybe. Or maybe we’re just trying to get them to get accurate search results, which is hard to exactly measure. We think we’ve got some proxies for it there, but we’re a little shakier as we go out. If we go from problem to outcome, it’s a little shaky, but we think we can get reasonably firm there. Then when we try to go to business impact where it’s a huge leap. When we’re working problems-up, going to business impact (where we hope this will affect retention, and we’ve tried to do some models where you can actually try to get some element of a sense of the scale of what the business impact is), it feels really loose and shaky.
And that’s a problem-focused one where you’re solid there, but then shakier as you go out as compared to an outcome-focused approach, like trying to improve activation. If you’re able to improve new customer activation, you’re confident that’s going to change your business impact, but you’re actually not sure what the problem is in the first place, so you’re way shakier on the problem. The lens of uncertainty and different approaches to building and prioritizing projects come with different risks of uncertainty at different levels. I’m worried I’m way too much in the abstract, here. Tell me if I’m making any sense.
Just shipping features and moving on is a huge problem for product teams
Josh: To go back to your example, you’ve got this search feature in the product. When you frame that, you know you want to improve it. That’s problem-focused framing: “We have lots of evidence that the feature is less good than it should be. We want to improve it.” The way you add maybe an outcome focus to that is by asking, how will you know? How will you know that you’ve improved the feature? Specifically what will people be doing differently after you’ve improved the feature? That’s a user behavior that is the outcome question. After we’ve improved inbox search, people will get to search results more quickly. People will not run three searches in a row, but they’ll search, find and go. That’s the first question: what will be people be doing differently as a result of this feature?
That’s really important, and I want to stay on that question for a second before I get to your next question. That’s really important for product teams, because it’s often the case that we ship a feature and then move on. Somebody asks for a feature. We ship it. We’re done. We move on to the next one. We never go back and ask: “Are people using this feature? Are people getting the value that we expect them to get from this feature? Have they adopted the feature?” After we’ve made the feature, we want to have actually validated that the feature is behaving as intended because people are using it in the way that we expect. That’s a really important discipline. It helps us know whether we can be one and done with the feature or whether we need to go back and iterate. Just shipping features and moving on is a huge problem for product teams. Then you leave this rubble of half-finished features behind you.
Brian: Absolutely. Product data is a real thing. You’ve got to validate. Did you solve the problem? Sometimes, you try to use outcome as our way to measure that as well as qualitative feedback there. Going back to a feature-driven approach, it feels like the anti-patterns or the riskiest ones are on the outside, which is one end from the business impact. If you have a project that’s on business impact, that’s high-risk. We’ve actually unwittingly asked teams to try to do this. They’re like: “We don’t even know where to start. We don’t even know how to think about this thing because we’ve just skipped to the end.” The way to approach this is to start with figuring out what customer outcomes you’re actually trying to orient this team around. You’ve got to do some work. You’ve got to do some research to actually identify those outcomes that map to that business impact. That’s an anti-pattern: to try to shoot from business impact straight into: “Okay, team. Kick off. Go move into execution mode here.”
Josh: That’s actually something I see a lot in my work with organizations. Organizations will be pretty good at defining the high-level impact that they want: say it’s to reduce costs or increase customer loyalty — whatever the focus is for that period of planning. Then they skip that middle layer, which is the outcome layer. They jump right to features and say, “We’re going to reduce costs by implementing System X.” No, you’re not. You’re not going to reduce costs with one feature. If you’re a team that’s been given a mandate — say you’re a team of five. Even in an organization of 20, you’re going to have a hard time reducing costs less than in an organization of 100 or 500. When you start to see those kinds of teams dealing with these very high-level business impacts, that’s a smell. You know there’s a problem there, and you need to decompose the problem in more detail.
Brian: Exactly. It’s the smell of, “This is unlikely to go well.” I think it comes from two sides. If it’s a feature-driven one, which is typically what happens, the risk is that you’re too far away from what the actual core problem is. Try to reorient that way before you progress down. If you’re coming from business impact, you can’t just jump straight down to the feature. You’ve got to orient around that customer income. It’s the safety net for how to get far more confident that you’re building something of value. That’s how we’re trying to put this into our way of thinking about building product without necessarily upending the whole approach we’re doing.
How to prioritize and execute
Brian: Another angle you mention in your book is execution and prioritization. Outcomes seem like they most naturally fit a prioritization, or is that a leap?
Josh: One of the things that happens when you start working with outcomes is you have to work to come up with your theory of how the business works. The non-profit world calls this the theory of change. What’s the big picture — where people are behaving this way, then these good things happen and that has these results for the business?
Starting to build those models leads very nicely into roadmapping and prioritization
The more you know about your business as your business goes on, the more you can start to build that. I don’t know if you want to call it a business model or a behavior model or an interaction model, but you understand the way your system works as a company. You have to do the work of saying, “We want to reduce costs, and so to reduce costs, here are the 25 things that people are doing that waste money.”
Starting to build those models leads very nicely into roadmapping and prioritization. If you’re a brand new startup, and you’re two months in, you don’t really know that stuff. Everything is uncertain. If you’re a few years in, you’re making money. You have some understanding of what your customers value about you. You know so much more, but you’re still looking across this model and saying: “Given what we’re trying to do, here are all the possible areas that we could work on. What are the things that we understand? What are the things that we really don’t understand and need to investigate? Where is the work that we need to do?” All of that happens as you start to build a model. Then, that model then gets reflected in roadmaps and prioritizations.
Brian: It’s a model. You really want all of R&D to understand, right? That’s something we’ve only done recently: actually bringing them through how our business works. It’s a complex business. There are a lot of pieces to it. We want everyone to understand them, so they can map what they’re working on or make those logical jumps and understand the work they’re doing and how that could conceivably impact the business model. It’s both having that model and sharing it and getting people fully immersed into it.
Josh: I think it’s more than just having everyone in..
The world of product design is shifting once again: “Best of breed” apps are mixing decades-old ideas with modern UI patterns – and in doing so, teaching us eternal lessons about how to design for a specific market.
It’s an exciting time for product design. After an arguably fallow period, the last couple of years has seen a cohort of design-forward products that feel like they share a similar ethos, and a desire to make big leaps forward. Many share similar design patterns. All are pushing out new ideas with a speed and confidence that their larger, older competitors are unable to match.
“We’ve always felt that Intercom has been part of driving this movement, and it’s exciting to see many others joining in”
What’s more, this straight-up design innovation is happening in a somewhat-unlikely corner of the industry: business software. While most of us may have looked down our noses at the design of “enterprise software” a few years ago, some of the most interesting new products and design ideas are coming out of companies who are building tools for work. We’ve always felt that Intercom has been part of driving this movement, and it’s exciting to see many others joining in.
Smaller upstarts are building exceptional products by out-innovating lumbering incumbents. SaaS products like Airtable (better Google Sheets), Coda (better Google Docs), Slack (better IRC), Notion (better Evernote), Superhuman (better Gmail), Zoom (better Skype), Linear (better Jira), and yes, Intercom (I couldn’t possibly!) are all aimed at carving off a healthy slice of a large existing market.
Superhuman, a Gmail competitor
People used to say that you could come up with startup ideas by replacing old Unix commands or spreadsheet hacks or a Craigslist vertical. Now it’s even simpler: choose a massively successful product with a large user base, hone in on a specific segment of their customers, and simply ship brilliant product design work aimed specifically at them. Free of the burden of having to be relevant to billions of very different customers, these “best of breed” products are now at the frontier of product design innovation.
Best of breed products
You’re probably familiar with disruption theory: essentially the strategy of smaller companies building a simpler, cheaper alternative to an existing product.
Best of breed products are similar, but come from the opposite direction: rather than cleaning up with the low end of tiny customers who want something simpler, they can cherry-pick the most sophisticated (and often most lucrative) customers from higher up the market. Think of it as disruption from above.
“Such is the enormity of the market for business software today that even a small proportion can sustain a significant business”
It’s now clear that a decent chunk of users who spend all day using (and feeling the daily frustrations of) those older tools will happily switch for even a marginal improvement, often layering several best-of-breed solutions on top of an existing mediocre one.
And such is the enormity of the market for business software today that even a small proportion can sustain a significant business. If Superhuman can win over even a tiny percent of Gmail users with a more focused product, they will be very happy indeed.
Whatever the tipping point, it’s clear that buyers are willing to pony up for a better solution. How else can you explain video conferencing service Zoom’s recent eye-watering valuation, given that a great many of the customers undoubtedly already have access to Google Hangouts or similar for free? It’s because the design of Zoom is so much better than Hangouts, that it’s worth it. Good design is good business.
But still, “good design” is pretty vague. How should designers make decisions when designing best of breed products specifically?
Designing best of breed products
Any product designer worth their salt will start by understanding two things: their audience, and their competitors.
Let’s assume that you have identified an audience of demanding, discerning users who value product quality and their own time. Let’s also assume that your main competitor is some insanely huge, successful, resource-rich company like Google who are already deeply entrenched with a broad offering like GSuite.
At first it seems like an impossible David vs. Goliath proposition, but then you quickly realise some huge advantages you hold:
You don’t have to be all things to all people. Google has to support millions of billions of users, including less sophisticated users with legacy hardware and slower Internet connections, shackling them to lowest common denominator solutions.
You can focus on one use case. They must satisfy many.
You are fast. They are slow.
You know your customers intimately. They haven’t a clue who is using their product because most of the planet is using their product.
You’re better than them at design. There are a great many talented designers working at Google, but they simply don’t have their A-players working on some obscure corner of GSuite. No disrespect meant, but in my experience it’s true.
This is liberating. You can do things they can’t. You can build product that’s fantastic just for your niche. You can cover much less surface area, but go way deeper. The ceiling of complexity that might work for your customers is probably higher, so you can build more powerful products and expect your users to take the time to learn it, because your product will give them new superpowers.
Let’s look at an example. Slack, Superhuman, Stripe, and Linear all use a similar pattern to allow for keyboard input. From anywhere in these apps, you can hit Cmd-K to invoke a modal input, into which you can type an array of commands. Here’s what it looks like in Superhuman, the Gmail competitor:
From here you can type to act on the current mail (reply, archive, remind, move), navigate the app (compose, switch inbox, search), or take actions (copy recipients, open calendar, switch theme).
I love this UI pattern: it’s fast, learnable, and makes you feel like a badass hacker from the future (an oft-overlooked feature). It’s clearly a power user feature – you could never imagine mainstream Gmail users navigating like this – but once you get used to it, you can plough through email in seconds. It’s random access navigation applied to inbox triage. And it’s good design.
Why? Because Superhuman have focused all of their efforts on people who want to be able to process large amounts of email quickly. People for whom a 20% increase in efficiency would be life-changing. For whom that gain represents $30 per month worth of value over the free thing they already use.
And so they go hard on it. They hammer home the speed point on their marketing site. The near-total reliance on keyboard navigation means that the screen UI can cut away a ton of cruft, making it faster again. Any time you attempt to use the mouse, the app almost admonishes you for doing so, teaching your the faster way.
This reasonable little message appears on screen whenever you click the “Mark as Done” button:
But here’s what you get when you simply select some text with your mouse:
And here’s how Superhuman feels about you hovering a link like some kind of goddamn caveman:
It’s even a little bit weird, but… aren’t you glad that a product today is doing something weird at all? It’s not for everyone, but it doesn’t have to be. If, however, you’re the type of person who loves this type of thing, well, you’ll love it. It’s picking a stance that’s great for some, and it’s sticking with it. That’s what a best of breed product is.
Of course, Gmail has some keyboard shortcuts. But Gmail can’t berate you for using your mouse. Best of breed apps are designed to help you get the most out of them. They don’t have to dumb things down. Design decisions are tightly connected to the product strategy and business goals (e.g. our main selling point is speed, so we’ll force our users to be as fast as possible, so that we actually deliver on our selling point).
Everything old is new again
You may be looking at this Cmd-K pattern and thinking it looks familiar. That’s because, as with all design, there’s plenty of prior art here. You might be reminded of Spotlight search (or Quicksilver, or Alfred). You might think that Superhuman vs. Gmail is essentially command-line interface vs. graphical user interface.
And you’d be right. This is where being a student of the history of software can pay off. You don’t even need to invent brand new interaction patterns to design best of breed products. Innovation doesn’t necessarily imply invention. The application of an existing solution in a new context can be highly innovative.
“The Canon Cat was an early example of what we might now call a best of breed product”
As I used Superhuman I was stuck by how much it reminded me of the work of legendary designer Jef Raskin, in particular the Canon Cat computer.
Although best known as the originator of the Macintosh project at Apple, the clearest realization of Raskin’s vision for an “information appliance” arrived in the form of 1987’s Canon Cat. (Raskin later captured his underlying ideas in his classic book, The Humane Interface.)
The Canon Cat was an early example of what we might now call a best of breed product. Perhaps the first in tech. It was a response to an existing successful mass-market incumbent that was enjoying broad appeal.
The Macintosh had succeeded by billing itself as “the computer for the rest of us” and introduced the masses to simple, accessible concepts like a GUI and a mouse. While wonderful for most novice users, Raskin was frustrated by what he saw as the trading off of power in service of broad accessibility.
Raskin saw the opportunity to make a computer for a smaller niche audience, “particularly office people,” who wanted to “make mountains of work disappear faster and easier than ever before.” Sound familiar? By identifying a specific audience and selling point, he was able to be radically opinionated in creating a product that was far, far better for that core set of users.
As we’ve seen, best of breed products can be better by doing less. The Canon Cat did away with the mouse, an aggressive move in favour of the faster input afforded by keyboard input (just like Superhuman). It did away with the desktop metaphor and filesystem, booting straight into a single multi-purpose document that could perform word processing and spreadsheet-like calculations inline (just like Coda).
It even did away with cursor keys. But as we’ve already seen, best of breed products also add things to make the experience better. In particular, it introduced two new keys:
These ‘Leap’ keys don’t just perform basic cursor movement. Holding one of these modifier keys while typing will immediately shift input to the nearest instance of the typed letters – much faster than using cursor keys of a mouse. Again: kind of weird. But good weird! If you’re curious, the Internet Archive have an in-browser emulator of the Canon Cat you can play with.
Leap Technology - YouTube
If nothing else, the Canon Cat proves that products aimed at getting work done, far from being a wasteland of enterprise mediocrity, are an opportunity to push out innovative new ideas. However, the Canon Cat sold only a modest 20,000 units, certainly not a huge commercial success for a hardware device with high marginal costs. Does this relative disappointment mean that best of breed products are in fact destined for a tiny audience, and thus business failure? Not at all.
The economics of modern software development are far more efficient. A SaaS product charging the same modest audience $30 a month is pulling in north of $7m annual recurring revenue. That’s before you begin to consider that today’s addressable market is orders of magnitude larger, and the barrier to entry far lower.
The wheel turns
Technology moves in cycles. The large cycles (PCs, internet, mobile) wash over the entire industry, spurring on flurries of innovation. Yet most cycles also settle over time, as the winners and losers shake out and consolidate, and familiar patterns consolidate.
The emerging trend of best of breed apps is not a world-changing development. It’s not that self-important. It’s part of the seemingly endless cycle of consolidation and unbundling. It’s about solving specific problems with smart, brave, incisive design. Yet for those of us who love the craft of building software, there’s something noble and even thrilling about that.
“It’s thrilling to see the conditions today allow for different ideas, old and new, to once again succeed”
We’re moving past the era of generic, general-purpose software for the masses. Small teams can build excellent software for niche audiences and build a killer business in the process.
There have always been people willing to bring exciting, genuinely useful new ideas to market. To the extent that the Canon Cat failed, it failed because of unit economics and timing, not design. But it proved that old ideas can be new again, and it’s thrilling to see the conditions today allow for different ideas, old and new, to once again succeed.
That’s why I say it’s an exciting time for product design. We have a long and fascinating history of left-field ideas to draw from. The barrier to entry for trying new things (or resurrecting old things) have never been lower. The collision of these factors with the emergence of the best of breed market is breathing life into product design innovation. Everything old is new again.
Operating a sales organization at any scale involves a lot of tedious, repetitive work. Without sales automation, this work can become a black hole for your sales reps’ time.
In their “State of Sales” report, Salesforce found that in an average week, sales reps spend 64% of their time on “non-selling” tasks – everything from entering lead data to manually prioritizing opportunities. It goes without saying that while these tasks are necessary to run your sales organization, they’re not the best way for reps to be spending their time.
The idea of automating these “non-selling” tasks isn’t new – long before the explosion in sales tools, SAP, IBM and Oracle were already helping companies streamline their sales process. What is new are the types of tasks we’re now able to automate, from qualifying and routing leads to creating deep integrations between our sales stack and martech stack.
These advances in sales automation have enabled our reps spend their time on the activities that matter most (hint: the revenue-generating ones) and deliver a better, more personalized buying experience. Here are our top tips, workflows and tools for automating the sales process.
What is sales automation?
The sales automation process takes manual, time-consuming tasks that sales reps have to do on a daily or weekly basis and handles them automatically – in most cases, through customizable workflows. Scheduling follow-up meetings? Updating account information in your CRM? These are all tasks that are prime candidates for automation.
“With less time spent on manual tasks, sales reps can focus on more impactful work: personalized outreach, demos, negotiations”
Here’s a familiar example: routing leads to sales reps. It’s a process that’s crucial to nail if you want to maintain your sales velocity, but having people do it adds no value and only invites human error. For leads that contact us through live chat, we use a chatbot to automatically route conversations to our SDRs based on short list of qualification questions.
Automated workflows like this one save sales teams so much time and improve the team’s overall productivity. With less time spent doing manual tasks, sales reps can focus on more impactful work: personalized outreach, demos, negotiations and so on. Prospects are happier too – faster sales cycles benefit everyone – and more likely to convert to customers.
Identifying opportunities for automation
While sales automation is a powerful tool, it isn’t meant to eliminate all the work that sales reps do. We aim to automate the parts of our sales process that are high touch but low value – that is, the activities that take up a lot of time but don’t actually require human decision making or oversight to do well.
For the time and motion study, your sales reps time their tasks for an entire day. They measure:
What task they’re doing.
How much time each task takes.
How many times per day they do it.
The end goal is to identify repetitive tasks that take up a lot of time. For example, if a sales rep needs to add lead information to your CRM, this may take them five minutes each time and be done 15 times each day. That’s over an hour of every sales rep’s day spent copy-pasting data – far too much time on a task that doesn’t actually drive revenue.
“The end goal is to identify repetitive tasks that take up a lot of time”
If you’re looking to implement new automated workflows for your sales team, do your homework first to identify the inefficiencies you’re currently facing. It’s best to have hard data on your current situation before jumping in to make changes. Otherwise, you may end up adding sales tools to your team’s tech stack that don’t really solve the issue at hand, or you’ll have a hard time proving a positive ROI on the changes you’ve made.
Using sales automation to reduce inefficiencies
We use our own customer messaging platform, Intercom, to eliminate a number of inefficiencies for our sales reps. Here are three examples that you can easily replicate for your sales team:
1. Keep your prospect and customer data in sync
Our integration with Salesforce allows us to automatically sync prospect data between our two tools. If we’re speaking to a new lead over live chat, for example, we can create a profile for them in Salesforce with a single click – without having to leave the conversation. Once the lead’s profile has been linked, all of their demographic information like their first and last name, company and email address will be kept up-to-date in both places.
This automated workflow keeps our reps from needing to copy-paste information between Intercom and Salesforce every time they talk to a new lead or need to update the information for an existing opportunity. With the click of a button, a two-way sync is set up between Intercom and Salesforce, allowing our reps to focus on the conversation at hand instead of data entry.
2. Automatically connect with leads from target accounts
Previously, we had no easy way to alert our sales team if prospects from our target accounts – high-value accounts with dedicated sales owners – were active on our website. If a prospect started a conversation, they’d be randomly assigned to a sales rep who, in most cases, didn’t have the necessary context. This created an inconsistent experience for prospects and led to missed opportunities for our reps to move key deals forward.
Intercom’s account-based marketing (ABM) features have made it easy for us to connect sales reps with their target accounts in real time. Now we can automatically alert reps when prospects from their accounts are online, and all live chat messages are instantly routed to the right person, so they can pick up the conversation exactly where they left off.
3. Integrate sales reps’ workflows into their inbox
Sales reps spend a lot of time switching between tabs – their email, CRM, lead enrichment tools and messaging apps. That’s exactly what we noticed on our own sales team. Whenever a lead’s status changed, new information came in or existing information needed to be updated, our reps would have to hunt it down in one of their tools or even copy-paste data between tools.
By bringing apps into the Intercom Inbox, we’ve eliminated the frustrating back-and-forth of disconnected tools. Our sales reps’ Inbox is now customized to work the way they do, with easy access to lead qualification data and the ability to quickly navigate to a prospect’s Salesforce profile.
One of my favorite apps for the Intercom Inbox is the Stripe app. You can create new subscriptions, upgrade existing ones or just review billing details, all while you’re chatting. If you need to make any changes, you can easily send prospects or customers a subscription confirmation, and their plan will automatically update in your inbox and in your Stripe account.
6 tools we use to automate the sales process
We have a carefully chosen lineup of sales tools, a number of which we picked specifically to automate time-consuming, low-value activities. Here are six of the tools that our sales reps use regularly and I highly recommend to other teams looking to scale their sales automation efforts.
Custom Bots supercharge our sales pipeline by taking care of repetitive, administrative tasks that our SDRs used to be tasked with – from qualifying website visitors to scheduling demos and creating new leads in Salesforce. We’ve tailored our Custom Bots to send different leads down different paths, depending on where they are in the buying journey.
Using chatbots as part of our automation lineup enables prospects to get what they need faster. In less than a minute, prospects can register for a webinar, book a meeting or even start a trial. That way, when they do connect with our sales team, our reps are able to focus on what only humans can do: building the kind of meaningful relationships that actually closes deals.
Salesforce is our CRM of choice. Our Sales Operations team loves how they can customize it, do robust reporting and integrate it with the other tools in our tech stack, including all the ones listed here. Its extensive platform allows us to sync lead and customer data between all our tools, even the ones that don’t talk directly to one another.
As I mentioned earlier, the Salesforce app for Intercom is crucial to ensuring our sales reps have complete, up-to-date context on their leads. When new website visitors chat in, our two-way integration enables us to instantly send qualified leads to Salesforce, either with a chatbot or in one click by a sales rep. Our sales reps can also see information from Salesforce right in their inbox – the account’s status, owner, opportunity stage and value, and more.
Clearbit is another sales tool we’ve found invaluable. The Clearbit Reveal app for Intercom automatically fills in missing information about new leads like their company name, location and industry. With this information, conversations can be routed to the right inbox, whether that’s to our SDRs or, for current customers, to our support and relationship management teams.
With the Clearbit app, we are also able to proactively target our most valuable website visitors by using attributes like Alexa Rank or company size to customize who is able to see our Messenger. We can even dynamically insert Clearbit attributes into our messages to personally welcome visitors and convert more of them into sales opportunities.
We use LeanData to automatically route our sales leads. Once we’ve set our assignment rules, LeanData takes care of ensuring the right prospects are assigned to the right reps. For instance, if a qualified lead belongs to a company with more than 1,000 employees, they should be assigned to one of our mid-market account executives who has experience handling complex sales. In this case, LeanData will use our routing logic to round robin this lead to whomever’s up next on our sub-team of mid-market AEs.
An example of lead routing that can be done in LeanData, including notification and trigger rules.
Not all of our leads come in through live chat, although many do. Some sign up for webinars, download one of our books or meet us at industry events. SalesLoft enables our sales reps to streamline and automate our email outreach to these prospects so we can grow our relationship with them and their interest in Intercom.
We’ve set up email cadences in SalesLoft that allow our sales reps to proactively follow up with qualified leads. Instead of having to send one-off emails, we can use existing templates with custom attributes to personally engage with prospects at scale. This saves our sales reps time, ensures our messaging is consistent and helps increase the velocity at which we’re able to move deals forward.
Here’s one final automation tool we love: Tray. We use the Tray Platform to build automated workflows across multiple tools. Tray makes it easy to surface notable customer events – such as changes in product usage or spend – that our sales reps should be aware of. We can push the data bi-directionally to Salesforce and even send real-time notifications on Slack.
For example, if a customer purchases a new add-on like Product Tours, we consider that an important change. Tray will surface this event and notify the rep assigned to the customer’s account. Then the sales rep can decide what action is most appropriate: reaching out personally to say thanks, sending over resources on using new features, scheduling a time to discuss their objectives and so on.
Make your team more efficient with sales automation
Not everything your sales team does can or should be automated – after all, robots still can’t close deals. But by identifying low-value, high-touch tasks your team does regularly, you can start to look for tools that save time, allow you to spend more time on revenue-generating tasks and ultimately give your sales reps what they need to close deals faster.
The old world SaaS model was basically all about sign up and convert. The new SaaS model is subscription revenue-driven, which begs the question: what is a conversion today? After all, we don’t buy software these days; we subscribe to it.
At Collision, I spoke about the new techniques that product owners and marketers will need to navigate the world of customer relationships. You can check out the video above or read on below for a lightly edited transcript.
It’s not just SaaS; subscriptions are taking over
It turns out that it’s not just us within the SaaS business that are realizing that retention matters. It’s happening everywhere; in fact, we’re seeing this happen in beauty, in lipstick, clothes, underwear, beards,meat, just things from Japan. And that’s not even the only one from Japan; there’s actually at least 18 different Japan subscription boxes. All of these services are literally things that you can get per month for $9, and they show up on your doorstep in a box.
This is what we’ve ended up in: a world of subscription everything.
And we’re seeing it across every weird walk of life. If there is a thing that you buy regularly, you can have it show up on your doorstep every month for $9 or equivalent. And that changes a lot: how we think about marketing, how we think about what our product is and how we think about what customer success actually is. The magic words that matter here are every month; we get this customer every month. And that’s different to the old world, where you get a customer once because they buy the thing once, and they’re done.
“Most importantly, subscription businesses enable you to think about marketing as a function of delivering customer success”
This shift moves us from brand promiscuity to brand loyalty. This idea that you now pick one razor blade manufacturer and you’re done. You never choose razor blades again. We go from chaotic revenue that we can’t easily predict to predictable revenue because we know that they’re going to keep coming back. It enables a world of “try before you buy” instead of the old world, where you buy the product and then find out if it’s any good – “buy before you try.” It turns a previously complex sales process into a simple sales processes with self-serve sign-up.
Most importantly, subscription businesses enable you to think about marketing as a function of delivering customer success, and not just about the transactional “get that customer over the line.” And that’s probably the biggest shift. What’s changed therefore in our business, is that the subscription world is genuinely here to stay.
Customer retention is more important than conversion
If you run a software as a service company, you probably know about this shift, but we’re seeing it everywhere. The subscription economy is a lucrative world – it’s one that the market rewards its predictability and scalability. It’s a fundamentally different business model, and everything about how you market it and how you talk to your customers changes.
That’s why I’ve been saying that retention is more important than conversion for all businesses, but specifically for marketers. And we’ve learned a lot in our industry about conversion over the years, and you’re all familiar with this. We know that all this is how you grow your landing page traffic. And when you do, we know you point them to a website, and on your website, you probably do things like run an AB test.
Through AB tests, we’ve learned that simple calls to action outperform complex ones. And calls to action people can see outperform ones that they can’t see. And ones that are in the right place outperform ones that are in the wrong place. And we’ve constantly played with all of this shit about how do we put the button in the right place? Is it red or is it green? What color makes sense, et cetera?
But we’ve learned as much as can be learned about home page conversion in my mind, and that prompted this tweet by a guy called Benedict Evans, who make a point that a cool new messaging app can launch today, and within a few days, it can get a million users.
A cool new messaging app getting to 1m users is the new normal. Keeping them, and getting to 100m, is the question.
That’s not actually the challenge any more. In fact, that’s just the cost of entry. The real challenge is getting to 100 million users and keeping them. Which is why retention, and the idea of retention, is actually where you need to position your mind. It’s where you want to point your product team and your marketing team. How do we retain customers? Retention is the next next funnel; it’s this idea that all the wasted energy that we’ve put into trying to get the wrong customer to sign up is not what we want to do. We need to get the right customers in and have them stick.
To give you a simple example, here’s a question: Would you rather a million customers after four days, or a million active customers after 16 months?
It would seem like the former business is the one that’s growing and successful. That business was a chat app called Yo. The latter business is Slack. Suffice to say, Yo doesn’t really exist any more, and Slack is going to be worth tens of billions of dollars. Activity and retention is what makes your business successful, not signups.
The importance of net dollar retention
If I’ve convinced you of that, the next question is, “How do we measure this?” Ultimately, it comes down to what’s called net dollar retention (NDR).
If somebody signs up today, how much are they worth in one year’s time? Are they spending more money or less money, or are they still with me at all? And the variables here are typically seen as churn and expansion. Most of the time within your product group, you should be maximizing the opportunity that people will stick around and use more of your product, or minimizing the probability that they’ll quit. And if you can do either of those two things, you’ve a massive leverage on your business.
In the graph above, the difference between churn and expansion is an order of magnitude over time. You have a business that expands nicely and will grow entirely off its own momentum. If you have a business that organically shrinks over time, you have to do all this extra work just to keep going, and that difference plays out in all sorts of nasty ways.
Just to give you a visual of how this is typically measured, the graph above shows what we want to see: all cohorts of customers become more valuable over time. And if they do, then what you realize is that if you look at the top bar the net new customers is actually less important than the growth of all existing customers in any given month. That means your business has this beautiful organic momentum. It means literally, you could take your hands off the wheel, and the business still grows.
In the graph above are some recent companies that have gone public – maybe not so recent in a couple of cases – but you can see they all exhibit this beautiful trait of observing NDR above 100%. When we land a customer, they’re worth so much more in a year’s time than they were worth at the time we landed them.
The reason it matters is because if you’re in, say, marketing, one of the big variables you’re going to care about is your lifetime value (LTV). And you compare your lifetime value with how much money it costs you to win a customer. If your lifetime value is greater than your customer acquisition cost (CAC) you can spend money effectively.
LTV > CAC
If your LTV is greater than your CAC, it’s okay to spend thousands of dollars on a customer because you know that in the future, they’ll be worth more than those thousands of dollars. But that formula has to be true. If your business shrinks over time, you’re effectively buying a leaky bucket, and it’s not going to work.
High customer retention is built on great product onboarding
So where does this go wrong? It’s like so, right Des, you’ve convinced me. Sounds great. How do I get this up and running? And that is a challenge. Typically what we do is this:
We do all these wonderful marketing activities to get all these people to our home page, and then it all just goes to shit.
And maybe some of them sign up, and then it goes to shit. Or maybe some sign up and you try to get them set up, then it goes to shit.
Maybe in a rare case, you’ll get a happy customer, and in that case, your job is to keep that customer happy and keep them in this positive loop, where they keep using more and more of your product.
Because if you don’t, they’ll become a former customer, or a customer of somebody else’s, and then it’s all gone to shit.
The moral of this little segue is that you have to work very hard to stop it all going to shit. And that is ultimately the customer lifecycle, and that’s what your product team needs to focus on. When somebody expresses intent in using my product, how do I make sure it does not go to shit? How do I make sure that they stick around, and they use more and get more value over time?
“Product onboarding is the key to customer retention”
The key area – and the area that’s most under-invested in for most businesses – is onboarding a customer successfully. Product onboarding is the key to customer retention. Can you actually get customers up and running well? If you can get them in and get them set up properly, it absolutely changes the dynamics of your entire business. We’ve spent many years working on product onboarding at Intercom. I’ll talk to you about some examples that we’ve learned along the way.
The above visual of how we treat customers represents a lot of what we do to our customers. You know the experience of when you go to buy a product, and you get all of the promotional material and magazine adverts? It all looks beautiful, and then you buy the camera, and now, you get all this dull manual. This is the normal experience. The software version of this looks like, “We have this beautiful, simple file management tool. Come and use this.” And you’re like, “Okay, I’ll sign up.” Boom, check out this crap, right?
That’s the typical experience that we give our customers. We over-sell. It’s so easy to iterate on beautiful marketing designs and promises, and sell people on something that just fundamentally doesn’t exist. And then you can scratch your head and be like, “Where did it all go wrong?” But it turns out you landed them in it.
Onboarding is the thing everyone needs to think about.
What is onboarding? It’s this sort of middle ground between a customer has decided they want to try your product. They think it’s the right tool for them and are going to commit to using it for years to come. That includes trying it out, potentially picking a plan, buying, configuring and inviting their team; all of that is all necessary to get somebody set up for success in your product.
Examples of good product onboarding
What are the ingredients? Well, how do you build this bridge between your sign-up form and an actual happy customer? The way I think about it is, if you look at some of the best in class businesses out there.
Slack, for example, have obsessed about onboarding. They make you use every feature: upload a profile photo. That’s how you set up your actual pic. At the same time, they’re teaching you file attachment and how that works. They make you chat with the Slackbot, so you understand how to interact. They make you mention people and join channels, but they obsess over it.
Apple Music, for example. I recently signed up for it. They really obsess about how do I make sure that Des gets the right music first? And they’ve built this interactive playing ground, where you kind of hit things to either remove or add to your library. But again, their obsession is how do we make sure that Des hears the right music? Because if he doesn’t, he’s going to close it and open Spotify.
Similarly, Superhuman, which is the hottest new email client in the Valley – well, maybe joint hottest alongside Front – their whole thing is keyboard shortcuts and speed is what’s important, and they’ve built this near-on interactive game, where it’s just keep using all of our fancy features as much as you can because we know that when you’ve used them all, you’re going to love this product.
Coda, another example, is the future of documents in a sense. And they’ve built an interactive walk-through where they won’t let you use their product until you’ve seen it at its best. They really want you to taste the value that they bring. They insist on you demonstrating comprehension, understanding and appreciation of every cool thing that they have. That is so much better than dropping them onto a blank page and saying, “Go for it,” right? But they obsess about this idea that we know if people use our signature features, they will stick around. They will retain, and our business will succeed. If they don’t, we will fail.
“Are you building what you sell? Are you selling what you build?”
And once you fundamentally accept that, it changes how you prioritize onboarding. Onboarding exists in this state between what your marketing team are promising the world, and what your product team are building. The key question here is, are you building what you sell? Are you selling what you build? And most companies don’t actually have somebody who obsesses over this. They kind of sit there scratching their head. It sort of falls between the chasm between product and marketing, but it’s a really, really important area for you to think about.
5 tips to improve your onboarding
Here are some examples of how you can improve your own onboarding.
1. Interview customers who have recently signed up for your product
You want to interview people who:
Are trying to use your product. It sounds like hard work. It is hard work, but then again, you’re playing for a multi-million dollar business, so it’s worth doing some hard work.
Signed up and then vanished. What were they looking for? Are they an actual prospect?
Signed up, started a trial and converted recently. What went right? What is the thing that tipped them over the edge? When did they know? What did they need to see?
Signed up, started a trial and cancelled recently. They actually really gave you a good shot, and then said, “Screw it.” What went wrong? What was missing? Would anything have changed their mind?
Currently on a trial with your product. This where you’ll get the most energy. What open questions do they have? What else are they doing? What were they doing before they came to your product?
In all cases, you’re trying to work out, what is that calculus in your head that makes you decide that this is the right or the wrong product for you, and how can we influence it?
2. Decide which customers you can onboard.
Secondly, pick the customers you can onboard. You can’t onboard everyone. Your product will turn into a one size fits none mess. Not everyone is ready to use it. Specifically, people have to need your product, want your product and be capable of using your product.
No two of these is sufficient. You can need and want something but not be able to afford it, like me with a Tesla. Sounds great, but I’m not going to buy one. I’m wasting your time. Similarly you can want something and be capable of using it, but just not really need it. And lastly, most obviously, you can need something and be fundamentally capable of doing it but have no desire for it, and that could be anything like going to the dentist. Most people aren’t like, “Oh, I really want to do it.” They just know that they need to do it and they can do it.
3. Use the 4 forces: push, pull, allegiance and anxiety.
Another piece is to understand the role of the 4 forces. Most people who are trying to switch to your product are switching from something else. The Rewired Group identified 4 forces at play. Two..