Transforming Complex Experiences by Focusing on the Key Control Points

Jehad Affoneh at UXDX USA. Video: https://youtu.be/IXS0a-gp7mM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Toast and the complexity of restaurants

[00:00:00] Jehad: We've been going through a bunch of transformations at Toast over the last couple of years, from transforming our point of sale to our support experience to onboarding. And the question I really look back at all the time is: if I could go back two years and give advice to myself, what would that be? That's where this talk came to be.

[00:00:20] Before I start, I want to give you a little bit of context on what Toast does. This is our mission: we empower the restaurant community to delight their guests, do what they love and thrive. It's pretty cool. Toast is a vertical SaaS company. What that means is we go really, really deep on one domain and solve every single problem in that domain, and our domain is restaurants. The light just went a little bit lighter, which is awesome. Our domain is restaurants, so we go really deep on helping our customers, who are restaurants, solve every single problem that they're facing.

[00:00:57] Before joining Toast, I thought restaurants were really simple businesses. You get the food, you do service, you follow reviews and you're good to go. I was very, very wrong. Restaurants are not only complex businesses. Most people go into restaurants because they love food, but they're actually really operationally difficult. They're low margin. It's a high-stress, high-turnover industry. Really, really difficult. And they're often measured by one or two interactions: how good is the food, how did you make me feel? All the things that happen in the background are working toward those two interactions. So it's a really complex business. Keep that in mind as we go through this experience.

How do you eat an elephant?

[00:01:39] So how do we approach really complex businesses? I changed "control points" to "pull the thread," so you're not going to hear control points. These two things are the same. If you look at a big problem, I love this saying: how do you eat an elephant? Has anybody heard this before? Okay, so if you've heard it before, you know what's coming next. But if you just think about "how do you eat an elephant," it's such a daunting question. You start thinking about the size of the elephant, how do you catch the elephant. But in reality it's just one bite at a time, one step at a time.

[00:02:09] If you take that concept a little bit and move it forward, and you look at this very oversimplified customer journey, really, really simple: users onboard, they use the product, they get help when they need it, and they grow. When you have one or two customers, this is really your customer journey. When you have 100,000 customers with different tech-savvy levels of interacting with software, and you have multiple different products, not just one, then "use" is its own customer journey for every single product. Every problem in the support story, for example, has 100,000 different permutations, depending on what happened, depending on the environment, depending on who's behind the phone, depending on what happens in, for us, the restaurant. Then this starts to get really complicated. The journey starts to get really, really complex. You have more products, you have more customers, you have more problems, and you have really interesting things that you probably haven't run through before.

[00:03:10] If you take just one piece of that and say, how do we support our customers, you start having all the different problems, and permutations of different problems, that customers call about. Again, in this case restaurants for us, but whatever your business is, you're supporting customers as they have a problem. Just like AJ said this morning, this is one of those experiences that can fix customer impressions of you or can derail them in the other direction. It gets really, really complicated.

[00:03:36] But it gets even more complicated as you think of all the different interactions that you can draw from the customer to internal operations. If you start drawing the customer journey, both what customers see but also what you need to change internally, it starts to look, worse is the wrong term, but even more complex. You start thinking about how you train hundreds and hundreds of agents on the different products you're shipping. How do you make sure these agents are informed, but also have the context of that specific restaurant when they call in? How do you make sure they're trained on empathy, but also on the actual product and experience? How do you make sure they have the knowledge of the latest product you just shipped a week ago? How do you do that without slowing down your innovation muscle? All these problems start becoming so complex as they interact between the customer and the internal view.

[00:04:26] It starts looking like this. This is why we call it pull the thread. It starts looking like a ball of thread that's as daunting as the question of how do you eat an elephant. How do you unroll this ball of thread, especially when you have a bunch of them across the experience?

The mistake of dividing and conquering

[00:04:42] We often approach it this way. We often look at this, and it's a bit daunting. If you're as lucky as we are, we have an awesome research team and service design team who do wonders. How many people here who are not researchers have worked with a researcher this year? How many have worked with a service designer? Right, actually a few. That's not bad.

[00:05:06] So we often started this way. I know not all companies do this, but we in the room often start this way. We do the customer journey, and we do it both from the view of the customer and from the view of the internal teams that support the customer, whether it's support or any other problem. And we start untangling the different experiences, or the different pain points, that customers face. We put together the end-to-end journey that now looks a little bit less daunting than that ball of thread, and we start understanding these problems independently.

[00:05:37] And then we often make the same exact mistake of dividing and conquering. We take this holistic view that we've built from scratch, often based on rigorous research and service design and so on, and then we discover a set of five or 10 problems, and then we almost immediately give them to five or 10 teams that have not been part of that holistic view. They have not gone through that process end to end, and their role is now to solve one of these problems at a time.

[00:06:09] If you think about that for a second, with a ball of thread in your mind, what happens is that different teams are pulling on that ball of thread in different directions, at different times, at different speeds, trying to solve their piece of the pie, their piece of the problem. What they're actually doing is making incremental progress in their area, but they're creating more and more knots within that ball. More problems emerge, more issues the customers start facing. You start learning more. You're creating smaller thread balls within the big thread ball.

[00:06:42] And from the outside in, everything is actually improving by the metrics you've initially set, because you're looking at the 10 projects. You have 10 project teams who are working effectively, who have the right metrics, who have the right goals. They're actually moving forward. Then you realize the end-to-end experience isn't working, though. So you hire a bunch of different sub-projects and sub-teams, and you coordinate communication between those teams. We almost all make that mistake in these big transformative projects. And you only realize some time later that you're not necessarily solving the complexity. You're managing the complexity.

Managing complexity versus solving it

[00:07:22] Managing complexity is very different from solving complexity. Managing complexity is a point in time. You're solving it for that number of customers, for that process and for that experience. What most of us don't realize initially is that because you're just managing the complexity, in some cases you're making it even harder to solve the complexity in the future. Because you're managing the complexity that you have in front of you, the thread ball you have in front of you, and the more knots you see, the more people you add to solving these knots, creating sub-teams and subgroups and so on. And most of the time you get to a point, which is the point, at least for me, where I realize, hey, maybe we've gone too far: where you start thinking the solution is more program management, the solution is more people in the mix to untangle that thread.

Pulling apart the support experience

[00:08:12] So we've been thinking about the support experience at Toast, and we approached the problem similarly. If you look at the thread ball here, you start seeing the signals of an experience that needs to improve. Wait times. Lack of data: we're not really sure, when a customer calls, who they are and what problems they're facing. We should have called them; they should not have called us. You start seeing these types of problems, and you discover, okay, we have a pretty complex problem to solve.

[00:08:39] Then we broke the problem down, and as we started breaking it down, you realize: we have live chat, you can call a number and you'll get to Toast. But live chat, for example, was too live. If you're not in front of your computer within 5 minutes, we assume you don't need help anymore and we move on. You can imagine, in a restaurant environment, that's not great. Authenticating our customers is really difficult in a restaurant environment. People don't go to the phone number that's registered with us and give us a call from that number so we know who they are. They have a problem, it's lunch rush hour, they pick up the phone that's in their pocket, and they spend the first five minutes trying to authenticate who they are, which is really frustrating, both for the customer and for the agent. You have the problem that the knowledge base needs to be up to date all the time, but customers are also running multiple different versions, which means it can't just be up to date; it also has to be updated for all these different types of software that we have out there.

[00:09:38] As we started looking at these problems, our next gut feeling, our next call, was: let's make an authentication team, a live chat team, a knowledge base team, a phone call authentication team, and so on. Let's divide and conquer this problem. Here's the issue with that. The first one is that you start coming up with siloed solutions. The way we authenticate on the phone will probably be different from the way we authenticate on live chat. You start having too much communication required between these teams. You start asking the team doing authentication to work really, really closely with the team doing the knowledge base, because otherwise what we have out there is going to be different from the script the agent has when they call.

[00:10:27] The farther away you are from the minute you did the customer journey, the less holistic it becomes. Every single day from the day the service design team put that journey together, it starts becoming more about how we're running things internally and less about the customer view. And the last piece is that you're still delivering a fragmented experience. You're managing complexity; you're not solving complexity. You still have a fragmented experience for the duration of all these teams working on these projects.

Pull the thread

[00:10:55] So we paused and said, what if we rethink this support experience a little bit differently? We came up with a method that we call control points internally, but it's a little bit easier to explain with this: how do you pull the thread on the problem you're facing? If I give you a ball of thread now and tell you, "Hey, you have the next hour to untangle it," it's very unlikely that you would ask five or six people around you to start pulling from different directions with you. It's far more likely that you're going to start figuring out where the thread is that's hanging out that you can start pulling, and every time you face a knot, you can untangle it and move on.

[00:11:40] So how do you find that thread that can help you untangle the rest of the ball? Finding it is sometimes really hard, because you look at different pieces and you think it's what you need to look into, and you discover it's actually a really deep thread inside the ball. You just thought it was the one you could pull.

[00:12:00] So as we look back on the possible path of defragmenting the experience, and at how we revisit this: we can start by looking at what the thread is. It's a fragmented experience. How do we look at the key failure points and really understand the journey? Then we skip that step of dividing and conquering, and we go into how we identify the thread to pull, and I'll share more about how we did this for support. And then how do we take that and expand it to the end-to-end experience? In that piece, the customer cohort you start with is really, really important, because you can't start pulling the thread for everybody in that experience.

A GM, a rush hour and a broken printer

[00:12:43] So let's look back at support. For us, we were making incremental progress. The authentication team had improved the time it takes to authenticate a customer when they call in from a phone number we don't recognize by 10 or 20%, which was huge if you think about that number across thousands and thousands of tickets. That's not nothing. Our live chat team made really good improvements to the process, so we don't drop you off when you're chatting with us. We give you a little bit more time to come back, and if you come back within a certain time... It improved our customer satisfaction scores and so on. So every team was making pretty good improvements, but we were not seeing that in the overall support experience.

[00:13:20] So as we thought about what the thread to pull is, I want you to imagine a busy restaurant. This is based on a ton of research, but just for the sake of the next minute, imagine a really busy restaurant at rush hour, 12, 12:30. They're serving food, and the printer in the kitchen goes out. The whole service now comes to a halt, unless you have the kitchen display system from... but anyway. The whole process stops. So the first thing they're going to do is, whoever is in the kitchen, they're going to pick up the phone and call.

[00:13:59] Most of the time that's the GM of the restaurant, the person responsible for that location. Most of the time that person is on the floor talking to customers. They're in the kitchen trying to move it faster. They're trying to deal with a customer who's unhappy with their food. They're trying to comp a customer for a bad experience. They're all over the place. You're now taking them away from the floor and asking them to sit in the kitchen, pick up a phone and call. Most of the time they call from their cell phone, and they spend the next 2 or 3 minutes authenticating. They can't be on the floor and on the phone with us, because it's really loud, so we can't hear them and they can't hear us. They can't be on the floor while they're waiting. They can't go in and out of the kitchen, because that's a really difficult thing for them to deal with. And they now have a bunch of different things that are slowing down because they're on the phone. Depending on the problem, it could be 5 minutes, could be 10 minutes, could be 15. It could be, "Hey, you need to reset the printer, it's not connected," or if the printer is broken, we need to send you one. So depending on the problem, it could be many different things, and eventually you solve it.

[00:14:55] But the biggest problem here is that I have to be live as a GM. I have to be live on the phone. I can't be authenticated, because most of the time I'm calling from a number we've never seen before. Remember, this is a high-turnover industry, so even if we ask for your phone number every time you become a GM of a restaurant, that doesn't guarantee you've done it already. There's potential for wait times, because we get the majority of our tickets during three big hours a day, breakfast, lunch and dinner. That's the restaurant industry. And then the knowledge base is not easy to access if you're on the floor. The first reaction of a GM isn't to go and pick up their phone, go to the toasttab.com knowledge base, look up the printer type that they have and read about it a little bit, and try to solve it and understand it, especially if they're facing this problem for the first time.

Async chat support as the thread to pull

[00:15:46] So our realization was that async support, and async chat support in particular, is really the thread to pull. Now, this may seem obvious. We're not the ones who invented async chat support. But we really pressure-tested: is that actually the thread to pull? Does it help us improve the rest of the experience? Because it may help us solve the initial piece of the experience, but does it help us untangle the whole thread ball?

[00:16:13] So we looked at a bunch of things based on the restaurant environment. One is: does it solve the most obvious problems? Authentication, for example: if you're starting from async chat support in our app, we know who you are, we know which location you're looking at, we even know the device that you may be talking about. So that solves that. We can give you quick answers, because text is very different from the phone. We can empower agents better, because they're not on the phone. One of the things we heard from agents all the time is that it's such a stressful environment to be an agent during rush hour. You're on the phone, there's a GM in your ear as you're trying to understand what the problem is, and every minute of silence is a minute of stress. That goes away with async chat support. So that was our "okay, we're going to test this out and move in with that theory."

[00:17:00] We picked a cohort of customers who had already used chat support with Toast, so we didn't have to do behavior change yet for the rest of the customer population. And we started with, okay, this is the Toast app on the phone, and we offered support in it. The first thing we realized is that a bunch of the questions we were getting are pretty simple questions. They're questions that, if you look at the knowledge base, you can solve. They're not "my printer is broken." They're more like, "Hey, which config do I need to change to disable online ordering during rush hour?" Something that's not that difficult for someone who's really experienced with the system.

Untangling the knots one by one

[00:17:34] We introduced AI answers. That was the first knot we were able to untangle: a percentage of tickets can now be solved with AI directly. They never get to an agent. The customer is happy because they get their answer within 10 seconds or less. The agent's happy because they can focus more on the deeper problems they've been trained to deal with.

[00:17:54] Then we extended that to the agents. Because it's written, we can give agents AI assistance as they figure out what the answer should look like. They have the restaurant information, they have the problem. It's not a problem that AI could have solved, we know that, so now it's going to an agent. The agent now has an experience in front of them where they can ask AI questions that use all the data we have internally to help solve it. That's the other knot.

[00:18:20] Then what we realized is that we can use this to help improve our knowledge base. Because every time a customer says, "That AI answer you gave me didn't work, I need an agent," that's a moment of improvement for our knowledge base. Every time the agent looks up the answer and it doesn't help, that's a moment when we can improve our knowledge base. The knowledge exists somewhere; it's just not accessible to either the customer or the agent. So our knowledge base became a more useful experience for customers, because we were pulling the thread on what part of our knowledge is not good enough.

[00:18:54] And then, with that, we had the ability to intelligently route tickets in ways we can't do on the phone. So you're able to train a much smaller number of agents on really deep expertise in certain areas, because you know where to route which problem. And you can imagine, the more you pull, the more you discover. But basically, if you look at these improvements, they're not exclusive to async chat support. Improving our knowledge base is for everybody. AI assistance for agents is for all; we were able to roll it out to all agents. AI chat answers could be available publicly to customers without having to go through this experience. So even though we started with async chat support, we were improving the whole "how do I get help" process, and the more we pulled the thread, the more we were able to do.

Three questions to ask

[00:19:40] So here are the three questions. If you can think of a single problem today that you're dealing with that's transformative enough, large enough that it could have been multiple projects, here are the three questions, looking back, that I would have asked. The first one is: do you deeply understand where the pain in today's experience is? Most of the time, as we look back at the experiences, we haven't done the work to deeply understand, using service design and rigorous research, what the end-to-end journey actually looks like. You have to understand what the pain points are to be able to decide what the thread to pull is. And if you don't have this readily available, then you need to spend the time.

[00:20:25] The second one is: do you have a primary avenue that works? For us that was the app. For you, that could be your product, a web experience, an app, a phone. There are multiple different ways to connect with customers. But for us, the reason the app was the primary avenue, versus our web portal, versus the phone, versus anything else, is that you're authenticated. It's in your pocket. We can reach out to you any time we want, so when it's async, we have a way to get back to you. We get your full attention, to some extent. It has a camera and video, so if it's a printer issue, we can quickly start debugging with you live. All these things don't necessarily exist in other avenues. So do you have the right primary avenue? If not, you may need to go and create it. You may need to start with "we don't have the right connection point with customers to even solve this problem."

[00:21:18] And then the last piece is: do you have a clear user cohort to start with? For us it was customers who had already used chat support. We had a group of customers who use Toast who had already had this experience, so we didn't have to start from scratch on behavior training. We had a relatively small cohort of customers that was significant enough, but small enough that we could do a lot of experimentation with that primary avenue before moving forward, and we only released to that cohort of customers initially. And, by the way, not just a cohort of customers, but a cohort of agents who knew how to do chat support and async chat support, who knew how to get back to an issue two, three, four hours later and still be connected to that customer and show empathy through writing, and all of these things that are important.

Toast Now, results and scaling the approach

[00:22:02] In support, again, we discovered the clear need for async support, thinking about what restaurants look like. We spent a year creating Toast Now, which is the app. I didn't go through that too much, but we realized we didn't have a primary avenue with customers where we could do this. So our first step was that we created a direct connection point, and we provided independent value so people would use it, so they could later use it for support. It became their in-their-pocket reporting app that they use all the time. So when we introduced support, it was a natural progression of how we connect with customers.

[00:22:35] And then we started with app users who had already used chat support, a cohort of customers who are engaged and have done this before, and who are ready for experimentation, because we're not changing their behavior at the same time that we're asking them to try a new thing. We've rolled this out, I think I can say that, to all customers recently, last week or so. We'd been testing this for a few months, and we rolled it out to all customers recently, and the response from customers has been awesome. Both customers and agents, by the way.

[00:23:09] We tracked a few metrics for this, but the two key metrics we track are customer satisfaction, which is much higher for this experience, and agent satisfaction. Are our agents happy? And it's much higher for this experience. This is the Holy Grail of a support experience: are agents happy, are customers happy? Because if you have one or the other, it's likely going to break eventually. It's managed complexity versus solved complexity.

[00:23:37] We're scaling this approach. We're going to use it for how we do onboarding, for how we connect directly with employees of the restaurant, which we're working on, and for how we connect directly with the guests of the restaurant. So all of these things: how do we pull the thread, and where do we start? What's the right thread to pull, if you have a challenge that you're thinking about? And I have 22 seconds to spare. Thank you.

Q&A

[00:24:05] Host: How are you? So nicely done. Thank you, man. It's kind of a mic drop on day one. I don't even know why I'm up here. In all seriousness, what you presented: roughly how long a period of time did that represent?

[00:24:26] Jehad: I would say 12 to 18 months, from the time we realized this is a really important problem for us to solve to the time when we rolled out to all customers. Lots of stages in between. For example, the app on its own has been immensely helpful for customers, regardless of whether it has support or not, but it has given us the opportunity to have a direct connection with customers and improve the experience there. Then with support we had to scale really carefully, so we were able to scale the number of agents with the number of customers, and scale the number of products we support using this experience with the different cohorts of customers that we had. So we scaled carefully across the board, but I would say 12 to 18 months.

[00:25:11] Host: 12 to 18 months from the initial brief to actual real production code.

[00:25:18] Jehad: Yeah, yeah. It's available to our customers today.

[00:25:19] Host: That's fantastic. And then how many developers were involved in that effort?

[00:25:25] Jehad: It depends. For the app, it's four to six. And then we have a small team of folks on the R&D side that's focused entirely on the support experience, maybe three to five people. And then, obviously, an awesome team on the care side that does the hard work of solving customer problems.

[00:25:49] Host: They're the PagerDuty.

[00:25:51] Jehad: Yeah, yeah. The customer-facing teams that are solving these problems on a daily basis.

[00:25:56] Host: So really, at the end of the day, what that does is enable somebody like Jehad to get up on this lovely stage and take credit for all of their work.

[00:26:06] Jehad: I have the privilege of representing the work of so many folks at Toast.

[00:26:12] Host: Nice privilege. Wonderful. Well, let's see here. We've got "Congrats." How did you reprioritize the team's work in the roadmap?

[00:26:21] Jehad: I'll answer for the app separately from support. For the app, it was a bet. We took a very small group of people, two to three people at the time, and we made a bet based on that vision: that if we do this, then we can transform multiple different things. And we had milestones for how far we'd go. We released very early with what we call customer advisory board customers, so 20 or 30 people who we work really closely with, and the team was literally on WhatsApp messages with these customers, so we were iterating every single day with them. Once we'd proven the traction with that group, it became much easier to say, okay, this is the right bet for us to make, and we scaled from there. And once we'd made that bet, it became a little bit easier to say, hey, we need to reprioritize some of the work of the customer success team to focus on this. The more you untangle, the more folks are interested in helping pull harder on the thread.

[00:27:18] Host: Absolutely. Keeping the metaphor going.

[00:27:20] Jehad: Yeah.

[00:27:22] Host: I like what you did there. And then, are you going to be able to keep the band together? Is this team moving on and taking on another large challenge in the business? What does that look like from a teaming perspective?

[00:27:35] Jehad: Yeah, we're taking what we've learned from this experience and applying it to multiple different areas of the business, onboarding as an example. We're taking the learnings we've had, especially on AI, and expanding them in a different direction on the product side as well. But that initial group of people remains working on this effort and related efforts.

[00:27:59] Host: With their matching jackets?

[00:28:02] Jehad: Yes, yes.

[00:28:05] Host: I'm assuming that's just part of the deal.

[00:28:08] Jehad: Of course. Yes.

[00:28:11] Host: Right. And then, were there moments when you had executives come in and flip the table or pound their fist and look for an initial finding, because they had made that capital investment?

[00:28:25] Jehad: Yeah, I think the hardest thing about this method is that it initially seems slower than putting 10 teams on 10 different problems and having them all go at the same time. One of the biggest things that teams struggle with is measuring outcomes over outputs, and productivity over activity. And there's a lot of activity in 10 teams working at the same time: the reports, the green and yellow and red. It just looks great. But the reality is they're not making as much progress in the long term.

[00:29:01] So the biggest piece here is finding the executive sponsor who can keep the focus on just continuing to pull the thread. Initially it's pretty slow. You have to understand the problem, you have to try a few things, you have to try it with a very small number of customers so you don't screw up the existing system, and so on. But the faster you pull, the more people realize, okay, this is working. So I would say, maybe for the first six months, being really stubborn on the vision and really flexible on the details matters.

[00:29:28] Host: Yeah. It doesn't sound stressful at all.

[00:29:30] Jehad: No, no, it's great.

[00:29:31] Host: Jehad, it's been a real pleasure. Thank you so much for sharing your knowledge. I appreciate it.

[00:29:38] Jehad: Thank you.