In support of user support

One of the first tasks I undertook for the ePortfolio system that I work on was to develop a useful support system. By this I mean a means of receiving, tracking, and dealing with user queries and problems. So if you’re thinking of setting up your own CMS and not spending a squillion quid on an out-of-the-box version then here are a few pointers:

1. Status – what can your user see happening to their query? With the support system users, when logged in, can see a list of all queries they’ve made and at what stage/status they’re at. If it hasn’t been touched, a developer will see a red box with Not Started written in it. You don’t want users to see that! What they see is ‘Under review’. Once the query is being looked at, the status switched to “Analysis” – this might last days, but it’s a purple box. Usually, the problem gets dealt with immediately and the status can be put to “Completed”. This moves the query on to a second “completed” list, both for hte developer and the user.

2. Communication – naturally you want an autorespond to the initial enquiry “Thanks for contacting us ….”. Even though users are usually savvy enough to know it’s automatic, at least they know it’s in the system. The autoreply also gives them a query id number so they can quote it in any future communication. It’s still a good idea to keep in touch with the user, just to let them know you’re a human at the other end and you are dealing with it. That can buy you a lot of time too.

3. Speeding things up – Apart from the actual time-consuming process of fixing the problem, your written responses can be done much quicker if you have a pile of stock sentences that seem to get used frequently: “Sorry for the inconvience caused”, “Thank you for drawing this issue to our attention”, “Why do we have to deal with idiots like you” (ok, I made the last one up – I just think it). I save these into the database and use AJAX [you’ve mentioned this already – Ed] to place it appropriately into my response.

4. Closure – When the problems fixed make sure it actually is fixed! When you close the query you really don’t want them coming back to you with “you’ve only half-sorted it..grrr!”. Although a finished item is closed, I set up the system to flag up replies even to closed items. They’re usually just “Thanks” but you can’t be too sure. One last thing, at the end of you message saying “I fixed it”, still have a sentence saying: “If you have any more problems please get back in touch” or words to that effect. Deeper problems get picked up this way and users don’t feel fobbed off.

User support can be central to getting a site that works properly, with happy users who feel they are valued and listened to. Users are the best testers, not only because they identify the more obscure bugs, but they also point to frequent user errors. An example of this: our site has a lot of forms to fill in. People began to complain that they’d spend ages filling in a form only to find their session was timed out when they came to submit it. Ok, so we set up a cookie-based method to re-log them back in. Also, we put the session timeout period up to 120 minutes when filling in a form. This still didn’t deal with all the errors. Just user error left – filling in forms but not pressing the submit button. It happens on many occasions. So in went some script to try to catch them that stray from the un-submitted form. Now, when someone says they filled in a form and it didn’t save we can confidently say that it was almost certain down to something rather complicated that’ll take ages to figure out – doh!

In summary, don’t just consider user support as a chore to stop them from bugging you about this and that. Build a simple system to manage the calls as it’ll saves you time and ultimately lead to a much better site with much happy users.


About this entry