Hiring support people? Look to the trees.

Expert customer support help by people who love people.

Hiring support people? Look to the trees.

April 26, 2011 CoSupport News 0

If your support team is 25% or more of your small app company, you’re doing something wrong.

No, I don’t mean you shouldn’t have a robust support team; on the contrary I think having a full team of support people is often an overlooked advantage. But having to have so many people on support means you’re not identifying why your customers need so much support, and you’re not fixing the issues causing that support need.

Throwing more people at a problem doesn’t solve the problem, it just makes it a problem for more people. If your staffing is purely reactive, you have chosen for your support to be reactive as well. Why keep hiring people to just stay on top of daily emails?

Instead of hiring just one more person to do your support, hire up a person already on your team to swab the decks. Take them off emails for a month. Have them write new help sections. Have them work in the forums, have them work with your design team to get some common problems solved. Do you get 15 refund requests a day? Have someone on your support team rewrite your published refund policy and make it more prominent and clear.

You can’t just let your daily email volume swell and think hiring more people to answer email is the solution. The real solution is bettering your support practices, and being a better educator and fixer of your product so that much support isn’t needed.

There’s a sweet spot for a support team when they are answering just enough emails or calls each day and working on just enough other things. Ideally a support person should spend about 50% of their day on emails and 50% on other community management stuff: writing help docs, working on product development, creating tutorials. That’s a hard spot to find because we’re typically going at looking for it the wrong way. We pull out our metal detectors and scan the sand instead of looking to the trees.