Advertisements

Three Principles for Support

Support is an underrated contributor to the success of many organizations. Good news: small businesses and startups in particular are uniquely positioned to provide great support to their customers. The size, newness, and/or rapid evolution of these companies, as well as their penchant to hire young workers who do not know any other system, gives them opportunities to immediately install support as a priority, which in turn lets you mercifully avoid having to make a halfhearted latter-day toward saying that “our customers are what really matters” and the like.

If your customers are indeed what really matters, then you should take a keen interest in helping them at every stage, which in turn lets you also avoid instinctively commoditizing or outsourcing your support at the first opportunity. By making support an integral part of your organization, you keep your company focused on real things – how real users are using your app, how you are affecting them, and how they are affecting you.

As companies create a strong support apparatus and staff it with empathetic, creative and articulate persons, they build trust with their customers, receive unfiltered and often invaluable advice from them, and ultimately drive new development cycles, too. Support is a nexus of product ideas and marketing – it isn’t just trying to fix someone’s harddrive, or tell them that you’re deeply sorry for their “inconvenience.” Support is a conversation between actual persons about something that is dear to both of them – it is easy to forget this dynamic. You don’t have to commoditize your support staff (especially if you are a small organization), and you really should keep them front and center in your company so that you gain better insight into how your app is performing.

1. Pacing is key

Angry (or at least flustered) emails and phone calls are perhaps the most stereotypical aspect of support. But why are these customers angry? They’re contacting you because your product is important to them, not because they want to devour your attention and distract you – even if they did, the frequent 15 minute call-waiting times, automated replies, form letters and procedural jargon would make it a waste of their time, too. And that’s the problem.

Lengthy delays are a problem for support. If the user doesn’t just give up, then by the time she reaches you, she’ll likely already feel (on some level) that she isn’t important to you and that your approach to delaying support has aggravated (and far outstripped) whatever actual issue she had with the app.

That’s too bad, since in many cases, a swift and humane response can turn even the most difficult support cases into a positive and productive conversation. I have seen numerous annoyed users reply to an initial response with exuberant thanks for its speed and individualized nature, as if the issue itself had become secondary. And maybe it has! Once the user knows you care about him, then resolving the issue may become much easier, as your words are more meaningful and he may even try more actively to investigate on his end, too.  Fast support turns an impersonal waiting line into a one on one conversation.

2. Master your many voices

Every support case is different, although they do fall into some broadly applicable categories. For example:

-Friendly feature requests: these are users who love your app but want it to be even more richly featured or tweaked slightly. You can engage these users with a casual, attentive and enthusiastic voice – acknowledge their thoughts, say that you’ll think about it, but don’t make promises or overpromise. If done right, you can satisfy these users by acknowledging that their thoughts are important, even if you don’t end up implementing them. And you shouldn’t implement all of them, and probably not even most of them – being able to decide later that you’re going to say no to most feature requests, even as you acknowledge appreciation for all of them, is important.

-Concerned or frustrated queries: these users may have issues that, to a support specialist, seem like low-hanging fruit or imminently fixable issues. Even if they are, it’s important to maintain clarity and respect in your response. Spell out the steps needed to resolve the issue, and ask questions if necessary. Veteran support writers may even be able to read between the lines, and in turn sense that a user is actually experiencing a common issue but simply hasn’t expressed it in the most straightforward way. Being able to predict and make educated guesses can not only solve problems more quickly, but also earn users’ respect, since they’ll know inside that you really listened to what they said.

-Upset users: you will certainly encounter unhappy and upset users at some point. Whether they don’t like your new feature or can’t figure out why you made x or y choice, it’s important to keep an even keel and listen carefully. You can learn much from angry users, since they can be the best at spotting issues and pain-points. Like I noted earlier, good pacing/response time can in many cases take pressure off. Beyond that, careful attention to the discernible pieces of information within an angry email is key – once you can discern what the issue is, chances are you can solve it. The hard work is in being able to separate the specific info from the tone.

-Genuinely complex/technical issues: These users are likely the most challenging to give a good response to. They have succeeded in finding a deep, unusual error in your app, and may frame it in technical language or with anger/frustration,. In these cases, your skills and knowledge of your app will be genuinely tested. Get as much information from the user as possible, and ask for help from your QA team and your engineers.

With a good support staff, your organization is already well on its way to better understanding how your app works and how it is being used. Beyond that, support also builds credibility and creates an audience for your products – so the next time you make a big release, or announce a big sale or contest, the loyal users whom you listened to and supported will be onboard.

3. Don’t get bogged down in technical jargon if possible.

Apple has become one of the most successful companies in history by realizing that users basically don’t care about technical specs and explanations – they care about experiences. The same holds true for basic app support. In light of that, saying that the app doesn’t work because of any of the following reasons can easily confuse and even aggravate your users:

-a certain feature is just too hard to implement, or a certain task too hard to complete properly and without crashing (there isn’t much that is impossible in software, for example, and most users seem to know this even on a naive level – they have high expectations, and developers always have more to do)

-your (the user’s) phone/tablet is slower than molasses and hence to blame for the issue (if they’re using your app, they’re using a technically supported device and you should do everything you can to help him/her – don’t blame the user)

-your QA team overlooked something (this can be confusing, as it reflects badly on company culture and because many users don’t even know what “QA” is)

Users are interested in solutions, not overly technical spiels (even the self-proclaimed savvy users are, in my experience, often not interested in this line of explanation). Have you ever called your telecom, heard that your pain is actually the result of latency issues or “experimental” cell towers, and then sighed in relief and said “well! now that you put it that way, it’s not so bad!”

Be empathetic. If you can’t solve the issue with a clearly worded response and instructions, try to appreciate the user’s situation, and make even a minor suggestion (another service that may suffice, for example) if you can. And hey, some cases will require that you get a little more technical in order to dig into the issue and find the problem. Support is ultimately about listening carefully and then responding with the right tone and voice on a case by case basis.

Advertisements
%d bloggers like this: