Onboarding Your Team to a New Help Desk Tool
New tools fail from low adoption, not missing features. A practical plan to onboard agents and requesters to a new help desk — a pilot team, the first week's habits, redirecting kindly, measuring adoption and retiring the old channels.
Successful help desk onboarding is mostly about habits, not training: set the tool up before anyone sees it, pilot with one team, make filing a request easier than sending a message, redirect old channels kindly but consistently, and show people the benefit — visible status, faster answers — within the first week. Measure adoption by the share of requests that arrive through the desk, and retire the old channels only when that share is high. Most tools that fail were never adopted, not missing a feature.
Why new tools fail
A help desk has two audiences with different incentives:
- Agents (the people answering) gain visibility and order, but lose the familiarity of their inbox and chat.
- Requesters (everyone else) must change where they ask — and the old way, messaging a person they know, feels faster.
If filing a request is slower than messaging, people will keep messaging, and agents will keep answering there to be helpful. Within a month the tool holds half the work and nobody trusts it. Everything below is about making the new way the easy way.
Before launch: set it up properly
Don't launch an empty tool. Before anyone outside the pilot sees it:
- Categories and teams — 5–10 categories from your actual recent requests; teams named the way requesters think ("Laptop, account or software → IT").
- Targets — provisional response and resolution targets per category. See the SLA tracking guide.
- Five knowledge-base articles — the most-asked questions, so the first people who use it get instant answers. See ticket deflection.
- Roles — who's an agent, who's an admin, who approves what. See role-based access for internal tools.
- Accounts — invite people with the right role and team so their first login works. In LetRelay, an admin invites people directly; if email is configured they receive credentials by email, otherwise the admin sees a one-time temporary password to share.
- Migrate open work — if requests lived in a spreadsheet, move the open ones in; see moving from a spreadsheet to a request desk.
Pilot with one team
Start with the team that receives the most requests (usually IT) and a friendly group of requesters. Two weeks is enough to find the problems that matter:
- Fields nobody understands.
- A category everyone picks by mistake.
- Notifications that go to the wrong person, or nobody.
- A step that's slower than the old way.
Fix them before wider launch. A pilot's job is to fail small.
Train agents first, and briefly
Agents need a short, hands-on session — 30 minutes, on real requests:
- Working the queue: sorting by deadline, assigning, statuses, public replies vs internal notes.
- The triage rotation: who owns new requests on each shift.
- The redirect script (below).
Then give them a one-page cheat sheet. Nobody remembers a 90-minute demo.
Requesters: one link and one sentence
Requesters don't need training; they need a link and a reason. Announce it once, clearly:
From Monday, send IT, HR and facilities requests through [link]. You'll see the status of your request at any time, and nothing gets lost when someone's away.
Put the link everywhere people look for help: the chat channel topic, the intranet, email signatures of the agents, the new-starter checklist. The GOV.UK service manual's advice on writing for interfaces applies to announcements too: short sentences, the action first, plain words.
Redirect kindly — and consistently
The most important habit in the first month: when someone messages a request directly, the agent files it for them and replies with the link:
Got it — I've logged this as RLY-212 so it doesn't get lost: [link]. You can follow it there, and next time you can file it directly from the same page.
Doing it for them the first few times is faster than explaining, and it shows the benefit (a reference number, visible status) instead of describing it. What breaks adoption is inconsistency: if some agents keep answering in chat, requesters learn that chat still works.
Show the benefit in week one
People adopt tools that visibly help them:
- Requesters notice when they stop having to chase: publish the median first-response time after the first week.
- Agents notice when the queue shows what's due next and nothing is lost in their inbox.
- Managers notice the first report: volume, response times, what's breaching. See help desk metrics that matter.
Measure adoption
Track one number weekly: the share of requests that arrive through the desk versus side channels. Agents can tally side-channel requests they redirect. Aim for most requests through the desk within four weeks. If it plateaus, ask why — the answer is usually a slow form, a confusing category, or one team still answering in chat.
Other signals worth watching:
- Requests filed per active user (are people using it once and giving up?).
- Requests with empty or "Other" categories (is the category list confusing?).
- Time from creation to first view (is anyone watching the queue?).
Retire the old channels
Once most requests arrive through the desk:
- Turn the old shared inbox into an auto-reply with the link.
- Change the chat channel's purpose to "discussion — requests go to [link]".
- Stop answering side-channel requests except to redirect.
Diffusion-of-innovations research describes adoption spreading from early adopters to the majority over time; a firm but friendly switch-off is what moves the last group.
New starters: onboard them to the desk on day one
After launch, every new employee is a chance to build the habit from the start. Put the desk in the new-starter checklist:
- Their account is created before day one, with the right team and role.
- Their first-day instructions include "how to get help: [link]".
- Their first request is filed for them — "set up your laptop" — so they see a request, its status and its resolution before they ever need to file one.
New starters who learn the desk first never learn the side channels.
Common mistakes
- Launching with an empty knowledge base — the first impression is "it doesn't know anything".
- Too many required fields — every extra field sends people back to chat.
- A big-bang launch to every team at once — problems multiply; nobody can fix them fast enough.
- Agents answering in chat "just this once" — it teaches requesters the old way still works.
- No visible benefit — if status isn't visible and nothing is faster, why would anyone switch?
FAQ
How long does it take to onboard a team to a new help desk?
About a month for a small organization: a week to set up, two weeks piloting with one team, and a week or two of wider rollout with redirection. Adoption continues improving after that.
How do I get employees to use the help desk instead of messaging IT directly?
Make filing a request as easy as a message, file side-channel requests for people with a link back, keep every agent consistent about redirecting, and show visible status so the benefit is obvious.
Should we launch the help desk for all teams at once?
No. Pilot with one team, fix what the pilot finds, then add teams one at a time.
What should be set up before launching a help desk?
Categories, teams, provisional targets, a few knowledge-base articles, roles and accounts, and any open requests migrated from the old system.
Sources
Building Relay — the internal request desk with AI triage and SLA tracking.
Run your internal requests on LetRelay
AI triage, SLA-tracked queues, and bottleneck analytics — the help desk your team actually likes. Free to start.
Keep reading
Internal Help Desk Satisfaction Surveys That Tell You Something
How to measure satisfaction with an internal help desk without annoying everyone — one question after resolution, a follow-up only on bad scores, response rates, CSAT vs effort vs NPS, and turning answers into changes.
Facilities Request Management: From Broken Chairs to Keys
How to run facilities requests like a proper service — categories, location on every request, safety issues that skip the queue, vendor work, recurring maintenance and the numbers that show where the building needs attention.
HR Service Desk: Handling Employee Requests Without the Inbox
How an HR service desk works — categories for pay, leave, contracts and benefits, privacy that's enforced not promised, targets that respect deadlines like payroll, self-service for policy questions, and the metrics HR can use.