I went out to dinner last night to a place I’ve gone hundreds of times, and I ordered a salad that I’ve ordered many times before. The salad wasn’t as good as it’s been in the past: the lettuce was old, and the dressing was watery. When the waitress asked her usual question, “How is everything?,” I politely told her the truth. Her reaction is one that I’ve seen many times in interactions between service people and customers. She responded as if I had said something entirely inappropriate, and she acted like she wanted to get away from me as fast as possible.
Of course, that’s not the way it’s supposed to be. The waitress is supposed to focus on the customer, listen carefully, make apologies, discuss what should be done about the problem, and perhaps offer alternatives. The waitress should bring the incident to the attention of her manager and the appropriate chef. Then the waitress is supposed to remember the incident for at least the duration of the meal, make an apology again at the end of the meal, and perhaps (depending on the incident and the restaurant) offer some form of compensation at the end: maybe a free dessert or a reduction in the bill.
“How is everything?”
So far you probably agree with me. But let’s shift the scene to the interaction between an IT person and her customer. The first difference you’ll see is that the IT person rarely asks, “How is everything?” Most IT people are so strapped for time that they can’t seem to accomplish the tasks they’ve been given. They rarely take the time to converse with customers, and they seldom ask a customer how he or she feels about a system unless the conversation is an explicit part of a systems analysis task.
So if an IT person hears a complaint, it’s probably because the customer feels strongly enough about the problem to make a special effort to raise an issue. That’s bad for three reasons:
- By the time the customer makes the complaint, there is a large amount of frustration and anger. Interaction with IT is strained, and the customer wants an immediate solution to a problem that probably doesn’t have a quick solution.
- Many problems and complaints will remain unvoiced. Some customers will just silently tolerate poor systems, poor processes and poor service. They’ll never complain to IT directly, but they’ll build up a lot of resentment toward the IT organization, and they’ll complain to their co-workers and friends. To them, IT will become the enemy, and you’ll never know it until it’s too late.
- Resentment builds in the IT organization as well. The IT people hear only negative comments, so they form a very one-sided view of the customer. Through IT’s eyes, a customer becomes someone who complains.
Listening and Apologizing
Let’s move on to the next step in the waitress example. There are two things that should go on in a problem discussion between a waitress and a customer: listening and apologizing. Through listening, the waitress should get an understanding of what the problem is, and how the problem impacts the customer. And in apologizing, the waitress should convey two messages: (a) that’s not how things should be, and (b) steps will be taken to make things better.
Looking at a typical interaction between IT and a customer, we see that listening usually takes place but apologizing seldom does. And the listening, particularly in help desks, often takes the form of just listening long enough to categorize the problem into something that’s been seen before. Once the categorization has been done (whether right or wrong), then listening stops.
Why don’t we get apologies in IT? Perhaps it’s because we don’t understand what an apology is. An apology is not an admission of guilt, nor is it an acceptance of personal liability. It is instead a way of connecting to the customer on a human level, letting the customer know that you can relate to the pain they’re experiencing, and that you truly want to make the pain go away.
Once the problem is understood and apologies have been made, we move on to the next step: problem resolution. Sometimes the resolution of a problem is an explanation instead of a solution. We don’t see this much in restaurants, but we see it a lot in IT help desks. Someone calls in with a problem (e.g., “All the text in my document is double-spaced.”), and we tell the customer how to use the system differently to achieve the desired result (e.g., “Use the ‘Format Paragraph’ menu option to change the line spacing.”). In IT organizations, we tend to view this type of call as an annoyance, but there is a real underlying problem (e.g., “the system is too complicated, and system help isn’t sufficient”) that could be solved if we devoted the time and energy to solve it. That’s why call tracking is so important for IT help desks: to determine the most common calls so that we can focus our efforts on solving the most common problems.
Ok, but what about problems that can’t be resolved with an explanation? In a restaurant or a small company, the processes are simple, and it’s easy to notify the right people about the problem. Whether they solve the problem or not depends on their own attitude, dedication, and resource availability. The key here is to avoid blaming people, and to instead look for a way to change processes to make things better.
Our last step in the restaurant example is to follow-up with the customers. The follow-up has two goals:
- Convince the customers that you care about them, that you care about solving their problems, and that you’ll take steps toward appropriate solutions.
- Make the customers feel better about the restaurant so that they will return.
How often do you follow-up on a help desk call to make sure that the problem is resolved? How often do you follow-up on a customer complaint to see if the customer is happy? In IT organizations we tend to neglect the follow-up because of resource constraints and because, frankly, the customer has no place else to go. But in neglecting this step, we’re doing a huge disservice to ourselves and our customers. Providing follow-up makes the customer feel better; it makes the IT person feel better (especially if the customer is pleased); and it gives us an opportunity to identify situations where an inappropriate solution has been applied, so that we can apply a better solution.
Here’s what we can learn from the waitress example:
- Plan for informal interaction between IT people and their customers. Give the IT people time to ask “How is everything?” and to really listen to the answer. If you do this well, then small problems can be resolved before they develop into big problems. You’ll occasionally hear praise, which is a huge morale booster. And most important, you’ll develop a better relationship between your IT organization and their non-IT customers.
- Teach your people to really listen – not just categorize complaints. Categorization can still occur where it’s necessary, but it should happen after the listening.
- Teach your people how to apologize, remembering the two messages in the apology: (a) that’s not how things should be, and (b) steps will be taken to make things better. Make sure that everyone understands that you can apologize for something without accepting personal blame for it, and without blaming anyone else.
- In resolving problems, look for process issues instead of blame. Even if it’s someone’s “fault,” the person made the mistake because of the process that was taught or because of the reward structure that provided the motivation.
- Don’t ignore problems which can be resolved through explanation. If enough people need an explanation, then there’s an underlying problem that ought to be corrected.
- Have a specific process that ensures follow-up on all problems (or a random subset if resource constraints prevent full follow-up). If a problem isn’t resolved, then restart the problem-solving process.
I started by discussing a common situation in a restaurant which was handled badly, and I drew parallels to the relationship between an IT organization and its customers. I can make allowances for an occasional waitress lapse in a lower-priced restaurant, but in a higher-priced restaurant I wouldn’t tolerate this sort of behavior. Don’t our IT customers deserve to be treated at least as well as customers in a higher-priced restaurant?