Before transitioning to the tech world, I always viewed customer or tech support as something to be avoided. A button to click or address to email only in the most desperate of times, when things just were not working. It would end up being a hassle, special numbers or passwords would be required, and responses were often lacking helpful solutions.
Since then, I’ve spent a couple of years providing customer happiness for Watu, immersing myself not only in customer service but also the wonderful world of software. In addition to being an eye-opener with regards to this magic little button of tech support, the industry has also come a long way in terms of customer appreciation, transparency and openness. Now, in fact, there isn’t just one access point to customer service – you have access via chat, tickets, Twitter, email and more.
Zappos’ incredible customer service focus has inspired others to give the ‘wow’ factor and suppliers have realised the value of happiness. And not just happiness in clients. Software companies like Automattic, Buffer and Baremetrics are leading a cultural revolution, hiring happy folk who genuinely have a passion for helping others. We don’t want to just answer your questions and close your ticket. We want to solve your pain point, make your day, ease your workload, simplify steps and put a smile on your face.
So how do you, as the customer, make the most of this change in heart? And what exactly do those responses you’re receiving actually mean? I’ve read through blogs and analysed my own experiences to provide 3 suggestions for decoding your tech support and maximising your customer service experience.
Your feature suggestions
Like most other startups, we have a path laid out for our app, but it’s a flexible one. One that can be scrubbed away and redrawn, or at least one that might ocassionally take a detour. This is where clients play a crucial role: the app is for you. Especially if you’re a heavy user and pay for the more expensive version of the app when available. It’s not that paying more means your ideas are more valid, but rather that you are clearly invested in the product, use it regularly, and therefore can provide the most applicable suggestions.
The fact is, maybe we, on the software team, have some grand ideas that we think will benefit you, but in reality if all our customers are pleading with us for X feature, chances are, we need to listen.
So what really happens when you put in a feature request? Well, check out the response tone to see if you can decode it. ¨Your request is being sent to developers for review and we may take it on.¨Ok, this is the most open-ended. What does it mean? Quite literally what it says. Your request will get added via another software platform like Trello or Jira as an idea for developers. Gain enough traction via requests from other clients, or a developer being particularly keen, and it may get the thumbs up. But don´t hold your breath.
What if the response isn´t so positive, yet more polite – something along the lines of ¨Thanks so much for submitting. That idea isn´t in the pipeline at the moment, but we´ll bear it in mind.¨ Dear clients, this is the gentle let down. The customer service equivalent of ¨It´s not you, it´s me.¨
The fact is, an app has many clients. And each client has their own specific workflows and needs. But most startups provide platforms, not customised software. What you suggested may be a brilliant idea for your business. But it could be completely irrelevant for everyone elses’. So it´s a no, and not just because developers´time is expensive, but because platforms have features that must be the same across the board, for all clients and the teams behind the product want to avoid ´product bloat´. Make a change in the former, and suddenly all clients have this appear in their account. And if you´ve requesteed a cat gif giving a high five for every win you make, the others may not appreciate it so much.
Errors in the account
This is normally why the support button is sought after and clicked. You´re running into a problem and it may be a bug, it may be your browser, it may be…anything. That´s the support team´s role to don the detective badge and find the source. But we don´t want to just find it. We want to find it with as little delay, with minimal communication (i.e. interruption to your day) and as efficiently as possible. Therefore the information that you provide can play a huge role.
The safest default in this case is: the more detail, the better
Providing the support team with a background – what were you clicking? Your stats (not 36-24-36…) like what internet browser are you using? Desktop or mobile? And what the error was, as in, what exactly did the error state and when did it occur? If you want to put a bow on top, throw in a screenshot. I, in all my geekiness, love a screenshot as it helps me to almost immediately diagnose a fix the error.
In our staffing management platform, for example, we might get tickets like the following:
Client: Your site isn’t working
Support team’s first reaction: Hmm. Which part isn’t working? It’s not loading? Or it’s displaying in a strange way? A specific feature isn’t doing its job?
Client: The staffer isn’t showing as booked on her job
Reaction: Which staffer? Which job? Which manager booked her, and when?
Client: There’s an error when I download payroll
Reaction: What type of error? Can you screenshot the page when it’s happening? Which payroll run? When?
You can see the pattern and what’s missing. Detail, detail, detail. The above type of ticket normally takes 2-3 more messages between myself and the client to determine the problem and provide a solution vs an initial email detailing everything that happened and, most likely, a response from myself saying it´s been fixed. I think we can all see the appeal of the latter.
To add to it, our software along with many others, have clients based around the world and that introduces something rather tricky: timezones. On most days, my clients submit and get a response with 24 hours, if not just a few hours. But sometimes, throwing varying workig hours and time zones into the mix means this back-and-forth can delay solutions tremendously. And that doesn´t usually lead to client happiness.
So overshare, spill it all, get verbal. Send us the whole story, and we´ll get back to you with a solution.
What about a good ol´ fashioned helping hand
The previos two points – feature requests and solving errors – applies to most tech software companies. As the customer happiness rep for Watu, I also believe wholeheartedly believe in the following for our service:
Get in touch.
Not just to report a problem, not just to suggest a feature. ¨Get in touch¨ isn´t just a canned mssage line or a polite way of signing off an email. It´s a genuine welcome, an open arms, encouraging clients to reach out for any help they may need in the software.
My goal isn´t to just solve your problems and have you on your way. I want to do this, and have you confidently using the software, making use of all the fine detail, and taking advantage of everything we have to offer. I know the software inside out and I want to share this knowledge. In our case, I relish the opportunity to take a pain point of a client and turn it into a task they didn´t realise could be so simple. Asking me the optimal way to build a complex job in the system, for suggestions on what type of questions to ask as part of their staff application form, if I can review their account and provide better workflow ideas. All of these are valid support team questions and offer me the chance to apply my knowledge creatively, whilst providing clients a step-up with the system. It´s a win-win.
So don´t hesitate to click that support button. Drop us a line (or rather, many) and give us that satisfaction of making our clients the happiest. Take advantage of all these ridiculously friendly customer support teams and share your questions, thoughts, and doubts. Go on, will you please get in touch?