The Story of Hudson, Part II

I knew that I didn’t want Hudson to be like a typical call center. I wanted to be customer centric, making our reputation and profits based on how much we helped customers and exceeded their expectations.

When I started Hudson and took the first tech support account, I didn’t intend to be in the “call center” business. I didn’t know anything about running a call center. I simply knew that people had problems that they needed help with, and that whoever answered the phone had to solve the problem and communicate well. I knew I could do both of those tasks.

So I naively set off to turn myself into a tech support company. I spent six months answering phone calls and emails from customers. Volume was low in those days, so I had time to think between calls, and I spent time researching and developing software and procedures for recording the details of calls and reporting to publishers.

After six months of being chained to the phone, I was pretty sure I was ready to hire an employee and tell them what to do: how to speak to the customers, how to solve problems for the one product we mostly supported, and how to keep records. The question then was: who should I hire?

Before we start talking about some of the characteristics of a great employee, I need to tell you something about my first client, a large college textbook publisher, and her philosophy about the importance of making customers happy. I told the story in the blog entry The Story of Hudson, Part I, describing how I took over support from a bunch of programmers who rarely thought there was a problem with their product! Also, even when they would admit a problem, they were always in a hurry to give the customer the answer and to quickly get off the phone.

My client, on the other hand, wanted every customer to be happy, and for us to go whatever lengths necessary to make this happen!

In this day and age of cost-cutting and downsizing, that might sound like a crazy philosophy. But it made sense to the publisher. At that time, many of the software products we supported were given away free, to support the sale of the educational textbooks to the student. All the money was made by selling textbooks, and everything else was just seen as a marketing or support cost toward that goal.

(In the educational market today, more and more of the textbooks are actually online, but access to the online textbooks is still sold to the students. Software is still given away to the instructors, but the students pay for all the components they need for their class).

At that time, there were many more inexperienced users, and software in general was more complicated and less intuitive. Operating systems were less visual and helpful. So there were bound to be many users who needed extensive hand-holding. I worried about whether my client would object to paying for these long calls. But my client reminded me that each professor who adopted their book meant many sales to many students over many years. If a professor got unhappy because they didn’t understand the software, or he had too many complaints from students or his assistants who had trouble with the software, then he might consider using a different textbook.

So from the very first days, I learned to focus on a high level of service for our goals. It wasn’t enough to solve the customer’s problem in a polite and efficient manner. To make people actually happy took something more! After all, the software had either confused them or hadn’t worked properly. Somehow we had to reverse the initial bad experience, so that the result of the call went beyond the customer’s initial expectations.

Even today, where every client is much more cost conscious than my original publishing clients, this philosophy is still important, because of social media. An unhappy customer now has many places to post his opinion about your software and service. Even if you never expect further revenue from an individual customer, they can have a profound effect on your future sales!

Of course, we had to learn to modify and adjust our philosophy for each new client, some of whom had much less of a future revenue stream for each customer. But we stuck with the idea that when in doubt, we should err on the side of making unhappy customers happy by exceeding their expectations.

We wouldn’t measure success by statistics; we would measure agents by the quality of their calls, and their effect on the customers.

As we took “exceeding expectations” and “no unhappy customers” as our operating practice, I simultaneously began to learn about the call center industry, both for technical support and customer service. I quickly learned that “no unhappy customers” was not how the call industry was organized! Most call centers were focused around getting agents to follow a script for efficiency and get off the phone as quickly as possible, either solving the problem with the script or escalating the problems.

The call centers were focused on measuring agents’ statistics, such as Time to Resolution (TTR). TTR simply means the time the agent took to resolve the problem). If an agent has a higher than average TTR, that agent was considered to be in trouble, and possibly a candidate for re-training, or even termination. Long calls or a significantly longer call average than the standard was a big red mark against the agent. Agents were even given extra compensation for meeting these statistical standards.

To be fair, most of these call centers had high volumes, with dedicated agents. If they had external clients, their clients had only committed to paying for so many agents, and they had imposed service agreements on the call center such as “90% of all callers should wait three minutes or less… Or “the average TTR should be 7.5 minutes,“ with penalties for not maintaining these standards. So every second counted! Internal call centers were regarded as cost centers, with little focus on the customer experience. Minimizing costs was usually the primary goal.

I knew that I didn’t want Hudson to be like a typical call center. I wanted to be customer centric, making our reputation and profits based on how much we helped customers and exceeded their expectations. I was certain that great customer service and tech support would lead to more successful clients, with better customer retention. So we wouldn’t measure success by statistics; we would measure agents by the quality of their calls, and their effect on the customers.

Once a problem becomes routine, people who self-describe as “technical” don’t take satisfaction in explaining the same solution to people over and over again.

As I began to hire and evaluate job candidates, I quickly learned a second thing about call center employees. I looked at resumes of call center employees, and looked at what call centers said about their technical support agents on their websites. Call center agents for technical support were predominantly technical people. They were required to have technical credentials and to pass technical exams.

But as far as I could tell, there were very few tests for the ability of the agent to communicate with the customer. It was assumed that if you could solve the problem, you just needed to tell the customer what the solution was. I didn’t think it was that simple; good communication rarely is! It seemed to me that the management of call centers overestimated the technical part of the job, and underestimated the communication and support requirements.

Through experience, I also learned that hiring technical people for tech support didn’t give me either the best or the most stable employees! People who are technically oriented and like to solve problems get bored explaining the same problem over and over again to people. As the song says, “The Thrill is Gone!” Once a problem becomes routine, people who self-describe as “technical” don’t take satisfaction in explaining the same solution to people over and over again. The more the person identifies themselves as a “technical” person, the less suited they are for the day to day task of helping people overcome a known technical problem.

With our first few employees (and a few mistakes to learn from), the picture of the typical Hudson technical support agent began to be clear.

1. We learned that technical certifications or credentials weren’t important.We had no objections to technical credentials, but they proved to be a poor predictor of success. No matter what the candidate’s background, we tested their problem solving ability.

2. When evaluating people’s interview results, give more weight to communication skills than to technical skills.Notice that I didn’t say “give no weight” or “ignore” their technical skills. Technical support agents have to understand computers, how software works, and generally have a good model in their heads about the sort of things that go wrong with software and how to fix them. What we came to understand was that we could train technically capable candidates to solve problems for a particular account or product, but that is was very hard, if not impossible, to get a big improvement in most people’s communication skills.

So as the successful employees came and stayed, the profile of the successful Hudson agents began to emerge. They tended to be self-taught and were computer enthusiasts. They loved computers and had learned to solve their own computer problems. Other people went to them for help with their computer problems. They didn’t mind that the problem was routine, because they liked helping people. If in addition to their problem solving skills, they were good communicators, then they were good candidates for Hudson agents.

So we started with these self-taught enthusiasts who like helping people, and focused on teaching them how to problem-solve efficiently. The results were great. We had no shortage of happy notes and calls from customers who had been helped and whose expectations had been exceeded.