Self service portals rarely fail on content. They fail on navigation. The answer is usually in there, filed under a heading the person would never have guessed, three clicks from a landing page that assumed they already knew which of nine categories their problem belongs to.
TL;DR
- A portal asks the user to classify their own problem before they can look anything up. Most people cannot, because classification is the expertise they lack.
- Portal search only works if the person guesses the vocabulary the article uses. A question does not have that requirement.
- The honest measure of a portal is not visits. It is the share of visitors who then opened a ticket anyway.
- A conversational front end is not a replacement for the content. It is a different index over the same articles, and bad articles stay bad.
- Portals still win for anything with a form, an approval or a status to show. A question cannot replace a request that needs tracking.
- Keep the portal, change the entry point. The expensive mistake is rebuilding the content when the problem was the front door.
The classification problem
A portal landing page offers categories. Hardware, Software, Access, Network, Accounts, Printing, Mobile, Other. To get anywhere the user must decide which one contains their problem, and that decision is the single hardest thing you have asked them to do.
My video calls keep dropping could sit under Network, Software, Hardware or Mobile depending on the cause, which is exactly the thing the person does not know. Somebody who could categorise the problem correctly is halfway to fixing it, and would probably not have come to the portal at all.
So the structure that makes a portal maintainable for IT is the structure that makes it unusable for everybody else. Categories group by cause, and users arrive with symptoms.
What a search box cannot do
Most portals answer the classification problem with search, which helps and has a specific limit: keyword search only works if the user guesses a term the article actually contains.
The vocabulary gap here is wide and consistent. Users search for wifi and the article says wireless network. They search for my password and the article is titled Credential Management. They search for the thing they see on screen and the article describes the underlying service by its project name. Each of those returns nothing, and a portal that returns nothing teaches the user that the answer is not there.
A question-shaped interface removes the guess, because the system matches on meaning rather than on the exact word. That is the entire mechanical advantage, and it is a real one. It does not make a thin article thorough.
Measuring a portal honestly
| Metric | What it actually tells you |
| Portal visits | Nothing. Visits rise when people cannot find things |
| Article views | Little. A view is not a resolution |
| Visited then raised a ticket anyway | The real failure rate, and usually uncomfortable |
| Searches returning nothing | The vocabulary gap, by exact term |
| Searches returning results, then a ticket | Content gap rather than navigation gap |
| Articles never viewed in a quarter | What is in the portal for no reason |
The third row is the number worth building first. It separates the two failure modes that every portal conversation conflates: people who could not find the answer and people who found it and it did not help. Those have different fixes and the aggregate figure hides which one you have.
The fourth row is nearly free and it is the fastest content improvement available. A list of search terms that returned nothing is a list of words to add to existing articles, no writing required.
Where the portal still wins
A conversational front end is not a general replacement, and pretending otherwise produces the opposite disappointment.
Anything with a form belongs in the portal: a request that needs structured fields, an approval chain, a cost centre. Anything with a status belongs there too, because somebody checking where their replacement laptop is needs a record rather than an answer. Anything requiring authorisation belongs there, since a conversation is a poor place to capture a decision somebody is accountable for.
The split is clean enough to write down. Questions go to the conversation. Requests go to the portal. The work is making the conversation hand over cleanly when a question turns into a request, which is the join most deployments leave unspecified.
Changing the front door, not the house
The expensive version of this project rebuilds the content. The cheap version keeps every article and changes what people meet first.
Checklist:
- Pull the list of searches that returned nothing, and add those exact words to the articles that should have matched.
- Retitle the top twenty articles as the questions people ask, keeping the formal title as a subheading if anybody insists.
- Put the answer in the first sentence of each article rather than after the background, since most readers stop at the answer.
- Measure visited-then-raised-a-ticket for one month before changing anything, so you can tell whether the change worked.
- Decide the question-versus-request split in writing, and route each to the surface that handles it properly.
- Leave the categories alone. They are for the people maintaining the content, and users will no longer be starting there.
Teams that do the first two items alone usually see the ticket rate on covered topics fall, because the content was adequate and the index was the problem. That is the cheapest available finding and it costs a morning.
Disclosure: Matram is owned by the same people who publish PeopleOpsHQ. It is relevant here because it sits in front of content you already have rather than replacing it, answering from your existing articles and documents, and it is priced flat at $29, $69 and $199 a month with unlimited seats, which suits a surface the whole workforce uses. It has no free tier, it answers questions rather than actioning tickets, and it is not an ITSM platform, so every request that needs a form, an approval or a status still belongs in the portal. The options are compared in our IT support chatbot comparison.
Final thoughts
The common diagnosis of a failing portal is that the content is bad. Sometimes it is. More often the articles are serviceable and the entry point asks the user to do the one thing they came for help with, which is working out what kind of problem they have.
Measure how many portal visitors raised a ticket anyway, pull the searches that returned nothing, and retitle the top twenty articles as questions. Then decide which contacts are questions and which are requests, and send each to the surface built for it. The portal is not the problem and it is also not the answer to everything.
Frequently asked questions
Why do IT self service portals fail?
Usually on navigation rather than content. A portal landing page asks the user to decide which category contains their problem, and classification is precisely the expertise they lack, since somebody who can correctly file a dropping video call under network rather than software is already halfway to fixing it. Categories group by cause and users arrive with symptoms, so the structure that keeps a portal maintainable for IT is the structure that makes it hard to use.
Is portal search enough to fix this?
It helps and it has a hard limit: keyword search only works when the user guesses a term the article actually contains. People search for wifi while the article says wireless network, or for my password while the article is titled Credential Management, and each of those returns nothing, which teaches the user that the answer is not there at all. A question-shaped interface removes the guess by matching on meaning instead of exact wording.
What should you measure on a self service portal?
The share of visitors who raised a ticket anyway, which is the real failure rate and is usually uncomfortable reading. Visits and article views tell you almost nothing, since visits rise when people cannot find things, while the visited-then-raised-a-ticket figure separates the two failure modes that every portal discussion conflates: people who could not find the answer and people who found it and were not helped.
What is the quickest content improvement available?
Pull the list of searches that returned no results and add those exact words to the articles that should have matched them. It requires no writing, it is usually a morning of work, and it closes the vocabulary gap at the precise points where real users have already demonstrated it. Retitling the top twenty articles as the questions people actually ask is the second cheapest, for similar reasons.
When is a portal still the right answer?
Whenever there is a form, an approval chain or a status to show. A request needing structured fields and a cost centre belongs in a portal, as does anything where somebody is checking progress on a replacement device, and so does anything requiring an authorisation that somebody is accountable for. Questions go to the conversation and requests go to the portal, and the work is making the handover clean when one becomes the other.
Should you rebuild the knowledge base or change the entry point?
Change the entry point first, because it is a fraction of the cost and it tells you whether the content was ever the problem. Teams that only add missing search vocabulary and retitle their top articles as questions commonly see ticket rates fall on those topics, which is direct evidence that the articles were adequate and the index was not, and it leaves the far more expensive rewrite as a decision you can make with evidence.