IT helpdesk SLA for a 200 to 1,000 person company: targets, queues and escalation
Setting an IT helpdesk SLA that a small IT team can keep: priority levels, response and resolution targets, working hours, escalation and the channels to open.
Last checked 6 min read
A 400-person company usually has an IT team of three to six people, a shared mailbox and a WhatsApp group that everyone uses to say "laptop not working". Work gets done, but nobody can say how long anything takes, and the loudest request wins. An IT helpdesk SLA changes that. It tells employees what to expect, tells agents what to pick up first, and gives the IT head numbers to defend the team with.
This is how we would set one up for a company of 200 to 1,000 people.
Start with a ticket priority matrix
Priority should come from two questions: how many people are affected, and how badly they are held up. A simple ticket priority matrix:
| Whole company or a site | A team or a key process | One person | |
|---|---|---|---|
| Cannot work at all | P1 Critical | P2 High | P3 Normal |
| Can work, with difficulty | P2 High | P3 Normal | P3 Normal |
| Request or question | P3 Normal | P4 Low | P4 Low |
Examples: internet down at the Chennai office is P1. The payroll team unable to open the attendance export on salary day is P2. One person's printer driver is P3. A request for a second monitor is P4.
Let the requester describe impact in plain words ("I can't work at all" or "it is slowing me down") and let the agent set the priority. People nearly always pick "urgent" when given the choice.
IT helpdesk SLA targets that a small team can keep
Two clocks matter: first response time (a human has looked at it and replied) and resolution time (the issue is fixed or the request delivered).
| Priority | First response | Resolution | Clock |
|---|---|---|---|
| P1 Critical | 30 minutes | 4 hours | Round the clock if you support it, else working hours |
| P2 High | 2 working hours | 1 working day | Working hours |
| P3 Normal | 4 working hours | 3 working days | Working hours |
| P4 Low | 1 working day | 5 working days | Working hours |
Treat these as a start, not a promise from a textbook. After three months, look at what the team actually achieves and set targets just a little tighter than that. An SLA that is missed every week teaches everyone to ignore it.
Three rules make the clock fair:
- Working hours and holidays. Define the working day (say 9:30 to 18:30, Monday to Saturday for a plant, Monday to Friday for an office) and load the holiday list. A ticket raised at 18:00 on Friday should not breach over the weekend.
- Pause when waiting. If the agent needs the employee to restart, share a screenshot or bring the laptop in, the ticket moves to "waiting on employee" and the clock stops.
- Different topics, different targets. A new joiner's laptop has a date, not a priority. Give requests such as "new laptop" or "software access" their own fulfilment time instead of forcing them into P1 to P4.
Staffing: how many agents?
There is no fixed ratio, but a common starting point is one agent for every 75 to 100 staff, fewer if a lot of requests are solved by help articles, more if you support plants and shift workers. Measure tickets per person per month for a quarter before you hire.
A worked example. A Hyderabad company with 600 staff gets about 700 tickets a month, roughly 32 a working day. Four agents handle about 8 each, which leaves time for projects. If volume rises to 50 a day, the first fix is usually not a fifth hire: it is publishing articles for the ten most common requests (VPN setup, password reset, printer mapping) and seeing how many tickets they absorb.
SLA escalation: who hears about it, and when
A breach that only the agent sees is not managed. Agree an escalation path:
- At about 75% of the target, the assigned agent is reminded.
- At breach, the team lead or IT manager is told.
- If a P1 or P2 is still open well past breach, the head of department or CIO is told.
Keep escalation about information, not blame. The point is that someone with authority can move resources, call a vendor or tell the business.
For P1s, add a short incident routine: one person owns it, updates go out every hour to the people affected, and a brief review happens within a week. If the incident involves a security breach, also bring in whoever handles security at once. CERT-In's 2022 directions require many kinds of cyber incidents to be reported to CERT-In within six hours of noticing them.
Channels: where tickets come from
Open as few channels as you can staff, and make every one of them produce a ticket.
- Email to ticket. A helpdesk address whose mails become tickets and whose replies thread back. This is the minimum.
- A request form with topics, so the right team gets it and the form asks the right questions (asset code, location, screenshot).
- WhatsApp, on the company's own WhatsApp Business number, if your staff live on it. Remember Meta's rule: you can reply freely within 24 hours of the person's last message; after that only an approved template can be sent.
- Phone, for P1s and people without a laptop, with the call logged as a ticket.
- Walk-ins, logged by the agent on the person's behalf.
What you should not keep is the WhatsApp group. Requests there cannot be tracked, prioritised or measured.
Measure a few things, monthly
- First response and resolution times by priority, against target.
- SLA breaches by topic: the topic with most breaches needs a process fix, not a lecture.
- Reopened tickets: a high rate means tickets are being closed too early.
- Satisfaction rating after resolution.
- Top ten topics by volume, which become your next help articles.
Repairs logged as tickets against an asset also feed the repair history you need for AMC renewals. And tickets for shared admin logins are a good prompt to move those logins out of chats, as covered in our guide to shared password management for IT teams.
Putting it together
Write the SLA on one page: the priority matrix, the targets, working hours, the waiting rule and the escalation path. Share it with department heads before you switch it on, so nobody is surprised when their "urgent" printer request becomes a P4.
The Vatsin Helpdesk sets first-reply and sorted-within hours per help topic and tells the team manager, then the head of department, when a ticket runs late; any tool that can do the same will serve. The discipline matters more than the software: one queue, honest priorities and targets you review every quarter.