What it is
A written commitment on response and recovery times โ for example, "we answer within an hour and fix within a day". It protects both sides from vague expectations.
How we apply it
We write it into the support contract after handover โ specific deadlines, not "as soon as we can".
Where an SLA helps a business
- You pay for support and want to know how quickly they will answer and fix things, not "whenever".
- An internal IT team should answer staff within clear times, and management should see where those times slip.
- You need to tell urgent from important: a server going down and a broken mouse are different stories.
How we use it
- In the support contract. After handover we write down specific response and recovery times, not general words.
- Inside the IT help desk. The priority is set when a ticket is taken and defines the resolution target. The default response target for a new ticket is 30 minutes. Overdue tickets are highlighted in the queue and listed in the SLA section and the morning digest. If nobody reacts to a ticket, it escalates every 15 minutes during working hours: to the chat, then to administrators personally, then to the owner.
- Separate statuses. "Accepted" and "in progress" are kept apart: work time is measured from the moment the assignee actually starts.
We build ticketing systems with SLAs under Telegram and VK bots.
What happens without one
- Tickets hang. Nobody knows how long to wait, and urgent issues drown among small ones.
- Nothing to show management. At the end of the month, instead of numbers, there is "we worked a lot".
- Arguments with the contractor. "We answered quickly" versus "nothing worked for two days", and no way to check.
When you do not need it
If there are only a few requests a month and one person handles them, a formal SLA is overkill. It is needed when requests are many or when response time affects money.