Most answering services are built to do one thing well: catch a call from someone who has never spoken to you before, take their details politely, and pass them on so you can sell to them. That is a real job and it is worth doing. It is also only half of what an IT company's phone line is for.
The other half is support. Existing clients, often on a contract with a written response time, ringing because something has stopped working. Those calls do not want a warm greeting and a callback promise. They want to know that the clock has started, that someone competent knows about it, and that the right person is being woken up if it is serious.
An answering service for an IT company has to do both of those jobs on the same line, and they pull in opposite directions.
The two jobs are structurally different
A new business enquiry is a low-urgency, high-value, low-frequency event. Getting back to them within a couple of hours is fine. What matters is that the caller feels heard, that you capture enough to qualify them, and that the enquiry does not evaporate.
A support call is the inverse. It is high-frequency, individually lower value, and time-critical in a way that is written into a contract. What matters is not warmth. It is accuracy of intake, correct severity classification, a ticket in the right system, and escalation if the situation warrants it.
Generic answering services are optimised for the first case. They measure themselves on rings-to-answer and message accuracy, and their scripts are built around capturing a name, a number and a reason for calling. Drop a P1 outage into that model and you get a polite message saying that Sarah from Meridian rang about the server, sent to an inbox at 19:40 on a Friday.
The workaround IT firms build in response is predictable. The support number gets published separately, or clients are told to email tickets instead, or the answering service gets used for overflow only while the team still tries to catch everything themselves. None of these is a system. They are all patches over a service that was never designed for the job, which is why the engineer on duty still checks voicemail out of habit.
Ticketing and PSA integration is the whole ballgame
If your answering service cannot write into your PSA, everything downstream degrades.
Most IT firms run their operational life through ConnectWise, Halo, Autotask, Freshservice or something comparable. The ticket is the unit of record. It carries the SLA clock, the client contract, the time entries, the audit trail and eventually the invoice. A call that does not become a ticket has not really happened as far as the business is concerned.
When an answering service sits outside that system, someone has to bridge the gap by hand. In practice that means a technician reads an email at the start of their shift and re-keys it into the PSA. The consequences stack up quickly. The SLA clock starts when the ticket is created, not when the client rang, so your reporting overstates your performance and the client's own logs will eventually disagree with yours. Duplicate tickets appear when the client also emails. Details get lost in transcription. And nobody can answer the question "how many after-hours calls came in for this client last quarter" without going through an inbox by hand.
Ask any prospective provider a direct question: can you create a ticket in the PSA, populated with client, contact, severity and the call notes, at the moment the call ends? Then ask to see it happen. Plenty of services will describe an integration that turns out to be an email parser someone set up once. The difference matters enormously when contract reporting depends on it.
SLAs are contractual, not aspirational
There is a category error at the heart of most answering service conversations with IT firms. The provider talks about speed as a service quality. The IT firm needs it as a contractual obligation.
If your agreement with a client commits you to a fifteen minute response on a priority one incident during business hours and a one hour response out of hours, that is not a target you aim at. It is a term you have sold, priced and been paid for. Missing it can trigger service credits, feed into a quarterly review, or simply give a client the ammunition they need when they are already thinking about moving.
So the practical requirement is not "answer the phone quickly". It is that whatever answers the phone must guarantee response behaviour at least as tight as the tightest SLA you have sold, and must produce evidence that it did. Timestamped call records, timestamped ticket creation, timestamped escalation. If you cannot pull that evidence during a client review, you are relying on the client's goodwill rather than your own records.
The escalation chain, and what actually deserves one
Every IT firm needs a route from a ringing phone to an on-call engineer's mobile at three in the morning. Very few calls should take it.
The design work is in the distinction. A genuine outage, a suspected security incident, a site-wide failure or anything affecting a client's ability to trade justifies waking someone. A password reset, a printer, a licence query or a billing question does not, even if the caller is annoyed. Get that boundary wrong in one direction and you burn out your engineers. Get it wrong in the other and you breach an SLA while someone sleeps.
A workable chain has a few properties. It is explicit about which severities trigger it. It has a defined attempt sequence, so if the primary on-call engineer does not answer within a set number of minutes, the call moves to the secondary and then to a named escalation contact. It logs every attempt. It knows who is on the rota this week without anyone having to remember to update it on a Friday afternoon. And it has a fallback that is a human decision rather than a dead end, because an outage call that reaches nobody is worse than one that reaches the wrong person.
Triaging severity without pretending to diagnose
The instinct when briefing a non-technical handler, or an AI voice agent, is to give them a decision tree that mimics a first-line technician. Resist it. Attempted diagnosis by someone who cannot diagnose produces confident, wrong information, and a client who has been told their VPN is probably fine will be much angrier an hour later.
The better script gathers structured facts and classifies impact, not cause:
- Who is affected? One person, one team, the whole site, multiple sites.
- What can they not do? Access email, log in, take payments, reach a specific application.
- When did it start, and has anything changed recently?
- Has anyone else from the organisation reported the same thing?
- Is there a workaround, or are they completely stopped?
Severity falls out of the answers by rule. Whole site cannot work equals P1. One user cannot access one non-critical application equals P3. The handler never says what is wrong, only what is happening and how much of the business it has stopped. That is defensible, repeatable and genuinely useful to the engineer who picks it up.
This plays to the strengths of AI answering: structured intake, consistent question order, accurate capture and rule-based classification are exactly the things software does not get tired of at two in the morning. Judgement about the underlying fault is exactly the thing it should not attempt.
One number or two?
It depends on your mix, and it is worth looking at the numbers rather than guessing.
A single number is simpler for clients, avoids the very common problem of a support call arriving on the sales line at the worst possible moment, and means one set of routing rules to maintain. It requires good triage at the front, because the first question has to be whether this is an existing client, and it needs the CRM or PSA to recognise the caller's number so that the answer is instant rather than interrogative.
Split lines make sense when support volume is high enough to justify its own routing, hours and reporting, or when your sales conversations are consultative enough that they deserve a different handling style entirely. The risk is that clients keep the sales number in their phone from three years ago and ring it during an outage, so a split only works if the sales line still routes support calls correctly rather than taking a message.
If you are early in this and unsure, one number with strong triage is usually the safer starting point. The decision to split is easy to make later once you can see the volume. Many of the underlying principles are the same ones that apply to any growing firm choosing how to handle inbound calls, and the guide to choosing an answering service for a small business covers that groundwork.
What good looks like
An answering service for an IT company works when a caller can ring one number, be recognised as an existing client, have their issue captured accurately and classified by rule, see a ticket appear in the PSA with the clock started, and either get a routine response next working day or have an engineer's phone ringing within minutes. New business enquiries flow through the same front door and land somewhere they will be followed up properly, without competing for attention with a live incident.
That is a systems problem more than a staffing problem, and it is why an increasing number of IT firms are building it with AI intake and rule-based routing rather than adding headcount to a rota. To map that against your own SLA commitments and ticketing setup, take a look at Nimble Dingo's AI growth systems and work out what your line actually needs to do.