Don’t just fix it for your customers, explain how you did it

Autopilot is easy – it’s the comfort zone of responding to a service request, fixing it and then moving to the next (probably similar) request. Invest some time in educating your users and cut the number of calls.

Stop drifting along and think carefully when the next service request arrives. What will you be explaining to the customer? Will you show them how to resolve the issue they have reported?

Assuming that it is reasonable to do so, you could be saving yourself considerable effort and at the same time empowering someone to work more independently having learned a new skill.

Here are my recommendations for reducing repeat service desk calls:

  • Explain how the problem arose – what caused it and is it something the user can both comprehend and fix?
  • Explain what you are going to be doing in order to fix the problem, assuming of course, that the user is able to understand the explanation.
  • Where appropriate, demonstrate to the user how they can prevent the problem from occurring (and that’s very different form just fixing it)
  • Finally, if it could happen again, even with preventative steps, show the user how they can fix it without needing to call for assistance. They will thank you for it!

Raise your next service desk ticket the right way

In a working age dominated by streams of endless email, often carelessly composed, it’s easy to send rapid fire requests for assistance to your nearest service team. Give them a helping hand and raise that service ticket the right way – your service team will thank you for it, and you will probably get a faster resolution!

When you don’t have to speak with anyone to request help, you are missing the important guidance questions that naturally form part of any conversation where a subject is being explained to another individual. Raising service requests using email is very easy, but should result in no less contribution from you than would be made in a one to one conversation.

Remember some basic email principles

The subject line needs to describe the problem. There’s no point opening a service request with a subject line like ‘help please!’. You are emailing a service desk – they know you need help! Make the subject line a concise description of your problem. Subject lines like ‘report fails to complete with error number 1001’, or ‘computer fails to start and reports disk missing’ are so much more useful and informative than ‘help please!’.

Keep your message body equally concise. You don’t need to write  a book about the problem, but instead offer a clear summary of the request that can be quickly read and digested by a reader.

Describe your request with care and thought

Consider each of the following as essential components of a service desk request. Omit any one, and you can be sure the service desk will want to ask them before the can provide a resolution.

  • Who are you – what is your role and the context of your activity
  • Where can you be found / contacted
  • What you were trying to achieve – put the task into context and what steps (if any) you have taken in order to resolve by yourself
  • When the problem occurred – sometimes the time of the problem is relevant, particularly if it happens to be affecting others too
  • Why is it important that your problem is fixed – are there specific deadlines that apply to your work? Will the broader business function be impacted by the problem you describe?

Inform the service team of changes to the situation

It’s really helpful for you to explain changes in the situation to the service team – when you do, your request might be re-prioritised as a result. This makes the work of any service team member much easier to prioritise. Remember that service team staff will be supporting many other users in addition to you. Problem fixed itself? Update the ticket and close it, with a suitable explanation. Problem changed or grown in significance? Update the ticket with a suitable explanation, including any changes to the possible impact of the issue.

Every problem is an IT problem, right?

Wrong.

The need to become more efficient, to adopt new processes, to work in new ways and within new structures brings plenty of opportunity – and also challenge. Wherever these opportunities and challenges emerge from, there is invariably a dependence upon Information Technology in facilitating a solution. Once this dependence on technology has been identified, it’s easy for each and every other part of a possible solution to become utterly dependent upon technology to deliver the whole solution, and often before other change takes place.

I don’t believe this should be the case. I believe everyone in an organisation today must be able to identify and implement solutions using IT; everyone should be able to contribute. They don’t need to be big and complex solutions – quite the opposite really. Small, simple solutions that can be owned by the staff who need them are often much more effective than those which require the support or contribution of highly specialist colleagues.

But the thing is, in my experience at least, most medium to large organisations have yet to realise that we have probably all been a little too singularly dependent on the IT department to solve everything for us. Technology has evolved beyond this; smart systems enable us to create solutions without the need to employ such experts. If we are struggling to deliver quick and flexible solutions, maybe our systems are outdated? It’s the smaller, more agile organisations that are able to capitalise on flexible solutions – cloud services and SAAS – that are leading the way, adopting new systems quickly to meet changing demands. Maybe in our larger organisations, staff are not sufficiently skilled in the tools they may already be using to achieve the best results. Ensuring the latest and highest performing systems are available is what the IT department needs to focus upon. Ensuring that staff are capable and empowered to identify and delver solutions is essential… but that’s not just an IT problem…