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.
| Tactic | Effort | Reaches | When it goes live | Cost if done too early |
|---|---|---|---|---|
| Signature line on every desk e-mail | An hour, once | Every requester, every exchange | The day the first-visit checklist passes | Every requester sent to a page that fails them |
| Last line of the acknowledgment | An hour, once; the link tested quarterly | Every e-mail requester, at the moment of need | Same day as the signature | A failed first visit for every e-mailed ticket |
| Shortcut on every desktop and home screen | A change request and a morning | Everyone with a machine, including non-readers | Week two, once the first two tactics have produced no complaints | Hundreds of curious clicks landing on an empty search in one day |
| The new-starter minute in induction | Sixty seconds per intake, written once for HR | Every new starter, before any habit forms | The next intake after the checklist passes | New starters trained to e-mail, on day one, by the desk |
| Three managers using it for a month | Three conversations and three team-meeting minutes | Three teams, by example | Week four, once the portal has handled a month of real visitors | A manager's public endorsement of a page that embarrasses them |
| Walking the quiet departments | An afternoon per department | The people no other tactic reached | Week eight, guided by the adoption numbers | Promises made in person that the portal cannot keep |
| An all-staff announcement | Ten minutes | The people who read all-staff announcements | Optional, once, after everything else, if at all | Three 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?
Is there ever a place for an all-staff announcement?
What should the signature line actually say?
Our warehouse and shop-floor staff have no e-mail and no desk. How do we reach them?
How long before we see adoption move?
Should technicians redirect people who e-mail or walk up?
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.
