Feature image by Sean Loyless

I've been to quite a few conferences over the last couple of years (46 conferences and events, by my count). Converge Conference was something different. Although a tech conference, the focus in the talks I saw was most definitely on soft skills and experiences, and not really on the tech. This was highly refreshing.

There were 3 talks in particular that resonated with me.

• All of a sudden ... no luck! by Rachel Andrew - more information below.
• Enterprise Porridge by Morna Simpson
• How to fake it for 18 months and (almost) launch a hardware product by Jason Frame

As the blog post title suggests, I'm going to focus on providing technical customer support. But I'd like to provide a bit of information about the other talks.

Morna spoke about the state of trying to get funding from public bodies such as Scottish Enterprise. Basically it sucks! I've experience of this myself as I'm helping a friend work on a startup in Scotland called Bee Found. I believe Morna is going to write this up so I'll leave it there.

Jason spoke about building a hardware product; but more than that, he spoke about how he's a creative person who as previously failed to deliver. He spoke about how he now understands himself and can then create goals which will mean he's a much better chance of finishing things, where he previously would lose interest and stop. A really interesting talk with a personal story which made it all the better.

On to the main topic; thoughts on providing technical customer support:

Tech Support Experiences

I've heard a lot about Rachel Andrew, but never seen her talk before. It was just luck that in this case she was talking about something I've spent a very large amount of the last two years at Pusher doing; Customer Support - a key part in the customer service within a SaaS. The talk was very well delivered and due to my relevant experience this talk really hit home.

Here are a few extracts (the headings) from Rachel's slides and some thoughts around them.

<h4 id=”“value-of-amazing-customer-support””><a href=”#”value-of-amazing-customer-support””>”Value of amazing customer support”</a></h4>

We all know the value of great customer support; it's not just an opportunity to help a customer with a problem but also one to build a relationship. A relationship is a two way thing and if a good one is created it can result in loyalty and referrals.

Support can be amazing in terms of both quality and also speed of response. Sometimes just letting a customer know that you're going to look into something with a reasonable timeline is enough. And make sure you follow up when you said you would.

<h4 id=”“one-customer-well-taken-care-of-could-be-worth-more-than-$10,000-worth-of-advertising”—jim-rohn”><a href=”#”one-customer-well-taken-care-of-could-be-worth-more-than-$10,000-worth-of-advertising”—jim-rohn”>”One customer well taken care of could be worth more than $10,000 worth of advertising” - Jim Rohn</a></h4>

By Thomas Hawk

This continues on from the idea of referrals.

But, how do you know which customers are going to offer you that kind of ROI? Can and should you treat customers differently depending on the potential ROI?

At the end of Rachel's talk I asked her if they in any way look at who a customer is when providing support and if they take that into consideration. She said they treat all customers the same. But, she did say that they do build up relationships and get to know customers. And Perch, the product she created and provides support for, works with a licensing model so they know any real support request - rather than a pre-sales query - is from a paying customer.

I think this can be really difficult subject; if you can associate a support request with a customer then you may already have a relationship with them, they may be on a higher paid plan, they may have purchased lots of licences, or they may have paid extra for premium support. But if you don't know who the customer is then should you do anything to prioritise incoming support queries? Unless some kind of support process is clearly defined and communicated to those making a support query should you treat all support requests the same? Even if you have one support request from [email protected] and one from [email protected]?

<h4 id=”“support-is-something-people-pay-for””><a href=”#”support-is-something-people-pay-for””>”Support is something people pay for”</a></h4>

I've already mentioned this above. But it's worth highlighting that many products and services do make support a premium part of a licence or the service.

<h4 id=”“customer-service-is-the-new-marketing”—derek-sivers”><a href=”#”customer-service-is-the-new-marketing”—derek-sivers”>”Customer service is the new marketing” - Derek Sivers</a></h4>

By Camille King

For me, Gary Vaynerchuk got this before anybody else. He was talking about small town rules back in 2009 and little has changed. Probably before then.

What is interesting is that I've heard about big brands jumping on this, finding it too difficult (to measure ROI or really manage it), and then reduce their focus. I still think this is massively important. If I was involved in managing the social media process for a large company I'd have a large - well paid and trained - team handling social media.

As a company grows, managing this does become more difficult. But it's worth it.

<h4 id=”“creating-data-on-support-helps-you-plan-for-growth””><a href=”#”creating-data-on-support-helps-you-plan-for-growth””>”Creating data on support helps you plan for growth”</a></h4>

The main thing I took away from this point is the importance of support analytics. At Pusher we use Tender which, unfortunately, doesn't have great reporting. The reporting features has been in beta since I joined Pusher, 2 years ago.

At Perch, they use Help Spot and it looks to provide good reporting. I also think Zendesk looks like it provides good reporting.

<h4 id=”“i-get-support-tickets-that-are-nothing-short-of-extortion”—andrey-butov”><a href=”#”i-get-support-tickets-that-are-nothing-short-of-extortion”—andrey-butov”>”I get support tickets that are nothing short of extortion” - Andrey Butov</a></h4>

Don't threaten the people you are in touch with on support. Yes, they do represent the service or production you are annoyed with. But, while it may get an initial response, it won't help you - the customer - build a good relationship with your service provider.

Feature requests and product focus

"The trouble with feature requests"

"Protect the core use case of your product"

"Add features that benefit the majority, not the noisy minority"

"Customer support can be your best market research"

There are some companies and services that provide a public roadmap of features. If the things on the roadmap aren't met then it annoys people. This is especially the case if a customer has built something they relied on being delivered as it was in the roadmap.

So, not providing a public roadmap may be easier. But, how do you measure demand for features? Do you simply note them somewhere internally? How do you ensure all feedback is captured?

The benefit of a public roadmap, and public feature requests, is that it's easier to capture demand. There's less need for an internal process to do this.

But, how do you ensure that users don't jump on a feature that you don't feel fits with your core product vision? If you have a public roadmap, you can't.

<h4 id=”“design-support-our-of-your-product””><a href=”#”design-support-our-of-your-product””>”Design support our of your product”</a></h4>

I love this idea. We all know this, but we don't spend enough time improving things.

If you think about support processes at the moment it generally goes like this:

Try feature in product -> doesn't work -> get error message -> user contacts support

At the point where the user is at get error message they should be able to solve the problem. If they they instead user contacts support then your error message isn't good enough. The error message should tell the user how to solve the problem. The process should be:

Try feature in product -> doesn't work -> get informative error message -> user fixes problem

Rachel's example was:

Simple, but effective. The same goes for API error messages.

Perch don't have FAQs because they believe so much in designing support out of your product.

<h4 id=”“provide-a-variety-of-help-material,-different-levels-and-formats””><a href=”#”provide-a-variety-of-help-material,-different-levels-and-formats””>”Provide a variety of help material, different levels and formats”</a></h4>

Different users approach doing things in different ways. Some like to read tutorials or developer guides, others like API references and there may also be a preference for screencasts.

The more options you have the more chance you have of satisfying all users. This can be time consuming, but it may be worth considering.

<h4 id=”“it’s-not-working””><a href=”#”it’s-not-working””>”It’s not working”</a></h4>

OMFG! RTFM! Sorry, I mean "I'm sorry your experiencing problems. Could you please…"

If you've ever handled support before then you'll know what this is. If you've ever submitted a support request like this then, think about it!

When submitting a support request you have to provide as much information as possible to help the person providing support solve the problem you are seeing.

Support systems should help ensure that the important information related to the problem is captured. At Pusher I broke the support categories down based on what a customer may be trying to achieve

• Connecting - I can't connect
• Subscribing - problem with subscribing to channels
• Publishing - publishing information either from the server or client
• Account/Billing - stuff related to plans, billing etc.
• etc. etc.

You get the idea. For each of these I'd really have liked to had specific fields for important information related to that category; what's your app_id? what library are you using? What debug information do you have? I'm sure this will be built into the support system in the future.

Lots to think about in this talk. I highly recommend you have a look over Rachel's slides for further insights.