Customer support 101 for SMEs that sell software
Let's say, hypothetically, you're running a small company, you sell software on a B2B basis, and you're just starting to really grow the number of customers you have, and they have questions for you.
Congratulations! This is a good problem to have. You should set up a helpdesk.
You now have a problem
Chances are that right now, when one of your customers needs help, they pick up their phone or write an email to the first person at your company they know. This is likely to be the last salesperson whom they talked to. Their request for help then bounces around the business side of your company until eventually someone deals with it.
This is awful. People can get forgotten about.
Get some software
You really want to ASAP have a way to more-or-less automatically turn "Bob at the Ministry of Silly Walks emailed me 2 weeks ago" into a big red flashing alarm that says "SUPPORT REQUEST FROM BOB IS 10 DAYS OVERDUE" instead of just a nagging feeling in someone's conscience about how far their email inbox is backed up.
Get an off-the-shelf SaaS helpdesk system like ZenDesk or one of their competitors. Put all (non-trivial) support requests through it, so now they're being tracked in a single place instead of bouncing around peoples' inboxes.
(ZenDesk is one that I've used myself and would recommend, but they have lots of competitors and there aren't really any huge barriers to entry for going into this market. There are lots of good-enough SaaS products in this space.
(In theory a good CRM system might include the features that you'd need to use it as a helpdesk too, but I've never used one.)
You should buy this off the shelf rather than making one yourself. Writing a helpdesk system yourself will cost way more (in staff time, and opportunity cost) than just buying a cheap monthly SaaS one.
Get some people
Hire at least one person with the job title "account manager" or "customer support agent". You should be able to choose how many to hire with a simple ratio - hire one CSA per every X customers, where X is some constant specific to your market and product.
When you're starting out, you can estimate this by counting up the number of hours that are being spent by your existing staff on dealing with requests from customers for support, and dividing by the number of hours in a full-time work week.
Getting usable bug reports out of people
A related problem is that you'll be bug reports comprisonly only the words "the website is broken!" This aren't delightful to deal with; making your technical people have to investigate to reconstruct the entire context from scratch (broken for whom? broken how?) is a waste of both money and the customer's own time waiting for an answer.
Giving your customer support agent (CSA) a template list of standard questions to ask will help. "Where are you connecting from, work or home or the surface of the moon? What browser are you using? Does it work if you try from your phone on 3G?" Maybe don't pepper the customer with all your standard questions if you already definitely know the answer to some.
As an experiment you could try putting up a web form somewhere that asks all these questions and then dumps the output into a new support ticket. I wouldn't bank on funnelling all support requests through something like that though, because I'd expect random strangers to prefer using nice familiar tools like their telephone and their email client in order to ask for help, rather than some weird one-off web app that they've never seen or heard of before. I would be very, very, very unsurprised if it turned out that at least one SaaS customer support portal has this already as a built-in standard feature.
An aside: get automated website monitoring (there are tons of cheap SaaS for this) so that, if the website really is completely down, you find out before your customers do. Email your customers to apologise for the downtime and reassure them that you're working on it before they have time to ring you up.
How this works in practice
At my previous job, we used ZenDesk for organising customer support tickets. It worked pretty well. A customer would email our support address, which would automatically generate a ticket in ZenDesk. Each ticket would act like a little mailing list that you could CC yourself in on if you thought that ticket was relevant to you. The customer just sees a nice straightforward email chain, and pressing the 'reply' button in their mail client gets their response to the right people.
Alternately, the customer would email one of our support reps directly, and the CSA would do put that email into ZenDesk, creating a support ticket and then everything worked just the same from there.
For dealing with requests that come in by phone (that aren't just simple 5-minute "oh the button's over there, under the blue wibbly thing, next to the little spinning Illuminati pyramid"), the CSA would write the usual kind of follow-up email that you'd normally write to a customer after any phone call (what was discussed, what happens next, etc), but instead of emailing it to the customer, they'd put it into a new ZenDesk ticket, subscribe the customer to it, and have ZenDesk email it to the customer. So then conversation can be continued later by email with the same interface and there's a record of what went on, in the same place as all the other support request tickets.
ZenDesk's web interface for the customer support agents is simple to use and reliable (though it warms up your laptop with the odd megabyte of JS here and there, but oh well nothing's perfect).
We didn't bother trying to unify customer support tickets in ZenDesk with developer tickets in $TICKETING_SYSTEM_OF_THE_WEEK (Jira, Trac, Trello, whatever). When there was a customer support request that needed a nontrivial amount of dev time or a bug fixed, we'd manually put the URL for the dev ticket into the private notes on the ZenDesk ticket, and vice versa. Worked well enough.
Offhand I think ZenDesk have a pleasant-ish REST web API if you really want to automate things and/or make a huge mess for yourself.
© Copyright 2017 Richard Barrell