Customer Service as Art

Articles

Rob La Gatta, Community Advocate, shares a little bit about how mighty Modern Tribe handles customer support with a dedicated, remote, freelance team where collaboration, shared goals, and most importantly empathy make for a stellar customer service experience.

Customer service is more than just solving problems and making people happy they decided to use your product. Support is a form of art. How you shape customer service is up to you. Like Thomas Kinkade and Pablo Picasso before him, success in art is defined by crafting an approach that best connects with your patrons. The most beautiful thing about art, though? When you start with a blank slate, you can take it in any direction you want. And the same goes for support.

Some say "good artists are born, not made." But the masters in the Louvre didn't emerge from the womb with paintbrush in hand. They developed interests and pursued those, learning from their experiences to better themselves — and more importantly, their processes — over time. If support really is an art…why treat it any differently? Shouldn't you be able to come to the table with little more than passion for the cause, and carve your own style that spreads throughout the community based on how well it speaks to them?

Running support with a non-technical background

Just over two years ago, I joined Modern Tribe to help handle support for Events Calendar PRO.

The premium plugin was still relatively new at the time. Shane — our CEO — and I did a daily divide-and-conquer on the CodeCanyon forum. The only strategy we had was "make sure to respond before people get pissed off."

That much I understood. But beyond that, things were hazy. Coming into this role I had no experience doing dedicated customer service, barely knew a thing about Events Calendar PRO, and had only a working knowledge of WordPress itself. I could find a line of code in a PHP file but wouldn't feel comfortable making changes myself. I could fake my way through a conversation on Javascript or CSS but would freeze up if asked to hack at core files.

And guess what? It didn't matter…and still doesn't.

If anything, a non-technical support lead can approach customer service without the constraints of a developer's mind. A non-technical support person views things as the customer does, and can convey community wants/needs to the dev team in plain English. They force devs to consider and plan for the fact that not all users are developers.

There is a line that you need to walk: give the devs too much control, and they may build what they want without considering the community. Let the customers drive the carriage, and you're sure to veer from the project's core scope. You're probably going to run over budget, too.

At Modern Tribe, we call the support lead a "community advocate." Remember that it's hard to advocate for the community if you can't put yourself in their shoes.

Since taking that first pass at CodeCanyon, we've grown. Support has become a five-person team and is likely to get bigger in 2013. Shane's removed himself from daily support entirely, and I've stepped back to a management role so I'm not as involved in the day-to-day exchanges either.

My technical skill is not much more advanced than it was two years ago. Likewise as I build the team, technical accomplishments are one of my lowest priorities. I want people who care and empathize; if that means they need to bring in dev help for the more complex support tickets, that's a tradeoff I'm more than willing to make.

Why all good support teams also do Quality Assurance (QA)

If a support team isn't at least partially involved in the QA process, they're doing it wrong. With proper testing instructions even the least technical support staff can effectively run quality assurance testing to verify that something works.

Consider five premium plugins, each with a dedicated support forum that one team member manages. This person effectively "owns" that forum: they address all threads, report feature requests and log bugs to the core dev team. As those come in, the dev team works off this feedback to produce the next release. When it’s time to verify that the new code accomplishes what the community wants to see, does it really make sense to have an isolated QA team verifying that? Ultimately, who'd be the most sensible person to conduct testing here? Answer: the support team member who initially reported the problem. They know the problem, have a rapport with the user and won't have to waste time researching how to replicate the issue. What better way to expose your staff to the code they'll be required to support in the near future?

This is why it's always surprising to hear from teams who handle QA differently. Normally they fall into one of these categories:

• QA exists independent from the support team.
• The devs who did the work do QA. (You'd better be damn confident in your dev team if this is the route you take!)
• There's no real formal QA process whatsoever.

The merits of each could be debated…except maybe the last. (That's just foolish.) But all three create silos — independent, isolated teams working among themselves, which makes for a fragmented experience for the end user. By exposing support to QA, and having support teams increasingly involved in pre-release testing so that everyone knows what’s shipping, we've been able to do a much better job of accurately communicating to users…and setting their expectations on the scope or timetable for a given fix.

As an added bonus, we've found as we get the team more actively involved in the entire project cycle, everyone becomes more excited and willing to share their ideas. The situational awareness such testing offers helps the support team to work more effectively with devs just as much as it helps in their customer encounters. This works well with co-located teams. But what happens with remote employees?

Avoiding the pitfalls of a remote, freeelance support team

Whether QA is a factor or not, support momentum becomes more complex when everyone works remotely. Consider the fact that the whole team is part time and everyone freelances — meaning they've got other clients, too — and things can get messy, quickly. We've only got so much overlapping time in a given day and so we have a strategy for handling support.

No system — no matter how awesome — is going to keep a bad team from failing. If you've got support staff who are genuinely disinterested, view this as "just a job" or who don't share the customer's sense of urgency, then you've got bigger problems.

As a general rule of thumb: if a support member doesn't approach every new support exchange with, "How would I feel if I were in this person's situation?" then they probably aren’t well-suited for a remote support position. The amount of uncertainty — the sleepless nights you'll have wondering how much babysitting this person requires to get the job done — you don't want that. As with anything freelance, you want self-starters: good people who you can count on to get things done. And you'll be able to tell pretty quickly which side of that coin they fall on.

You will find good people — they're out there. Here are few things I've found effective at maintaining momentum with my distributed team:

• A shared commitment to 24-hour response times. This is pretty standard, and I question the dedication of any team who doesn't guarantee customers a response of some kind within 24 hours of the original post. We openly publicize this 24-hour window. It forces the team to stay accountable, because they know there is no gray area: if your forum has threads outside that timeframe, you've failed and so have our systems. And it's going to warrant a discussion you'd probably rather not have.
• Twice-weekly scrums. We meet for 30 minutes, twice a week, to review the support obstacles we're facing. Everyone brings up exactly what stands in their way and we figure out how to work through it on the spot. Everyone normally comes away with one to two action items outside of their regular support duties, to report back on at the next scrum.
• An active Skype chatroom. We've got our broader "Products" chat with the whole crew, but we also started a support-only chat a few months back. What a change this has made! It's like a never-ending scrum meeting where we can ask each other questions and pass off threads or support emails to someone better qualified. Plus, there's just enough goofiness and off-kilter banter that it feels as close to a watercooler as you're going to find in the digital world.

Despite the fact that I have never met three of the four support members on my team, we've developed working systems that are as effective as any established by comparable groups working in physical offices.

Turn support into a flexible creature

Different systems are going to work for different teams, and that's OK. This piece is meant to be an overview of what worked for Modern Tribe in case it might work for you too…and you're welcome to take a page from our book if it does.

But if I could leave support teams out there with one bit of advice, it's to try new things. Buck conventional wisdom. Go with your gut and accept that your idea might not work.

What I touched on here and — for that matter — virtually every aspect of Modern Tribe's support system does not come from a book or from reading articles like this one. It comes from trial and error: seeing what works, what doesn't and adjusting to make sure it doesn't happen again. If you're willing to do the same, you'll learn a lot.

Image based on Billetes y sombreros by Germán Póo-Caamaño, CC-BY-2.0.