Support comes in different forms. Customer service is most common. But this also includes internal support, both helpdesk and staff manuals. Regardless of form, the challenges are similar. A problem arises — the person with the problem should find help, and it is the company's responsibility that the problem is solved.
We can call this process the support journey.
In many companies, it is snub and far too long. Limitations are found in the tools they use, but often it's a fundamentally wrong way of thinking that's fundamentally wrong. Here comes an attempt to think better.
Background: The elements of a typical support trip.
1. The person's problem arises
2. The person finds where to turn
This can be anything from finding the company's website. Find your way on the website. Call a phone number. Send me an e-mail. Here there is a clear transition in responsibility from the person with the problem to the company. The ball's on the other side.
3. The company identifies the person
4. The company identifies the problem
5. Disclaimers
6. Queue time
In most cases, a must-have with organizations. The resources do not exist and the processes are not in place to avoid queues. Here there is often talk of efforts to shorten them as best as possible.
Unlike the other steps, the queue time is dead time. Nothing happens. Just wait. Therefore, the queue time becomes the biggest bottleneck in the support journey.
7. Interaction with the person who needs help
8. Solution identified
9. The solution process is started.
10. The case is logged.
Problem: One step at a time.
We take an example from an experience I myself had recently with a big bank in Sweden. A classic invoice query.
I'm going to go to the website. I'll find the phone number. Here I first get to identify with BankID (before they even know what I'm after). Then I have to click through 3-4 button selections to identify my problem. I then spend 1-2 minutes listening to disclaimers about recorded calls, personal data and customer surveys. A total of 5 minutes.
Then I'll be in line. Then in place 10 and will have to wait another 20 minutes.
Total waiting time 25 minutes.
Once in the conversation, 3 more questions will come to find a solution to my problem. I find out that my invoice will be sent out again. Then they need additional information to "make sure everything is right."
The call took about 10 minutes. So a total of 35 minutes from when I found where to turn until the problem weight was off my shoulders.
Solution: Take as many steps as possible during queue time.
If we go back to the different steps of the support journey, we can see that one step stands out. A step where nothing happens to move the case forward:
THE QUEUE TIME.
Therefore, we should ask ourselves:
1. What is the least possible we need to queue a person?
The goal is to queue the person as soon as possible — so that the person gets help as soon as possible. easily. All we have to do is identify the problem to know which queue the person should be placed in.
2. How many steps can we complete in parallel with the queue time?
The easiest to start with are disclaimers. Instead of playing "sorry to wait" repeated indefinitely during the queue time, this can be a great opportunity to play all the disclaimers in peace and quiet.
The next level is to identify people during the queue time. Why not start the BankID connection instead of making it an extra obstacle at the beginning of the conversation?
As the cream of the crop, we let the person answer as many questions as possible that make it easier to find a solution to the problem, but also easier to log the case afterwards:
- What order number do you have?
- What department are you working on?
- Have you tried that X?
If we do this, we don't just fill the queue time with purpose. We shorten the handling time afterwards, which means that.....the queue time will also be shorter 🤯
Not just phone
Example chat:
A bot collects as much data as possible and identifies the person with, for example, BankID connection before the chat is sent to the right department. The case is then logged with the same bot functionality after the interaction.
Example mail:
Mail is often a non-preferred channel, but a necessary evil for those companies with limited availability. It will be the only channel in the evenings and weekends.
And when it comes to email, it can be difficult to keep it effective once the issue gets there.
Therefore, the efficiency challenge is to divert as much traffic as possible away from mail. Can chat be introduced? Can as much traffic as possible help themselves through the website itself? What questions can be solved directly by phone? How can online help be increased through automated channels?
Example Internal Support:
Often there are ready-made troubleshooting processes that employees are willing to follow to help themselves. It is important to automate these as it becomes extremely inefficient to use such a precious resource as IT to do this manually.
The majority of internal support cases are about finding out which person is right to turn to. Then an automated sorting process becomes the right tool to streamline.
Think in parallel
This way of thinking about identifying bottlenecks and doing as much as possible in parallel with inevitable death time, can of course be applied to many areas of a company. It's also not a revolutionary way of thinking, and other features at companies have come much further here.
But in support, there's a lot to do. Although technology is much more modern today and more opportunities exist, companies are still stuck with mindsets limited by old technology that is no longer in use. They take it for granted that some things just can't be solved, and put Bamse patches on wounds that can be healed forever with a little common sense.
Here I would challenge you to go through your processes and look at them with this lens. Perhaps you will find something you can do today that can have a major impact on how your users experience your support?
