How big should your IT helpdesk team be?

How many IT people do you need for 100 employees? Or 500? Or 1,000?

The honest answer is: it depends. That is not very satisfying, but it is usually true. A single-office company with managed laptops and mostly SaaS apps is a different job from a school district with thousands of student devices, projectors, cameras, phones, access points, and six buildings that all need someone on site when things break.

Still, "it depends" should not mean "nobody knows". There are useful starting points, and there are also some real-world ratios that show how badly some teams are stretched.

A reasonable starting point

For a normal office environment, 1 IT/support person per 75-100 users is a decent planning range. This assumes you have basic standardization, a ticketing system people actually use, documented repeat work, and not too many physical locations.

If the environment is more complex, the ratio should move down. More sites, more hardware types, more on-prem infrastructure, more compliance, more business applications, more special cases: all of these mean fewer users per IT person.

There are two details worth calling out. First, manufacturing is shown in devices, not users, because the number of people on payroll may be a poor proxy for support load. Shared terminals, scanners, label printers, shop-floor PCs, and production systems all create work.

Second, schools are shown with a more conservative recommendation than many schools actually get. Education IT often has a huge amount of hardware per user, and downtime tends to be very visible. If the projector, Wi-Fi, or login system is broken, a classroom full of people immediately knows.

Real life is often worse

Here is the sad part: real-world examples often show much higher ratios than the planning ranges above. These numbers are not recommendations. They are examples of what teams are actually carrying in some environments, based on our own data and publicly available sources.

The education numbers are the ones that stand out the most. They should not be read as "schools can support 700 users per IT person". A better reading is: many school IT departments are supporting far more than the usual office staffing model would suggest, often while also handling classroom hardware, cameras, phones, access control, wireless, curriculum systems, and state reporting.

The same caveat applies to manufacturing and multi-site retail. If one support person is responsible for hundreds of devices spread across buildings or towns, the ticket count may not fully show the work. Travel time, spare equipment, vendor coordination, and production downtime all matter.

Why the 1:100 rule breaks

The 1:100 rule can work in a plain office with controlled devices, good identity management, and a small number of well-understood applications. It becomes less useful as soon as the environment stops being plain.

A 100-person company with mostly cloud apps and managed laptops might be fine with one strong IT generalist. A 100-person company with warehouse operations, on-prem servers, compliance requirements, custom business applications, badge access, cameras, and five locations is a different workload even though the employee count is identical.

This is why user count should be only the first number, not the final argument. A better staffing discussion includes the support surface area:

• How many endpoints are supported, and how many different types?
• How many physical locations need coverage?
• How much infrastructure does the team own?
• How many business applications require support?
• How much work is project work rather than tickets?
• How often is support blocked because only one person knows a system?

There is also the classic solo IT problem. One person may technically support 300, 400, or 500 users for a while, especially if management only looks at payroll cost. But that person is usually also doing purchasing, vendor management, endpoint management, networking, security, onboarding, offboarding, and every escalation. Even if the tickets are getting closed, the risk is obvious: no backup, no depth, and no real vacation coverage.

What to measure before asking for headcount

If you want to make a staffing case, bring helpdesk data instead of just quoting a ratio. The ratio helps frame the conversation, but the operational numbers show whether the team is keeping up.

• Tickets per month. A 100-person company opening 400 tickets a month is not the same as one opening 40.
• Open ticket backlog. Backlog tells you whether the current staffing level works or whether tickets are aging in the queue.
• Time to first response. This shows whether users are getting acknowledgement quickly or waiting in silence.
• Time to resolution. Track this by category, especially onboarding, password resets, laptop swaps, access requests, VPN, printers, and Wi-Fi.
• SLA misses. If even low-priority tickets miss basic SLAs, the team is either under-resourced, poorly organized, or missing the right skills.
• First-contact resolution. If everything escalates, the first fix may be training, permissions, documentation, or triage rather than another hire.
• Device count and variety. 500 identical laptops is one kind of workload. 500 mixed laptops, scanners, shared warehouse PCs, cameras, phones, iPads, lab machines, and vendor boxes is another.
• Sites and travel. A 500-user single office and a 500-user company across 50 locations should not be staffed the same way.
• Infrastructure ownership. On-prem servers, firewalls, SANs, access control, internal apps, and compliance all consume time even when no user has submitted a ticket.

This is why the ratio should be adjusted by complexity:

If you already use a helpdesk system, this is where the data should come from: ticket counts, queues, aging, categories, SLA misses, repeat work, and escalations. The staffing discussion gets much easier when it is based on the work entering the system and the work left unfinished.

A simple staffing model

Start with the ratio that matches your environment, then adjust it with the data above.

• Move toward 1:25-50 if the environment is chaotic, BYOD-heavy, under-documented, or full of exceptions.
• Move toward 1:50-75 if the team supports mixed infrastructure, multiple business applications, compliance, or a lot of hands-on support.
• Use 1:75-100 for a reasonably standardized office with good automation, good documentation, and a ticketing process people actually use.
• Treat anything above 1:150 as a warning sign unless the environment is unusually simple or a lot of work is outsourced.

A useful headcount argument usually looks something like this:

• We have 500 users.
• We support 900 laptops/desktops, 80 phones, 120 cameras, 35 access points, 20 servers, and 8 sites.
• We close 1,600 tickets per month.
• We miss 22% of our low-priority SLAs.
• One person is primary for firewalls, switching, MDM, Microsoft 365, backups, imaging, and onboarding.
• Based on the environment, 1:100 is not the right planning ratio for us.

That is much harder to dismiss than "we are busy". It also gives management choices: hire, outsource, reduce scope, improve tooling, standardize more aggressively, or accept slower service. At least the tradeoff is visible.

The responsibility matrix is worth doing

One of the simplest ways to expose staffing risk is a responsibility matrix. Open a spreadsheet. Put every technology area your team owns in column A. Then put every IT person across the top, including the manager. For each technology, mark one person as Primary and one as Secondary.

The Primary owns the system: standards, upgrades, documentation, long-term decisions. The Secondary knows enough to support it, find the docs, and keep things moving when Primary is out. Everyone else should still know enough to triage before escalating.

Here is a shortened example:

Area	John	Erica	Jim	Mike	Tom
Windows Desktop Imaging	Primary	-	Secondary	-	-
Anti-Virus	Primary	Secondary	-	-	-
Patch Management (Windows)	Primary	-	-	-	Secondary
Remote Access VPN	Primary	Secondary	-	-	-
Internet Firewalls	Primary	Secondary	-	-	-
LAN Engineering	Primary	Secondary	-	-	-
Login Scripts & GPOs	-	-	Primary	-	Secondary
Active Directory	-	-	Primary	Secondary	-
DHCP	-	-	Primary	Secondary	-
Internal DNS	-	-	Primary	Secondary	-

If your real spreadsheet is not at least 100 rows deep, it is probably missing things. Windows imaging, MDM, antivirus, endpoint detection, backups, firewalls, switches, Wi-Fi, VPN, DHCP, DNS, GPOs, Microsoft 365, Google Workspace, SSO, payroll exports, badge access, camera systems, printers, onboarding, offboarding, vendor portals, compliance evidence, certificate renewals, monitoring, logging, DNS records nobody remembers creating. The list gets long quickly because IT owns a lot of small systems that only become visible when they break.

This matrix helps in three ways:

1. It shows whether one person is primary for too many important systems.
2. It turns vague training needs into specific ones: Jennifer needs DHCP, Larry needs firewall basics, Darnell needs imaging.
3. It makes business continuity risk visible. If one person leaving or going on vacation breaks six critical areas, that is a staffing and documentation problem.

It also makes the headcount conversation less personal. Instead of saying "I am tired", you can say "we have 117 owned technology areas, 73 have no secondary owner, and our only firewall person is out next month". That is a much clearer operational risk.

My take

For a reasonably controlled office, start around 1:75 to 1:100. Move closer to 1:50 when the environment is physical, regulated, multi-site, heavily on-prem, or full of one-off systems. If the number goes above 1:150, look carefully at what is being ignored, outsourced, delayed, or carried by one person.

The ratio is only a shorthand. The real question is whether the team can respond on time, resolve work without an unhealthy backlog, maintain the systems it owns, document enough to survive vacations and turnover, and still do project work without everything else falling behind.

If the answer is no, the team is understaffed no matter what the spreadsheet ratio says.