Junior people in customer support—Something to avoid for complex products
Customer support departments usually have the highest turnover rates among all departments in a software company—which is also common in many other industries. If a team loses a lot of people, voluntarily or not, is having junior people onboard inevitable? Well, that’s what we want to put in perspective in this post.
First, let’s clarify what we mean by the two key terms in our title: junior people and complex products:
By “complex products” we mean software (or other products and services) that encompass many features and configurations, and inevitably multiple combinations of these elements. If the software itself is complex, its target business applications are probably complex as well. Complex solutions to complex business scenarios make providing adequate customer support very demanding. The knowledge required from a customer support agent in these environments is not easily acquired—it requires time. And, for that reason, money.
By “junior people” we don’t mean young people, nor people who have recently arrived in the company. Instead, we mean people with little knowledge of all the elements just described—product features, business scenarios, and the application of the product or service to address these scenarios.
The reason we suggest avoiding junior people in customer support for complex products is painfully simple: they cannot perform the task well. This may sound a little harsh, but we’ll try to break it down to make it easier to digest.
To help illustrate, we created this simple table, where we outline the routine tasks of a customer support department in a software company. Here we point out the levels of seniority typically required to contribute to each activity reasonably well, and the type of participation of each seniority level: Conducts the activity, Executes the activity, or just Participates in the activity.
|Take customer calls, chat, messages, or emails and address their issues||–||E||E||–|
|Create and classify tickets||–||E||E||–|
|Analyze inputs and root causes of issues||–||E||E||–|
|Devise operational solutions to reported issues (e.g.: workarounds)||–||E||E||–|
|Detail steps to replicate failures before forwarding issues to a level 2 or product maintenance team||–||E||E||–|
|Create internal tickets||–||E||E||–|
|Provide feedback to customers||–||E||E||–|
|Participate in escalation routines||–||E||E||P|
|Support process improvement initiatives||–||P||P||C|
|Categorize / prioritize tickets||–||P||E||P|
|Distribute tickets to team members||–||–||E||P|
|Evaluate ticket backlogs (causes, priorities, actions)||–||P||P||C|
|Analyze KPIs and identify improvement measures||–||P||P||C|
|Conduct or participate in lessons learned meetings||–||P||P||C|
|Educate customers with proactive information / guidance||–||E||E||E|
We know many will argue that leaving the “Junior” column blank is not accurate, since junior people can at least service tickets related to simple matters. While we agree on that, our point is that we never know what the level of complexity “will be” until we have either talked to the customer or read their ticket. By then it will be too late, at least for the always-desired first call resolution.
Now that we probably created some agreements and disagreements, we can try to answer the next question: “And how on earth do you find and hire trained people?” Unless you hire an ex-employee or someone who worked for one of your customers or business partners (and you probably don’t want to do these last two), you will hardly ever find “trained” people. Instead, what we have seen as good practice is to look for “knowledgeable people” and not “junior people.”
Over and over again, we have seen customer support managers telling us things like: “it takes two weeks of training to get a new employee to learn the basics of our product.” When we dig into it, we find out that actually most of the training time is dedicated to teaching them business concepts or applied technologies, for example—and not the product itself.
We can use the training for a payroll system as an example. In most cases we see that between seventy and eighty percent of the time and effort is spent on teaching the new employee the business practices and laws related to payroll—not the system itself. On the other hand, if we were to teach a person who is proficient in payroll, it might take no longer than a single day for them to learn the entire system, because they are familiar with the concept and already understand how payroll systems work.
Therefore, a great practice for teams that provide customer support to complex solutions isn’t to avoid “new people”, but “junior” people. This way you won’t bring to the team people who don’t have the required personal maturity to deal with experienced customers, or the proper understanding of the customers’ business to know what the user is talking about or the severity of the issue at hand. You also won’t have team members that lack the experience to handle the conflicts that easily arise from complex and stressful situations.
Think about bringing “knowledgeable people” onboard, and they will learn your complex product or service in no time. Leave the “junior” people to start their careers working with simple solutions, rather than trying to find simple issues to assign to them when dealing with complex solutions!
Are you now wondering about the cost to do that? Great. We’ll be discussing that in our next posts…
Agree with the above? Have a different opinion? Have a particular issue with it and would like to exchange some ideas? Please leave a comment! We’ll be happy to learn or share more information and insights about the topic.