Making the First Visit to the Portal Succeed

Monday, 08:50, at Harbourview Clinic. Amira is a nurse on her first morning. The welcome e-mail on the ward's shared computer says "for IT help, please use the portal", with a link. She clicks it. The link opens a login page. She has a username on a sticky note from the induction, but the password on the note was for the clinical system. When she tries it the page says "invalid credentials" and nothing else. The ward clerk, passing, says "oh, just e-mail them, that's what we all do." Amira e-mails. She will e-mail for as long as she works there. The portal has lost her in forty seconds, on her first morning, in a way nobody at the desk will ever see.

A first visit is the first time a person opens the portal with a real need, as opposed to being shown it or reading about it. It ends in one of three ways: they find the answer, they raise a request in about a minute, or nothing useful happens. The first two produce a second visit. The third produces a person who e-mails, and who tells the next new starter to e-mail. And the desk never finds out because a failed visit leaves no ticket. This article is part of our Self-Service Portal Adoption series. It is about making that one visit succeed on purpose.

It covers why the first visit decides everything, where first visits come from, and which source is the best one. Then come the link in the acknowledgment, the search that answers, the form that takes a minute, and the status screen that says something. Next is what a failed first visit costs, with a worked example, followed by rehearsing the visit yourself, with a table. A short war story and the first-visit checklist to copy come last, in that order.

The First Visit Decides Everything

People try a portal once. They are not unreasonable. Trying it cost them something, a minute and a little hope. If the minute was wasted they have learned what the portal is for, which is nothing. The lesson is durable. A person who had a bad first visit does not re-evaluate the portal when the desk improves it, because they are not looking at it. They are e-mailing. They remember the one time the lift was broken longer than the hundred times it worked, and a portal is a lift.

The desk, meanwhile, sees none of this. A successful first visit produces a ticket or a read article, both of which leave a trace. A failed first visit produces an e-mail that looks like every other e-mail, and the desk counts it as a person who prefers e-mail. The failure is invisible at the exact point where it does its damage. That is why this article exists: the first visit has to be made to succeed by design, before it happens. Once it has happened there is no second chance that does not have to be earned at ten times the cost.

The good news is that a first visit is short and has only a handful of steps. And each step can be tested in advance. A link opens and a page appears. A search is typed, and a result appears or a form appears. The form is sent and a confirmation shows. Later a status is checked. Seven moments. If each one does what the person needs, the visit succeeds, and if any one of them does not, it fails. The rest of this article walks the seven moments and says what "works" means at each.

Where First Visits Come From

First visits arrive by five routes, and they are not equally good. The new starter clicks a link in a welcome e-mail or is shown the page at induction. The requester who e-mailed clicks the link in the acknowledgment the desk sent back. Someone notices the link in a technician's signature. A colleague says "try the portal" and sends the address. And the all-staff announcement produces a few curious visits, mostly from people with no need that day. That is the worst kind of first visit, because there is nothing to succeed at.

The acknowledgment is the best route by a distance. The acknowledgment is the automatic reply the desk sends when a request arrives by e-mail, with the ticket number in it. The person reading it has three things no other first visitor has: a live need, a ticket number, and a reason to click. That reason is to see what happens to their ticket. They arrive on the portal with their own ticket already in it and something to look at. Every other route delivers a person to an empty page and hopes they think of something to search for.

Design for the acknowledgment route first, then the new starter, and treat the announcement as something that happens rather than something you rely on. The new starter route matters because new starters have no habit yet and will adopt whichever path works on day one. That is what makes Amira's forty seconds so expensive. The acknowledgment route matters because it reaches every person who already e-mails, which on most desks is nearly everyone. It reaches them one at a time, at the moment they care. The promotion plan that uses both is in Promoting the Portal Without Nagging; this article is about what happens after the click.

The Link in the Acknowledgment

The link in the acknowledgment goes to the person's ticket, not to the portal's front page. This is the single most important sentence in this article and the most commonly ignored. A person who clicks "view your ticket" and lands on a front page with a search box has to find their ticket. That means working out where tickets are, which means a login or an e-mail address prompt. The visit has become work. A person who lands on their own ticket sees their words, a status, and a name. They have learned in two seconds that the portal knows about them.

The acknowledgment itself carries three lines and no more. They are the ticket number with the link, a sentence saying when a person will reply, and one line for next time. That last line says: "If you have a quick question, the portal's search answers most of the common ones straight away." Not "please use the portal in future", which is a correction delivered to someone who has done nothing wrong, and not a paragraph of policy. The acknowledgment is the desk's most-read message, read by every requester, every time. And its last line is the quietest and most effective piece of promotion the desk will ever run. A requester who reads it twelve times a year has been told twelve times, gently, by a message that was helping them.

Test the link the way the requester will use it. Click it from a phone, because that is where acknowledgments are read. Click it from a machine the requester has not logged into the portal from, because they never have. If it asks for a password the requester does not have, the first visit ends at the password. If you run QuerySolv, requesters need no account to use the portal. That removes the commonest first-screen failure before you start. In tools that require one, the acknowledgment has to say how to get in, in one line. Otherwise, the link is a door with no handle.

The Search That Answers

The first search must return something useful, because the first search is the moment the visitor decides whether the portal knows anything. They type "wifi" or "password" or "printer", and either an article with a sensible title appears or the words "no results" appear. The second outcome is not a neutral event. It is the portal telling them it has nothing, and they believe it. And they are not wrong, because on most desks the knowledge base at launch has nine articles and none of them is about the printer.

Seed the knowledge base with the answers to the ten commonest questions before the first visitor arrives. Write each title in the words a requester would type. "Printer shows offline" is found by someone typing "printer"; "Resolving print spooler service faults on shared devices" is found by nobody who has the problem. Then test the search with the ten commonest ticket subjects from last month, exactly as the requester wrote them, including misspellings. Count the useful hits. Under eight of ten and the first visitors will meet the empty result more often than not. How to make search answer before a ticket is raised at all, including synonyms and the empty-result page, is the subject of Search That Answers Before the Ticket.

The empty result still has to be designed, because some searches will fail however good the content, and the first visit must survive them. The page for "no results" shows the request form, pre-filled with what was typed. Above the form is one line that says "No article for this yet; tell us and we will answer you directly." The visitor has not been refused. They have been offered a shorter path to a person, and the first visit ends with a ticket number instead of a shrug. A desk that treats its empty results as a to-do list, which is what they are, finds its ten most searched-for missing articles in a month.

The Form That Takes a Minute

The form on the first visit is the desk's one chance to prove the portal is quicker than e-mail. And it does that by being quick. Three fields, which the visitor can always answer: what they need in one line, their e-mail address, and what happened in their words. A button. A note beside the button says it takes about a minute. A first visitor is deciding whether to start, and "about a minute" is the answer to the question they are silently asking.

Every field beyond three costs first visits, and required fields cost the most. A required field asks for something the visitor may not have, and a new starter has very little. They have no asset tag, no cost centre, no idea which "category" a monitor that will not wake up belongs to. Amira, on a ward computer bolted to a trolley, was never going to turn it over to read a sticker. The case for taking the desk's questions at triage rather than on the form is in Required Fields Without the Revolt. So is how to win the argument with the colleague who wants the eleven fields back. For the first visit the rule is simple: time the form yourself, as a new starter. If it takes more than two minutes or asks for anything a new starter would not know, it fails first visits.

The confirmation screen after the form is sent is the last moment of the visit and the one most often left to the tool's default. The default says "Thank you, your request has been received", which is what a letterbox would say if it could talk. The screen the first visitor needs says: the ticket number, the first line they wrote, and when a person will reply. "Ticket 7731: 'second monitor not detected'. A technician will reply by 11:00 tomorrow." Now they know the desk has it, they know what the desk thinks it is, and they have a time to come back and check. The confirmation has turned a first visit into a reason for a second.

The Status That Says Something

The second visit, when it comes, is to check the ticket. What the visitor sees decides whether the portal is where they check in future or whether they phone. A status of "Open" says the ticket exists. "Assigned" says somebody has it and not who. "In progress" says something is happening and not what or when. None of those answers the question the visitor came with, which is "when will I hear". A visitor who leaves without an answer gets it by e-mail instead, which is a chase. The portal has just taught them that checking the portal does not save a chase.

The status that says something has a name and a time in it. "In progress, with Rhea. Next update by 15:00 today." The tool supplies the status word. The desk supplies the name and the time, in the public reply the technician wrote when they picked the ticket up. The portal shows the most recent public reply beside the status. That first public reply, written within the hour and containing a time, is the mechanism that makes the portal's status worth reading. Writing it is a habit rather than a feature. The habit is described in Status Updates That Prevent the Chase. And the portal is simply where the update is read by the people who would otherwise have phoned.

Check what the visitor sees when the ticket is resolved, because the resolved screen is a first visit of its own. It should show what was done, in the technician's public note, and make it plain that a reply reopens the conversation. So a requester whose problem has come back does not start a new ticket or an e-mail thread beside the old one. Most tools reopen on a requester reply; some do not. A resolved ticket that cannot be answered from the portal is one more reason to e-mail, and the visitor will take it.

What a Failed First Visit Costs

The cost of a failed first visit is counted in years, not minutes, because what fails is a habit being formed. Take Harbourview as a worked example, with invented numbers. The clinic takes on about three dozen new staff a year. Suppose each one, as a requester, raises somewhere between six and ten requests a year. A new starter whose first visit fails e-mails all of them. So one failed induction morning becomes roughly six to ten e-mail tickets a year for every year that person stays. Each needs the triage questions the form would have asked and produces a chase or two that the status screen would have prevented. Across one year's intake, that is somewhere between two and four hundred requests a year arriving the slow way, for the life of their employment. That is because of forty seconds on a Monday morning.

The second cost is the colleague effect. Amira did not fail alone; the ward clerk told her to e-mail, because the ward clerk's own first visit had failed a year earlier. A failed first visit does not stay with one person. It becomes the local advice, and the local advice outlives everyone who first gave it. The desk now has a ward where "just e-mail them" is the culture, and cultures are not changed by a line in a signature.

The third cost is the price of a second first visit. A person who tried once will try again only when given a reason that outweighs the memory. That could be a manager who uses it in front of them, a colleague who found something there, or a need the e-mail route failed to meet. The desk can arrange some of those, slowly. But a first visit that succeeded costs nothing further, and a first visit that failed costs a campaign. Fifteen minutes of rehearsal before launch, against a campaign per ward. That is the arithmetic.

Rehearsing the First Visit Yourself

The rehearsal is the desk walking the seven moments as a stranger, and it has three rules. Use a borrowed machine that has never seen the portal, or a phone. Use a new starter's account, or none. And do it from the real starting points. Those are the actual welcome e-mail, the actual acknowledgment from a test ticket raised by e-mail, and the actual signature link. A desk that tests from its own logged-in workstation finds nothing wrong and learns nothing, because its own workstation has every door already open.

The table is the seven moments with what success and failure look like at each and who fixes a failure. Run it three times, once per starting point, and write down the time each moment took. The whole visit, from clicking the welcome link to reading a confirmation with a ticket number, should take a stranger under three minutes. Anything that stops the stranger, asks them for something they do not have, or shows them a screen they have to interpret is a failure. A failure at any one moment fails the visit.

Most desks fail the rehearsal at moments one, three and six, and all three are cheap. Moment one is usually a link that works from the desk's own machines and nowhere else. Moment three is usually content that has not been written yet. Moment six is usually a default message nobody has looked at since the tool was installed. I once sent four hundred people a welcome link that opened the portal's administrator sign-in. Eleven of them tried to log in, and one of them succeeded in locking the account. The rehearsal that would have caught it takes under a quarter of an hour.

A Short War Story: The Dead Link at Bellweather Logistics

Bellweather Logistics, a haulage firm with four depots, added a line to its new-starter welcome e-mail pointing to the help desk portal. The line was written three weeks before the portal went live, with a placeholder address that opened a page saying "coming soon". The portal went live on schedule. But the welcome e-mail was a template owned by HR, and nobody told HR to change it. So for the next fourteen months every new starter at every depot clicked a link that said "coming soon". They concluded the portal did not exist and asked a colleague, who said to e-mail the desk. Farah, who ran the desk, noticed only when a depot manager mentioned in passing that his new drivers "kept asking when the portal was launching". By then around ninety people had started, each with a first visit that had failed before the page even loaded. Each was now a confirmed e-mailer who passed the advice on. The desk had spent the same fourteen months wondering why the depots never used the portal and had sent two reminders. The fix took HR five minutes. Undoing the habit took the better part of a year, one depot at a time, with managers using the portal in front of their teams. A first visit can fail before the portal is even reached. And the only way to know is to click the link a new starter clicks, from where they click it.

The First-Visit Checklist

The checklist below is the rehearsal on a page, in the order the visitor meets each moment. The three starting points are at the top and the timings at the bottom. Run it before launch. Run it again whenever the portal, the acknowledgment or the welcome e-mail changes. Run it once a quarter regardless, because welcome e-mails are edited by people who do not know what the link is for. Every box is a yes or a no. A no at any moment is a visit that fails for every person who reaches it. So the sheet is finished when every box is ticked, not when most of them are.

FIRST-VISIT CHECKLIST — RUN AS A STRANGER, ON A BORROWED MACHINE
Portal address: ______________________   Run by: ____________   Date: ________
Machine used: [ ] phone  [ ] shared terminal  [ ] new starter's laptop
Account used:  [ ] none  [ ] new starter's account  ( never your own )

STARTING POINTS (test all three)
  [ ] Welcome e-mail link, as HR currently sends it, opens the portal
  [ ] Acknowledgment link, from a test ticket raised by e-mail, opens that ticket
  [ ] Signature link, from a technician's sent e-mail, opens the portal

MOMENT 1 — THE CLICK
  [ ] Opens within a few seconds on the phone and on the shared machine
  [ ] No login prompt, or a silent sign-in that asks for nothing
  [ ] Not the administrator sign-in; not "coming soon"; not an error page

MOMENT 2 — THE PAGE
  [ ] Search box visible without scrolling, cursor already in it
  [ ] Example searches shown inside the box
  [ ] No banner, carousel, welcome message or catalogue above the search

MOMENT 3 — THE SEARCH
  Ten commonest ticket subjects from last month, typed as the requesters wrote them:
  1. ____________ hit [ ]   2. ____________ hit [ ]   3. ____________ hit [ ]
  4. ____________ hit [ ]   5. ____________ hit [ ]   6. ____________ hit [ ]
  7. ____________ hit [ ]   8. ____________ hit [ ]   9. ____________ hit [ ]
 10. ____________ hit [ ]                              Useful hits: ____ / 10
  [ ] Article titles are in the requester's words, not the desk's

MOMENT 4 — THE EMPTY RESULT
  [ ] Shows the request form, pre-filled with the words searched
  [ ] One line offering a direct answer; no bare "no results"

MOMENT 5 — THE FORM
  Fields: ____   Required fields: ____   Time to send: ____ min ____ sec
  [ ] Every required field answerable by a new starter on day one
  [ ] "Takes about a minute" or similar shown beside the button

MOMENT 6 — THE CONFIRMATION
  [ ] Ticket number shown
  [ ] First line of the request shown back
  [ ] Time by which a person will reply shown

MOMENT 7 — THE STATUS CHECK (return the next day)
  [ ] Status shows a named person
  [ ] Status shows a next-update or last-update time
  [ ] The requester can reply from the page
  [ ] A reply to a resolved ticket reopens it, or the page says what to do instead

TIMINGS
  Click to search box: ____ sec    Search to article: ____ sec
  Form start to confirmation: ____ sec    Whole visit: ____ min ____ sec
  Failed at moment: ____   Owner: ____________   Fixed by: ________   Re-run: ________

Harbourview ran the sheet the week after Amira's first morning. That was because Amira, three weeks in, mentioned the login page to a technician who happened to be on the ward. The welcome e-mail link opened a sign-in that the clinical staff's accounts could not pass. The search found four of the ten commonest subjects, and the confirmation screen was the tool's default. Three fixes, one afternoon. The next intake of new starters was walked through the portal at induction, on a ward machine. And the desk watched the first one search "badge", find the article, and say "oh, that's easy." That sentence is the entire objective.

Frequently Asked Questions