Having adopted a new cloud application, it needs to be acknowledged that your team is likely to need some ongoing support. This may relate to process issues, features in the application they are having problems with, or perhaps features they are not currently using that may add some value.
We frequently observe problems that if dealt with earlier could have largely been avoided. If you take a couple of steps back from what each cloud application functionally performs, they all boil down to managing data of some sort. When errors occur, it’s generally fairly easy to address one or two pieces of data that are incorrect. If those errors don’t get dealt with though, you end up with more, and more problems to deal with. Not only that, but often one item of data is reused and affects data in other places, so errors flow through the system, causing problems wherever they go.
Then there’s the question of adoption and engagement. Are your team using the system in such a way that they are getting maximum benefit from it? It will be very difficult for them to if they face problems that don’t get addressed. How you provide support really depends on the size of your team and complexity of your processes - as you’d expect. As we refine and adjust our premium support service, the below are the areas we try to remain focused on at all times.
Intent - why do you provide the support you do?
We all know how infuriating it is dealing with a bit of software or computer that you can’t quite get to grips with. Or fixing problems that you know ought to have been dealt with far earlier, before they landed on your desk. By ensuring that people are adequately supported when using software, you get the chance to remove that frustration. To make a tangible difference to how much people are enjoying their jobs.
Along with that, of course there’s a real opportunity to continually improve your processes and business systems by listening to your team and identifying further streamlining and optimisation.
For whom, by whom
The place to start is by thinking about who will be using the software, and what they’ll be doing with it. From there move onto who will actually be providing this hands on support. Because to be clear, when we say 'support', what we mean is assistance with performing a task or function - not the training that is required prior to provide background knowledge. If you have to provide support on specific functions on a recurring basis, then you may need to take a step back and start thinking about providing some additional training.
You may like to provide support internally, in which case you need to identify who will be responsible for ensuring that requests are dealt with in a timely manner. If they don't have all of the required knowledge and may require assistance on areas such as accounting practice or the finer details of the application, where will that come from? This may be someone else in your team, the application company, a professional advisor such as an accountant, or a cloud application integration specialist (like us - a shameless plug here, providing cloud application support is what we do, so if you want to discuss how we can help, we'd love to hear from you).
Make your channel clear - process, priorities and timing, cost
Everyone needs to know how they get support, how their requests will be tracked and resolved, the length of time it is likely to resolve issues of different priority, and if you have outsourced any part of the support, whether any cost will be incurred.
Because we deal with such a high volume of support requests each month, we use a ticketing system (Zendesk) to manage them all. You may not need to go this far, but we do recommend that you use a preferred method of submitting a request, and that this is email, not a phone call.
There’s range of reasons for this: it can be highly disruptive to the person providing support to get phone calls while they are working on other tasks; it’s difficult to keep track of the different requests that exist (while email isn’t ideal in this regard, it’s better than the phone and scribbled notes); and there’s no documentation of the issue that can be referred back to later in the process if needed.
Communication - the most crucial bit of all
It doesn't matter how much time and attention you put towards your support processes, if you don't ensure your team is well communicated with, you will always encounter problems. Of utmost importance is contacting the requester to let them know that you have received their enquiry. This is vital, there’s nothing guaranteed to annoy software users more than feeling like they are not supported or that their requests are being ignored.
It’s really simple to do this - reply, letting them know the request has been received, the amount of time you expect it will take to resolve it, and when you have it scheduled for. It’s often worth communicating back to the requester what corrective action you will take, to ensure that you don’t inadvertently make a set of changes which actually don’t resolve the original problem.
We’ve observed that many problems are exacerbated by miscommunication at the beginning of a support request, which leads to confusion further down the track. Try to ask for all of the information you need as early as possible, and if there are any grey areas or you are unsure of what the expected resolution is, work to clarify these before you make any changes.
Oh, and a note here about Replying All. You need to make sure that all relevant people are CC’d into emails, and that when they are replied to, that everyone remains CC’d. Otherwise people lose track and important information isn’t communicated - you can easily end up making changes that have the approval of one user, but for some reason aren’t acceptable to others.
Once everyone knows what work is going to be done, it’s a case of going away and making it happen. As you progress, communicate to the entire team how you are getting on, and if your understanding of the problem or length of time to get it resolved changes.
Estimating Time - it's harder than you may think
We felt that this question of estimating time deserved a mention in it’s own right. We like to think that we are good at estimating things, but if you think about how often you say, 'I’ll be there in 10 minutes', and it takes more like 20, you may start to realise that often our time estimates are inaccurate. This is the case even when we know exactly what we'll be doing - when dealing with an application support issue where a resolution isn't always immediately obvious, it becomes far more problematic.
When you have to estimate the length of time it will take to resolve a problem, tend towards being generous. It’s far better to say something will take an hour and for it to only take 30 minutes than the opposite. Don't fall into the trap of trying to look super efficient and on top of your game - if you don't know what the answer is, and how long something will take, say so.
Related to this, don’t under-estimate the overall amount of time that may be required to support your team using cloud applications. Yes, they are mostly intuitive compared to desktop applications and provide great user experiences, but problems do occur - whether they are bugs, poorly performing features, data problems, or user error.
Be the Fence - provide training and documentation
Of course, it’s all well and good providing support and fixing problems quickly and responsively, but it’s always better to prevent a problem from occurring than dealing with the symptoms. Providing adequate training at the beginning of a cloud adoption process goes a long way, and ideally training is complemented by documentation that evolves over time.
The time - and headaches - that will be saved is significant, which affects your bottomline, along with all of the opportunties to improve on your processes.
We believe that support is so important that we include a two month support programme in all of our implementation projects. We will not perform a project without this, as it’s fundamental to success. Countless software projects have been abandoned post-adoption due to users becoming frustrated and giving up, which is an enormous waste of time and money that can easily be avoided.