How to Give Great Customer Service: What I Learned At UserConf 2012

At SEOmoz, we're always trying to improve our customer service by making our customers as happy as possible. Last month, my colleague Nick and I went to San Francisco for the inaugural UserConf, a conference all about "keeping your customers (happy)." You can remove the parentheses, though; UserConf focused entirely on keeping customers happy. Customer retention was just a serendipitous outcome.

That's what I love about Customer Service 2.0; we're real people making other people happy, not pre-programmed Droids focused entirely on efficiency and cost savings. While we want to make our customer service as cost-effective as possible - cheaper customer service means cheaper product cost for our customers - our primary goal is to provide customer service that's worth recommending to other people. The speakers at UserConf gave some great advice on how to provide that type of service.

This isn't the customer service we're looking for.

I got a lot of value at UserConf and wanted to share some of the main points and takeaways I got from each speaker. My philosophy is that the more the customer service industry shares what makes great customer service, the more likely it'll benefit us all when we ultimately need help ourselves. After all, a rising tide floats all boats. Let's open up those floodgates!

Keynote: Richard White, UserVoice

Background: Richard spoke about why UserVoice was hosting UserConf and why we were there: not to learn about why we should make customers happy, but to learn how. It's self-evident why you should do it: it's the right thing to do.

Key Points:

• Customer service as a job is more complex now because most customers solve the easy problems themselves through search and other self-help resources. We see this in our customers, which is why we built our Help Hub and are answering more and more support-type questions in the Q&A forums.
• In subscription-based business models, like at SEOmoz, sales and support is one and the same. Every time a user contacts you, their subscription is on the line. If you provide good service, they're more likely to stay. If you don't, they're more likely to leave.
• The US Department of Commerce found that the number one reason for customer attrition is poor customer service. The number two reason is poor product quality. While you should ensure you're building as quality a product as possible, be certain to support that product well above all else to optimize your retention.

Takeaways: Make it easy for your customers to help themselves instead of requiring them to reach out for help. Instead of thinking of customer service as a cost to be managed, think of it as a sales and retention avenue. Empower your team to make customers happy, and if you can, incorporate support interactions into your CRM so you can see just how effective a retention avenue good customer service is.

Good self-help is a little more detailed than this, but it's a start

Designing for customer experience: Kevin Hale, SurveyMonkey

Slides: https://speakerdeck.com/u/roundedbygravity/p/how-to-design-software-users-love

Background: Kevin started out working for Wufoo, and moved to SurveyMonkey when it got bought. Part of his success was building a culture around customers from the beginning. He spoke about making everyone at your company understand customers, as did Ben from Olark, who we'll discuss in a bit. We've got some of this culture at SEOmoz, but I'd like to develop it even further using some of the points that Kevin made.

Key Points:

• Think of customer service as a polyamorous relationship; we're going on a first date with new users, but we're married to our existing users. We've got to impress our first users, but also keep our existing users interested and happy. Part of this means you need to define who "new users" are and work with your marketing team to make them really impressed, but also set the right expectations around the relationship.
• One great way to do this is delighting people with the little details. He mentioned a blog that's also made it around the Mozplex: http://littlebigdetails.com/.
• Engineers are isolated from the feedback their code gets. Basically, they're divorced from customers. You need to switch to "support-driven development." Think about support first when writing code. How do you help your engineering and product teams see the results of their work? Check out this article about it: http://www.uie.com/articles/user_exposure_hours/.
• Team exposure can happen at a smaller level, too. At Wufoo, one support interaction is randomly sent out to the rest of the company every day. Everyone at the company sees the interaction and can get a sense of what's going on over time. Also, it helps with quality control; you create better responses if you know they're public.
• Think about the way you receive feedback from customers. If you have a contact form, ask customers to define their emotional state (e.g. angry, frustrated, sad, happy, confused, etc.). This makes their comments a lot less emotionally heated because instead of needing to express their feelings in their writing, they get it out and in front from the get-go.
• Keep customers in the know! At Wufoo, when a user logs in, a popup lets them know about features and improvements that have come out since they last logged in. Keeps customers feeling like there's always improvements. I love this idea.

Takeaways: To use Kevin's metaphor, customer service at a company like ours is all about the long-term marriage. We want to make our customers happy throughout their subscription, and beyond. Even when our customers cancel, some of them come back, so we make sure to give them the best cancellation experience we can. I don't want to make it sound like we only do these things to make more money, though. To us, it's more important to stay TAGFEE than to squeeze a few more dollars out of people.

Some ways that we keep our customers happy for the long haul include giving credits when customers encounter issues or bugs that prevent them from doing their work; keeping track of feature requests and letting customers know when they're implemented (thanks, product team!); and issuing a refund when a customer that intended to cancel earlier accidentally let the next charge go through. After this conference, we'd like to add more context drop-downs to our contact form; better inform our customers of improvements and fixes we've made for them; and keep everyone on the team informed of what's trending with customers week by week.

Being Roger's therapist is usually easy, but some weeks can be a little tough

Allhands support: Ben Congleton, Olark

Slides: http://www.slideshare.net/bencongleton/all-hands-support-talk-to-your-customers

Background: Like Kevin, Ben spoke about involving your entire business in customer service to make your products better. If everyone at the company knows what customers are writing about, they're more likely to design products to address pain points and fix bugs for customers.

Key Points:

• If you put engineers into support roles, you'll "close the feedback loop." Normally, engineers don't see the effects of their code work. They finish the project and never see it again, except for one-off bug requests. If they help do support for their releases, they'll see what happens with what they're built. They're also more likely to create tools for support to fix things on their own (since they'll know how support is doing their work). We've seen this work here at SEOmoz, and hope to eventually have everyone at the company doing a little support. They even get a badge after they do it! Check out David's Help Team University seal.
• At Olark, all engineers rotate onto chat so they get 1:1 time with customers. A lot of companies do this to create a culture driven by customers. Wufoo rotates their entire team onto customer service. Wistia puts all non-technical hires on customer service first, from which new employees "graduate." Other companies have time requirements around how the rest of the company spending time on CS, e.g., 10 hours every 6 weeks.
• A couple of examples of this: Kayak has a "red phone" that periodically rings straight to the engineering team. Here's their page about it: http://www.kayak.com/news/kayak-red-phone.bd.html. This way, every once in a while, customers talk straight to engineers so engineers hear from customers. At New Relic, everyone at the company does support. Non-customer-service people answer 25% of their support questions. People at the company rotate in and out of the team, which answers "escalated issues." You could also do this for a short period of time, though I like the idea of doing it all the time here.

Takeaways: Going forward, when SEOmoz launches new features or products, I want to make sure to involve the whole company in doing support for the new releases. This way everyone will see the results first-hand and be able to make decisions about success on their own. Logistically, it's going to be tough. After all, if we just released a new feature, I want to make sure our engineers have the time to fix bugs as quickly as possible. At the same time, I want them to be able to see their work after it's gone live. Making a rotational temporary team seems like the best compromise.

Since the red phone idea's been taken, maybe we should have a player telegraph instead?

When everything goes wrong: Matthew Patterson, Campaign Monitor

Slides: http://mrpatto.com/userconf

Background: Matt spoke in a very nice Australian accent about how to create an emergency action plan. Things go wrong, and often predictably so. There should be very specific plans in place for emergency scenarios.

Key Points:

• Campaign Monitor hires people in all sorts of locales to make sure they've covered particular languages or timezones. Initially, they have that team member fly to Australia for language and tone training. It's more important to train for culture in-person than it is for technical stuff in-person; they can learn technical stuff remotely. As SEOmoz expands, we're considering night shifts in Seattle or colocations on the East Coast or, eventually, Europe. We want to make sure not to lose our culture in the process.
• Have an early warning system. At SEOmoz, we have an email alias with key stakeholders on it so when something looks like a potential larger-scale issue, anyone who notices it can email all of these stakeholders. It helps us get things fixed ASAP.
• Think about the problems that we know will happen. Mozzers, you know what I'm talking about: rankings issues, crawler issues, Mozscape and OSE outages, Mozscape release issues, etc. Our customer service team should have strategies for these before they happen so we can let y'all know about them and plan around them.
• Keep responses consistent for all customers. Build up a library of phrases, descriptions, and commonly used terms. Instead of having macros that are very specific to particular issues, just make more general chunks of information. This will ensure all customers get the same information.
• Give customers regular updates, even if they're just letting them know you're still working on it. We should establish a minimum contact period, like once every couple of days for shorter-term fixes. For longer fixes we should resolve the issue by letting customers know what the ETA is. Ideally we would email them when it's finally fixed too, but that's harder to do for a lot of issues. We'll think of ways to do this.
• Establish explicit rules around what to do when things go wrong. For example:
  1. Send an email to early warning for confirmation
  2. Post to Known Issues Forum so you all know about it
  3. Draft a macro to send to customers so we stay consistent
  4. Reply to customer in bulk with this macro and link to the forum. This will help us get answers to most customers more quickly
  5. Add message to notification area of Web App

Takeaways: Actually have a plan for all the possible disasters that could happen with your product. Let everyone at the company know where these plans are, whether they're on the company Intranet or in a manilla envelope in a safe in Gringotts. Do this so that your customers are taken care of quickly and accurately. I think the best first step is to establish an early warning email alias - it's helped us a lot.

On second thought, there's probably safer places to keep our emergency plans than Gringotts...

Quickly scaling to 24/7 phone support: Jessica Semaan, Airbnb