Why Users Bypass the Portal: Five Reasons and a Diagnosis

Tuesday, 09:40, at Meridian Parts. Dana runs the three-person desk and is pulling last week's numbers for the operations director. Seventy-eight tickets. Sixty-one came by e-mail, fourteen by phone, and three through the portal. One of the three was Dana testing the portal on Friday afternoon. The portal went live in the spring with an all-staff e-mail, a poster by the kitchen and a line in everyone's signature. The director's question, when he sees the numbers, will be the one Dana has been dreading since the spring: "So why did we buy a portal?" The answer she has is "people just prefer e-mail", which is true, and useless, because it does not tell her what to change.

A self-service portal is the web page where a person can search for an answer and ask the desk for something. They can also see what has happened to the things they have already asked for. They can do all of this without e-mailing or phoning anyone. Bypassing it means doing exactly what the portal was built to replace: sending the e-mail, making the call, walking over to the desk. People do this for five reasons, and the five look identical from the desk. That is why the usual response, another announcement, so often fixes nothing. This article is part of our Self-Service Portal Adoption series, and it is about finding out which reason is yours before you touch anything.

It covers why the only comparison a user ever makes is with e-mail, then the five reasons one at a time. The article shows what each looks like from the desk and where its fix lives. A table tells them apart. Next come the one-week diagnosis, which is mostly five conversations, and fixing one reason at a time. The article finishes with a short war story and the bypass diagnosis sheet to copy, in that order.

The Only Comparison a User Makes

A user does not compare the portal with nothing. They compare it with the easiest thing they already do, and for nearly everyone that is e-mail. The mail client is already open. The address is remembered after the first letter. The sentence is half-written in their head before they start typing. Eight seconds, no new page, no password, no decision about which category a broken screen belongs to. That is the standard the portal is measured against, every time, by every person, at the exact moment they need something.

The portal gets no credit for being better on paper. It can have a searchable knowledge base, a form that asks the right questions and a status page that would save the requester three chasing e-mails. None of that counts if, at the moment of need, it is one step longer than e-mail. "Slightly harder than e-mail" is a fair description of most portals and a complete explanation of their adoption. Nobody has ever opened a help desk portal for pleasure. They open it because it was, that minute, the fastest way to get the thing.

This is better news than it sounds. You do not have to change people, which is slow and mostly impossible. You have to change which path is shorter, which is engineering, and there are only five ways the portal's path gets longer than e-mail's. Each has its own signs, its own test and its own fix. Each also has a wrong fix, which is the one that gets applied when the desk guesses, so the rest of this article is about not guessing.

Reason One: E-mail Is Easier

The first reason is the plain one. The portal works and people know it exists. They e-mail anyway because e-mail is in front of them and the portal is a bookmark they would have to find. Nothing is broken. The portal is simply further away than the mail client at the moment the screen goes black. A person with a black screen and a meeting in ten minutes takes the nearest door.

It happens because every extra step is a reason to stop. The portal asks for a browser tab, a web address the person half-remembers, perhaps a login, then a form. E-mail asks for a name. The desk sees the two paths as "the right way" and "the old way". The user sees them as "four steps" and "one step", and the user is counting correctly. The desk's own technicians, when they need something from facilities, e-mail. Ask them.

The signs are tickets by e-mail that are polite, reasonably complete, and come from people who, when asked, say "I know about the portal, e-mail is just quicker." There are no complaints about the portal at all, because nobody has used it enough to complain. The fix is to shorten the portal's path until it is as near as e-mail. Add a shortcut on every desktop with a plain name, the link in every signature, and the link in every acknowledgment. That is the whole of Promoting the Portal Without Nagging. You will never make e-mail harder, and you should not try. You make the portal nearer.

Reason Two: The Portal Is Slow or Empty

The second reason is that the portal, when reached, does not deliver. Slow means the page takes several seconds to appear, the search takes several more, or a login bounces through the directory twice before the page loads. Empty means the search box returns nothing, because the knowledge base behind it has nine articles and six of them describe the desk's own internal procedures. The user did exactly what the poster asked and was told, in effect, to go and ask somewhere else.

An empty search result is the portal saying "no" in a font. It is also the most common portal experience on a desk that launched the page before writing the articles. That is most desks, because the page takes a day and the articles take a quarter. The user searches "wifi", gets nothing, searches "wireless", gets nothing, and concludes, correctly, that the portal does not know anything. They will not search a third time this year.

The signs include searches with zero results in the portal's own logs, where the tool keeps them, and many do. There are people who say "I looked and there was nothing". There is a knowledge base with fewer than twenty articles, or twenty articles written for technicians. The fix is content before anything else, starting with the ten questions the desk answers most often. That is the subject of The First Twenty Articles. The speed problem is separate and simpler. Time the page from a laptop on the office floor, not from the server room. Fix whatever takes more than a few seconds before anyone else is sent there.

Reason Three: The First Visit Failed

The third reason is history. People try a portal once. The first visit ends in one of three ways. They find the answer, they raise a request in about a minute, or nothing useful happens. If nothing useful happens, the portal is filed in memory as "the thing that didn't work". That memory outlasts every poster, every reminder and most reorganisations. The person is not refusing to use the portal. They used it. It failed. They moved on.

First visits fail in predictable ways. The link in the welcome e-mail went to a login page and the person had no login. The search returned nothing. The form asked for an asset tag, which is a number on a sticker on the underside of a laptop that the user has never turned over. The confirmation screen said "Thank you" and nothing about what happens next. Each of these is small. Each ends the visit, and the visit was the only one you were going to get without earning another.

The signs include a spike of portal activity in the launch week and a flat line after it. There are people who say "I tried it once". There are new starters who use the portal in week one, because they were shown it. They e-mail from week two onward, because week one went badly. The fix is to make the first visit succeed on purpose, which is its own article, Making the First Visit Succeed. The fix is not another announcement. An announcement invites a second first visit, and a second first visit has to be earned, because the first one spent the trust.

Reason Four: Nobody Told Them

The fourth reason looks like the first and is not. The person genuinely does not know the portal exists, or knows one exists and not where. The all-staff e-mail was read by the people who read all-staff e-mails, who are a minority with a particular temperament. Everyone who started after the launch was never told. The warehouse, the shop floor and the night shift do not have e-mail open all day and did not see the poster. It is by the kitchen in the office building. The all-staff announcement is the industry's favourite way of telling everybody something once and being surprised about it for ever.

It happens because announcing feels like finishing. The portal was built, the e-mail was sent, the task was ticked, and from the desk's side the information has been delivered. From the user's side a message arrived on a Thursday among forty others, with a subject line that began "IT update", and was gone by Friday. Information is not delivered when it is sent. It is delivered when the person needs it and it is in front of them.

The signs include the words "what portal?" in replies and whole departments with no portal tickets while others use it steadily. There are new starters e-mailing from day one. And there are people who, when told, ask for the link and then use it. That last sign is the useful one, because it separates reason four from reason three: a person who tried and failed does not ask for the link. The fix is the promotion plan, especially the new-starter minute and the manager who uses it in front of their team. But diagnose before promoting. Telling three hundred people about a portal that is empty or slow converts reason four into reason three, at scale, in a week.

Reason Five: The Form Asks Too Much

The fifth reason is the form. The request form has eleven fields: category, subcategory, asset tag, building, floor, cost centre, impact, urgency, preferred contact method, "have you restarted the device", and finally the description. The user has a broken screen and a meeting. They reach the third field, close the tab, and e-mail "my screen's broken", which takes eight seconds and lands in the same queue. The form was designed by the people who read it rather than the people who fill it in, and it shows.

It happens for good reasons, one field at a time. Every field was added by the desk to save the desk a question. The asset tag was added so nobody has to ask which laptop. The building was added so nobody has to ask where. The impact was added so triage is quicker. Each one is a reasonable request and each one costs the requester a decision they may not be able to make. Required fields are where people stop, because a required field they cannot answer is a locked door, and the e-mail client is right there with no doors at all.

The signs include "Other" as the commonest category on portal tickets, because it was the only choice that did not require knowing something. There are forms started and abandoned, where the tool counts them. There are e-mails that begin "I couldn't find the right option on the portal so...". That last one is a person telling you the exact field that stopped them. The fix belongs to another article. A Request Form People Will Finish makes the case for three fields the user can always answer. The rest are asked at triage by someone who knows what an asset tag is. In short, the form's job is to get the request in. Everything else is the desk's job, afterwards.

Telling the Five Apart

From the desk, all five reasons look the same: the e-mail count is high, the portal count is low, and the dashboard says so every Monday. The symptom is identical and the fixes are different, so fixing by guess costs a month per guess and the desk does not have five months. The table puts the five side by side with the sign the desk can see and the words users say when asked. It gives a quick test that takes under an hour and shows where the fix lives. Most desks that run the tests find two or three reasons, not one. The table also tells you which to fix first: the lower rows before the upper ones. Fixing the path to a portal that fails on arrival only makes the failure quicker.

Two of the tests are worth doing even before the diagnosis week starts, because they take ten minutes and settle a lot. Search the portal for the ten commonest ticket subjects from last month and count the useful hits. If the count is under five, you have reason two whatever else you have. And fill in your own request form for a broken screen, timing it. If it takes more than two minutes or asks for anything a new starter would not know, you have reason five. Everything else needs the conversations.

The One-Week Diagnosis

The diagnosis takes five working days and uses three sources of evidence: the tickets, the portal's own numbers, and five conversations. The first two narrow the field. The third decides it, because reasons three and four live in people's memories and nowhere in any log. Do all three. A desk that reads only the tickets will conclude "e-mail is easier" every time, because that is what tickets look like whatever the reason.

Days one and two are the tickets. Pull a month and count by channel, which is the route a request took to reach the desk: e-mail, phone, portal, walk-up, chat. Then count portal tickets by department and set the counts beside each department's headcount. A department of forty with no portal tickets beside a department of twelve with nine is a reason-four department or a reason-three department. The conversations will say which. Read fifty of the e-mail tickets and mark the ones that begin "I couldn't find", "I tried the portal but", or "as discussed". Each of those is a user naming their reason in the first line.

Day three is the portal's own numbers, where the tool keeps any. Some tools log searches, zero-result searches, forms started and forms sent, and visits by day; some log one or two of those; some log nothing at all. Take what is there. A high search count with a high zero-result share is reason two. Many forms started and few sent is reason five. A visit graph with one tall bar in the launch week and nothing after it is reason three or four. If the tool logs nothing, the conversations carry the whole weight, and you ask seven people instead of five.

Days four and five are the conversations. Pick five people from different departments, including one new starter and one person from the quietest department in the ticket count. Ask each the same question: "The last time you needed something from IT, what did you do, and why that way?" Then stop talking. Write down the words they use, not your summary of them. Do not explain the portal, defend it or mention it until they do. The answers sort themselves into the five reasons with very little effort, and the sorting is usually not what the desk expected. I did this once and all five answers were reason four. I had announced the portal in a message titled "IT update", which is the subject line people delete unopened. I had told everyone, in the sense that the message had been sent.

Fix One Reason, Then Measure

The temptation after the diagnosis is to fix everything in a week: twenty new articles, a shorter form, a desktop shortcut, a new announcement, all at once. Resist it. You will not know which change worked. And the announcement will land before the content is ready, which converts whatever reason you had into reason three for everyone who responds to it. One reason at a time, in an order, with a month between.

The order is from the inside out. If the portal is empty or slow, fix that first and fix it quietly, because every person sent to an empty portal is a first visit spent. Then the form, for the same reason. Then rehearse the first visit yourself and fix what breaks. Then, and only then, promote, and promote to the people the diagnosis said had not heard. Then count, which is the subject of Measuring Portal Adoption, and compare the month after the fix with the month before.

Expect the numbers to move slowly. Habits are slow, and an adult who has e-mailed the desk for four years is not going to stop because the desk had a good week. A month with no visible change after a fix is normal. Two months with no change means the fix was for the wrong reason. In that case, the answer is to go back to the conversations, not to fix a second reason on top of the first. If you run QuerySolv, one item comes off the list before you start: requesters need no account to use the portal. In that case, the login wall is not among the reasons you have to test for.

A Short War Story: The Poster at Tollgate Foods

Tollgate Foods, a food manufacturer with two factories and a head office, launched a help desk portal. Tollgate used a poster in every canteen and an all-staff e-mail. Marcus, the desk lead, counted four portal tickets in the first month against a hundred and ninety by e-mail. He concluded that people were set in their ways. He sent two reminder e-mails over the following quarter and asked line managers to "encourage" their teams. And the count the next month was five. Six months after the launch a new technician, Lena, sat down with five people and asked how they had last got help. Four of the five had tried the portal once. The production staff used shared terminals that opened the portal to a login page none of them could get past. The office staff had searched "payslip" and found nothing, because payslips belonged to HR and the knowledge base held eleven articles about IT. The cost was six months of a portal nobody used and two reminders that made the desk look like it was nagging. The cost also included roughly eleven hundred e-mail tickets that each needed the triage questions the form would have asked. The reason was discoverable in one afternoon of asking, and the desk spent six months announcing instead.

The Bypass Diagnosis Sheet

The sheet below is the one-week diagnosis on a page. Fill in the ticket counts on the first two days and the portal numbers on the third where the tool has them. Fill in the five conversations on the last two, writing down what people said in their own words. The scoring at the bottom is deliberately blunt: a reason with two or more marks against it is one you have. And the lowest-numbered reason you have is the first one to fix. Keep the sheet. The same diagnosis run again in six months, against the same questions, is how you will know whether the fixes worked or merely felt like progress.

PORTAL BYPASS DIAGNOSIS — ONE WEEK, ONE PAGE
Desk: ______________________   Run by: ______________   Week of: ____________

A. THE TICKETS (days 1-2; last full month)
   Total tickets: ______
   By channel:  e-mail ____   phone ____   portal ____   walk-up ____   chat ____
   Portal tickets by department, with headcount:
     ____________________  portal ____  headcount ____
     ____________________  portal ____  headcount ____
     ____________________  portal ____  headcount ____
     ____________________  portal ____  headcount ____
   Of 50 e-mail tickets read, how many begin:
     "I couldn't find ..." ____   "I tried the portal but ..." ____   "as discussed" ____

B. THE PORTAL'S OWN NUMBERS (day 3; where the tool keeps them)
   Searches in the month: ____     Searches with no result: ____
   Forms started: ____             Forms sent: ____
   Visits by week: launch week ____   last week ____
   Not logged by this tool: ____________________________________

C. THE QUICK TESTS (any day)
   Ten commonest ticket subjects searched on the portal: useful hits ____ / 10
   Request form filled in for a broken screen: fields ____   minutes ____
   Fields a new starter could not answer: ______________________________
   Page load from the office floor: ____ seconds   Search: ____ seconds
   Login needed to reach the portal:  [ ] no   [ ] yes: works from shared machines? [ ]

D. FIVE CONVERSATIONS (days 4-5)
   "The last time you needed something from IT, what did you do, and why that way?"
   1. ______________ (dept ____________): __________________________________________
   2. ______________ (dept ____________): __________________________________________
   3. ______________ (new starter):        __________________________________________
   4. ______________ (quietest dept):      __________________________________________
   5. ______________ (dept ____________): __________________________________________

E. SCORING (one mark per sign found, from A to D)
   1. E-mail is easier           marks: ____
   2. Portal slow or empty       marks: ____
   3. First visit failed         marks: ____
   4. Nobody told them           marks: ____
   5. Form asks too much         marks: ____

   Reasons with two or more marks: ______________________
   Fix first (lowest-numbered of those, except 2 and 5 always before 4): ____
   Change made: ______________________________   Date: ________
   Re-measure channel counts on: ________   Re-run this sheet on: ________

Dana ran the sheet at Meridian Parts the week after the director's question. Section A showed the warehouse, forty people, with no portal tickets at all. Section C showed the form asking for a cost centre, which nobody outside finance knows. Section D produced three "e-mail is quicker", one "I tried it on the warehouse terminal and it wanted a password", and one "there's a portal?". Three reasons, in a known order, with the form first because every other fix would send people to it. The director got a one-page answer instead of "people prefer e-mail", and the answer had dates on it.

Frequently Asked Questions