Every managed IT provider in Egypt offers 24/7 support, including us. The phrase has become close to meaningless, because it describes when someone will answer rather than what will happen. The differences that matter are in the definitions underneath, and they are worth twenty minutes of reading before you sign.
Here is what to look for — and these are fair questions to put to any provider, us included.
Response time and resolution time are different things
A one-hour response commitment means someone will acknowledge your ticket within an hour. It says nothing about when the problem will be fixed. Both numbers should appear, and resolution targets should vary by severity rather than being a single figure.
Who defines severity?
This is the clause that quietly decides everything else. If the provider classifies incidents, then your urgent problem can be logged as medium priority and the service level is technically met. The better arrangement is an agreed severity matrix written in plain language — with the customer able to escalate a classification and a defined process when the two of you disagree.
What does out-of-hours actually cover?
Ask specifically:
- Is out-of-hours support a full team or one person on call?
- Is it included, or billed at a different rate after a threshold?
- Does it cover all systems or only those designated critical?
- Is on-site attendance available at 3am, or is out-of-hours remote-only?
- What is the escalation path if the on-call engineer cannot resolve it?
Remote versus on site
Most issues can and should be closed remotely — it is faster for everyone. But some cannot: failed hardware, a switch that needs physical attention, a site with no connectivity. The contract should state when an engineer travels, how quickly, to which locations, and whether that is included. For a business with sites in more than one governorate this is not a detail.
What is explicitly excluded
Every contract has exclusions and that is reasonable. What is not reasonable is discovering them during an incident. Common exclusions worth confirming in writing: third-party applications, equipment beyond end of support, work arising from changes made by other parties, and anything classified as a project rather than support — that last one being the most elastic definition in the industry.
Reporting you would actually read
Monthly reporting should tell you something you can act on: ticket volumes and where they cluster, service levels met and missed with reasons, recurring issues and what is being done about the cause, and what changed in the environment. A report that only says how many tickets were closed is a measure of activity, not of whether your IT is getting better.
The clause we would look at first: who classifies severity, and what happens when you disagree. Everything else follows from it.
And the question behind all of them
When you call at an awkward hour, does the person who answers know your environment? A provider who designed and documented your systems can act. A provider reading a generic runbook cannot, no matter how quickly they pick up.
Skilled engineers on a secure connection, with the response time agreed in advance. Remote Support →
