Why your 40-person company needs a support system, not just a fixer

At most small companies, IT support isn't a system. It's a series of Slack DMs, hallway interruptions, and emails to whoever fixed the Wi-Fi last time. The person who ends up handling these requests rarely chose the role, and the company rarely acknowledges the hours it consumes.

This guide walks you through setting up real IT support when nobody's job title says IT. By the end, your company will have a clear place for requests to land, a named owner, published expectations, and an escalation plan that works at 11 p.m. on a Friday. The focus here is how support runs. For which individual tasks to automate from the support queue, we have a separate guide.

Slow or invisible IT support has real consequences. (Springer / Journal of Information Systems) found that slow IT response times drive 38% of employees toward shadow IT, using tools and workarounds that fall outside IT oversight. A proper setup prevents that drift before it starts.

What you'll need before you start

• A shared inbox or simple request form. A shared email address (something like it@yourcompany.com) works at first.
• A named person willing to own IT support, and a realistic hour budget from leadership: typically 5 to 10 hours per week at this company size.
• Thirty minutes with whoever holds the budget, because two of the steps below need a decision they own.

Step 1: Give requests one place to land

Replace scattered channels with a single intake point. Every request goes there. If someone stops you in the hallway, the answer is: "Send it to the shared inbox so I can track it."

The goal here is visibility and structure. If a request isn't logged, it doesn't exist, and you can't tell whether you're drowning or imagining it. A shared inbox also gives you a count at the end of the month, which matters when you need to justify more time or outside help.

Keep it simple. A shared email address, a basic form in your project tool, or a dedicated Slack channel with a rule that every message becomes a tracked item. The essential IT tools for SMBs don't need to be expensive or complex at this stage.

Step 2: Assign an owner and budget real hours

Name one person as the IT point of contact and block dedicated hours on their calendar. This sounds obvious, but most companies skip it. The office manager "just handles it" between their other responsibilities, and nobody tracks how much time that actually takes.

Make the investment explicit. If your "IT owner" spends eight hours a week on support but that time never shows up in a workload conversation, the company is making a staffing decision without knowing it. Founders who handle IT themselves know this pattern well: the work is real, but it stays invisible until something breaks badly enough to force the conversation.

Step 3: Write down what's in scope, and what isn't

This is the step most companies skip, and it's the one that saves the most arguments. Decide in advance what IT support covers and what it doesn't, then publish it somewhere the whole company can find.

Reasonable things to put outside scope:

• Printer and scanner driver issues beyond basic troubleshooting
• Hardware repair (coordinate with the vendor, but don't do it yourself)
• Teaching someone how to use their personal device or a tool one department bought without involving IT
• Deep troubleshooting of niche software the company didn't approve

There's also a sensitive exception worth calling out. Access to HR tools, finance systems, and password managers usually should not sit with general IT support. These involve privileged data, and keeping them separate protects everyone involved.

Publishing scope also protects the owner from creep. Scope creep is the main reason accidental IT people burn out. When the boundary is written down, saying "that's outside what we cover" is a reference to policy, not a personal refusal.

Step 4: Define three priority levels and what each one promises

Three tiers are enough: critical, normal, and low. The purpose is to give the word "urgent" a shared meaning across the company.

• Critical: multiple people blocked, or a security incident. Response within 30 minutes.
• Normal: one person blocked, workaround may exist. Response within 4 hours.
• Low: questions, setup requests, nice-to-haves. Response within one business day.

Be clear that a response is not the same as a resolution. The damage from slow IT is mostly the not-knowing. When someone reports a broken login and hears nothing for three hours, they assume nobody cares. A quick "Got it, looking into this" changes the experience entirely.

Publish these expectations. An expectation nobody knows about cannot be met. Pin them in the same place you posted the scope document, and reference them when people ask why their low-priority request isn't done yet.

Step 5: Build your escalation path before you need it

Decide in advance who gets called when a problem is beyond your skill, when it's outside business hours, or when it looks like a security incident. Write down names, phone numbers, and vendor support contract details in one shared document.

Three scenarios to plan for:

1. Beyond your skill. Which vendor, consultant, or knowledgeable colleague do you call? Do you have their contact details and any relevant contract numbers?
2. Outside business hours. Is there anyone available, or does the company accept that after-hours issues wait until morning? Be honest about this. A plan that says "call nobody" is still better than no plan.
3. Security incidents. A lost laptop, a suspicious email someone clicked, or an account that's clearly been compromised. These need a faster, different path than normal support.

Now ask the uncomfortable question: what happens when the IT owner is on vacation, sick, or leaves the company? Most organizations this size have no answer. Finding that out during an incident is the worst possible time. Name a backup, even if their only job is to follow the escalation document and call the right external contact.

Understanding how IT infrastructure scales helps you build an escalation path that still works as you grow.

Step 6: Write down the answers you give most often

You already know the ten questions that come up every week: how to connect to the VPN, how to reset a password, where to find the Wi-Fi credentials for the meeting room. Write short, searchable answers and keep them somewhere the whole company can find them, whether that's a Notion page, a Google Doc, or a pinned channel post.

This isn't about building a knowledge base. It's about stopping yourself from typing the same answer for the fifth time this month. (Forrester Research) reports that only 55% of employees feel fully supported by their organization's IT service desk. One reason is that answers exist in someone's head but not anywhere people can look them up on their own.

Keep this lightweight. For a deeper look at which tasks to document, which to automate, and which to keep as human work, the support automation guide covers that decision in detail.

Step 7: Check whether the setup is holding

Once a month, count three things:

1. Total requests. Is volume growing, stable, or dropping?
2. Response times. Did you meet the promises you published in Step 4?
3. Out-of-scope requests. How many requests fell outside what you defined in Step 3?

Rising volume against a fixed hour budget is your scaling signal. If you budgeted eight hours a week and the work now takes twelve, that gap will keep growing.

Frequent out-of-scope requests mean the scope needs updating, not that people are being difficult. Maybe the company adopted a new tool and nobody told you it was now "your" problem. Adjust the document rather than fighting the same battle every week.

Also watch for recurring requests. If the same issue keeps appearing, the right move is to fix the root cause (update a default setting, write a guide, change a configuration) rather than answer faster each time. The real cost of IT support often hides in repetitive work that could be eliminated.

What this setup can't do

Be honest about the ceiling. A single owner with a shared inbox has no coverage outside their working hours, no redundancy when they're sick, and no specialist depth for security, compliance, or infrastructure questions.

This informal model works up to a point. The moment it breaks usually looks like one of these:

• Request volume regularly exceeds the budgeted hours, and the owner is falling behind.
• A security or compliance question comes up that nobody can answer confidently.
• The company crosses roughly 30 to 50 people and the single point of contact can't keep up.

When you hit that threshold, bringing in managed IT support is a real option alongside hiring. It's not only "instead of" an internal IT person; it can also work as a layer underneath one.

Where deeploi fits

Everything this guide asks you to build comes pre-built with deeploi, the All-in-One IT Management Platform for SMBs. It combines automation with expert support in a single per-user subscription.

The bigger difference is prevention. deeploi builds your IT setup to one best-practice standard from the start, with devices, access, and updates configured together rather than one at a time. A large share of the requests this guide teaches you to triage never get created, because the conditions that produce them are gone.

How a request gets handled

When someone on your team has a problem, they submit a ticket, send an email, or call if it's urgent. The first response comes from Sam, deeploi's AI IT support agent. Sam does much more than point people at a help article. He can act directly in your workspace and on your devices – suspending a user, adjusting mailbox access, changing group memberships, or reading live device data to work out what's actually wrong. Every action he takes requires sign-off from your IT owner, so nothing changes in your systems without someone at your company approving it first.

{{cta}}

Sam answers instantly, at any hour, which is coverage a single internal owner cannot offer. And he knows his limits. Anything he cannot resolve goes straight to deeploi's human IT experts, who respond within 30 minutes guaranteed and 12 minutes on average. Sam is never the last word on a problem. He is an extra set of hands in front of a support team, not a replacement for one, and for urgent cases your team can pick up the phone and reach a person directly.

What deeploi covers as an all-in-one IT management platform

• Employee onboarding and offboarding, covering accounts, access, apps, and devices
• Device management for macOS, Windows, and iOS, including setup, configuration, encryption, and enforced updates
• Software and license management
• Account and access management across Microsoft 365, Google Workspace, and connected SaaS tools
• IT support for every employee, in German and English
• Endpoint security and patching, backup and recovery

No pay-per-ticket

deeploi does not charge per ticket or per hour. Requests are unlimited, with no caps and no per-incident fees. This matters more than it sounds: when support is billed by the incident, employees quietly learn not to ask, and the provider has no financial reason to prevent the ticket in the first place. A flat per-user price puts both sides on the same side of the problem.

If you already have an IT person

For companies with one IT admin, a CTO handling IT on the side, or a working student, deeploi takes over the repetitive load – support requests, device management, onboarding, and offboarding – so the internal person works on projects instead of password resets. It solves the two problems one person structurally cannot: coverage when they are on vacation or sick, and a team with expertise across areas nobody masters alone. This is support for the person you already have, not a replacement for them.

FAQ

How many hours per week does IT support actually take at a 30 to 50 person company?

Typically 5 to 10 hours per week for day-to-day requests, plus spikes during onboarding waves, office moves, or incidents. The number tends to creep upward as the company adds tools and people, which is why tracking volume monthly matters.

What should be out of scope for internal IT support?

Hardware repair beyond basic diagnostics, printer and scanner drivers, personal software training, and deep troubleshooting of tools one department bought without IT involvement. Also keep access to HR systems, finance tools, and password managers deliberately separate from general support for data protection reasons.

When should we stop doing this ourselves and bring in outside help?

When volume regularly exceeds the hours you budgeted, when a security or compliance question needs specialist knowledge nobody on the team has, or when the company crosses roughly 30 to 50 employees. Any of those signals means the informal model has hit its ceiling.

We already have one IT person. Does external support still make sense?

Yes, and for different reasons than a company with no IT person at all. External support provides coverage during absence, expertise outside the IT person's specialty, and capacity to handle repetitive requests so they can focus on projects and infrastructure instead.