Recently, iTWire took the opportunity to speak with Adrian McDermott, President of Products at Zendesk. One area of particular interest was the increasingly complex customer interaction landscape and how Zendesk supports this, and has used the recent alliance with Slack to enhance their mission.
iTWire: let me start by asking about how any organisation manages their customer interactions. Describe the current view of the world and how we might make some progress.
McDermott: From a next-generation platform point of view, what [our] customers are really looking for is the ability to have tools and services that live within a heterogeneous ecosystem.
Everyone has many SaaS tools - everyone has a mix of technologies, and I think this quaint idea that you can fit a customer record into a two-dimensional Oracle table with name-value pairs, and that's where it would live forever, and everyone would use it, is long gone.
A customer really is more like an event stream - they experience your brand as a linear narrative - I bought this, I read this, I got this marketing email, I clicked on this one, I didn't click on that one, I read this thing, I bought this thing, I complained about this thing. These things happen serially, one after the other - you have to recognise that stream of events and capture that stream of events to really move forward.
iTWire: so, the difficulty here is to attach a degree of relevance to each of those points.
The amount of machine-generated data that exists in the world is ridiculous, when you think about how fast it's growing. This is as much a problem in customer-land as it is anywhere else.
iTWire: In most cases, a customer really doesn't care whether they're dealing with someone in Marketing or Sales or Support, they simply want their problem fixed.
McDermott: The canonical example of a voice-driven system is "press 1 for Sales, press 2 for Support, press 3 for Marketing" which is basically exposing your org chart. I think it's very easy within a company to realise that you're exposing your org chart and not have what we would think of as outside-in thinking, where people are coming in with directed objectives - it is a 'return,' it is a 'purchase,' it is some other enquiry, and those are the entry points you need to offer on the channels that the customer wants to use - very important, right?
There is extreme discomfort… there are stats that we can show which indicate there are generational differences in terms of the channels that people want to use. People of my children's generation barely know that the telephone actually makes calls - that is not what that device is for. So, one has to recognise that when one sets one's customer experience out.
iTWire: How do you see the recently announced cooperation with Slack?
McDermott: Interesting. So, Slack - I think about it primarily as a tool for managing internal communications that are open-ended and long-running and are shared in a group. I think one of the things we think about doing is managing communications that are directed towards an outcome. That's following along from some business process. The key thing about our tools is that they're driven by workflows and by an outcome - you measure customer satisfaction etc.
If you think about our integration with Slack, a good way to anchor the conversation about the difference; we have an integration with Slack called 'side conversations.' Within the Zendesk support there is this concept of a 'ticket.' A service ticket; a conversation which is marked, as most service tickets are, by a beginning, a middle and an end.
The 'beginning' is the customer reaches out - these things tend to be in-bound, they don't have to be - you can proactively create tickets, but they tend to be [in-bound]. And then they're resolved or closed through that process. And in the middle, the conversation goes back and forth. There are a series of actors that play out on that stage. When we thought about integrating Slack, what we saw was that paradigm of informal communication between groups in the organisation was really powerful for solving problems.
We use Slack internally and we saw our own support agents taking work that was happening inside the ticket and (say) jumping out to the Legal Department, going into the Legal Slack channel and saying, "hey, I've got this customer who's asking me this question," and then collaborating in there, and then coming back and putting an answer back in for the customer. What you're losing is the context of how that answer was generated - who you had the conversation with and everything else. So, within this ticket, there's this thing we've called side-conversations, which is [for example] Marissa here and I as Zendesk employees might sit in Zendesk and we might both have licences for Zendesk and we talk to customers, and we can communicate though the medium of the ticket.
But, you, or a third-party, or you're somewhere else in the organisation, and you're just connected to us on Slack, so we can generate a side-conversation from the ticket where every back-and-forth betwixt you and I, and Marissa is recorded in the ticket and is stored in there. What you don't know is, I'm using Zendesk within a ticket - you just think we have a Slack channel together - a three-way Slack conversation, but what I'm doing is documenting those processes and actions. Which is important because if all of your process shifts into Slack, you suddenly lose that ability to analyse that data; analyse those processes.
Think about the classic metrics of Customer Service - how many stations were on this ticket? How many people were involved? How long did it take? How many conversations back-and-forth were had? What was the effort and energy that was put into it?
We think it's super-important to capture all those things without disrupting, necessarily, the flow. So the agent continues to live in Zendesk, the thing that they know, but is talking to you, and you live in Slack, so neither of us had to jump out of our channel, but we tied together each of these things. So, that's Zendesk side-conversations for Slack, we also have side-conversations for email, for first- or third-party collaborators who are going to be communicated with over email. We see third-party delivery people, franchisees, etc. as being a way to enrich the ticket with this broader community of people.