Support is important. It can be the first interaction between your client and your company.
Support falls into three broad categories – there are other types of calls but when it comes to strictly support, these are the categories:
– “I want to do this, but I can’t (because I don’t know how/am doing something incorrect)”
– “I want to do this, but I can’t (because there is a bug)”
– “I want to do this, but I can’t (because the product doesn’t work in that specific way)”
The problem is that, unless the client is very familiar with the system, or the bug produces an obvious error, the language used is often the same for each type of call.
Support involves finding out which of the three scenarios applies to the call, and then figuring out the next steps to talk.
The first category is the easiest to deal with, generally. If you know the system, you can advise on the correct steps the client needs to take to achieve the results they want.
The next easiest is arguably the second category. There’s a bug. The next step is to try to replicate it yourself, which involves finding out what the client was trying to do – including the exact method – when they produced the bug.
Sometimes that involves digging deeper into the type of device and browser etc the client is using. This is where tools like http://supportdetails.com/ come into play – an easy way to get the information you need to replicate the problem yourself.
Once you’ve done that you need to write a bug report up so that the developers have the details of the bug, and, more importantly, what the correct or expected behaviour is. Sometimes these aren’t the same things – there is a discrepancy between what the client thinks the system does, and how the system was built, and its important to make sure the client is aware of how the system is meant to work, and how they can use the system to achieve their goals.
The final type of call – the one where the system doesn’t work the way the client wishes it to, can be awkward, but generally is okay once you’ve established that the client wants new functionality. You need to ask the correct questions to get a complete picture of what the client needs to do any why.
There are a few different methods to do this.
One person I know who heads up Quality Assurance at a digital agency is proponent of the 5 Whys method. Keep asking the client why until you are down to the root of their needs, and then you can work from there/help find the best solution. There are some critics of this method, disputing how useful they are if the ask-er isn’t an expert in the field for example, or the fact that, depending on the sub-method, different aks-ers may get different answers from the same ask-ee.
User Stories are another method of finding out functionality. They are written in language familiar to the client, and are short sentences describing one part of the functionality. They are often in the format of:
As a [role], I want to [goal]
Although there can be more specific stories depending on the functionality, simplicity is the aim of these. They are to try to understand and define the fundamental goals of your client and then you can decide how best to use the product you offer to help them achieve that goal.
The skills involved are often picked up on the fly, each call helping to hone and streamline the process, learning the best way to get to the bottom of the issue. Each client will be different, and so different approaches will be needed for each client, based on the type of person the client is, the type of business they run, but the basics are applicable to most support calls.