- Most businesses do not need a full in-house IT team to run effective support
- Defining tiers (Tier 1 basic, Tier 2 technical, Tier 3 specialist) before choosing tools saves time and money
- A ticketing system is the foundation. Email threads and spreadsheets are not a service desk
- SLAs should be realistic. Committing to 1-hour response for everything creates a support debt you cannot clear
- Managed IT providers give you a full team on a monthly fee, often cheaper than one senior hire
What an IT service desk actually needs to do
An IT service desk has one job: make sure that when something breaks or blocks a person from doing their work, it gets resolved in a predictable, trackable way. Most organisations that claim to have a service desk are running something looser: an email address, a group chat, and a few people who respond when they happen to see a message.
A real service desk receives requests through a defined channel, logs them as individual items, assigns ownership, tracks progress, and closes them with confirmation that the problem is resolved. No logging means no backlog visibility. Unowned tickets get ignored. Without closure confirmation, your queue fills with issues marked "probably fine now" that nobody has verified.
It also needs to handle two distinct flows: incidents (something is broken and needs fixing now) and service requests (a user needs something set up, changed, or explained). Treating all requests the same way creates priority confusion. A laptop that will not boot is not in the same category as a request to add a new user to a shared drive. Your desk needs to distinguish between the two, even at a basic level.
Unresolved IT issues cost an average worker 22 minutes of lost productivity per incident. Across a 50-person organisation handling a handful of daily issues, that adds up to days of lost output each month: a cost that never appears on an invoice.
Define your support tiers before buying any tools
The single most useful thing you can do before evaluating any software or service is to define what kinds of IT problems your organisation actually faces, and sort them into tiers. This takes about two hours, costs nothing, and prevents you from over-engineering a support model for problems you do not have.
Most issues should resolve at Tier 1. Anything that passes through goes to Tier 2, and only genuinely complex work reaches Tier 3.
- Tier 1: Basic support. Password resets, printer issues, software installation questions, email configuration, basic hardware troubleshooting, and anything resolvable with a knowledge base article or a 10-minute remote session. The person handling Tier 1 does not need deep technical knowledge. They need patience, a good knowledge base, and access to remote support tools.
- Tier 2: Technical support. Network configuration, application errors that require log analysis, device imaging, VPN setup, software licencing problems, and anything requiring administrator-level access. Tier 2 engineers need genuine technical skills and the ability to diagnose problems without a script. Response times are slower than Tier 1 because these issues take more investigation.
- Tier 3: Specialist support. Security incidents, infrastructure architecture, custom integrations, compliance-related system changes, and anything that requires a specific area of expertise your Tier 2 team does not have. Tier 3 may involve external specialists, a managed security provider, or a vendor's own support team. These tickets have longer resolution timelines by nature.
Tier definitions make staffing and tooling decisions straightforward. A business where 90% of issues are Tier 1 needs a different setup from one where infrastructure changes are constant. You may find your entire Tier 1 load can be handled by a self-service portal and a managed provider, with no internal hire required at all.
Ticketing and tracking: the minimum viable setup
The foundational rule of a service desk is this: if it is not in the system, it does not exist. Every request needs a ticket. Every ticket needs a state (open, in progress, waiting on user, resolved). Every resolved ticket needs a record of what was done. This is not bureaucracy for its own sake. It is the only way to manage a queue that more than one person is working on, and the only way to identify patterns when the same problem keeps coming back.
"A service desk without a ticketing system is just a queue that nobody can see."
For small and medium businesses, the tool choice matters less than the discipline of using it. Freshservice, Zoho Desk, Jira Service Management, and HelpScout all work well at this scale. Freshservice is the most purpose-built for IT service management: it includes asset tracking, a self-service portal, and automation rules out of the box. Zoho Desk integrates cleanly with other Zoho products if you are already in that ecosystem. Jira Service Management suits engineering teams that are already on Atlassian. All three can be configured and running within a day.
The minimum setup you need before going live is: one intake channel (a form or email address that creates tickets automatically), ticket categories that map to your tier definitions, an assignment rule so tickets land with the right person, and a simple SLA clock so you can see what is overdue. Everything else (asset management, automation, customer satisfaction surveys) can be added once the basics are running smoothly. Trying to configure everything at once is how service desk rollouts stall.
SLAs: what to commit to and what to avoid
A service level agreement (SLA) is a commitment about how quickly you will respond to and resolve different types of support requests. SLAs are useful because they set expectations, create accountability, and give you a way to measure whether your service desk is actually performing. They become a problem when they are set unrealistically, because you then spend more energy managing SLA breaches than you do fixing problems.
The most common mistake growing businesses make is setting the same SLA for everything. A single "respond within one hour" rule sounds professional, but it is unworkable if you have any Tier 2 or Tier 3 volume. A network routing problem that requires a qualified engineer to investigate will not be resolved in an hour. Committing to that timeline just creates a list of SLA violations that nobody trusts and everyone ignores.
A more durable approach is to set SLAs by priority level. Priority is driven by impact (how many people are affected) and urgency (how much is it blocking right now). The table below is a reasonable starting point for a business with 20 to 150 users. Adjust the timescales to match your support capacity and be honest about what you can actually sustain.
- Critical (system down, multiple users affected): respond within 30 minutes, resolve within 4 hours
- High (one user blocked from core work): respond within 2 hours, resolve within 8 hours
- Medium (degraded service, workaround available): respond within 4 hours, resolve within 2 business days
- Low (question, minor issue, non-blocking): respond within 1 business day, resolve within 5 business days
It is better to set conservative SLAs and consistently beat them than to set aggressive targets and miss them regularly. Users remember the times you missed more than the times you delivered. If you are working with a managed provider, the SLAs in your contract should match what you publish internally. Mismatches between your internal commitments and your provider's contractual obligations create gaps that users always notice.
Avoid creating SLA targets based on what sounds good rather than what your capacity supports. If your Tier 2 engineer is one person covering multiple responsibilities, a 4-hour resolution SLA on complex issues will breach constantly. Start with what you can reliably deliver and tighten SLAs as your capacity grows.
When to bring in a managed service provider
A managed IT service provider (MSP) gives you access to a full team of IT professionals on a monthly retainer. In practice, this typically covers your Tier 1 and Tier 2 support, proactive monitoring of your infrastructure, patch management, and often security services. The business model works because the MSP spreads specialist staff costs across many clients. You get the benefit of a team without the cost of building one.
The financial case is straightforward. A senior IT engineer with the skills to cover Tier 2 support, some security knowledge, and infrastructure competence will cost between €60,000 and €85,000 a year in the Netherlands, excluding benefits, equipment, and management overhead. A mid-market MSP contract for the same organisation typically costs a fraction of that figure. You are not just buying cheaper support. You are buying cover across holidays, illness, and the gap periods that happen when a single in-house person leaves. Continuity has real value.
The question of when to bring in an MSP rather than hire internally comes down to volume and variety. If your IT requests are predictable in type and low in volume, a well-configured self-service portal and a part-time internal resource may be sufficient. If your requests vary widely in technical complexity, or if you need 24-hour coverage, security monitoring, or compliance-related IT support, an MSP is almost always the more cost-effective and more resilient option. A hybrid model is also common: an MSP handles the day-to-day queue while an internal IT manager owns vendor relationships, procurement, and strategic decisions.
Measuring whether your service desk is working
A service desk you cannot measure is a service desk you cannot improve. Most ticketing tools provide basic reporting by default, and you do not need complex analytics to get useful insight. Start with four metrics and review them monthly. Once those are stable and understood, add more depth. Chasing ten metrics from the start usually means none of them get proper attention.
The four metrics that matter most in the early stages of a service desk are: first response time (how long before a user gets an acknowledgement that their ticket has been seen), resolution time (how long from ticket creation to confirmed resolution), SLA compliance rate (what percentage of tickets are resolved within the committed timescale), and repeat issue rate (how many tickets this month are about the same underlying problem that appeared before). The last one is particularly valuable. A high repeat rate tells you that your service desk is fixing symptoms, not causes. Recurring printer issues that appear week after week are a hardware procurement problem, not a support problem.
Beyond the numbers, a brief satisfaction survey sent at ticket closure is worth implementing early. A single question ("Was your issue resolved to your satisfaction?") with a yes or no answer and an optional comment field gives you qualitative signal that metrics alone cannot provide. Users who are dissatisfied despite a ticket being marked resolved are often pointing to something important: the fix was temporary, the communication was poor, or the resolution time was technically within SLA but felt unacceptably slow given the impact. That feedback is gold if you act on it.
The ITIL framework, maintained by Axelos, is the industry standard for IT service management processes and defines the practices referenced throughout this guide. The itSMF Netherlands is the local professional body for service management practitioners.