Effective software support
Software

Software Support – A Guide To Effective Support

One of the side-effects of writing bespoke software is providing software support. Sometimes this is as simple as the odd bug-fix or security update. But more often than not you’ll be supporting the people using your software, and that can be a unique challenge.

Nothing can ruin a developers day faster than a phone call with the phrase ‘the system’s gone down‘.

Fortunately, the majority of issues are easily remedied, regardless of whether they are software or person-related. But sometimes it will be a more serious issue, and even worse, it could be your fault. We’ve all been there, and no matter how careful you are sometimes it will be because of something you’ve done.

Supporting yourself

Don’t Panic

When you’re under pressure it is easy to panic and rush out a fix, don’t. An extra few minutes testing is well worth it compared to a chain of premature fixes that themselves need fixing.

Be Honest

Nobody wants to admit they goofed, but a little honesty can help prepare the way for a more relaxed bug-hunt and fix. Putting pressure on yourself won’t help. Simply explain that you’ve made an error and you’ll work on the fix immediately. Then do.

Manage Expectation

If you don’t know how long it will take to fix an issue, say so.

Don’t say it will take an hour if you don’t know it will take an hour.

In the original Star Trek, the engineer ‘Scotty’ once admitted that he always doubled how long he thought it would take to fix a problem. When he fixed it before the deadline he looked like a miracle worker.

Whilst Scotty’s approach may be a little excessive, don’t set yourself and your client an arbitrary deadline, you will only put pressure on yourself and disappoint your client if you don’t meet it.

Software support is about people

Most software developers are quite happy working with their computers and will spend hours tracing and fixing a bug. However when faced with even a few minutes of having to support a person, many would prefer to be doing anything else, literally.

I used to find that supporting users was by far the worst part of day-to-day work.

But as they say, it’s all about perspective, and one day I had an epiphany. I started to categorise the people I was supporting into a few major types and this really helped me be more effective. Not only more effective at supporting the users, but in getting them to support the software. The four main types I’ve found are:

The Innocent

Broken Monitor

These are the users who inadvertently run into issues because the system lets them. I call them ‘innocent’ because these are the people you should write the system for and that software support exists to serve. You can almost entirely eliminate this group of support callers by making your system intuitive and easy to understand. Provide instructive and helpful feedback and ensure that every important action has a confirmation request “Are you sure?” and response “I’ve done it”. If you get a call from these guys it’s probably your fault and you have two options:

  • Live with the repeated support calls, emails or texts.
  • Redesign the part of the system causing issues. If you are charging a fixed support rate then making these tweaks for free makes sense. You get the same money but have to work less for it.

The Adventurer

Those who want to know how to do things (often as a result of pressure from their own clients or bosses) and end up being the ones that first encounter an issue. You’ll soon become familiar with these users, particularly when your inbox has a dozen emails from the same person, all asking things like “How do I do x?” or “I tried to do this and…” or “Can the system do x?”.

These used to be the users that made me angry, then I realised that actually, they are my greatest ally.

The constant barrage of questions can be exhausting. But if there is an issue in the software or a use-case I didn’t consider, these users are likely to find it first. This means that I can fix things before the main body of users encounter it. By sending these users out as a sort of make-shift beta-testing team, you are getting a lot of man-hours for free. I now find myself encouraging these users more often than not.

The Struggler

There are some who struggle. This can be for many reasons and it is all too easy to class these users as lazy, cantankerous or stupid. But sometimes people struggle for other reasons. Increasingly I find that my software is the first that some people have ever had to use in any meaningful way.

People who’ve only just figured out the basics of email are now being asked to operate a complex system on an unfamiliar device with pressure from all sides to perform.

It can be easy to mistake these users for adventurers at first. But they are very different. Yes, they may end up in some obscure part of the system, but it will be by accident rather than design. These people need software support, but often the demands of these users will exceed your allowed budget.

Handling these users can be challenging and generic software support is unlikely to be successful. In the past I’ve tried different approaches and found the key to success is matching the correct method with the right user:

  • Peer to peer tuition. Sometimes getting a colleague to show them the ropes is the most effective solution.
  • One-on-one tuition. An hour or two in a quiet room where the user can ask as many questions as they like often works miracles.
  • Ensuring their boss knows. It’s their manager’s job to get the best out of their employees, if there is an issue they need to know, a tactful email is sometimes all that is required.

The Lazy User

These users aren’t necessarily lazy, but they view using the software as a chore and resent everything about the task and by extension, you. These are the hardest to handle in my experience. The tell-tale signs of one of these users include;

  • Asking how to do something and then complaining that the procedure is too hard.
  • Not believing you when you tell them how quickly a task can be accomplished.
  • Repeatedly asking the same question over the course of days or weeks.
  • Expect you to fix errors they’ve made.
  • Sometimes combative or belligerent demeanour.

I’ve tried all sorts of approaches over the years when dealing with this group, but some people just don’t want to know. The most effective solution I’ve found is to gently and tactfully bring the subject up with their line manager.

Don’t call my baby ugly

The Frustrated User

Most people would never dream of calling somebody else’s baby ugly, even if it does resemble a purple prune covered in hair.

Very few people would approach an artist and tell them that a product of their endeavour is “rubbish”.

Almost everyone is happy to tell you that your software is **** when it’s not doing what they want.

What many people fail to realise is how much like art software development is.

Elegance and creativity go hand-in-hand with writing software, and a lot of programs really are works of art. Most programmers are justifiably proud of their work, for which they are often underpaid and normally under-appreciated. But when a frustrated user tells you that your baby is ugly (or a lot of other four-letter words) it can be hard not to take it personally.

It isn’t personal (usually).

It’s just like trying to hammer in a nail, if it goes wrong it’s easier to blame the hammer or the nail than it is yourself. To most people, your baby is simply a tool, a complicated hammer, and one that is currently not doing what they expect it to. So try not to take it personally.

Dealing With Negativity

When the calls start coming in at night or over the weekend it can be easy to get angry. It’s amazing how many people seem to think that sending you a text at 6am on a Sunday is OK.

In the past, I’ve had to literally drop everything and go for a walk after dealing with some end-users. But remaining calm is the only way to fix things, and the last thing you ever want is for people to think of your support as “difficult” or “awkward”.

Dealing With Abuse

Don’t. Terminate the conversation immediately. Nine times out of ten that fixes the issue, permanently. If it doesn’t, report it to their manager.

But be sure it is abuse. If someone doesn’t like a feature of the system and calls it a name, no matter how unjustified, that isn’t abuse. If they call you a name, it is.

When the support demands grow

You want to help, you allow people to call you, email you, text you. But you can’t remember the last time you had a day off. You start to dread the phone ringing or new email notifications.

At this point make sure you have a dedicated support phone number and ensure that people use it.

You can turn the phone off when you finish for the day have some quality time to binge-watch “Tales from the loop”. Same goes for your email, institute a “support@” address and check it periodically, rather than being constantly nagged to check it by notifications.

Keep A Log

Note every call, email and text. Record the time, the duration, the subject and the user. Then work out how much time per month you are spending on support versus the amount you are charging. If it is below what you are comfortable with either:

Try to reduce the support demands using the methods in this article. Or approach the relevant individual at the company and discuss the situation with them. In my experience, the rate of support calls will either radically drop-off after this conversation or you’ll walk away with more money.

Either way, everybody is being treated fairly.

Finally

Supporting users is challenging and often thankless, but it is something we must do.

Effective support is a key factor in retaining existing customers and gaining new ones.

By considering the support aspect of software from the outset it is possible to make better systems and have fewer frustrated users. By embracing user support as an intrinsic component of the system it is possible to significantly reduce support requests. The easiest way to do this is by ensuring that your UI is friendly and intuitive. For more complex tasks it is important that adequate guidance exists on the page. Where necessary a ‘wizard’ or guided process should be instituted. All of these can dramatically reduce support requirements.

This article is based on over 20 years of supporting users. I hope you’ve found it helpful and learn something from it, I just wish that I’d found an article like this when I was starting out.

Featured image by Nick Youngson CC BY-SA 3.0 Alpha Stock Images