Six Things Standing Between Your Organisation and Self-Service That Works 

Six Things Standing Between Your Organisation and Self-Service That Works

Tags:
Posted: 27/04/2026 by Keyvan Shirnia, Chief Revenue Officer, Raido Oja, Principal Solutions Architect, and Gary Pruden, Chief Technology Officer

On user interfaces, undocumented processes, and why you can build a portal in an afternoon but spend three years on everything underneath it.

 

Raido: The user interface. That is number one.

 

Gary: I would have said the same thing.

 

The snow on York Avenue had not let up. We had been in the diner for over an hour by then, the three of us, with a cancelled meeting and nowhere else to be. The conversation had turned to self-service. I asked Raido and Gary a simple question. What actually stops self-service from working?

Raido did not hesitate. Our plates had been cleared twenty minutes ago but our cups were still full. The waitress had figured out early on that we were not going anywhere and had stopped asking if we needed anything. She just kept the coffee and tea coming.

 

Radio: There are a few things that come into play here. The first is the channel itself. Do people actually want to go to a portal? Do they want to log into a separate application to self-serve? If you have to open something new, authenticate, navigate a page you may have never used before, that is already friction. If you have single sign-on, fine. If it happens to be inside Teams where you are already working all day long anyway, would that not be even better? Self-service should live where you are. How it is accessed is a massive thing.

 

Keyvan: And then once you are in?

 

Raido: How easy is it to use? This is what I hear from every single customer when we start a new implementation. The first workshop we do, designing their service catalogue, the first piece of feedback is always the same. Our current catalogue is so hard to use. I cannot find anything. The forms are difficult to fill in. Over and over. User experience is absolutely number one.

 

Keyvan: But most of these portals are built by IT. Surely IT understands what users need?

 

Raido: That is exactly the problem. IT builds it. Most of the time they do not include marketing. They do not include web design. They get a platform developer to design the portal and that person may know very little about UI design.

 

Keyvan: Wait. Marketing? In a service desk project?

 

Raido: Yes. And the service desk as well, because they understand end users. They are on the phones and emails all day. They know the language end users use. They know what kinds of problems people are having. And you need an SME to design the end user experience. UI design concepts are very specific. The padding, the tone of the background colour. Small things that make a big difference. It needs to be pleasing to the eye. It needs to be inviting. And then simple to use.

 

I thought about the diner we were sitting in. Someone had thought about the layout of this place. The counter for people in a hurry. The booths for people who were staying. The menu readable in thirty seconds. None of it was complicated, but all of it was deliberate. Most service portals feel like they were designed by someone who has never had to use one.

 


Keyvan: All right. What is number two?

 


Raido: Content. And this is where people are really struggling. It starts with having a good knowledge base. If you are not getting the answers you are looking for, you are just going to Google it or talk to a chatbot. And then there is the service catalogue itself. You need to hit critical mass. If what users need is not in the catalogue, they are going to pick up the phone.

 

Gary leaned in. He had been stirring his tea with more patience than diner tea has any right to expect.

 


Gary: We had one customer, not that long ago, where something like seventy-five percent of everything they had was categorised as Other.

 


Keyvan: Seventy-five percent?

 


Raido: Ha. That does not surprise me one bit. Seen it too many times.

 


Gary: Just a form on their portal that said Other. And what happens is it workflows to an agent who then interprets it and does something with it. So how is that self-service? All that portal was doing was acting as a communication mechanism between the end user and the service desk. And what does the agent do as soon as they get that request? They phone the user up to find out what they actually want.

 

That number stayed with me. Three quarters of everything going through a single form that adds a step rather than removing one. The portal had not enabled self-service. It had created an extra layer of administration between the user and the person who was going to help them anyway.

 

Keyvan: So there is a critical mass problem. Below a certain threshold the catalogue actively pushes people away.

 

Raido: Exactly. And a lot of our work is about analysing what is in that Other bucket and making sure the catalogue has the right things in it. You want to minimise that percentage right down.

 


Outside, a delivery van moved slowly up York Avenue with its hazard lights on. The headlights of the cars behind it were barely visible through the snow. The fog on our window had thickened to the point where the neon sign from the pharmacy across the street was just a pink blur.

 


Keyvan: Number three?

 


Raido: Business processes. And this is the one that catches people off guard.

 


Keyvan: In what way?

 


Raido: Let us say you get the UI right and you have the content and a good knowledge base. If you do not know what your business processes actually are, none of it matters. And quite often customers only start thinking about it when we start talking about self-service and automation. Because at that point you are suddenly forced to write it down or explain it. What is the process? They are so used to just doing it. A ticket comes in, they deal with it, they ask someone. They have never really had to think about what the steps actually are.

 


Keyvan: And it is all in someone’s head.

 


Raido: That is exactly the problem. No formal processes. Everything done case by case. And once customers realise how big a job it is to actually define what they are doing day to day, that is where a lot of them lose their nerve and fall into the old status quo. Let us just keep doing what we do now.

 


The waitress appeared and put down a plate of something none of us had ordered. She looked at Gary. “Pie. On the house. You have been here two hours.” Gary smiled at her and said thank you in that quiet way he has.

This is one of those things that self-service exposes rather than creates. The processes were never documented because they did not need to be. When a human being is interpreting every request, the knowledge can stay in people’s heads. The moment you try to automate, you need to codify. And codifying something that has never been written down is where the real work begins.

 


Keyvan: How many is that now?

 


Raido: Three. It feels like more.

 


Keyvan: It does. Go on.

 


Gary: Number four is data. And specifically, people data. We went to one retailer where none of the people in the store apart from the manager were even recognised on the system. He was the only one who could log a ticket. If he was not around, nobody could raise anything.

 


Raido: And it is not that those people are not digitally literate. They are literally not in the system, or at least not in the system that we are aware of. They work for the company. How are they not in the system that allows them to raise a request?

 


Gary: We see this in retail a lot. Gas station operators calling their manager to log tickets even though they all have phones in their pockets. Associates on the shop floor walking past problems all day and having to go to the back office to get someone else to report them. The channels are there. The devices are there. The people are just not enabled to use them.

 


Raido turned his cup slowly on the saucer.

 


Raido: And then there is the data quality itself. We had one customer with three separate sources of people data. Associates coming from one system, vendors from another, and independent customers from a completely different external database. All managed differently. All kept up to date differently. And they all use the same services.

 


Keyvan: So, if the system does not know who you are and what you are using, the whole thing falls over.

 


Raido: The expectation from a user is simple. I pull up a page, I am logged in, you know everything about me, you know what devices I use and own. When I have a conversation with the chatbot or fill in a form, I should only need to tell you what I need and not have to explain who I am. That is the maximum you should need to ask. We should not be asking users where they are or what device they are using. That is absurd. But it is still happening everywhere. In fact, let us be more ambitious here. In many cases I expect a self-service system to also know what I need, based on my role, my location or the devices I use.

 


A snowplough rumbled past the window. For a moment the whole diner shook slightly and the cutlery rattled on the counter. Then it was quiet again. I counted the inhibitors. The interface. The content and catalogue. The business processes nobody has written down. The data and identity problems underneath. Four things, and we had not touched technology once.

 

Keyvan: Please tell me there is not a number five.

 


Raido: Approvals.

 

 

Gary laughed.

 


Raido: All the automation in the world is not going to help if you are waiting for a manager to approve something. Approvals go stale very quickly. If you do not deal with them straight away, they just sit there. I requested a new mouse and it sat unapproved for two weeks.

 


Keyvan: Two weeks. For a mouse.

 


Raido: It is not that the organisation cannot afford a mouse. Or, should a new mouse even need approval? The approval email went into a black hole and the manager does not even know what the request is. So what do you do? You pick up the phone. You drop them an email. And at that point the whole self-service model has broken down. The user went through the effort of using the system and still did not get a result.

 


Gary: That is how you train people not to use the system. One unanswered request and they never come back.

 


Keyvan: And number six? There is a six?

 


Gary: Adoption. Adoption does not happen by itself. You have to be persistent. You need a communication strategy. You need to understand your audience because the services that IT needs from the catalogue are very different from what end users need. You have to personalise. The capability exists in the platforms to do it. You can show people what is relevant to their role. But most organisations do not do it because defining the roles and entitlements is another piece of work they have not done.

 


Raido: And you have to think about who your users actually are. We worked with a healthcare organisation that was also looking after people in care homes. Digital literacy was quite low. So you have to ask, is self-service actually accessible for these people? What devices do they have? Is it mobile only? You really have to look at how people access things and what is appropriate for them.

 

I looked at the list. Six inhibitors. Interface. Content. Processes. Data. Approvals. Adoption. None of them are about building a portal. The portal is the simplest part of the whole thing.

The pie was gone. I am not sure who ate most of it. Gary put his cup down.

 

 

Gary: You know what I am realising as we talk about this? This is not about self-service. It is about everything else around self-service. Self-service is almost the easy bit. We can knock a portal together in an afternoon. That is not the problem. The problem is the data, the knowledge, the business processes. That is what takes the time.

 

Raido nodded. It was the quietest agreement I had heard all morning, and the most definitive.

I thought about that sentence as we wrapped our scarves and pulled our coats on. Self-service is the easy bit. It sounds counterintuitive. It is the thing organisations invest in, the thing that appears in the business case, the thing that gets the slide deck and the steering committee. And it is the simplest part of the problem. The hard part is everything underneath it. The beams.

We stepped out onto York Avenue. The snow had not let up.

Same house. Different room.

 

Keyvan Shirnia is Chief Revenue Officer at Fusion GBS.

Raido Oja is a Principal Solutions Architect based in New York and a long-standing member of the Fusion GBS community.

Gary Pruden is Chief Technology Officer at Fusion GBS

This blog is part of The Six Critical Capabilities series. To find out where your service management foundations actually stand, the Fusion GBS scorecard gives you a benchmarked baseline in five working days.