At most universities, requests arrive by several routes at once: an internal phone call, a chat message, an official letter, someone walking into the office. Each unit also keeps its own logbook or spreadsheet. The result is that nobody knows who has a request right now, or why it has been sitting for two weeks. A service desk is supposed to fix that. Chosen badly, it just adds one more channel to the same mess.
This checklist is for the IT department or the vice-presidency choosing a unified service platform. Every criterion comes with a practical test you can run in the demo session, so you don't have to trust the vendor's feature list.
Service catalogue first, software second
Before you watch any demo, list what each unit provides, who is allowed to request it, and what documents it needs. ISO/IEC 20000-1, which sets the requirements for a service management system, starts from the same place: a service that isn't defined can't be measured either. You don't need the certificate, but without that list every product looks good in a demo.
Eight criteria and a test for each
| Criterion | Why it matters | How to test it in the demo |
|---|---|---|
| A separate catalogue per group | Students, faculty and staff ask for different things. If everyone sees one list, half the forms get filled in wrong. | Log in as three users with three roles and check whether the list of requests changes. |
| Sign-in with the university account | Separate registration means forgotten passwords and tickets about the system itself. | Ask whether it connects to SSO or to the university's current identity system. |
| Hand-offs between units | A housing request sometimes also needs facilities and finance. The system should record the hand-off, not leave the agent reading out a phone number. | Route one request through two units and look at its history. |
| SLA with working hours | A response deadline only means something if it counts public holidays and office hours. | Submit a request late on the last working day before the weekend and see when its deadline lands. |
| Internal notes kept apart from replies | An agent needs to tell a colleague something the requester will not see. | Add an internal note, then check from the requester's account that it is hidden. |
| Knowledge base | Repeat questions (the student portal password, the clearance form) should have one fixed answer. | Check whether a knowledge base article can be linked into a ticket reply. |
| Reports for managers | A unit head needs to see which request types fall behind most, not just the total count. | Filter the report by request type and by unit. |
| Installation on university servers | Student and staff data is personal data, and many universities don't want it outside their own network. | Ask whether there is an on-premise edition and who handles its backups and updates. |
Three common mistakes
- Buying customer support software for internal services. Customer support tools are built for outside customers and usually lack university roles (student, faculty, staff) and a separate catalogue for each. If what you need really is customer support, see this comparison.
- Launching every unit at once. When twenty units start together, catalogues stay half-written and users give up in the first week.
- Ignoring agent capacity. The system makes requests visible, but if there aren't enough agents it only shows the queue more clearly. Estimate it before launch with the helpdesk staffing calculator.
FanServe was built for this
FanServe is Fanpino's single-window service platform for organisations and universities: a role-based catalogue, ticket workflows with hand-offs between units, SLA tracking with working-hour rules, internal notes, a knowledge base and reports. It comes as a cloud service or installed on the organisation's own servers. It supports right-to-left languages and is already running in production. If you want to run the eight tests above on it, request a demo.
Frequently asked questions
Is a service desk different from a ticketing system?
A ticketing system only logs and tracks requests. A service desk goes a step further: it adds the service catalogue, roles, deadlines and reporting, so it is clear what each unit provides and at what level.
Do we need ISO/IEC 20000 certification to launch?
No. ISO/IEC 20000-1 sets the requirements for a service management system, and certification is optional. The thinking behind it (a service catalogue, service levels, logging and closing requests) still helps when you choose software.
How many agents do we need?
It depends on monthly request volume, handling time per request and working hours. The free helpdesk staffing calculator gives you a first number.
Where should we start?
Start with two or three high-traffic units (usually academic affairs, housing and IT), write their catalogues, and add the other units after one semester.
Source: ISO/IEC 20000-1:2018, Service management system requirements. This checklist does not replace implementation advice or the text of the standard.
