IT Helpdesk SLAs and Response Times for NZ Businesses

How long does it take your team to get help from the IT helpdesk when something breaks? If nobody can answer that from a report, nobody is measuring it, and the cost is being absorbed quietly rather than managed.

For a business buying an IT helpdesk from outside, the details that matter are what is covered, how priorities are set, when someone responds, and what happens while the issue remains unresolved. This guide explains how to compare those commitments and how to check whether the support you receive matches your agreement.

Buying that support in is common. In the 2022 Business Operations Survey, which covers businesses with six or more staff, Stats NZ found that among businesses with six to nineteen staff roughly three in five used contracted external ICT support, while only about one in twelve had anyone in-house whose main job was IT.

Looking for IT helpdesk support for your own team? See Exodesk’s managed IT services for businesses in Christchurch, Dunedin and across New Zealand.

What is an IT helpdesk and why does it matter?

An IT helpdesk is the first point of contact when something goes wrong with your technology. It handles everything from password resets and software faults to network outages and hardware failures, and it is the part of IT support that staff see most directly.

When the IT helpdesk works, staff get back on task quickly and the disruption is forgettable. When it does not, people stop reporting things. They work around the broken printer, keep using the slow laptop, and save up three problems for the next time someone technical is in the building. That is the real failure mode, and it does not show up in any ticket report, because the tickets were never raised.

What is the difference between break-fix and a managed IT helpdesk?

Break-fix means you call when something breaks and pay for each job. It describes how the work is charged rather than what is promised, so whether there is an agreed response target, a priority order or any monitoring depends on the arrangement, and it is worth asking because there may be nothing written down.

A managed IT helpdesk is included in a fixed monthly service and judged against agreed service levels. Tickets are logged and tracked, the targets are written into the agreement, and the provider reports on whether they were met. It is the foundation of a working managed IT relationship rather than a series of transactions. If the question you are weighing up is whether to contract the work out at all, our guide to outsourced IT support and what an in-house hire costs covers that decision.

What response times should an IT helpdesk commit to?

Whatever your agreement says, because no standard sets IT helpdesk response times for you. That is worth saying plainly, because a great deal of published guidance presents a particular set of numbers as though an authority had blessed them. None has.

The international standard for IT service management, ISO/IEC 20000-1:2018, requires that service targets are agreed and documented rather than assumed. It contains no universal response time and no universal resolution time, because the right target depends on the service and on what the business needs. The same standard makes a point worth borrowing even if you never seek certification: it anticipates that another party may operate your service desk, and still expects the organisation to show evidence of control over how that party performs. Outsourcing the IT helpdesk does not outsource the accountability.

What an agreement needs is a small number of priority levels defined by their impact on the business, with commitments written against each one. The table below shows one way to define the levels. It deliberately leaves out times, because the right numbers depend on the business, the hours covered and the agreement itself.

Priority should follow impact and urgency rather than the type of fault. The same email problem can be minor for one person and critical for the accounts team on payroll day. Planned requests, such as setting up a new starter, are better handled with an agreed lead time than squeezed into a fault priority.

If your current IT helpdesk provider cannot produce a document defining levels like these, with commitments against each, that is the gap. Not the specific numbers, but the absence of any agreed number at all.

What counts as a response?

Ask what starts and stops each clock. An automatic ticket receipt confirms the request arrived, but it does not show that a technician has assessed it. The agreement should define the response being measured, when work begins, which service hours count, and any permitted pauses, such as time spent waiting for your reply.

Four different moments are worth separating: acknowledgement, a meaningful response from a technician, restoration of the service so people can work again, and permanent resolution of the cause. Staff can be working again well before the root cause is fixed. Where a fixed resolution target is not practical, agree restoration priorities, escalation and update intervals instead, with a revised estimate once the cause is understood.

What after-hours cover is reasonable?

Choose IT helpdesk cover around when your business needs its systems available and how long it can tolerate an outage, not only whether anyone works at night. A business that opens at seven needs to know what happens to a fault found at half past six. Ask separately about monitoring, human response and onsite attendance outside normal hours, and confirm the contact route, the response target and any charges.

Monitoring can detect a problem overnight, but it does not guarantee that someone will act on it before work starts. Our guide to proactive IT monitoring covers what monitoring catches. If you run retail, hospitality, healthcare or shift work, ask what happens at 7pm on a Sunday before you sign, and get the answer in writing.

What contact channels should support offer?

An IT helpdesk should offer phone, email and a ticketing portal at minimum. Relying on one contact method creates a bottleneck, and it fails badly on the day the bottleneck is the thing that broke.

Some IT helpdesk providers add live chat or a self-service knowledge base for the repetitive requests, which is worth having if your team will use it. Password resets and new user setups are obvious candidates.

Why the ticketing system matters more than it sounds

Every issue raised with the IT helpdesk should generate a ticket, including the ones somebody solves in two minutes by walking over. Tickets create the record that makes everything else possible: prioritisation, escalation, reporting, and finding out that the same fault has now happened eleven times.

Without that record, problems recur invisibly, staff chase whichever engineer they like best, and you have no way to tell whether your provider is performing. The absence of a ticketing system is not a minor process gap. It removes your ability to hold anyone to anything.

How should escalation work?

IT helpdesk escalation runs through defined tiers, with the ticket updated every time an issue moves up one. Three tiers is a workable structure: first line for common faults, second line for server, network and recurring problems, and third line for senior engineers or vendors on infrastructure work.

The mechanism matters less than the transparency. At each step the ticket should be updated with who now owns the issue and a new expected time for the next update, rather than a resolution time nobody can know yet. A poor provider goes quiet, and you find out by chasing. Suspected security incidents should go straight to third line, or to whoever handles security response, rather than working up from first line.

Signs your IT helpdesk is underdelivering

These are visible without any technical knowledge.

• Standard issues take more than a day and nobody can tell you whether that is inside the agreed target, because there is no agreed target.
• Tickets are raised but never formally closed, so the record of what happened is incomplete.
• No monthly report arrives, or the one that does only counts tickets rather than measuring anything.
• The same problems keep returning because nobody has been asked to fix the cause rather than the symptom.
• Nobody owns it when things go wrong, and the conversation becomes about whose fault it was.
• Your staff have stopped logging tickets and started working around problems instead. This is the most serious one and the easiest to miss.

If you want to put a figure on what a slow IT helpdesk costs, estimate the working time actually lost rather than how long tickets stayed open. A ticket can stay open while someone uses a workaround, waits for a reply, or carries on after the fault is fixed. For each incident, note how many people were affected and how long they could not work, allowing for other useful work they could do instead, then multiply the lost staff-hours by your own hourly employment cost. As an illustration, four people unable to work for half an hour have lost two staff-hours, and a ticket that stays open until the next day does not turn that into a full day. Count direct recovery costs and customer impact separately, without counting the same loss twice.

What to ask a provider before you sign

Six questions separate IT helpdesk providers who have thought about this from providers who have not. Ask them before you sign, and ask for the answers in writing.

• What are your response and restoration targets by priority, and what starts and stops each clock? Ask what each number measures, not only what it is.
• How do you define first contact resolution? The definition tells you more than the percentage.
• Show me a sample monthly IT helpdesk report. Look for performance by priority and repeat incidents, not just volume.
• What happens when you miss a target? Look for the reporting, escalation and corrective action the agreement requires, and whether any service credits apply.
• Who answers at 7pm, and what changes about the service then? Get it in writing before you need it.
• Who owns security patching, which systems are covered, and what deadlines and exceptions are agreed? Patching is a separate commitment from routine IT helpdesk work, and it belongs in writing too.

For businesses in Christchurch and Dunedin, local presence is the seventh question. Remote support cannot recable a rack or replace a failed switch. Ask how quickly somebody can physically arrive, and whether that is included or billed. If you are weighing up the in-house, outsourced and co-managed options more broadly, our guide to business IT support models compares them.