Service Desk
1. What it is
Service Desk is a ticketing and IT service management app where employees submit requests and agents resolve them. It includes a knowledge base, SLA tracking, team-based routing, and optional ITSM modules — Change Management, Problem Management, a Configuration Management Database (CMDB), Access Requests, and Grievances.
- Enablement: Licensed and opt-in. An admin enables it from Admin → Apps → All Apps and grants the licence.
- What it is not: Service Desk is not the Ask AI assistant. Ask AI can search Service Desk’s knowledge base to answer employees before a ticket is opened, but the two are separate apps with separate licences.
2. Standing it up
- Go to Admin → Apps → All Apps, find Service Desk, and enable it.
- Go to Service Desk → Settings → Routing → Teams & Agents. Create at least one support team and add agents to it. Without a team, tickets stay unassigned in the Available queue.
- Still in Settings, open Intake → Email Channel. The email channel is on by default — confirm the inbound address. AI processing lives under Advanced → AI; decide whether to turn it on (it is off by default).
- Under Settings → Advanced → Knowledge Base, confirm the Knowledge Base is on (it is by default). Optionally turn on additional modules under Settings → Advanced → Modules — Problem Management, Change Management, CMDB, and Access Requests are all on by default; Grievances is off by default.
- To grant agent rights, add a user to a support team. Users who are members of at least one active support team — or who carry the legacy help-desk-agent flag — are recognised as agents.
- Confirm it worked: agents should land on the Dashboard when they open Service Desk; members should see the Help hub with a Submit a Request card.
3. How it fits together
Tickets — the core work item. An employee submits a ticket (from the web, mobile, email, API, Microsoft Teams, or a recurring schedule), it enters the queue, gets routed to a team or agent, and moves through statuses: Submitted → Queued → Assigned → In Progress → Resolved → Closed. Tickets can also be Pending Approval, Cancelled, or Rejected, and any open ticket can be flagged Escalated without changing its status. Priorities are Low, Medium, High, and Critical.
Teams and routing — a support team is a pool of agents with a shared queue. When team-based routing is enabled (the default), incoming tickets are matched to teams by routing rules — conditions based on request type, priority, location, keywords, or AI-detected intent. Within a team, the ticket goes to the eligible member who scores best — the most room against their Individual Capacity, a matching skill and tier, and a good resolution record — skipping anyone on approved leave; a team in queue mode keeps it in the team’s queue for someone to claim instead. When team-based routing is off, tickets are assigned directly to individual agents by the Assignment Strategy.
Knowledge Base — articles, documents, uploaded files, and crawled web pages that agents and AI draw on to resolve tickets. Content can require approval before publishing. An article started from a template shows a warning — and the Submit, Approve and Publish confirmations repeat it — while any of the template’s [bracketed prompts] are still in it. The knowledge base supports role-based access tiers: content can be restricted so that only agents, managers, or admins see certain articles, while members see the rest.
ITSM modules — each is individually toggleable:
- Change Management — tracks changes through a lifecycle from Draft → Pending Review → In CAB Review → Approved → Scheduled → Implementing → Implemented → Closed. A change the CAB sends back shows as Returned. A board member who needs more detail votes Request Info: the requester and the assignee are told, and either of them — or Service Desk staff who do not vote on that board — can reply with Answer the board on the change page — the answer goes on the change’s timeline, and the members who asked can vote again. Changes have types (Standard, Normal, Emergency), a risk level, and can be routed through a Change Advisory Board (CAB) for review. Emergency changes can go straight to the CAB chair. A change’s schedule is checked against its board’s blackout windows; a change with no board (an emergency change approved on submit) is checked against every active board’s windows, as a warning only.
- Problem Management — tracks recurring issues from Identified → Investigating → Root Cause Found → Fix in Progress → Resolved → Closed. Problems link to the tickets (incidents) they caused and to CMDB configuration items. Any problem that is not closed can be published as a Known Error once it has a workaround, so agents can apply the workaround while the fix is pending. A problem that turns out to be the same as another can be closed as a duplicate from any open status: its linked tickets move to the problem you keep, and both problems record it. A Service Desk admin can reopen a closed problem that comes back; it returns to Investigating, and its old root cause and resolution are kept in its investigation log.
- CMDB — a registry of configuration items (services, servers, applications, databases, networks, storage) and their relationships. CI records link to related problems and change requests so agents can see the downstream impact of an outage.
- Access Requests — a self-service flow where employees request access to a location, workspace, site, support team, app, or equipment category. Requests go through an approval queue — or resolve instantly when the tenant’s zero-touch policy matches (for example, a location request from someone already assigned to a location in the same city is auto-approved by default).
- Grievances — a multi-stage escalation workflow that progresses through Filed → Acknowledged → Immediate Supervisor → Department Head → HR Director → Arbitration → Resolved → Closed, each stage with its own SLA window. This module is off by default.
Roles — four levels determine what a user sees:
| Role | Who qualifies | What they see |
|---|---|---|
| Member | Everyone else | Help hub, My Requests, and — when those modules are on — Changes, Grievances, and Access Requests |
| Manager | Manages a support team but is not an agent | Member surfaces plus Tickets, Changes, Grievances, Analytics |
| Agent | Members of an active support team (or legacy agent flag) | Dashboard, Knowledge Base, all enabled ITSM modules, Access Requests |
| Admin | Business admin or Service Desk app admin | Everything: Dashboard, Tickets, all ITSM modules, Analytics, Settings |
4. Running it
Reviewing and working the queue
Agents open the Dashboard to see their assigned tickets, workload summary (open count, overdue count, capacity utilisation), and the Available queue of unassigned tickets. Agents can Claim an unassigned ticket to take ownership or Assign it to another agent.
Managing SLAs
SLA targets are set per priority in Settings → Routing → Priorities & SLA. Each one is the time a ticket has to be resolved. The defaults are 4 hours for Critical, 8 for High, 24 for Medium, and 72 for Low, and a service department can set its own hours, which take precedence. The clock starts when a ticket is assigned (or when it is submitted, if nobody has it yet); a ticket not resolved by then is flagged as breached. A changed target applies to new tickets and to existing tickets when they are next assigned. Reopening or reinstating a ticket restarts its clock from that moment; a breach the ticket already had still counts against the SLA compliance rate.
Escalating a ticket
Escalation flags a ticket without changing its status. By default, the escalation is routed to the requester’s manager; an admin can change this to route to Service Desk app admins instead. A ticket nobody has replied to goes to a higher-tier agent first, when there is one. A ticket escalates on its own when its agent has not replied within the escalation timeout, or when it is still open that long after missing its SLA target. The timeout defaults to 24 hours. Grievances are never escalated on their own.
Auto-closing resolved tickets
By default, a resolved ticket auto-closes 5 days after it was resolved — the count runs from the resolution, not from the last activity, and reopening the ticket restarts it. A reminder is sent 2 days before the close date. Admins can adjust or disable this in Settings → Workflow.
Merging duplicate tickets
Agents and admins can merge a duplicate ticket into a canonical one. The source ticket’s requester becomes a follower of the target, and the source is cancelled with a merge note.
Running a satisfaction survey
When enabled (on by default), a satisfaction survey email is sent to the requester after a ticket is resolved. The default delay is 2 hours after resolution.
Recurring tickets
Service Desk app admins and business admins can create recurring ticket rules that generate new tickets on a schedule — daily, weekly, biweekly, monthly, quarterly, or yearly; agents can view them from Recurring Tickets in the sidebar. Useful for periodic maintenance or scheduled check-ins.
5. Settings
Settings are organised into four sections, accessed from the Settings tab (admin only).
Intake
| Setting | Default | What it changes |
|---|---|---|
| Email channel | On | Whether inbound emails create tickets |
| Allow unknown senders | On | Whether emails from addresses not matching any employee create a ticket (as an unidentified requester) or are dropped |
| Anonymous requests | Off | Whether employees can submit tickets without their name attached |
Routing
| Setting | Default | What it changes |
|---|---|---|
| Team-based routing | On | Whether tickets are routed to teams via rules, or directly to individual agents |
| Routing rules | On | Whether the routing rule engine evaluates conditions on incoming tickets |
| Auto-assign | On | Whether tickets are automatically assigned to an agent (vs. sitting in the queue) |
| Assignment method | Round-robin | How auto-assign picks an agent when team-based routing is off (team routing scores the routed team’s members instead) |
| Max concurrent tickets per agent | 5 | When team-based routing is off: auto-assign passes over agents holding this many open tickets while anyone else is below it (when everyone is at it, the ticket still goes to someone). Team routing uses each team member’s Individual Capacity instead |
| Escalation | On | Whether unanswered assigned tickets, and tickets past their SLA target, escalate after the timeout (never grievances) |
| Escalation timeout | 24 hours | How long a ticket can go unanswered, or past its SLA target, before it escalates |
| Escalation target | Requester’s manager | Who is notified on escalation — the requester’s manager or Service Desk app admins (an unanswered ticket goes to a higher-tier agent first, when there is one) |
| SLA per priority (Priorities & SLA) | Critical 4h, High 8h, Medium 24h, Low 72h | Time-to-resolve targets by priority level, counted from assignment |
Features
| Setting | Default | What it changes |
|---|---|---|
| Auto-close resolved tickets | On, after 5 days | Whether resolved tickets automatically close a set number of days after they were resolved |
| Satisfaction survey | On, 2-hour delay | Whether a satisfaction survey is sent after resolution, and when |
| Ticket tasks | Off | Whether agents can attach a task checklist to a ticket |
| Ticket retention purge | Off | Whether closed, cancelled and rejected tickets older than the configured window are permanently deleted (resolved tickets are kept until they are closed) |
Advanced — Modules
| Setting | Default | What it changes |
|---|---|---|
| Problem Management | On | Enables the Problems tab for tracking root-cause investigations |
| Change Management | On | Enables the Changes tab for tracking infrastructure and process changes |
| CMDB | On | Enables the CMDB tab for managing configuration items and their relationships |
| Access Requests | On | Enables the Access Requests tab for self-service access requests and approvals |
| Location auto-approve policy | Same city | Zero-touch policy for location access requests — Off, Same city, Same state, or Any existing assignment |
| Grievances | Off | Enables the Grievances tab for multi-stage grievance workflows |
Advanced — Knowledge Base
| Setting | Default | What it changes |
|---|---|---|
| Knowledge Base | On | Whether the Knowledge Base tab and content are available |
| KB content approval | Required | Whether new knowledge base content needs approval before publishing. Approvers (admins and app admins) always publish directly |
| KB content creation permission | Admins only | Who can create KB content — admins only, or all users |
| Suggest KB content on submit | On | Whether relevant KB articles are suggested when an employee starts a ticket |
Advanced — AI
| Setting | Default | What it changes |
|---|---|---|
| AI processing | Off | Master toggle for AI classification, priority detection, routing, and sensitive-content detection on incoming tickets |
| AI response mode | Manual only | How AI reply drafts get created (needs AI draft generation on): Manual only (agents press Generate AI Draft when they want one), Draft for review (AI drafts every arriving request; an agent approves before it sends), or Auto-send (AI sends the reply itself when it is confident) |
6. More help
- Service Desk FAQ — specific setup and operating questions
- Ask AI — the assistant answers questions about Service Desk from these articles.