| How to Give Great Customer Service: What I Learned At UserConf 2012 Posted: 06 Nov 2012 06:46 PM PST Posted by Aaron Wheeler 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:
- Send an email to early warning for confirmation
- Post to Known Issues Forum so you all know about it
- Draft a macro to send to customers so we stay consistent
- Reply to customer in bulk with this macro and link to the forum. This will help us get answers to most customers more quickly
- 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 Background: Jessica spoke about her experience scaling a customer service team of 3 people into one of 200 people in just a couple months. Like Kevin touched on a bit, she used a metaphor of love and relationships to explain customer interactions and how to provide great service. Key Points: - Airbnb made their customers part of the customer service team, like we do a little bit in our Q&A forum. Every customer base has one key value that they need met. For Airbnb, that value is trust. What is it for us? I'd say it's reliability. What do you guys think?
- Gather data very early on and ask a data scientist/engineer to help you gather and interpret the data in a valuable way. I asked our senior data scientist, Matt Peters, to take a look at our data points and give us some tips and a framework for data analysis. His biggest question to me? What problems do we want to solve with our data? Think of questions that you could answer using customer data, then get the answer. Don't just go blindly into it.
- For Airbnb, there are three key data points:
- Contacts per transaction. How many interactions do customers need to make per transaction Airbnb processes?
- The top issues customers are having
- The cost per ticket. How much does each customer interaction cost us? We don't track this but it'd be interesting to start.
- Manage expectations. What should customers expect when they start a conversation with us?
- You can use the Erlang formula to figure out how many people you should have managing the phones. It's complicated, but basically, the more time zones and languages you want to cover, the larger the exponent of growth. Just adding one language or time zone for a small customer base can add six people to your phone needs, and it gets bigger from there.
- This is what the overlap between customers and product looks like. We need to represent both teams:
 - Airbnb informs product on top customer issues with "AirDives." The customer service team gives a brief weekly presentation to the product team regarding the top issues of the week and stuff they think should be fixed, as well as options for fixes. The do a "deep dive" on one issue in particular to prioritize it as a fix. We just put a recurring weekly meeting on our calendars for this and will have to let you know how it goes!
- They have a bug fixing team on their support team so bugs can get fixes more efficiently and quickly. These bug fixers also build backend tools for the customer service team to fix one-off issues and measure customers and issues. It's not about catching up with issues; their team actually changes the company. We want to do more of this at SEOmoz.
- In sum, create independent and empowered customers that have the ability to help each other.
Takeaways: Harness the power of your customers. At SEOmoz, we have our Q&A forums, where customers help each other with their inbound marketing questions. However, some customers have been using it for support questions, and our other customers are helping them there! If you don't have a support forum, get one, and let all of your customers know about it. Email them, link to it in your main navigation, and reward people for helping each other. As the other speakers mentioned, get your whole company on board with the biggest customer pain points. How can you measure success? Every single person in the company, when asked, should be able to answer, "What are the 10 biggest bugs and issues with our product right now?" When audiences don’t agree: Dana Kilian, Eventbrite Background: Dana mostly spoke about setting expectations for customers and clarifying the role of their business for users. They have a different business model from ours so the presentation was a little less relevant for us, though I did extract a couple gemeralds. Key Points: - Know where you stand on the support spectrum. Look at the support spectrum at other companies: Craigslist vs. Etsy vs. Amazon. There's no service at Craigslist, but customers don't expect service. However, Amazon gives great service, and people expect it. We want our customers at SEOmoz to expect great service, but that includes great self-service.
- Establish baselines of support and share them with the company. What do we do on a regular basis? E.g., 10 refund requests/day, 10 credits/week, etc. We should let our team know what our regular support load looks like.
Takeaways: I saw some parallels here with SEOmoz and think we could do a better job of clarifying what our company does and doesn't do. At least 25% of our inbound sales interactions think that we do consulting, or that signing up with us will boost their rankings effortlessly. But we're an analytics software company, not SEO consultants. What do we do? What don't we do? How are we setting expectations for potential customers around these things? We'll continue to work with marketing to help define these things for customers before they need to call or email us about it.  Trying new things can be scary, but it's nearly always worthwhile Trying new things: Chase Clemons, 37signals Slides: http://supportops.co/userconf-2012/ Background: Chase described the channels that they use at 37signals to do customer service. It pretty much reflected what we do at SEOmoz, so check out his post to see what our channels look like. One note: almost none of the companies that presented or that were at the conference do phone support, or don't list a number on their site for customer service. What would it be like if we didn't have phone support at SEOmoz? What would we miss out on? That's one of the questions I thought about, since we receive over 500 phone calls a month. Key Points: - Review all of the potential URLs that customers might intuitively go to. URLs like /help, /support, /sales, /service, help.seomoz.org. Try to get a report of users that visit these URLs, and redirect them to the relevant page.
- Use screencasts to record multi-step stuff and let customers make screencasts. I personally like Screenr.
- After 3 email replies back to the customer, it's time to call them instead of emailing more.
- Consider having virtual office hours. I think Distilled does this as well. 37signals uses http://meetings.io/ to hold screensharing help hours.
- My favorite idea: hold 1:1 customer service session events in other cities ("PRO Delivered"). For instance, when we do Mozcations or other Moz events outside of Seattle, we could also offer 30 minute time slots to meet with customers about issues they're having. Hold these on the day of the event, starting at 9am up until the event. Would you guys be interested in that?
Takeaways: Make it as easy as possible for customers to get help from you via the channel that they prefer. While phone support might be hard for businesses, I've found that many of our customers prefer it, so we've got to think about how we want to scale it. Since we don't have a sales team, it might be hard to just not have a number potential customers can call and ask us sales questions at.  While some cat channels are useful, make sure to have email and live chat, too Customer conversations at massive scale: Doug Turnure, Microsoft Visual Studio Background: Doug spoke about the advantages of being a huge company with a lot of users: using huge amounts of customer data to determine feature improvements. Key Points: - Prioritize features and bug fixes based on usage. Use actual data on usage to justify prioritization.
- Observe repeated behaviors. Why are customers trending towards doing this same action over and over again? Could be a UI issue.
- Right after releases, you should share all feedback to the whole company every day. If that's impossible, aggregate all feedback and report it to the company as often as possible.
- Determine what the top features and functions are for the average user. For instance, what are the 20 most-used pages?
- Before the launch, in beta, offer 1:1 support to testers so you can really get to the crux of their issues.
- In surveys, don't ask for anything you don't need an answer to. Have a reason for every question.
Takeaways: Our support team needs to become more proactive in our data analysis. Use the data you have from customer emails, chats, and forum posts at scale to improve the UI. We use Zendesk here, so we'd like to implement a more granular and robust tagging system to aggregate this data at scale. End-of-conference Q&A: all speakers - We should ask product: what do you need from us to push for fixes? What data do you want? How do you want the data?
- At Wufoo, there is a quarterly shift review. The team reviews all of the team member's interactions during their shift that day and uses that to make recommendations on how to give even better service. It's also used in the performance review. They review tone, the feeling of the ticket, facts, reply time, and procedure. I love this idea.
- During interviews, ask interviewee to explain how to do things in detail. How do you cook a pie? How do you sign up for online banking? How do you describe these things to your grandmother? If you had to break up with someone over email, what would it say? Use these to figure out how a person describes things.
- Support is part of the product, not separate from the product. A perfect product requires almost no support. In fact, most service departments should live in product. Ours lives in Operations.
- Consider having "support holidays" for team members. Basically, a heads-down day of in-depth problem solving. Maybe we should require this type of activity and be specific about when, instead of just letting team members ask for it when they think they need it.
- One of the problems with support: there's no sense of accomplishment. That's what UserVoice has tried to fix with its point systems.
- How do you manage remote teams? Don't use tracking software - it sucks. Have Google hangouts, have meetups you fly everyone to, expand culture remotely with fun stuff, make life-size cardboard cutouts of remote employees for the in-office team. Have Campfire chat up all day or some other team chat room (I love this idea). Ask questions over the chat room so everyone can benefit and help.
- Customers get 3 strikes, then they're out. Actually, we have a one-strike policy at Moz. If a customer is rude, cusses at us, or otherwise acts unprofessionally, we'll help them close their account.
- One of the contentious suggestions was that for people that call or email too much, give them timeouts. Use "passive disengagement" to discourage individuals that are getting too much service and making it harder to provide good service to the majority. Suggest alternatives and competitors if your product isn't a good feature match or if they need more than you can give.
 Throw away everything I've said and don't read the next part Top 10 action items As you can see, I learned a lot! Here are my top 10 takeaways from the event that I'm going to work on at SEOmoz: - Getting everyone in the entire company to answer support questions makes your product better. The more time people in engineering, product, and marketing spend doing support, the better the product becomes for customers. Create a plan on how to do this and get buy-in from your company leaders.
- Your customer service team is the Marriage and Family Therapist between your customers and your company. They should keep the company informed on current issues, and customers informed on current fixes. At SEOmoz, we'll do this by having weekly meetings with department heads and project managers to let them know what the past week's biggest customer pain points are. We'll take what we learn and communicate it back with customers via forums, notices in-app, and email.
- Be accountable for the support you give. Share your interactions with the rest of your company via email, internal social media - whatever your team actually looks at. Review the interactions your customer service team members have on a regular basis. We'll try doing this one shift per quarter at SEOmoz.
- Hire people for shifts that will optimize your reply time. We have a lot of international customers at SEOmoz, so we start receiving requests at midnight PST. As our team grows, we'll posts an ad for a 12:00am - 8:00am shift and see what happens. Don't avoid putting it out there just because it's less desirable for the majority. If we get someone, we'll make sure to train the company culture in them vigorously.
- Build a step-by-step action plan for emergencies before they happen. Be very specific and involve the rest of the company.
- Define the core need of your customers, then determine what your customer service team can do to satisfy that need. I've got a suspicion that most SEOmoz customers crave reliability above all else. So, we'll do what we can to push for a culture of reliability.
- Have a team of bug-fixers on the support team directly so you can resolve issues as quickly as possible.
- Advocate for customers regularly and intentionally. Meet with the product team about bugs and issues, and be involved in prioritization. Back up your meetings with sweet, sweet data.
- Set expectations for your customers so they know what to expect when they need help. Do you have 24/7 support? If not, let your customers know!
- Communicate within the support team constantly. Keep everyone in the loop to stay consistent and up-to-date. We might try a chat room.
I hope this post helps you improve your customer service experience as well as your product as a whole! If you have any questions or want to discuss anything in more detail, please add a comment below. I'd love to chat! Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!  |
Postări
