Date Published June 25, 2019 - Last Updated 3 Years, 355 Days, 13 Hours, 26 Minutes ago
HDI’s SPOCcast is your single point of contact podcast for service management and support insights. For Episode 16, I interviewed Jeff Toister about some hidden obstacles to good customer service, the importance of empathy, what causes broken systems, and other topics. Here are some excerpts, but I urge you to listen to the full podcast for more great insights.
Jeff, the subtitle of your latest book is
Overcoming the Hidden Obstacles to Outstanding Customer Service
. What are some of those obstacles, and why are they important?
JT: I want to start with, “Why are they important?” and the genesis is really that we’re always trying to get our employees to perform at a higher level. Yet, I know one of the top challenges for most customer service leaders and particularly in a support environment is, “How do I do that? Sometimes I see people performing beautifully, and other times I’m scratching my head. Why are they doing this? I know they can do better.” So, I really wanted to uncover some of those reasons.
Some examples of hidden obstacles:
One is attention. We know we need to pay careful attention to our customers to understand what they need and to serve them. But it turns out that it’s really hard to pay attention. So, as an example, we have a built-in instinct that shuts off our listening as soon as we hear a story that sounds a lot like that same story that we’ve heard a thousand times before. So, you think about your most experienced analysts: They hear somebody sharing a story and they instantly, instinctively stop listening because they think they know what the person’s about to say. And many times, they’re right, but a few times they’re not, and that creates a service failure.
Another is emotion. In service, the emotion is what drives what someone thinks about their experience. In a support environment, the number one emotion we’re trying to create for our end users or our customers is relief. “I had some sort of issue, and now I feel relief that it’s taken care of.” But the way we manage and even train people is through transactions. We have a troubleshooting procedure. We have a ticketing system. We have maybe a CRM (Customer Relationship Management) system and I need to log the information. Everything becomes really transactional. We drive the emotion out of it. I once had a support agent say to me, “You know, I get six minutes to solve this issue. I don’t have time to try to make them feel better. I just have to tell them what to do.”
In service, the emotion is what drives what someone thinks about their experience.
Another one that comes to mind is the metrics that we use to manage our service desk. A common one would be Service Level Agreements or SLAs. And if I feel pressure that I have to close so many tickets per hour or close tickets within a certain amount of time, I’m going to take some shortcuts because that’s what my boss is watching. But those shortcuts create problems in other areas. For example—one that a lot of us are familiar with—we close the ticket before the issue is resolved. And now the end user’s got to open up another ticket to continue getting that resolution. Well, my SLA looks fantastic, but my customers are upset.
So those are just a few of the hidden obstacles.
One of the troubling trends is that now we have and increasing array of software that gives our employees “real-time dashboards.” So, this is how many tickets you’ve closed. This is your average compared to the team. This is where you are on the leaderboard. This is how many you have in queue. This is how you did yesterday. And you’re looking at this dashboard, and whether or not the intention is there, it drives behavior. And a lot of times when we put these productivity stats in front of people, what happens is, they start unconsciously working faster.
I worked with a support team where…their average queue time was getting up to an hour because they had some pretty bad support issues. But half of that queue time—30 minutes—was related to them going too fast through contacts, and not looking for that next issue avoidance. And they were able to change just a few behaviors to spend more time with each person, and not focus on the queue, and they cut their average queue from an hour to 30 minutes. Still not good, absolutely, but they were generating half of that volume.
RA: Whenever I talk to any group, I ask, “What qualities are important for customer service?” Empathy always bubbles to the top of the list. Why is it so important… and can it also be counterproductive in customer service interactions?
You know, I was thinking about empathy the other day because I think a lot of people get confused about what is empathy and what isn’t…. Empathy is the ability to understand what the other person is feeling…. I don’t see any situation where it’s counterproductive. If I understand what you’re feeling, I can serve you better almost every time…. It gets confused with sympathy, which is “I agree with how you feel, and I think you’re absolutely right to feel that way.” That can be counterproductive, because we know that sometimes customers do things to hurt themselves, or they make poor decisions, or they just do dumb things. We don’t want to tell them that; we want to help them be right. But if a customer is really angry about something and we start sympathizing with them, then we might be making it harder to actually help them. So that might be where it’s counterproductive.
RA: You talk [in your book] a little bit about the systems that exist within organizations…. Sometimes those organizational systems become broken. What are some of the ways to fix them—because we don’t want to catch people—while they’re doing service—we don’t want to catch either the customer or the representative in the middle of a broken system.
JT: I think the answer to that question is understanding why systems get broken in the first place, and if you understand what leads to broken systems, you can either prevent them or you understand the solution. I’ll just give you a few examples.
One is—and I’m sure there’s a technical term for this—where we start adding multiple systems to handle different problems—is it technical debt? [Roy confirms.] So that’s one great example where, if we look at how companies budget these types of investments, they’re usually in a capital expenditure (CapEx) budget, and once I spend that money, I want to get a return on that investment even if some new technology or some sort of new workflow presents itself, where that system’s no longer ideal. So just the way companies budget these systems, they often are more willing to just kind of piecemeal it; and the challenge is we know how much we’re spending on these different systems, but we don’t have a real good handle on how many problems having these multiple hodge-podge systems are creating. So, better accounting is kind of one solution to that problem—being able to quantify the financial impact of having these multiple systems.
Another example is just growth. So, as a company grows, you have one, maybe an in-house system you’re using to support your end users, your customers, and then as you grow you need something different. I worked with a support team where the person who handled the most tickets was the boss. And that’s great if you have a two-person support team. But if you have 10 or 20 or 30, that’s no good at all. But the boss wasn’t able to be the boss because she was mired in the trenches with these really outdated systems—outdated in terms of not being designed for the kind of volume they were getting.
And I’ll give you another one. Sometimes a corporate policy or approach is designed to solve one problem and it creates another. A good example of that would be Agile, where, especially in a software company…kind of the brief primer is, “We’re not going to wait until we’re perfect, we’re going to release an update to the software that’s an iterative improvement, and then we’re going to kind of keep working on those iterations.” Well there’s a lot of productivity to be gained with that. But what happens from a support standpoint is I’m constantly updating software that’s creating disruptions in workflow for my end users and if there’s a change, I’m also constantly asking my end users to relearn how to do things and all of those generate in some cases a massive amount of unwanted and unnecessary support volume. So, that Agile policy seemed like it was a good way to get things done faster, yet the back end’s where we create a lot more problems than we had before.
So, understanding what is causing these systems to be broken in the first place is often the key to finding a way to fix them.
About Jeff Toister
Jeff Toister is the author of three customer service books including Getting Service Right: Overcoming the Hidden Obstacles to Outstanding Customer Service. More than 140,000 people on six continents have taken one of his training programs on LinkedIn Learning (a.k.a. Lynda.com). Jeff is a member of ICMI's Top 50 Contact Center Thought Leaders on Twitter and a Global Gurus Top 30 worldwide customer service professional. Feedspot has named his Inside Customer Service blog one of the top 50 customer service blogs on the planet. Jeff is passionate about training and is a Certified Professional in Learning and Performance. Follow Jeff on Twitter @toister.
Roy Atkinson is one of the top influencers in the service and support industry. His blogs, presentations, research reports, white papers, keynotes, and webinars have gained him an international reputation. In his role as senior writer/analyst, he acts as HDI's in-house subject matter expert, bringing his years of experience to the community. He holds a master’s certificate in advanced management strategy from Tulane University’s Freeman School of Business, and he is a certified HDI Support Center Manager. Follow him on Twitter @RoyAtkinson.