Your Call is (Not That) Important to Us

Emily Yellin's Your Call is (Not That) Important To Us is a fast, fun read about the customer service/call center business, with a little bit of IVR thrown in. The book does well when it describes the history of customer service. There are some insights into companies that try very hard to get it right, like FedEx and Zappos and Jet Blue. It doesn't do as well with the speech IVR material. She grants too much credibility to fringe players like the MIT profs who want to create "emotional" computers and the companies pushing interactive avatars.

One of the central observations in the book is that customer service doesn't occupy a very high place in the list of priorities at most companies. This I've seen many times in the companies I've worked for or consulted with. Personally, I'd love to work at a company that decides at the highest levels that customer service is a top priority. The challenges of getting customer service right are very hard, even with a lot of support from executives. Without that support, it's impossible.

The "automated lady" isn't helping

This CNN article describes the frustration of homeowners who reach a recorded message when they call banks regarding foreclosure. I cringed at the homeowner's exasperation with the "automated lady," because I know how frustrating the situation is. The callers need to talk to a person but the banks are using a simple IVR to keep customers away rather than using the IVR to serve them. I can just imagine the chipper "automated lady" persona starting her greeting with pain-enducing phrase "Your call is important to us..."

The banks have resorted to a conventional solution to an unprecedented situation - play a recorded message and drop the callers into a queue. I understand that the number of calls and average call times are overwhelming the call centers, but there are much better uses of the technology. For example, you can use automated call backs to let the customers go about their business rather than forcing them to stay on the line.

There's really a huge opportunity here for an IVR integration company to help banks, if they can get into the banks and talk to managers about solutions. If anyone in an overworked bank call center wants to find a way to make their IVR help with their workload, contact me.

Design anti-patterns: Which Pot of Money?

This is one of the most pernicious problems in organizations. Decision making is often twisted by a single question that stakeholders apply to possible solutions: which pot of money is this coming out of?

To illustrate: I worked on a program to implement desktop applications in the call center of a financial services organization. One business was handed a large pot of money with these words: "Spend this pot of money for your call center. You can run as many projects as you like, but after the pot is empty you must pay for new projects from your own budget. The IT department is at your disposal. Defects or routine maintenance that are required after the applications go in comes from their budget."

The business unit, naturally, wanted to get the maximum amount of functionality onto the desktop as they could before the pot of money was empty, so they opened new projects as fast as they could write the statements of work--at one point the projects kept 15 project managers busy. The B.U. whipped the IT project managers to get the applications released as quickly as possible, secure in the knowledge that money to fix defects wouldn't come out of their budget, but the IT department's. Many PMs were happy to comply, since their performance was evaluated in part based on the number of projects they completed. Post production, requests for new functionality were disguised as "defects" and "routine maintenance," and handed to an overworked non-project service area within IT to implement. It was chaotic.

Of course, there were other considerations the B.U. had for getting applications released quickly. There was a schedule by which it was supposed to earn a profit, for example, and it needed the functionality on the CSRs desktop in order to deliver service to customers. In fact, that was a regular reason given for needing projects done so quickly. But the Which Pot of Money consideration was always there, like an unacknowledged whale shark in a swimming pool.

Remarks on The Best Service Is No Service

The Best Service is No Service (2008) by Bill Price and David Jaffe is a wonderful book about how to improve customer service. Their ideas are simple in concept but difficult to implement properly. The idea is this. If companies understand why customers contact them they should be able to identify "triggers" for inbound contacts. If companies proactively contact their customers with information that customers want then they should be able to eliminate a large proportion of inbound contacts.

Most of the book gives solid advice on how to implement this seemingly simple idea. It also points out some of the difficulties that companies will encounter, one being that the business area that is catching all the incoming flak - the customer service area - has little organizational pull in getting effective incoming contact mitigation implemented.

I work at the IVR and contact center end of customer service, and I can vouch for the fact that a lot of incoming calls could be prevented simply by communicating more effectively with customers - giving them information they need before they call and ask. Companies are just dying for design approachs to customer service, and this book is a good place to start.

CSRs as system integrators

I've written sympathetically about customer service representatives (CSR) in the past. They have a tough job. While trying to serve customers they often have to use multiple software systems, all with a different look-and-feel to the interfaces. Worse, the systems often can't talk to one another, so CSRs spend a lot of time retyping or copy-and-pasting identifying information from one interface to another in order to pull customer records. In this sense, the CSRs are system integrators, often doing repetitive data entry tasks that a well-integrated system would be able to do without human intervention.

So why not furnish the CSRs with well integrated systems that allow them to focus on customers' needs instead of repetitive data entry tasks? One reason is that a lot of new stuff gets thrown at CSRs very quickly. A new system to support a new service gets dropped on their desktop, they take a little training, and the calls start to roll in. Other services get dropped. System integration takes time, and even in the best circumstances would run well behind service changes in the call center.

Another reason is that call center directors would like to spend the money elsewhere, namely, on self service IVR applications that would allow the company to serve customers without speaking to CSRs. That's good for people like me, who design self service IVRs, not as good for the CSRs who are stuck with unintegrated systems.

It's important to keep in mind, though, that employee satisfaction is a major driver of customer satisfaction. Happy CSRs produce happy customers. Something to consider when planning upgrades to call center technology.

"Thank you for calling the Therapy Hotline..."

What do you think when you read a story about psychotherapy delivered over the phone? A room full of customer service representatives in small cubicles staring at monitors and helping callers with their problems? "You say you had a dream about your high school math teacher, a dragon, and a small dark room? Hold on while I access that information..." It's not necessarily like that. Some companies operate virtual call centers with high priced financial advisors or M.D.s working from their own offices, delivering professional advice while building relationships with the callers.

The history of automated therapy goes back to Weizenbaum's Eliza program in 1965. If phone service therapy catches on it won't be long before someone tries to save a little money by implementing an IVR to take the routine therapy questions. "For dream interpretation, press 1. For a pep talk, press 2. All other calls, press zero or remain on the line." Better yet, therapists could set up shop in Second Life so they could meet their clients "face to face."

IBM speech recognition

IBM has been working on speech recognition for a long time. Still, they've never gained traction with their speech engine in a market dominated by Nuance and its predecessors. This recent article in BusinessWeek about their appearance at SpeechTek 2008 reminded me that they're still there, looking for a market for what may be some pretty good technology.

It's kind of a mystery to me why IBM hasn't made much of an impact on the speech industry. IBM isn't the first company you think of for call center applications, but the engine is available on Avaya's platform. So I don't get it. Any ideas, let me know.

Alligator in the kitchen

The Holy Grail for IVR designers is a natural language application that can handle a significant percentage of calls to a service desk. 911 call centers are a kind of mission-critical service desk: you call with your problem and address and hope that help arrives before things get much worse. In order to get natural language to work you'd need to anticipate what callers will say when they call (or at least have categorized a number of previously recorded similar calls).

Unfortunately, there is just no way a VUI designer is going to craft a system that will recognize "alligator in my kitchen" as a legitimate problem call. Even human 911 operators have difficulty with the phrase, as you can hear in this recording.

Innovation by "The Chosen Few"

Years ago, as I was documenting work processes in my first big call center project, I made what I thought was an astounding discovery. The experienced call center reps I interviewed had some very good ideas for improving their customer service process. They were having to work around some of the constraints of their IT systems in order to deliver service, and often working around the processes they were given by their managers. When I talked to management about the CSRs processes they were surprised to hear some of my findings. Second astounding discovery: managers don't always know their experienced CSRs' best practices. I recall thinking, "these reps really know their business. If someone could organize their ideas and get them pushed through IT and their own management it would really improve service."

Some years later the organization went through a period of identifying and selecting "innovators" whose role it was to produce innovative ideas and pass them to the rest of the organization. Watching the "innovators" from a distance, it was hard to see that anything was of any more value than the ideas produced by my CSRs in the call center, and most of it was probably a good deal less.

Jack & Suzy Welch's recent BusinessWeek article, Finding Innovation Where it Lives, hits the very point that I thought I'd discovered during my first call center gig. The article may be behind a password, so I'll quote the relevant parts. They debunk the notion that innovations come strictly from individual geniuses working alone, but more often come from coworkers "in the trenches" solving problems as a group and trying to make things work well. However, the organization has to make innovation part of its culture. As I saw in the call center, having great ideas means nothing if no one is there to harvest the ideas and push through changes.

The Welches finish by quoting an e-mail they received from someone who had an idea for a product but didn't know how to introduce it into his organization. They write, "How sad...another place where managers send the message that innovation comes from the chosen few. Imagine the possibilities...not to mention the fun, when organizations engage everyone else in the process, too."

That's innovation management, the ability to change the organization and draw everyone into the challenge of improving services and create processes that harvest and organize everyone's ideas, not just those of the "chosen few."

GetHuman in the news

The GetHuman standard for call center customer service were covered in a recent BusinessWeek story. The gist of the story was that the GetHuman "movement" has lost steam, and gave some reasons why.

There's no doubt that customer service should be a top priority for companies, and that automated phone attendants are a frequent source of poor service. The GetHuman standard falls short because a company's call center needs to commit to a far higher level of service than is embodied by the standards. Companies that are committed to good service don't need the GetHuman standards; they have managers in charge who understand where the company needs to be and the amount work it will take to get it there. Companies whose call center managers think they can offer quality service by following a checklist are lost in the woods, and won't find their way out without some serious help.

I think standards and guidelines have their place in promoting good design practice if followed properly; I've said so before. I give GetHuman a lot of credit for raising the issue of poor customer phone service. However, standards can only take one so far; delivering great service is a matter of a company's planning, desire, and execution.

Tricking the caller to stay in the IVR

I don't think I've worked on an IVR project when the business people didn't suggest using "tricks" to keep callers in the system. You know what I mean by tricks: disabling the zero key, or playing a routing menu when zero is pressed, or using a non-zero key for transfers, messages that falsely state long queue times, or putting the caller back in the system after they request a transfer. Often the tricks are used in IVRs that are pure misery to try to use. Businesses have a reason to try to increase automation rates - it saves them money. The best way to increase automation rates is to ensure that your automation is useful and usable to your customers. Unfortunately, getting your IVR to that point takes a lot of work, and keep-'em-in tricks are simple to implement. Some business folks take the easy path, and insist on tricks.

The tricks almost never work, or don't work the way the owners intend them to work. If a caller really wants to talk to a representative they'll figure out a way to do it. Eventually. And once they get to a real CSR after they've been plagued by IVR tricks they often aren't very happy. I listen to a lot of calls between customers and IVRs and then follow the calls into the call center. Some customers remain calm with the CSR after a poor experience in the IVR. Others do not, and take out their frustration on the CSR. No one goes away thinking better of a company after a miserable IVR experience.

My recommendation to companies considering using tricks to keep customers in the automation: work on the quality of your IVR first. Monitor, survey, read the reports, improve. Once you're satisfied that the IVR operates flawlessly you can consider using some small inducements (a nice way of saying a subtle trick) to keep callers in the IVR. If it's done properly you might be able to increase your automation rate slightly with no cost to the user experience. However, it all depends on first getting the IVR right. Do the hard stuff first, worry about the tricks later.

IVRs aren't your company's biggest problem

It's easy to blame IVRs for a lot of your company's customer service problems. Because it's true-sometimes the IVR just isn't very well designed. A lot of times, though, it helps to look past the IVR into business practices.

Here's an opinion piece that takes issue with a Gethuman recommendation to send callers to a live CSR if one is available. The author of the article points out correctly that there's value to companies in identifying high value customers, and giving them preferred service. However, you can still prioritize customers without violating the Gethuman principle he identifies.

I have other problems with the Gethuman principle, and with the author's unstated assumption in the article. Both assume that IVR contacts are necessarily bad, or at least worse than a interaction with a human. For simple interactions that involve call transfers, account balances, password resets and so on, there's no reason why the IVR interaction should be less satisfying than one with a CSR. Better, in fact, if you add a little time in queue to reach a CSR. The fact that many IVRs give such poor service even for simple requests is due to failures of design and implementation, not to a limitation of the technology itself. You can serve simple requests from high value customers using IVR just as well as with CSRs if your IVR is well done.

The author identifies IVR as the culprit for poor customer service. In many cases, that's true, the IVR is poorly designed. The other, harder problem is that many companies are bad at identifying high value customers, and in defining what it means to provide high level service. What good does it do to get a caller to a CSR who mumbles, can't find information, doesn't recognize opportunities to provide additional service, doesn't answer the unasked question, and so on? Those problems aren't solved with even the best IVR.

The upshot of this is that IVR designers need to be able to see the big picture, and understand what problems the business is trying to solve. If they can't do that, they'll wind up spending a lot of time designing IVRs that don't address real issues.

Happy Labor Day

I celebrated Labor Day today, like many others, by staying home and getting some chores done. But I wasn't completely oblivious to the significance of the day. I thought about what I do and its significance to peoples work lives.

Sometimes I'm asked if automated phone systems are costing people their jobs. That's a fair question, because some businesses that put in automation do so only with the misguided goal of saving money by cutting a lot of CSRs. I don't think it costs jobs in the US, and in fact I think IVRs that are implemented correctly make CSRs' jobs more enjoyable. I've done analysis in enough call centers to know that one of the the biggest problems call centers face is turnover: keeping experienced CSRs in their seats.

CSRs have a tough job. They work with difficult software systems to serve customers who are sometimes abusive. They are constantly monitored by supervisors and QA analysts. The pay isn't that great. Career paths aren't that attractive. And, depending on the call center, a high proportion of the calls are mind-numbingly simple and tedious: password resets, transfers to another department, account balances, "did you receive my check/paperwork/order yet?" types of questions, and so on. People who don't find satisfaction with their jobs tend to move on, and there isn't a great deal of satisfaction in resetting passwords day after day.

It's that last category of call that needs to be automated properly - the simple, repetitive requests that can occupy a large proportion of a CSRs day. Keeping all of the simple questions away from the CSRs would allow them to spend all of their time on questions that require thought and expertise. Of course, the call center managers need to do their part and provide the sort of training that allows CSRs to deliver real value and properly reward those who do.

So I'll go on thinking that I'm doing my little part for the gallant CSRs who work in our call centers until someone sets me straight.