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 Escalated, Pending Approval, Cancelled, or Rejected. 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, tickets are distributed by round-robin. When routing is disabled, tickets are assigned directly to individual agents.
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. 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. 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.
- 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.
- 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 (Normal), 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.
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. The escalation timeout defaults to 24 hours.
Auto-closing resolved tickets
By default, resolved tickets auto-close after 5 days of inactivity. A reminder is sent 2 days before the close date. Admins can adjust or disable this in Settings → Features.
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 |
| Require request category | On | Whether a category is required when submitting a ticket |
| 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 tickets are distributed among agents in a team |
| Max concurrent tickets per agent | 5 | The cap on open tickets an agent can hold before new tickets go to the next agent |
| Escalation | On | Whether unresponded tickets escalate after the timeout |
| Escalation timeout | 24 hours | How long before an unanswered ticket escalates |
| Escalation target | Requester’s manager | Who is notified on escalation — the requester’s manager or Service Desk app admins |
| 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 after a period of inactivity |
| 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 and cancelled tickets older than the configured window are permanently deleted |
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.