NOTE: These recaps are a bit more for me than you. I’ll skip over stuff, include asides that are more personal notes to me, etc. Your mileage may vary. More detailed/sanctioned recaps will be available at http://microconfrecap.com at some point.

Presenter: Ian Landsman

  • Company: UserScape
  • Also: Bootstrapped.fm
  • Customer support is the original growth hack.
  • Tend to think of customers as metrics, lose sight of the human factor
  • Customers have their own hopes, dreams and desires. Keep a picture of your customers in your mind.
  • Support is sales.
  • Did nothing but customer support (no ads, marketing, very little SEO), but grew to $488k/year in the first three and a half years)
  • Tried an ad on The Deck, had zero conversions off it. (That’s surprising to me. Ed.)
  • First 100 customers = 1,700 support tickets. Majority are still customers. Have made $297k additional from those first 100 customers after initial purchase (support renewal)
  • Volume of support increased with revenue. As that support increased, first response time got longer. How you know it’s time to add additional resources.
  • Most support in pre-sales and technical (mostly the downloadable version).
  • Should have a support tool (one of his preferably). Email breaks down after a while. Especially as you grow past a single support person.
  • Support channels: help site, in-app and email.
  • Marketing is not support. Don’t answer support questions where you market (ie. blog), get them into the support channels.
  • Twitter being a partial exception. If you can answer in 140 characters, answer in 140 characters. But those cases are very infrequent.
  • Help Site: detailed info on initial setup, in depth on settings, and advice and best practices.
  • Have a clear way to contact support on the help site.
  • Be very clear about where the customer is. Visitors might wander in sideways through search engines. URL reinforces where they are (help.yourapp.com, for instance)
  • Have search.
  • Might have support docs in multiple places, but have them all available on the help site (link to API docs in nav, for instance)
  • Make it browseable/discoverable as well as search
  • Don’t require registration on the help site. Don’t make barriers to contacting support.
  • Don’t expose the internal metadata of your help desk: status types, categories, etc. Nobody cares. They have a problem, they’re waiting for you to give them a solution. That’s it.
  • Organize content for customers. Avoid where it’s organized by the staff for themselves (deeply foldered structures that only make sense if you know the product well)
  • In-App: Customer.io
  • Make sure they know in your app that they know how to contact support
  • Snappy, integrates the docs in-app.
  • Email: Still king in support world. Lot of support tools = “We don’t do email anymore!” But almost all support eventually goes through email. Customers like to talk with people who can help them.
  • Always be compassionate.
  • Customers get upset at little things. Don’t get upset. Turn that frown upside down. Keep the moral high ground in the conversation. How can I make them happy?
  • Customer you turn around, will be the one that’s loves you the most.
  • Always apologize (even if you maybe don’t need to).
  • Ignore frumpiness, focus on the problem. No matter what they say to you.
  • Once you solve the problem, that’s it. Now they’re happy.
  • Reply to support email:
    • Intro: Keep it informal. “Hi Tina,” for instance. Use names.
    • Outro: “If you have any other questions let me know. I’m happy to help. Have an awesome Monday!” End with a positive experience.
    • Keep it short.
    • Use canned responses. But be careful not to be too canned. Personalize the intro and outro. Maybe use a canned response just for the actual solution. (Note: TextExpander works great for this, Ed.)
  • Organize tickets:
    • Categorize: Just general type of request so you know what types you handle for later scaling. Keep them broad. Less than 10, so you can go through them fast.
    • Assign to individuals instead of groups. Because everybody thinks somebody else is going to do it.
    • Prioritize. Also keep simple. Urgent/not urgent.
  • Schedule
    • First thing in the morning
    • After lunch
    • End of day
  • Scaling support
    • Hire early for support. Can get away from you before you realize it. Hire part-time if need be. If you know what your support is, you can easily outsource it.
    • Eliminate low hanging fruit (see above)
    • Have the part-time work the morning to triage, then escalate to you for the things they can’t handle. That way customer gets fast reply.
    • This is why categorization is important
    • Everyone does support. Devs do support.
  • Feedback mechanisms
    • Once you start outsourcing support, you’re not in the feedback loop as much
    • Your team needs to keep you in the loop: problems and successes; use chat and support tools
  • Surveys
    • Periodic surveys. Let users rate your support over time.
    • Not a fan of surveys in each support emails. Lets angry customers route around support mechanism. It’s usually pretty clear when folks are unhappy.
    • If you want to track this, track it on the support end instead (you’ll know)
    • Follow up survey a few days later: We all hate these. You’re making your issues your customer’s issue.
  • Support is sales. Always be polite with customers. That’s how your company grows (upgrade to bigger plans, move on and sign up with a new company)

Q&A

  • Telephone support: Uses a service called Ruby to handle incoming phone support that translates into tickets or email.
  • How to deal with bad customers: Only had one bad customer, everyone else is just frustrated. If you focus on solving the problem and making them happy. It’s usually a small thing. Focus on the long-term value of turning a customer around. If you get a little bit rude back to them, it just escalates.
  • How do you scale support that requires huge domain knowledge (installable apps, for instance)? No real answer. Very tricky to hire developers only for support, but easier to balance it across regular developer support (Aside: this also works great for dev empathy. Ed.)
  • Office hours: Definitely set them. You might find customers that “need” 24/7 support, but you can’t do that. It’s never really been an issue, just be honest about it.