Here is the uncomfortable truth about every help desk rollout: the technicians are not the product's real users. Your two hundred staff members are, and they will judge ServiceDesk Plus by exactly one screen - the self-service portal. If that screen confuses them, they will go back to phone calls, and the expensive console behind it will not matter.
Adoption is the product. A portal that staff avoid produces a special kind of failure: the tickets that do arrive are the ones nobody could solve informally, the queue looks permanently terrible, and management concludes the software is bad. The portal in ServiceDesk Plus has everything needed to win people over - one place to raise a request, track it, read announcements and search answers. But features do not create habits. Simplicity on the first screen, visible progress, and a few deliberate launch moves do. This guide covers all three.
[ + Raise a Request ] [ My Requests ] [ Search Answers ]
Popular right now: Password reset · VPN access · New software install
Announcement: Email maintenance on Sunday, 10 PM to 11 PM
Sell the portal on what staff gain, not on what IT gains. An emailed request disappears into an inbox the sender cannot see; a walk-in request exists only in one technician's memory. A portal ticket gives the requester three things neither channel can: a ticket number that proves the request exists, a status they can check without calling anyone, and a written thread where the fix is recorded when it closes. For IT the same ticket quietly captures the structured details - category, site, asset - that make reports and SLA clocks possible. When you announce the portal, lead with the requester's benefits. "Now you can see exactly where your request stands" fills a portal. "Please stop emailing us" empties it.
Design the portal home like an airport sign, not a brochure. One dominant action - raise a request. The common requests as templates with friendly names: "I need a new laptop", "Something is not working", "Access for a new joiner". A knowledge base search that answers before a ticket is written, seeded with your ten most repeated questions in the words people actually ask them - "wifi keeps dropping in the meeting room", not "WLAN instability KB article". Announcements for planned maintenance, so the portal becomes the place people check before they panic. Every element you add beyond this fights the one button that matters. If a colleague cannot raise a correct ticket in under a minute on their first visit, simplify until they can.
Habits form when the system talks back. Turn on the notifications that create trust: an acknowledgement with the ticket number the moment a request lands, a note when it is assigned, and a resolution message when it closes, with a short satisfaction survey attached. Then honour the other direction - when a requester replies, adds information or reopens, the ticket must show it and a technician must answer. The fastest way to kill a portal is a ticket that goes in and nothing visibly happens for three days. Put the SLA response targets from your setup to work here: a fast first response, even "we have it, parts ordered, update tomorrow", teaches the office that the portal is alive.
The video walkthrough shows what requesters and technicians each see - judge the first screen for yourself.
Watch Full VideoYes. ServiceDesk Plus fetches a mailbox and converts incoming mail into tickets automatically, so email keeps working while habits change. The requester gets the ticket number by reply, and the ticket appears in their portal view - email becomes a door into the system, not a way around it.
Refusal is usually design feedback. If raising a ticket takes longer than walking to the IT desk, the portal loses fairly. Shorten templates, cut fields, answer visibly and fast for the first month, and log walk-ins into the portal with the person watching. Adoption follows the path of least resistance - make sure the portal is that path.
No. Requesters are unlimited and free in ServiceDesk Plus licensing; licences are counted per technician. The portal, email intake and the mobile app are all requester-side doors that do not consume seats.