Home › Topics › Self-Service Portal Adoption › Promotion

Promoting the Portal Without Nagging Anyone

Wednesday, 10:15, at Northgate Retail. Sam, who runs the desk, has just sent the third all-staff e-mail about the portal in four months. The subject line is "REMINDER: please use the IT portal", and the capitals were a decision. Within the hour there are two replies to all. A store manager: "What portal?" A buyer: "Can I still just e-mail you? It's quicker." And one direct reply, from Sam's own manager: "Maybe stop sending these." The portal has now been announced three times, which is two more than the new coffee machine got. The coffee machine has better adoption.

Promotion, for a help desk portal, is every way the desk puts the portal in front of the people it serves. Nagging is promotion that arrives when the person has no need, tells them they are doing something wrong, and repeats. The difference is not tone, though tone matters; it is timing and direction. Promotion that works arrives at the moment someone needs help and makes the portal the nearest door. Promotion that nags arrives on a Wednesday morning, in capitals, and asks three hundred people to change a habit for the desk's convenience. This article is part of our Self-Service Portal Adoption series. It is about the first kind.

It covers why nagging fails and what works instead, the signature line, and the acknowledgment that teaches. Then come the new-starter minute, managers who use it, and the shortcut on every desktop. Next it covers why you never punish people for e-mailing and promoting only after the portal works, with a table of tactics. A short war story and the promotion plan to copy come last, in that order.

Why Nagging Fails

Nagging fails because nobody changes a habit on request. A person who has e-mailed the desk for four years has a path worn into their day. And an e-mail telling them to take a different path changes nothing about which path is shorter. They read the reminder, agree with it in principle, and e-mail the desk the next time their screen goes black. The mail client is open and the portal is a link in a message they deleted on Wednesday. The reminder asked them to remember something at a moment when remembering is the last thing they are doing.

Nagging also reaches the wrong people. The all-staff e-mail is read carefully by the people who read all-staff e-mails carefully. And those people were already going to use the portal, because they are the people who do what the e-mail says. The people the desk wants to reach did not open it. They are the store floor, the warehouse, the new starters, the department that has e-mailed Priya directly since before the portal existed. The e-mail reached the converted and missed the congregation, and then it was sent again.

What works is the opposite in every respect. It arrives at the moment of need, not on a schedule. It shortens the path rather than describing it. It shows the portal working rather than asking for faith. And it never tells anyone they did something wrong by asking for help the way they always have. A person who is told that stops asking the desk and starts asking a colleague. Everything in this article is one of those: a link where the need is, a shortcut where the hand is, a demonstration where the team is. None of it is a reminder.

The Signature Line

Every e-mail the desk sends carries one line in the signature, with the portal's address. And the line says what the reader would get, not what the desk would like. "Quick answers and request tracking: help.example.com" is a line about the reader. "Please raise requests via the portal" is a line about the desk. The first is read as an offer and the second as a rule. People take offers and resent rules, whatever the words after them say.

The signature works because of where it appears. It is at the bottom of a message the requester wanted, from a person who just helped them. It appears at a moment when the desk is on their mind. It is promotion that arrives inside a good experience, and it arrives every time, without anyone sending anything. A requester who exchanges six messages with the desk over a ticket has seen the line six times, in the least annoying way a line can be seen. Nobody has ever replied to all to complain about a signature.

Keep it to one line and make the address short enough to type. A portal at a long address full of slashes and the tool's name is a portal nobody will reach from memory. So get a short alias from whoever runs the directory, "help.example.com" or "support.example.com". Use it everywhere: signature, acknowledgment, shortcut, induction. One address, said the same way every time, is the beginning of the portal having a name. A portal with a name can be mentioned in a corridor. A portal at a long address cannot.

The Acknowledgment That Teaches

The acknowledgment is the automatic reply the desk sends when a request arrives by e-mail, with the ticket number in it. It is the most-read message the desk produces, because every requester receives one every time. Its last line is the most effective piece of promotion the desk will ever run, for a reason the all-staff e-mail cannot match. The reader has a live need, a ticket number, and a reason to click, which is to see what happens to their request. They arrive on the portal with their own ticket already there. That is a first visit with a built-in success.

The acknowledgment says three things and stops. The ticket number, with a link that opens that ticket, not the front page. When a person will reply. And one line, offered not instructed: "For quick questions, the portal's search answers most of the common ones straight away." It never says "please use the portal in future", because that sentence tells someone who has just asked for help, correctly, that they asked wrong. A requester who reads that twelve times a year has been corrected twelve times by a machine. A requester who reads the offer twelve times has been told, gently, where the shortcut is, by a message that was helping them.

Test the link before the acknowledgment goes live, from a phone, with no portal session open, because that is how acknowledgments are read. The link must land on the ticket and show its status with a name and a time. Otherwise, the acknowledgment has invited someone to a page that disappoints them. The whole of that first click, and the six moments after it, is the subject of Making the First Visit Succeed. The promotion rule here is that the acknowledgment is the invitation. An invitation to a party that is not ready is worse than no invitation.

The New-Starter Minute

New starters have no habit yet, which makes them the only people on the payroll who can be reached without changing anything. They will take whichever path works on their first day and keep it. The new-starter minute is sixty seconds in the induction, on the kind of machine the person will actually use. During that minute, somebody opens the portal and searches one thing that comes up. They show where requests go and where their tickets will appear, and say "that's it." That minute is the only training on the portal most people will ever receive. And one minute is enough, because the page has four things on it and nobody needs to be taught a search box.

Do it on the right machine. Suppose a nurse is shown the portal on an induction laptop in a training room and then sent to a ward computer that opens a login page. She has been trained for a portal that does not exist where she works. Do it on the ward computer, the warehouse terminal, the shop-floor tablet, whichever the person's day will contain. If the portal does not open cleanly there, that is the fault to fix before the next intake, not a thing to explain around. If you run QuerySolv, requesters need no account to use the portal. So "you will need to register first" is a sentence the induction never has to contain, and the minute stays a minute.

Get the minute into the induction that already exists rather than adding a session. HR runs an induction, or a line manager runs a first morning. Either will add sixty seconds if the desk supplies the sixty seconds in writing. The instructions are: open this address, search for "Wi-Fi", point at the form, point at "my tickets". The welcome e-mail carries the same address, and the desk tests that link every quarter. Welcome e-mails are edited by people who do not know what the link is for. The approach is the one in Training Users Without Lecturing: show the thing working, once, briefly, and let the working do the persuading.

Managers Who Use It

Adoption runs downhill. Suppose a team's manager raises their own requests on the portal, checks their tickets there, and says in a team meeting "I just put that on the portal". That team adopts it within a quarter without anyone being asked. A manager may e-mail Priya directly, because the manager has always e-mailed Priya directly. That manager's team e-mails Priya directly, because that is what the team has seen work. People copy what their manager does far more reliably than what the desk says, and the desk cannot change that, so it uses it.

Ask three managers, by name, in person, to use the portal for a month, and tell them why. Pick one from a department that already half-uses it, one from the quietest department in the ticket count, and one who is visibly listened to. Ask them to raise their own requests there, to check status there instead of phoning, and to say so once in a team meeting. Offer, in return, to spend one minute in that team meeting showing the page. Three managers is a small enough ask to get a yes. It is a large enough sample that one of them will produce a team whose portal count visibly moves. That is the evidence for asking the next three.

Never ask a manager to tell their team to use the portal. That request converts the manager into the desk's megaphone. The team hears a rule from their boss on behalf of IT, which is nagging with a better postcode. The manager's job in this plan is to be seen doing it, not to be heard requiring it. Where a manager is genuinely enthusiastic and asks what else they can do, the answer is "mention it when it works for you". That is the only kind of endorsement anyone believes.

The Shortcut on Every Desktop

The portal's nearest competitor is the mail client, which is open. The portal cannot be open, so it has to be one click away from everything. A shortcut on every desktop puts the portal where the hand already is. The shortcut is pushed by whatever the desk uses to manage machines, with a plain name and a recognisable icon. On shared machines and tablets it goes on the home screen. In the browser it is a pinned bookmark or, where the organisation is willing, the page the browser opens to. The aim is that nobody ever has to remember the address, because remembering is the step at which e-mail wins.

The name of the shortcut matters more than it should. "Get IT help" is understood by everyone who has ever needed IT help. "Service Portal", "SSP" and the project's codename are understood by the project team. I once named the desktop shortcut after the project. Three people asked what it did, and one of them was on the project. Name it for the need, in the words a person uses when they have the need. Give it an icon that does not look like the eleven other icons the machine already carries.

Pushing a shortcut is a change to every machine, so it goes through whatever the desk uses for changes. Include a note that it is a shortcut and nothing more. Expect a handful of tickets asking what the new icon is; answer each one with the one-minute version and count them as first visits. The shortcut is the only tactic in this article that reaches people who read nothing and attend nothing. On most sites, that is a considerable share of the people the desk serves.

Never Punishing E-mail

The most tempting idea in portal promotion, and the most damaging, is to make e-mail worse so the portal looks better. The slow lane: e-mailed requests answered in two days, portal requests in four hours. The bounce: an automatic reply saying "this address is no longer monitored, please use the portal". The nudge that is a shove: a reply to every e-mailed ticket beginning "In future, please...". Each of these feels like leverage. Each one produces the same result, which is that requests leave the queue. The slow lane is a punishment with a project plan.

People who are punished for e-mailing the desk do not go to the portal. They e-mail a technician they know, at that technician's own address, where the service is fast and nothing is counted. They phone. They walk over. They ask a colleague who knows someone. The desk's e-mail count falls, which looks like success for a month. The ticket count falls with it. That is the shadow channel described in The Seven Ways Support Quietly Fails: work that is done and never recorded. The portal share goes up because the denominator shrank. Nobody adopted anything.

Keep every door open and give every door the same service. An e-mailed request gets the same reply time, the same named technician and the same status as a portal request. And the acknowledgment tells the requester, kindly, where the shortcut is next time. The portal wins by being nearer, not by e-mail being made further away. A desk can take requests by every route into one queue, which is the argument of One Queue, Many Doors. That desk can afford to be generous about doors, because every door leads to the same place. Generosity is also the only approach that leaves the requester feeling the desk is on their side. That feeling makes them try the portal when they are ready.

Remember: promotion that works arrives at the moment of need and makes the portal the nearest door. It never tells anyone they asked for help the wrong way, and it never makes another route worse. The portal wins by being nearer, not by e-mail being pushed further away.

Promote Only After It Works

Every tactic in this article sends people to the portal, and a portal that fails them converts promotion into damage. A signature line that leads to an empty search teaches three hundred people that the search is empty. A new-starter minute may be on a page that asks for a login the new starter does not have. That teaches the starter to e-mail, on day one, with the desk watching. Promotion is the last step. Before that, the page is one screen with four things on it, the top ten are written, and the form takes a minute. The first visit has been rehearsed on a borrowed machine. Promotion before that is an invitation to watch the portal fail, delivered personally.

The table lists the tactics with their effort, who they reach, when they go live and what each one costs if it is done too early. Read the last column before the first. The order is roughly the order of the rows: the quiet, always-on tactics first. They reach people one at a time at the moment of need, and a failure there is a single bad visit. The louder tactics come later, once the quiet ones have shown the portal can survive a visitor.

TacticEffortReachesWhen it goes liveCost if done too early
Signature line on every desk e-mailAn hour, onceEvery requester, every exchangeThe day the first-visit checklist passesEvery requester sent to a page that fails them
Last line of the acknowledgmentAn hour, once; the link tested quarterlyEvery e-mail requester, at the moment of needSame day as the signatureA failed first visit for every e-mailed ticket
Shortcut on every desktop and home screenA change request and a morningEveryone with a machine, including non-readersWeek two, once the first two tactics have produced no complaintsHundreds of curious clicks landing on an empty search in one day
The new-starter minute in inductionSixty seconds per intake, written once for HREvery new starter, before any habit formsThe next intake after the checklist passesNew starters trained to e-mail, on day one, by the desk
Three managers using it for a monthThree conversations and three team-meeting minutesThree teams, by exampleWeek four, once the portal has handled a month of real visitorsA manager's public endorsement of a page that embarrasses them
Walking the quiet departmentsAn afternoon per departmentThe people no other tactic reachedWeek eight, guided by the adoption numbersPromises made in person that the portal cannot keep
An all-staff announcementTen minutesThe people who read all-staff announcementsOptional, once, after everything else, if at allThree replies to all and a reputation for nagging

Measure at week six and week twelve, by channel and by department, and let the numbers direct the second wave. The department whose portal count is still zero is where the walking happens. And the manager whose team moved is the one to thank publicly and ask again. How to read those numbers, and which ones mislead, is the subject of Measuring Portal Adoption. The promotion plan without the measurement is a list of things the desk did. With it, it is a list of things that worked.

A Short War Story: The Slow Lane at Ashgrove Housing

Ashgrove Housing's desk lead, Tomas, made an announcement one Monday. Requests sent to the support address would from then on be answered within two working days. Requests raised on the portal would be answered within four hours, and he called it an incentive. Within a month, e-mail to the support address had halved, portal tickets had risen by a dozen, and total tickets logged had fallen by a third. That was because the missing requests had gone to the personal addresses of the two technicians the housing officers knew by name, and to the phone. One of those personal e-mails was about a laptop holding a tenant complaint file. It sat unread for eight days in the mailbox of a technician on leave. The complaint missed a statutory deadline, which cost the association a formal apology and a report to its regulator. The director asked Tomas why the desk was "doing less than before". And the honest answer was that the desk was doing the same and recording a third less of it. Tomas withdrew the slow lane and apologised to the housing officers in person. He spent a quarter coaxing the requests back into the queue, one technician's inbox at a time. Punishing e-mail does not move people to the portal; it moves them out of sight, and out of sight is where deadlines are missed.

The Promotion Plan

The plan below is twelve weeks on one page, with the prerequisites at the top, because the plan does not start until they are met. Each week names the tactic, the owner and the test that says it was done. The two measurement points are fixed so that the second wave is directed by evidence rather than by whoever complained most recently. Nothing in the plan is a reminder or a mandate. The all-staff announcement is at the bottom, marked optional, where it belongs. Fill in the names and dates, pin it where the desk can see it, and cross the weeks off.

PORTAL PROMOTION PLAN — TWELVE WEEKS, ONE PAGE
Portal address (short alias): ______________________   Plan owner: ______________

PREREQUISITES (none of the below starts until all are ticked)
  [ ] Front page is one screen: search, top ten, three-field form, my tickets
  [ ] Top ten questions written, titled in requesters' words
  [ ] First-visit checklist passed from a phone and a shared machine
  [ ] Acknowledgment link opens the requester's own ticket
  [ ] Channel counts for the last month recorded as the baseline:
      e-mail ____  phone ____  portal ____  walk-up ____  chat ____

WEEK 1  Signature line on every desk e-mail            owner ________  done [ ]
        Line used: "____________________________________________"
        Acknowledgment last line, offered not instructed  owner ________  done [ ]
WEEK 2  Shortcut pushed to desktops and home screens    owner ________  done [ ]
        Shortcut name: "____________________"   Change record: ________
        Tickets asking "what is this icon": ____  each answered with the one-minute version
WEEK 3  New-starter minute written for induction        owner ________  done [ ]
        Machine type used at induction: ______________   Welcome e-mail link tested [ ]
WEEK 4  Three managers asked, in person, to use it for a month
        1. ______________ (dept ____________)  team-meeting minute on ________
        2. ______________ (quietest dept)       team-meeting minute on ________
        3. ______________ (dept ____________)  team-meeting minute on ________
WEEK 6  FIRST MEASUREMENT
        e-mail ____  phone ____  portal ____  walk-up ____  chat ____
        Portal tickets by department vs headcount: ______________________________
        Departments still at zero: ______________________________
WEEK 7  Thank the manager whose team moved, publicly; ask three more
WEEK 8  Walk the departments at zero: one afternoon each
        ______________ on ________   ______________ on ________
        What they said: _________________________________________________
WEEK 10 Fix whatever the walk found before promoting further  owner ________  done [ ]
WEEK 12 SECOND MEASUREMENT
        e-mail ____  phone ____  portal ____  walk-up ____  chat ____
        Total tickets vs baseline: ____  (a fall means requests left the queue; investigate)
        Next three managers: ______________  ______________  ______________

NEVER IN THIS PLAN
  No slow lane for e-mail.  No bounce message.  No "in future, please".
  No manager asked to instruct their team.  No reminders.

OPTIONAL, ONCE, AFTER WEEK 12
  [ ] One all-staff message, written as an offer, sent by someone who is not IT

Sam ran the plan at Northgate after the third reminder, starting with the apology to his manager and the signature line. The buyer who had asked "can I still just e-mail you?" was told yes, always. She found the portal link at the bottom of the reply. She used it the following week to check on a ticket, because the acknowledgment had landed her on it. The store manager who had asked "what portal?" got the shortcut, named "Get IT help", on every till-side machine in his store. His was the department that moved first. Nobody was reminded of anything. The portal was simply nearer than it had been, and nearer turned out to be the whole job.

Frequently Asked Questions

Senior management wants the portal to be mandatory. How do we respond?
Show them the ticket count, not the portal share. Explain that a mandate moves requests to personal inboxes and the phone, where they are not counted and deadlines are missed. Offer the twelve-week plan with two measurement points as the alternative, and promise the numbers at week six. Most managers who ask for a mandate want adoption, and will accept a plan that produces it without a revolt.
Is there ever a place for an all-staff announcement?
Send it once, after everything else is in place, written as an offer of something useful rather than a request to change behaviour. Ideally, it is sent by someone outside IT, such as a manager whose team has already benefited. Even then, expect it to reach mainly the people who already use the portal. It is a courtesy, not a tactic, and it is never repeated.
What should the signature line actually say?
One line, about the reader, with a short address: "Quick answers and request tracking: help.example.com" or "Check your tickets and find answers at help.example.com". Avoid "please", "must", "in future" and the tool's name. Use the same short address in the acknowledgment, the shortcut and the induction, so the portal has one name said one way.
Our warehouse and shop-floor staff have no e-mail and no desk. How do we reach them?
Reach them through the shared machine or tablet they do use, with the portal shortcut on its home screen and no login barrier. Also reach them through their supervisor, who is the manager in the "three managers" step. A short address they can type on a phone matters more for this group than for anyone else. A poster works only if it carries that short address and nothing else.
How long before we see adoption move?
Expect little change in the first month and visible movement by the second measurement point. Expect that movement to be concentrated in the teams whose managers took part and in new starters. Habits change slowly, and a requester who has e-mailed for years will drift to the portal over several tickets, usually through the acknowledgment link. A total ticket count that falls is the warning sign, because it means requests are leaving the queue rather than moving to the portal.
Should technicians redirect people who e-mail or walk up?
They should help, log the ticket, and then show rather than tell. With the page open, they can say "I've put that in as ticket 4471; you can see it here". A redirect that refuses to help until the person uses the portal is a punishment and produces a shadow channel. The portal is offered as the quicker way next time, after the help has been given, never as the price of getting it.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.