Incidents vs Service Requests
QueueDesk structures tickets using standard ITIL concepts to help you separate urgent outages from routine service tasks.
1. Incidents (INC)
An Incident represents an unplanned interruption to or reduction in the quality of an IT service.
- •Goal: Restore normal service operation as quickly as possible and minimize the adverse impact on business operations.
- •Examples: "VPN is failing to connect", "Office printer is jammed", "MacBook is displaying a folder icon with a question mark".
- •SLAs: Incidents usually have short response and resolution SLA deadlines (e.g. 2 hours for high priority, 8 hours for low priority).
2. Service Requests (SR)
A Service Request is a formal request from a user for something to be provided — such as information, advice, or access.
- •Goal: Deliver the requested service through a standard fulfillment workflow.
- •Examples: "Need a license for Adobe Creative Cloud", "Requesting a new monitor", "Asking for information on HR policy".
- •SLAs: Service Requests usually have longer, more flexible fulfillment SLAs (e.g. 3 to 5 business days).
3. Problems (PRB) and Changes (CHN)
Two further ITIL record types exist alongside Incidents and Service Requests, and both are normally created by the service desk rather than by employees.
- •A Problem is the underlying cause of one or more incidents. Agents usually raise a problem record from a cluster of related incidents once a pattern emerges — "the VPN drops every Monday at 9am" — and the goal is a permanent root-cause fix rather than a restore.
- •A Change is a controlled modification to a service. Changes typically need approval, a scheduled window, and a rollback plan, which is why ITIL routes them through an agent or a Change Advisory Board (CAB).
4. Choosing What Employees Can Raise (Settings → Portal request types)
You control which of the four types appear on the employee portal.
| Type | Default | Why |
|---|---|---|
| Report an issue (Incident) | On — always on | A service desk with no way to report a broken thing isn't a service desk, so this can't be turned off. |
| Request a service (Service Request) | On | Standard self-service fulfilment: access, equipment, software. |
| Raise a problem (Problem) | Off | ITIL recommends problem records be raised by agents from related incidents. |
| Request a change (Change) | Off | ITIL recommends changes go through an agent or CAB. |
Turn Problem or Change on only if your employees genuinely submit those themselves — for example, if engineers in your company raise their own change requests. Everything else works exactly the same either way.
Tick or untick the types you want and use the save bar at the bottom of the page. The portal updates immediately for every employee, and a disabled type is rejected if someone tries to reach it by an old bookmarked link. If you use QueAssist portal chat, it logs the nearest type you allow rather than abandoning a conversation it decided was a Problem or a Change.
5. Categories and Routing
QueueDesk dynamically routes Incidents and Service Requests based on the options configured in Settings → Categories.
- •Out-of-the-box templates help you structure forms for either type.
- •Service Catalog items can be published specifically as Service Requests, which pre-fills the ticket fields and routes them directly to a specialized group.
6. Raising a ticket on behalf of someone else
Agents and admins can open a ticket for an employee who cannot use the portal themselves — for example, when they are locked out and cannot sign in.
When creating a ticket from the agent UI:
1. Expand Raise on behalf of at the top of the form.
2. Enter the affected person's work email (and name if helpful).
3. Complete the rest of the ticket as usual.
The affected employee becomes the ticket subject for QueAssist resolution emails and for any connected directory actions (account checks, password resets). The agent who opened the ticket remains visible in the activity log but is not the identity QueAssist acts on.
See Identity Scoping & Safety for how this interacts with portal chat, playbooks, and the audit log.