About a year ago, I left a job as a Director of Client Services and began interviewing at other firms. I had a great interview with a firm that I’ll call Company Y. After the interview, I wrote up a little essay describing my thoughts on the scalability, people, and operation of a client/customer service team. I hope you’ll find it useful and share your comments and feedback.

Scalability

A support department’s capacity to support work volume is based upon three factors: headcount, process, and supporting technology/tools.In its infancy, the support department gains volume by adding headcount. A department can reliably scale from one to two or three agents. Beyond three or four agents, however, inefficiencies begin to mount and dwarf the marginal gains from adding additional employees. For instance, two or three employees communicate easily about the state of the product and client base. Four or more employees can’t communicate nearly as well.

At this point, adding clearly defined standard operating procedures usually provide more productivity than adding additional employees. We can start this process by identifying and building upon the informal processes that the team and employees found useful. For instance, our team at Company X found notes on client accounts to be extremely helpful. As a result, we added a “you must add a note to a client’s account every time you touch it” to our list of standard processes.

At Company X, we found the most and least efficient parts of our workflow and built scripts and flows that helped employees cover their bases. In addition, we actively involved the team in defining and documenting the processes, giving them a strong sense of participation and ownership. This gave us a chance to reiterate that the processes were being developed to help the team thrive. We also had a chance to let our talented employees capitalize upon their strengths and take a break from the usual routine.

One of the most frustrating parts of developing processes is that the tools to support those best practices often come much later, if at all. Much of the work that the account managers did on a daily basis at Company X was significantly more manual than ideal. This is a source of risk, because if a company adds too many processes and “rubber-stamp” operations without giving employees effective tools, they begin to feel burnt-out and limited. They could feel like mere cogs in a machine because much of their work was simple and repetitive when it could have been automated.

Here’s an example at Company X. First, we established that retaining existing clients was substantially more cost-effective than trying to obtain new clients. So, we brainstormed on ways of retaining our client base. A member of our technical team suggested that we regularly audit each client account so that we could see how well they were using the software and make proactive suggestions.

We put this process into place. A successful audit could take 20-30 minutes: the account manager needed to log into each account and manually review every aspect of the account. Were the client’s users logging in on a regular basis? Create a custom report and find out. Are they using these reports effectively? Look at the page view reports.

Needless to say, this was a time-consuming process and we had limited bandwidth to get the job done. However, it also served an important function; we were able to suffer through the high cost of the process and ultimately determine that it was worth using. We also better understood how our customers used our software and learned of improvements we could make to our documentation and training processes.

Based on the work we did manually evaluating accounts, we were able to develop a utilization metrics system that helped us automatically quantify a client’s use and success with the software. Since the tool was automated, we could quantifiably track customer “satisfaction” over the course of time and even trigger early alerts about major changes in client engagement. We could even sort clients in our administrative interface by level of engagement, making it much easier to triage the clients who were in good shape, hurting but salvageable, or lost. As a team, we moved from need to process to sustaining technology.

Processes are never stagnant – as the landscape changes and additional staff join the team, we need to continually improve upon our modes of operation. However, we will come to a point where the baseline components of our process are stable enough for us to begin developing project requirements and ultimately tools.

There’s a balance of risks – on the one hand, you risk frustrating the team with time-consuming and repetitive processes that could be automated. On the other, you risk spending a good deal of time and money developing or purchasing the right solution to the wrong problem.

These days, I’m more inclined to use open-source or commercial products rather than trying to develop process-supporting tools. My litmus test is simple – do not reinvent the wheel. We would not create our own email server software, but we might integrate Exchange with our application.

There are two components to most process-related technology: general fundamentals (such as allowing a client to interact with a ticket-management system via email and a web interface) and specific adjustments or integrations with existing systems. I’ve found that many of the fundamentals are a) solved dozens of times by other people, and b) contain lots of “devilish details” that make developing your own version more difficult. Most of the time involved in getting two systems to communicate well is in developing an API for each system. Many off-the-shelf solutions include APIs for common tasks, so we need only attach our current software for the existing API.

At Company X, I found that we tried to develop our own tools when we should have purchased off-the-shelf solutions. We often had very limited tools that were tightly integrated with our system. The tools were fairly efficient (we didn’t have to enter data in more than one place very often) but they weren’t particularly helpful, either.

For Company Y, I’d likely recommend an off-the-shelf CRM tool such as RightNow. This gives us early wins (we can start tracking clients, tickets, and custom development more effectively), and we can add tighter integration with our existing back-end systems as we have time.

People

In our discussion together, I identified the best technical support employees as having the following characteristics:

* Early-career (relatively junior employees)
* Naturally gifted problem solvers who enjoy “digging into problems”
* “In touch” with the client base and their overall satisfaction levels, able to spot early problem trends

I also described ideal account managers as being:

* Naturally empathetic to their customers’ needs
* Effective, college-educated communicators
* Able to defuse upset customers

The wrong environment can make these employees feel “crazy,” overworked, and under-valued. Here’s a recipe for failure:

* Under-staff the department.
* Develop processes and procedures without employee input and fail to provide adequate supporting tools.
* Fail to provide adequate problem-resolution tools and resources.
* Fail to effectively respond to early-warning indicators described by the support team.
* Create an “us vs. them” relationship between the customer-care team and the rest of the company.

Conversely, a recipe for success:

* Staff the department appropriately given the workload and tools available. If possible, anticipate staffing needs 1-2 months in advance so that new employees can get up to speed; it’s difficult for new employees if the best trainers (their coworkers) are buried under a mountain of work. Thankfully, a team can tolerate understaffing as additional employees are hired and processes and tools are developed, but the shortage cannot be chronic.
* Use collaborative process mapping techniques to document and understand how employees use tools and go about their work. Follow-up by leading the team in converting the process map into a design map that addresses inefficiencies and waste in the current process, then follow up by actually implementing new processes and tools.
* Provide adequate tools for diagnosing and resolving problems. Ensure that other departments have a faster SLA to the support team than the support team has to the client.
* Evangelize for the customer-care team and investigate their early warnings seriously. Because they have the most day-to-day interaction with the customer base, they know better than anyone how customers feel about the product and its performance. Remember that many account managers have, perhaps to a fault, a very strong sense of empathy for customers and will be the best source of information about how clients are feeling.
* Help foster relationships between the customer-care team and incident engineers, developers, the sales team, and other members of the company. In addition to providing valuable insight, the customer-care team gains support and appreciation for their work.

Organization

Organizational issues are the most difficult to solve because they require a commitment across all functional groups.

A customer-care team is ultimately a conduit between a customer’s experience of a product and the rest of the organization. A customer-care agent cannot succeed unless they can provide the customer with a strong resolution to their problem in a timely fashion. However, that resolution is often out of the grasp of the individual representative.

It is therefore critical that the customer-care team can count on faster service level from escalating departments as they promise to their own customers. For instance, if customer service is expected to provide a satisfactory response within 24 hours but the development team consistently takes 48-72 hours to respond, three negative things will happen: a) the customer is let down, b) the representative takes the heat from the customer and feels equally let-down and overwhelmed, and c) bad blood often develops between the “martyr” customer-care team and the rest of the company.

A strong set of processes is important. For instance, as development requests often come through the customer-care team, we must create a set of processes and controls that ensure accurate communication about the customer’s needs and expectations.

A strong set of tools is also important. For instance, a customer-care representative must be able to see the current status of a trouble ticket so that they can proactively keep their customer informed and up to date. It’s obviously stressful for a customer-care representative to have to hound escalation engineers for regular updates. Any ticketing system developed or acquired should then include other departments as agents so that each issue is tracked from end to end.