Sales Executive Corner
Why We Switched From Intercom To Zendesk (And Almost Chose Desk.com)
At Outreach, part of our culture is being extremely transparent with our customers because we believe it builds trust, and communicates the level of thinking we put into our service.
While this article outlines our process of moving off Intercom for chat, I want to state unequivocally that we are still Intercom customers for their in-app notifications to end users. It’s difficult to be great at all things, and I think they are still the leader at this. While our needs have grown beyond what they can support for user/agent communication, I still believe they are a great company, and may still close the gaps outlined below.
If you’re interested in the shorter customer-focused notes on this, you can check out the customer announcement to understand how your experience will be impacted as an Outreach user. Onward!
Uncomfortably-Close Customer Success
At Outreach, we’re obsessive about customers. I’m doing much better these days, but for a long, long time I would wake up each morning with a mini panic attack as I reached for my phone to see what might be waiting for me in my inbox. I was always worried maybe something went wrong with a new feature we pushed out, or somebody was waiting for 3 hours on a question. These things are unacceptable to us, and the fact that something could go wrong wasn’t the problem, it’s that a person who relied on us was inconvenienced for more than a few minutes.
I find us lucky to have built a sales engagement platform that has become an incredible lynchpin in our customers’ daily activities. We didn’t set out with that goal, it just turned out that the problem we are solving, and how well we solve it, has put us in a position where people rely on us every day. It’s something you have to take incredibly seriously, and we consider it to be an honor to be trusted at that level.
...the fact that something could go wrong wasn’t the problem, it’s that a person who relied on us was inconvenienced for more than a few minutes.
Obsessed With Responsiveness
Our target responsiveness today is a 10-minute average first-response time, which doesn’t include, “Hey, I’ll get back to you later,” messages to push things off. To date, we are at around 25-minute average first-response time during business hours, and 32-minute overall response time across all hours. That's certainly not awful, but that’s not where we want to be, and you’ll see in this article that we’re looking for ways to shave that down.
If you want to hit a 10-minute average response time, you need to have people whose sole job is to be available to answer those questions immediately, or escalate to somebody more specialized for that question. You then need a flexible infrastructure to support the process you establish (and iterate on) around customer inquiries.
Our First System
...having a communication channel accessible from within the Outreach interface would increase the chances somebody would get in touch with any questions, concerns or issues
In the very early days, perhaps when we had a handful of customers, we plugged Intercom into Outreach because it was fast to get up, and met our standards of a well designed product. For those of you who are less familiar, Intercom is an in-app notifications system, which includes in-app two-way chat between end users and company reps (agents).
We found that having a communication channel accessible from within the Outreach interface would increase the chances somebody would get in touch with any questions, concerns or issues. That’s huge for us, because if somebody gets stuck on something and you don’t hear that they got stuck, you can’t help them get unstuck - and that means they won’t use your product.
Early on, I was both the head of product and the sole Customer Success representative. As the team grew, I found that we had multiple people all swimming in the same pool of messages and it wasn’t always clear who owned what, or the status of any given question/issue.
And now, after having broken through the five-hundred customers benchmark, we have a ton of people who rely on us every day. Any internal pains we saw when we only had a couple hundred customers are now magnified in something that sometimes feels like controlled chaos, depending on how many new large customers my sales team just passed to us, and if it's a 10, 20 or 100 seater.
When we realized we needed to establish more order in our process, I reached out to chat with some Intercom representatives. It was after our conversation, and tracking their product releases, I realized that they were focused on other problems and wouldn’t be able to help with these core issues anytime soon. And thus began the pursuit, starting in February, for a new solution.
At the time, we weren’t yet super familiar with what else was out there, and certainly weren’t yet experts on the best ways to structure a team and system to run things as efficiently as possible. We began the hunt and found that there are a number of products on the market in this space.
For Small Teams:
For Medium/Large Teams:
For Enterprise Teams:
We were already on a small company solution (Intercom), and it was time to go to a solution that would fit our needs now, and grow with us as our Success Team goes from four up to 100. Looking at the options, it was then down to Zendesk, Desk.com and Service Cloud.
Service Cloud was originally launched in 2009 by Salesforce as their customer service solution, but quickly became an enterprise-focused product. After noticing Zendesk competing nearly unchallenged in the mid-market space, Salesforce bought Assistly in 2011 and relaunched it as Desk.com in early 2012 in order to compete against Zendesk, who ended up having their IPO in 2014.
Given that Service Cloud was far more enterprise than we need right now, we decided to focus on Desk.com and Zendesk. We got trials of both, and talked to the reps of both organizations. Kelly Ryan of Zendesk, and Michelle Ellingston of Desk.com were our awesome points of contact (Michelle was also our Salesforce rep). If you want demos, you should get in touch with them.
Both were super friendly and helpful and did a check-in each week to answer questions as we got acclimated during our trial period. Both provided 21 day trials, and our intention was to jump in and bang on both systems in order to understand what the best practices and capabilities were. The trial period served to underscore issues with Intercom that we had the notion of previously, but couldn’t necessarily articulate clearly at the time.
After doing so much research, we found that some of the important pieces that were missing revolved around helping us track status of interactions with customers, working as a team, measuring activity, and increasing overall speed of response. I thought it would be helpful for other folks to see why we made the decisions we did, and perhaps use some of this information.
Status Tracking Is Important
In Zendesk and Desk.com, there is a notion of pending, which indicates that a ticket is pending customer response to your message. You’re then able to create custom views which can, for example, show everything pending customer response, or another view which only shows tickets in New or Open statuses for each group. This makes it a dream to know what is actually on your plate this moment, so you can quickly power through those tickets.
In Intercom, there is no notion of Pending, which means that there’s no easy way for a Success Team member to know what they have addressed (and is waiting for a response from a customer), and what is open/new and requires their attention.
This produces an organizational nightmare, where you keep checking and re-checking things that don’t need your attention, just to see whether or not the customer has gotten back to you.
Work Like A Team
...at the end of the day, with a few exceptions, they just want to have their answer and be moving again. They care less who it came from...
Building a larger team where different people specialize in different roles and have different amounts of information means that you need to get really good at ensuring the right questions get to the right people as quickly as possible. Simply put, it’s triage and routing.
The game of triage requires a system that lets a set of people handle or escalate questions/issues to folks with that specialized knowledge. That typically means that you’ve got various groups within your company with that specialized knowledge, and you need to be able to assign it to a group of people and let the first person available claim and tackle it.
In Zendesk and Desk.com you can assign a ticket to a particular group of people, so that the fastest person to get to the ticket within that group can jump on it. You can assign any agent to one or more groups based on what they know, and where you want them spending their time.
The advantage afforded to a team is that if there are five people in a certain group, and Person A responded to a message originally and then had to go to a dentist’s appointment, anybody else in that group will still see it when it comes back to Open, and can jump on it immediately, ensuring that the customer gets an answer well ahead of Person A getting back to the office from the dentist.
In Intercom, there is no concept of a group that you can assign it to. A ticket is either unassigned, or it is assigned to a particular person. If that person answers the message, and then need to go into a meeting (or run off for an emergency, or they are asleep), there’s no way for somebody else to see that item and help out.
That scenario (understandably) frustrates customers because at the end of the day, with a few exceptions, they just want to have their answer and be moving again. They care less who it came from, and more that the company cared enough to get them an answer as fast as humanly possible. And frankly, in my opinion, if a customer sees that multiple people are helping them out, they feel they are getting more attention from the whole company. This only goes bad when various agents don’t absorb the context and ensure they are picking up where the last person left off.
As a manager, I need to have a system that tells me response times by rep over periods of time, or by account. I need to have metrics on number of tickets from an account over a period of time, and what portion of those were questions, issues, and so forth. I also need to see by customer organization the response times my team has been providing them.
Zendesk and Desk.com let you customize your metrics display so you can see whatever you need to. Unfortunately, in Intercom they give you two graphs that come pre-packaged, and you’re unable to get much information by representative, or at the customer organization level. From a product development standpoint, it would be incredibly easy for Intercom to build something simple here, which suggests that they really are just not very focused on solving this particular problem set.
We are aiming for a 10-minute median response time, but what you aren’t able to measure, you aren’t able to hold to a standard and improve. You also aren’t able to clearly demonstrate to your team members (Success Managers and Account Executives) how well you’re treating the users within an account.
Is Outreach the missing piece in your tech stack?
Chat Had To Go
I couldn’t shake this strange feeling that if we were working to delight customers with our customer experience, I also had to challenge the notion that in-app chat was the right solution.
If we were switching systems, we needed to look for a replacement for chat. As it turns out, Zendesk and Desk.com both integrate with a number of independent chat solutions, such as Olark and Liveperson. Zendesk also acquired a solution in 2014 called Zopim in order to create a much deeper integration than you can get with third-party products.
So if we were going to Zendesk or Desk.com, there was a huge open question around which chat system would replace the Intercom chat system, and how large of an affect that decision would make on our choice of platform as a whole. We also wanted to know how painful it would be to switch off Intercom’s seemingly unbeatable chat interface.
In the process of evaluating each of those solutions as a potential replacement, I couldn’t shake this strange feeling that if we were working to delight customers with our customer experience, I also had to challenge the notion that in-app chat was the right solution.
After doing an audit of our Intercom chat threads with customers, I walked away with a realization that while we physically could hook up a chat application to Zendesk or Desk.com, the chat medium itself has actually been hurting our ability to handle customer inquiries quickly and efficiently.
Chat Draws Things Out
The best customer experience is one where they never need your help, and the next best is where if they do need help, they get their inquiry resolved as fast as humanly possible. The challenge with the chat medium is that customers tend to engage us with a stream of consciousness, padded with time between notes, commonly resembling this:
- Customer: "Hey, are you there?"
- +2 minutes later…
- Customer: "I have a problem"
- +6 minutes later… (now 8 mins in)
- Success: “Hey there, what can I help with?”
- + 8 minutes later… (now 16 mins in)
- Customer: “I am trying to load prospects but I’m having issues. Can you help?”
- +6 minutes later… (now 22 mins in)
- Success: “Sure, but can I have some more information about what issue you’re having?”
- +7 minutes… (now 29 minutes in)
- Customer: “Yeah the issue is with my CSV. It won’t upload correctly, I keep getting an error.”
- + 5 minutes (now 34 minutes in)
- Success: “Ok, I can help out with that. Can you give me more info on the CSV? Can you send over the CSV?”
- + 51 minutes later… (customer went to eat lunch - now 85 minutes in)
- Customer: “Yeah, it’s attached. It keeps giving me this one error.” +CSV +screenshot
- +13 minutes later… (now 98 minutes in)
- Success: “I took a look at your CSV and it looks like you’ve got messed up data in row 15. If you resolve that and upload it again, you should be great.”
- +8 minutes later… (now 106 minutes in)
- Customer: “Thanks!!”
In this scenario, the first five messages don’t even get to the basics around the question, and by the time we know what’s going on, we’re already 29 minutes past the time they had the issue. That’s a half hour wasted of the customer’s time, and it ended up running the customer into their lunch, which added an extra hour because at that point they had to wait until after lunch to get things going again.
Conversely, when we receive email-based questions, we see them skip straight to outlining the problem in the first message, allowing us to answer straight away, or immediately start getting more details on what’s going on.
Chat Sets False Expectations
is it fair to the customer to present an interface which implies sub one-minute response times, when you can’t or won’t uphold that response time?
At Outreach, our median response time over the last four months is 25 minutes during our business hours, and 8 hours outside of business hours. Still, that isn’t as good as we want to be (10-minute median), but is better than any other company I’ve seen with Intercom embedded in their product.
Even Intercom’s own support team has rarely (if ever) replied to a question of mine in less than 2 hours, and usually doesn’t get back to me for at least three to four hours. Many times, it’s up to a day later before I hear back.
Yet, the “live chat” interface (as a medium) leads me to expect a reply almost immediately. For example, if you go to Zappos.com and start the chat window, you’ll have somebody within 15 seconds. Now that’s chat! I can actually talk to Courtney and get answers immediately – not three hours later (by the way, Courtney says she likes pizza and bunnies).
The question then becomes, is it fair to the customer to present an interface which implies sub one-minute response times, when you can’t or won’t uphold that response time? We don’t believe it is, and if you’re running interactions which are asynchronous, then you’re better off having a message submit window that lets the user outline their entire question in one go, and go back to what they were doing, rather than lingering with false hope of a lightning-fast response.
I do want to clarify here that it’s not entirely impossible that after we break through the 10-minute median response time, we wouldn’t then begin to tackle a 5-minute median, and chip away further. At some point it may well make sense to use the chat window again, but we’ve learned the hard lesson that as a company that it’s better to start where we are than prematurely optimize for something we aren’t yet. Chat can come later, if we first iron out the infrastructure for it.
Making A Decision
After having evaluated Zendesk and Desk.com, we had both reinforced that Intercom had to go, and clarified what mattered to us (and also what didn’t) in the decision. We had found that both systems were very comparable, both having the following:
- A ticketing system
- Ability to create groups and assign agents to them
- Ability to create custom views by group to help them focus on the right things
- Ability to create custom notifications to agents and end users about ticket status, assignment, or anything else through triggers or automations
- Customizable analytics dashboard to let you see whatever you want
- Deep integrations into Salesforce
- A knowledge base to help provide information proactively to the customer
- Macros, which allow you to have shortcuts for common actions like assigning a colleague, escalating the ticket, putting in a message that says you’re introducing them to somebody, and submitting the ticket with an open status
All those things considered, they do indeed have differences we noticed, which I will now outline.
- They recently released a new interface that they call Next Gen. It’s an inverted color scheme, which is dark background and lite foreground. It’s nice!
- From the agent’s perspective, you could access the knowledge base from the agent interface, without loading another tab. This is really important when you want to leverage content links from the KB with a couple of clicks, and train your users to go there to get answers.
- We got a lot of feedback from many people that Desk.com had infrastructure problems that resulted in delays of message sending. We also experienced delayed message sending during trial, where if you sent a message from the system, it would be “sending” for about 30 seconds, and then arrive about 15 seconds after it was done “sending.” It didn’t inspire confidence, considering the feedback we heard.
- We also found that Desk.com’s knowledge base (support center) was exceedingly difficult to customize. Their editor looked like something out of 1992 and made it almost impossible to quickly get something up and going that didn’t look awful. They also had no starting templates that looked reasonable.
- Their knowledge base (support center) had no concept of categories, only “multi-brand” which made things even more difficult to customize. Each brand looked like a category, but was more complicated to get setup.
- With Zendesk, message sending was almost immediate, and that gave us confidence.
- Had we wanted chat, I would have used Zopim. It’s the most mature chat product, and integrates into Zendesk really nicely.
- Zendesk has multi-brand knowledge base as an option in addition to categories, topics and articles. This made things much easier to fill out.
- Many people we talked to said they used to be on Desk.com, and moved to Zendesk and the infrastructure was much better.
- Unfortunately Zendesk only came with three base templates for their knowledge base, and they aren’t very stylish, and aren't even on a responsive grid – but that can be fixed with some elbow grease. We did a v1 of a customization and, while we’re not super happy with it at the moment of this article (from a design and responsive grid standpoint), it’s serviceable and took a half day.
- The whole team liked Desk.com’s “Next Gen” agent interface better, but that’s fairly superficial.
- Zendesk makes agents have a separate window open to query for KB articles, in order to answer the customer’s question. That’s difficult when you’re trying to power through tickets quickly, and need to open a different tab. (EDIT: Zendesk has an application you can install which makes it trivially easy to view and paste links to help center articles. See screenshot below.)
All things together, the performance concerns of Desk.com and KB customization advantages of Zendesk are what made Zendesk win out in this evaluation, as for the most part they were otherwise very similar.
While Zendesk does have a message submit window you can embed in your application (different than chat), it was important to us to leverage messaging in a particular way that takes into account some future plans for in-app resources. With the Zendesk API, it was simple enough for us to build a custom message submit window, which creates a Zendesk ticket from within Outreach, all with the correct details of the customer logged in Zendesk. Our awesome engineer/cofounder Wes built in custom functionality to that window to let users screenshot the page, and use their cursor to draw arrows at - or circles around - the parts of the page they wanted us to see, making it easier for us to understand what the customer is referencing.
When your sales team is killing it, the customer Success Team feels like they are drinking from a firehose, just trying to keep up. It’s incredibly important we not just maintain, but improve our customer response times as we scale the company, and we believe making this switch has put us in a position to do that.
Frankly, we’ve agonized over this switch for around three months from start to finish, and after having lived in Zendesk for the last week, I feel comfortable saying that this is the beginning of using a system that will facilitate the growth we’re experiencing now and in the future, while helping us retain our reputation as a software company with unparalleled responsiveness with customers. It will equip us to continue to be uncomfortably close with our customers.
Lastly, I still believe in Intercom for messaging with announcements in application, and even for activity-based communication, whether in application or by email. They are hands-down the best at this, and I hope to see them grow as a company in other areas. If they ever circle back to features that support larger organizations, it’s possible they could potentially challenge Zendesk and Desk.com for some of the market share.
I hope this write-up was helpful for your own support scaling challenges. As for me, I have to go answer some tickets that just came in. =)