How to help users describe their problem
And user support to answer them more quickly

In this article, we’re going to give you the keys to making it easier for your users to express the problems they may encounter when using your business software, and for your IT support team to resolve them.

Are your users stuck on a process? Don’t know how to report the problem? Describe it, or don’t have the time to do it? Is your support team overloaded with vague requests for assistance?

Getting the right information to the right person at the right time is the key to user support that works as it should.

Why does this problem exist and why is it important to solve it?:
Your users don’t always have the answer to their question at their fingertips: lack of training, user manuals not adapted to their context, out-of-date or incomplete online help and resources, etc.

These days, their questions no longer relate solely to office automation (a problem with Teams), but also to business processes. For example, a user may be lost when faced with a long drop-down list of purchasing categories when they come to make their annual request for equipment on the ERP, or may not know or understand all the complexities and subtleties of the time management rules in their HR space, and have questions about their holiday balance.

A training report that has not been validated, a field that is unavailable or misunderstood, a purchase request that is blocked, with the digitalisation of workspaces and processes, the digital workplace, all these operational bottlenecks have an impact on your organisation. A blocked purchase request will have an impact on your production flow, because the necessary materials will not have been ordered, delaying your deliveries to customers, your payments, and so on.

Users therefore have more reasons to contact their business support in order to be unblocked.

The problem here is that: the user doesn’t necessarily know what elements the support team will need to answer their question, resulting in an incomplete request for assistance, and numerous qualification rounds to resolve the incident. The user also doesn’t always make the effort to be precise, but goes for the most direct and short answer: “it doesn’t work”, without specifying which screen, which field, or what should work, etc.

What’s more, the user also needs to remember the ticket entry process, and use it wisely: what’s the right email address to send it to, how do I fill in the fields on my ticketing tool, or “what if I tried calling rather than sending an email to speed things up”?

The problem, apart from slowing down the performance of the employee who gets stuck on a task, is that the accumulation of tickets and time-consuming return trips to respond to them will overload IT support, and therefore increase its costs, in an economic situation where lower costs are the order of the day for IT administration services.

Table of contents:

Poor description of requests
Poor routing of requests
Tips to make it easier for users to express themselves

Poor description of requests

When we find ourselves in a situation where we are unable to make ourselves understood by the person we are speaking to, we often have the impression that we are “talking to a brick wall”. This can happen when we have more information but don’t deliver it entirely unintentionally. This makes it more difficult for the other person to fully grasp what we are trying to express.

This situation can be transposed to the professional environment when a user encounters a problem with a piece of software. Users are obliged to send a message to the support team to be unblocked.

It’s not always easy to express a need or explain a problem, whether in our personal or professional lives. Sometimes we have difficulty finding the right words to describe what’s wrong, or formulating our sentences in such a way as to explain what should work and be understood by someone.

Just as in everyday life, it is possible to omit details or inadvertently retain data in a simple email. This may be because the user is unaware of the essential information that needs to be provided, or because they are unfamiliar with the tool, or because they lack the time, or because it is too easy.

The support request process must therefore ensure that the requirement is properly defined, so that the support team has all the cards in its hand when it receives the request.

Poor routing of requests

The problem with a poorly described request is that, by extension, it is often poorly qualified and contextualised, and will therefore lead to routing errors towards the appropriate support person to solve it.

This is a rather vicious circle, in which an incomplete description and contextualisation will lengthen the time it takes to process a request, and thus the company’s overall performance.

When a user enters information incorrectly or does not provide enough context, there is a risk that the request will not reach the person who can solve it. Support agents then have to go back and forth with the user to obtain more information in order to get a better context.

Requests often arrive in the wrong place.
They have to go through X levels of support, with the problem being re-qualified and repeated at each level.
It therefore takes longer to resolve the problem, which leads to a loss of productivity, performance and time for repetition.

There are several levels in the IT support chain:

Level 1: generalist support agents, who qualify and deal with rapid requests concerning one-off, non-blocking IT issues and standard procedures: a problem with connection or rights and profiles, but not with expense claims, a blocked purchase request or unvalidated performance campaigns, which are the responsibility of the business and which they send to Level 2.
Level 2: support agents specialised in business processes, who solve common, blocking incidents, such as a block in a process due to blocking application maintenance, or related to expertise required for a process. They must identify the source of the problem in order to provide the user with a solution, or pass on the information to Level 3.
Level 3: application managers or Business Process Owners who deal with requests requiring a high level of expertise. They often don’t have the time to deal with these issues because they are too busy.

In addition to the fact that requests from these two levels require a higher level of work, making response times longer, Level 2 and 3 agents are overwhelmed: there are more and more requests, more applications to deploy, more projects to carry out, and therefore more time to deal with these requests. And everyone is going to ask for the context again at every stage.

Tips to make it easier for users to express themselves

Here are some tips you can implement to make it easier for your users to express themselves, on the needs and problems encountered in your application:

To reduce the solving time / processing time for a request, you need to increase the level of information available to the person handling the request.