What response time should you expect from IT support?

Expect a written commitment, graded by severity: a business-stopping outage acknowledged in minutes and worked continuously, a single-user problem the same business day, and routine requests inside a day or two. The number that matters is not the fastest one in the brochure but the one in the contract, attached to a definition.

The document that holds these commitments is the service level agreement, and it is less mysterious than it sounds. It grades problems by severity, commits to a response time for each grade, and defines the hours the clock runs. The most important distinction inside it is response versus resolution: response means a qualified person is engaged and working; resolution means fixed. A provider can truthfully promise the first. Anyone promising the second for every fault, sight unseen, is promising to diagnose the unknown on a schedule, and you should read that page twice.

The severity ladder, in plain English. Priority one: the business is stopped, the practice management system is down, nobody can work; this should be acknowledged within minutes and worked continuously, including escalation, until people are working again. Priority two: a team or a critical function is down but the business limps on; hours, not days. Priority three: one person has a problem with a workaround; same business day is reasonable. Priority four: requests, changes, new starters; a day or two, scheduled. If a provider's contract does not grade severity at all, every problem competes in one queue, and your outage waits behind someone's printer. Ask, too, who sets the severity when a ticket is logged, because a provider who grades every fault themselves controls their own scoreboard; the definitions should let you call a P1 a P1.

Now the clock tricks, because they are common and legal. Response measured to an automated acknowledgement email is a robot answering, not a response; the clock should stop at a human engaging. Targets are aspirations and commitments are contracts; check which word the document uses. Business-hours clocks pause overnight, so a 4pm P2 with a four-hour response can legitimately be touched at 11am tomorrow; fine, as long as you knew. And resolution promises that quietly exclude faults involving vendors exclude most real faults, because most real faults involve vendors.

What counts as fast enough is not universal; it is a function of what an hour of downtime costs you. A venue trading seven days needs after-hours cover priced into the contract; a nine-to-five professional office mostly needs certainty that business hours are properly covered and that a true emergency has a path at any hour. Buy the service level agreement that matches your operations, not the most impressive one, because the impressive one is priced into your monthly fee whether you use it or not. The right question is not how fast is your response but what does an hour of downtime cost us, and it should be answered by you before any salesperson arrives.

Before signing, verify rather than admire. Ask for last quarter's actual response statistics against the agreement; providers measure this, and the good ones will show you. Then ask a reference the only question that matters: when it broke badly, how long before a human was working on it, and how did you find out? A provider whose numbers and stories agree is telling the truth. Statistics without definitions mislead as well, so ask for both together.

Monitoring changes this whole conversation, which is why it belongs in the same decision. When systems are watched around the clock, as ours are through a 24/7 network and security operations centre, a large share of serious faults are detected and being worked before anyone at your office notices, and the response time on a fault you never had to report is effectively zero. Ask any provider what percentage of their P1s are detected by them rather than reported by the client; the answer describes the service better than the agreement does.

The honest caveat: the fastest response loses to the fewest incidents. A provider with a dazzling service level agreement and lazy patching will hit their response targets often, because things keep breaking. Judge the prevention discipline, patching, monitoring, tested backups, alongside the reaction speed, and weight it higher. The best support contract is the one you rarely test.