Three starting points for running a support desk: an SLA policy you can fill in, an escalation matrix that says who picks up what, and a checklist for the first thirty days. Copy them straight off the page - no form, no download, no email address.
Fill in the two right-hand columns with targets you can actually meet during your own operating hours. Targets you miss every week are worse than no targets at all, because the breach report stops meaning anything. Start conservative and tighten later.
| Priority | When to use it | First response | Resolution |
|---|---|---|---|
| Critical | Service is down or unusable for many people, and there is no workaround | 30 minutes | 4 hours |
| High | A core task is blocked for one person or a small group, or a workaround exists but is painful | 2 hours | 1 business day |
| Normal | Something is wrong but work continues; the default for most requests | 1 business day | 3 business days |
| Low | Questions, small changes and anything with no deadline attached | 2 business days | 5 business days |
Before you publish it, settle these four:
Setting this up in practice: the SLA guide walks through priorities, operating hours and breach alerts.
Prefer to work it out rather than copy it? The SLA policy workbook walks you through the six decisions and assembles your own.
Managing the tickets themselves - statuses, priorities, who owns what - is a separate set of decisions: the ticket handling workbook.
Escalation goes wrong when it is a feeling rather than a rule. Write down the trigger, the owner and what actually happens, so an agent never has to decide in the moment whether something is bad enough to pass on.
| Level | Trigger | Owner | What happens |
|---|---|---|---|
| L1 | Any new ticket | Support agent on the queue | Acknowledge, diagnose, resolve or move to L2 within the first response target |
| L2 | Needs a specialist, or L1 has had it for half the resolution target with no progress | Named senior agent or the relevant team | Reassign in the ticket with a note on what has been tried. Customer is told it has moved on |
| L3 | Suspected defect, data problem, or anything needing a change to the product or infrastructure | Engineering contact | Raise the underlying issue and link it to the ticket. The ticket stays open and owned by support |
| Management | SLA breached on a Critical or High, a complaint, or a named account at risk | Support lead | Lead takes ownership of the communication, agrees a plan with the customer and sets a follow-up date |
Deciding the levels themselves? The ticket handling workbook builds a priority grid and a flow from triage to closed.
Moving off a shared mailbox goes wrong when everything is designed on day one. Get requests flowing first, then shape the structure around what the tickets actually show you.
Create the workspace and invite your agents. Connect the existing support address so mail lands in the queue. Create one group for the whole team - do not design a routing tree yet. Send a test message and watch it become a ticket.
Set one SLA policy using the table above, with your real operating hours. Decide who receives breach alerts. Turn on the customer portal so people can check status without emailing to ask.
Read a fortnight of real tickets. Create categories that match what you actually received rather than what you expected. Split into groups only where the queue is genuinely different work. Agree the escalation matrix.
Write knowledge base articles for the five questions you answered most. Turn on satisfaction ratings. Check first response time, resolution time and reopen rate, and set a target for the next month based on what you saw, not on what sounds good.
A fuller walkthrough of each step: using Raiseaticket as a ticketing tool.
SLA policies, escalation, reporting and a knowledge base are all part of the free plan - 5 agents and 500 tickets a month, no credit card and no expiry.
Free foreverNo credit cardNot a 6-month trial