Every IT support says the same thing: users like how their service is 24/7 and it is fast. But the words do not really confirm anything. You don’t know who will see your problem and when it will be fixed.
Those are the questions the users really need answers to. This matters even more when the office is online.
A Los Angeles managed IT firm at allsafeit.com is a useful reference point, as it has the number as the first number.
Read this blog to get more details
Response time is the gap between a ticket being logged and a person acting on it. That is all it measures. It says nothing about when the issue goes away.
The fine print decides what a response is. An automatic email that says “we got your ticket” should not matter. A good contract defines relay as a qualified technician doing work by phone, chat, or remote session.
Resolution time is the gap between the ticket being logged and the fix being confirmed. It is often much longer, and it depends on the issues. A locked account may take 5 minutes. A failed server may take a day.
Two terms show up in monthly reports. Mean time to acknowledge (MTTA) is the average real time. Mean time to resolve (MTTR) is the average resolution time. Both are averages, so a few very slow tickets can hide in many quick ones.
These terms come from IT service management, the discipline of running support as a defined process. If a provider cannot name its MTTA and MTTR, it is probably not measuring them.
One target for every ticket makes no sense. A printer jam and a ransomware alert should not wait in the same line. Most contracts use 4 priority levels. The targets below are examples of a common routine, not an industry standard:
Check who placed the priority. If the provider can downgrade your ticket without asking, a strict P1 target is easy to meet on paper. The contract should say how priority is set and how you can discuss it.
Picture a 40-person accounting place in Burbank at 8:10 a.m. on a Monday. Nobody can open the shared drive, and payroll is due at noon. Someone calls the help desk,k and the ticket is logged as Priority 1.
At 8:18, an engineer calls back and does a remote session. That is the replay, and it goes inside a 15-minute target. At 8:40, the engineer finds a failed storage controller and escalates to a senior engineer. At 9:30, a technician goes on site with a replacement part. At 10:05, the drive is back, and the office manager verifies it works.
The reply time was 8 minutes. The resolution took 1 hour and 55 minutes. Both numbers stay in the monthly report.
The clock is where most talk starts. A service level agreement sets the targets, but the timing rules choose whether the targets mean anything.
First, check whether the clock runs on business hours or about the clock. Say a P2 ticket arrives at 5:30 p.m. on a Friday with a 4-hour business-hours target. The clock may not start till Monday at 8 a.m. That is a 3-day wait that still matters as on time.
Second, check the pause rules. Most contracts stop the clock, and the provider waits on you, like for a password or access to a room. That is good. It turns into a problem when the pause is logged loosely, and nobody can see it.
Third, check the time zone and the holiday list. A provider in another state might follow its own calendar, not yours. A Pacific-time office on a provider’s Eastern-time clock loses 3 hours of coverage every afternoon.
Not every issue starts with a user ticket. Monitoring tools have alerts on their own, usually before anyone in the office sees them. A good provider treats both the same way, with a ticket, a priority, and a clock. That move from waiting for calls to watching systems is a big part of the evolution of IT services toward proactive support.
The way from alert to fix often has these steps:
Security alerts add a human step. Automated tools see known issues. An analyst is still needed for activity that does not fit a known routine, and that analyst has to be up at 3 a.m.
AllSafe IT, a managed IT provider in Los Angeles, gives a simple example. It works to a 15-minute first-response standard of the clock. It also tells buyers to ask any provider for a number with a definition, and then ask how that number is tracked.
Its helpdesk runs 24 hours a day with engineers, not just an answering service. For issues that can’t be fixed by phone, a local technician is sent from its Los Angeles office. Its managed detection and response service has a security analyst monitoring client networks around the clock.
AllSafe IT also uses flat monthly pricing on each client’s setup. That’s important for timing. Hourly billing can reward slow work, and a flat fee rewards solving issues for good.
Targets are only good if you see the results. Ask for a short monthly report with these numbers, separated by priority level:
Medians and the slowest 10% tell you more than averages. A provider with a 20-minute average can still leave one in ten users waiting half a day.
Write the definitions, priority levels, and clock rules into the contract, not a sales deck. Decide on who sets priority and how pauses are logged. Then check the monthly report against those terms every quarter.
Ans: No. Response means a qualified person starts work within that time. The fix depends on the problem and can take much longer.
Ans: It depends on the contract. Some providers charge per after-hours call, while others include it in a flat monthly fee. Ask before you sign.
Ans:Usually the provider’s first-line technician, using rules in the contract. You should be able to challenge a priority you think is wrong.
Ans: Ask for an anonymized monthly report from an existing client. It shows whether the provider measures response and resolution, and how it presents misses.
