How to scale up a customer support team?

As the founder, I've been handling all customer support questions myself (via email, chat, and phone). This is always good, since it keeps me in direct contact with my customers.

But I need to scale up and free up my time to focus on other things. So I need to build my customer support team and systems.

Can anyone offer any advice on how to go about training customer support people and how to build systems for customer support?

I'm NOT asking about which apps to use (zendesk, etc.). These are my questions:

1. How do I go about training new employees to be able to answer customer questions (some of which may be technical)?
2. I've heard of setting up things like "Tier 1" "Tier 2" support, etc. How might I go about doing this?
3. Any mistakes or common pitfalls I should look out for as I try to scale up customer support?

Thanks!

Few places need to scale from an all-doing-CEO into departments with dozens of folks overnight. If you're handling 'everything' right now you don't need to think about tiers right now. What you should do is delegate support and concentrate on your other tasks.

I'd say, start with one person. Hire a technical support person. Get him to know the product well. Let him view incoming support e-mails, hear you talking to customers, be a shadow viewer on all support e-mails and slowly start diverting cases to him -- small ones at first-- bigger ones later on. For some time it'll seem you'll be supporting not just your customers but him too ("e.g. it'll get worse before it gets better") but if you hired right, in no time you'll see that more and more load is off your shoulders, freeing you to do other things.

Scaling means simply monitoring the workload of anyone doing support and once it reaches a certain threshold (e.g. the avg. response-time to the customer exceeds a certain time threshold you set forth for good reasons other than slacking) you need to add more people. Repeat the process, only this time, let the first support person you hired train the next one and so forth. When the support force becomes more than a few people, appoint one of them to lead the support efforts. Once support traffic becomes serious, you then may want to start thinking about splitting up to tiers, where higher tiers have better service, faster times, longer hours, and perhaps, better more smarter employees to tackle more complex questions.

The good news is that you'll always have time to scale, develop your client base and and when it grows, respond in adjusting your support force to match. If you experience uncontrollable growth in business and a spike in support calls -- that's also good news, isn't it? you'll just have to scramble faster and it may be uncomfortable for a while until you adjust.

Mistakes? The usual: hiring the wrong people, not having a system in place to measure support utilization and turnaround, thus not knowing when it's time to scale. Not being able to track customer satisfaction with support and not being able to intercept problems in real time like frustration, fermentation and persistent problems that may require product changes vs. dealing with never-ending multiple support calls that'll just keep on coming for an issue.

Good luck.

Tier 1, tier 2 etc is simply a way of categorizing the support request and therefore the level of support engineer which needs to deal with it.

For example, tier 1 could deal with simple things like password resets and requests on how to do simple tasks.

Tier 2 then might be used when there is a potential bug and they need to work with the customer to recreate the problem and diagnose the issue.

Tier 3 then might be the actual developer(s) who are needed to then write the fixes required for the bugs identified.

The general logic is as you increase the tier the knowledge, expertise and cost of the engineer increases and likewise the complexity of what they get involved in increases too - you do not want a paid developer to be replying to password reset requests and, likewise, you do not want a fresh faced kid just out of college with no experience modifying your application or database.

Initially, you will probably have one person working on level 1 requests and then everything else comes to you so you are not replying to the mundane, repetitive requests from users who can't read the manual - as things scale you could then, depending on the volume of each type of support cases you receive, either add more level 1 and you remain as next level or you could add a level 2 and so on.

In most cases, all support cases will go to level 1 first and then move up the chain - most of the ticketing apps will allow this movement to happen to assign tickets to the right person/level.