When the problem was no longer really the Internet
For several months, I worked with an Internet connection that was… let's say… chaotic.
At the time, I did not yet have fibre. Satellite was my only option for working from home. On paper, everything worked. In reality, repeated micro-outages kept interrupting my Teams meetings with clients and colleagues.
I called support more times than I can count.
I went through the same steps again.
I had my installation checked.
I wrote to the complaints department.
And all the while, I was improvising my own workarounds. My provider had given me a 4G hotspot, but its data allowance ran out quickly and topping it up was sometimes an ordeal. So I switched to tethering from my phone.
I even wondered why I was still paying for an Internet subscription… since I was spending more time on 4G than on my router.
Looking back, I realise I had become… my own support desk.
In the end, what irritated me most was no longer the outages.
It was the feeling of not being taken into account.
I had the impression that my problem was following a process… but that nobody was really carrying it.
The day someone finally took my problem in hand
Then one day, someone from the quality department called me.
She suggested that a level 3 engineer take over my case.
A few days later, Julien got in touch.
For several months, he called me back regularly. Every two weeks, then once a month. He kept me informed, tested new avenues, looked for solutions. He even managed to obtain a goodwill gesture and a Wi-Fi repeater that nobody had been willing to grant me until then.
But what struck me most was not that.
It was that, for the first time, I no longer felt like a case number.
My problem was still not solved.
And yet…
My experience had completely changed.
What this story taught me about support
A few weeks later, Julien went on holiday.
My case was naturally picked up by a colleague.
Technically, nothing had changed.
I was still being handled by level 3.
And yet my experience of it was completely different.
I felt I had become one case among many again.
So much so that I called support back… to ask whether Julien could call me on his return.
Looking back, that experience deeply changed the way I look at support.
At the time, I was convinced that what I wanted was a technical fix.
In reality, what I mostly wanted was to know that someone was taking my problem seriously.
What if we are asking the wrong question ?
Is the channel really the point ?
Today, I come across this situation in almost every assignment.
The discussions often turn on channels, features or tools.
And yet, when I put myself in the users' place, I find exactly what I felt that day.
They are not simply looking to log an incident.
Above all, they are looking to be taken into account.
And I believe that is precisely where user experience begins.
For some years now, the same question has come up with almost all of my clients.
« Can we raise requests through Teams ? »
Then come the next ones :
« Can we answer directly in Teams ? »
« Can people track their requests ? »
And almost always, the discussion narrows down to the channel.
Yet I am no longer sure that is the right question.
The real question is perhaps far simpler :
What experience do we want our users to have when they ask for help ?
Users do not choose a channel.
They are looking to be taken in hand.
Users are not looking for a portal
The portal is therefore not only a tool for raising a request with support.
It is a promise.
The promise that, behind a few clicks, someone will take over.
That is probably why some portals, technically very well designed, still struggle to be adopted.
As consultants or IT teams, we naturally tend to think in services, categories or workflows.
That is normal.
But users do not think the way we do.
They simply think :
« I have a problem. Who can help me ? »
Let's be honest…
Why should an employee have to know how the IT department is organised internally in order to report that their printer has stopped working ?
To my mind, the portal should not ask users to understand our organisation.
It should allow our organisation to understand the user.
That is the whole difference.
Designing a portal… without the people who will use it
Over my assignments, I have noticed a paradox.
We spend a great deal of time designing the ideal portal… but in the end very little asking the people most concerned what they actually expect.
Users often arrive at the end of the project, at acceptance testing or training.
And yet they are the ones who will use the portal every day.
I have often found that a portal designed with users is far better adopted than a portal designed for users.
Adoption does not start on the day it goes into production.
It starts on the day we decide to listen to the people the service is meant for.
We sometimes see that as an additional cost.
And yet…
What does a portal cost when users never really adopt it ?
The portal changes role
I do not believe the portal is going to disappear.
Quite the opposite.
I think it is going to become even more important.
But its role is changing.
Yesterday, it was the front door of support.
Tomorrow, it will be more like the front desk of the company's services.
A simple, reassuring place, able to guide users whatever their need, before directing them to the right person… human or otherwise.
In the end, the best portal is perhaps the one you use… as a last resort.
Because before it, there may be an answer in a knowledge base.
An automation.
A Teams conversation.
In the end, I am not certain that the portal is the heart of tomorrow's support.
What I am convinced of, though, is one thing.
Users are not looking for a portal.
They are looking for the certainty that someone will take their problem in hand.
The rest is ultimately a matter of technology.
That, incidentally, is what I was getting at in the first article in this series : the best ticket is perhaps the one that never existed.
In the next article…
Will artificial intelligence replace support teams… or will it finally let them focus on what really makes their value ?