Put three IT AMC proposals side by side and they will look almost identical. Similar coverage lists, similar language, similar annual figures. The differences are real, but they do not live in the summary — they live in the response-time table, the exclusions list, and about six clauses most buyers skim.
This is a guide to reading an AMC properly. It applies whether or not you end up signing with us.
The distinction that matters most: response vs resolution
This is the single biggest source of disappointment in AMC relationships, and it is almost always a misunderstanding rather than a deception.
Response time is how long before someone acknowledges your ticket. Resolution time is how long before your problem is fixed.
Most AMCs guarantee the first and say nothing about the second. A contract promising a one-hour response is promising that within one hour, a human will confirm your server is down. It is not promising your server will be up.
That is not necessarily unreasonable — a provider genuinely cannot guarantee resolution when the fault might be a failed motherboard on a five-year-old server with no spare in the country. But you need to know which one you bought.
What to ask for: response times committed, and resolution times either committed or expressed as a target with reporting against it. At minimum, insist that resolution performance is measured and reported, even if not guaranteed. What gets measured tends to improve.
Severity definitions: who decides your emergency is an emergency
Every AMC has priority tiers — P1 through P4, or Critical/High/Medium/Low. The response times attach to those tiers. So the definitions decide everything.
The failure mode: you log what you consider a critical fault, the provider classifies it as Medium, and the four-hour SLA you were counting on becomes a next-business-day SLA. Nobody breached anything.
What to check:
- Are severity levels defined in the contract with concrete examples, or left abstract?
- Who assigns the severity — you, them, or by agreed criteria?
- Is there an escalation route if you disagree with a classification?
- Does “one user affected” automatically mean low priority? It shouldn’t, if that user is your finance director on payroll day.
Good contracts define severity by business impact, not by device count. Ask for that framing explicitly.
Coverage hours, and what “24/7” is actually covering
“24/7 support” appears on nearly every proposal. It rarely means what a reader assumes
Clarify:
- Are 24/7 hours covered by the same SLA, or do out-of-hours tickets have longer response times?
- Is out-of-hours support included in the fee, or billable at a call-out rate?
- Does 24/7 mean on-site availability, or remote only, with on-site attendance next working day?
- How are Fridays, public holidays and Ramadan hours handled? This is a genuine gap in Dubai contracts written from imported templates.
A contract can honestly say 24/7 while meaning “you may phone at 3am and someone will answer, then attend on Sunday.”
On-site vs remote, and who pays for the trip
Increasingly, AMCs are remote-first — which is efficient and appropriate for most tickets. The question is what happens when remote cannot fix it.
Ask:
- How many on-site visits are included annually? Unlimited, capped, or none?
- What triggers a site visit — your request, or their judgement?
- If a visit is chargeable, what is the rate and is there a minimum?
- What is the guaranteed on-site attendance time, and does it vary by location?
- Are preventive maintenance visits included and scheduled, or reactive only?
“Unlimited remote support with on-site as required” is a phrase worth interrogating. Required by whom?
The exclusions list is the actual contract
Read this section first. It defines the product more precisely than the coverage section does.
- Hardware parts. Labour is covered; the failed component is charged. Standard practice, frequently a surprise.
- Consumables — toner, drums, batteries.
- Software licensing and subscription renewals.
- Third-party vendor issues. Your ISP is down, your cloud provider has an outage. Does your provider coordinate with them, or hand you a reference number?
- End-of-life equipment. Many AMCs exclude hardware past a certain age or beyond manufacturer support. If half your fleet is six years old, this clause may exclude half your fleet.
- Damage from misuse, power events, or environmental causes. Reasonable — but power quality is a real issue in some Dubai buildings, and a blanket exclusion deserves discussion.
- Anything not in the asset schedule.
The asset schedule and how it goes stale
Your AMC covers a specific list of equipment attached to the contract. Anything not on the list is not covered.
Nine months in, you have added laptops, replaced a switch, deployed two access points and installed three cameras. None are on the schedule. A fault on any of them is out of scope, and the discovery happens at the worst possible moment.
What to require:
- A documented process for adding assets, ideally without amending the whole contract
- Clarity on whether additions are included or repriced
- A scheduled review — quarterly or half-yearly — where the schedule is reconciled against reality
- Confirmation of who is responsible for keeping it current
If the provider maintains an asset register as part of the service, that is a meaningful value-add and worth paying for. If the schedule is a spreadsheet frozen at signature date, expect friction.
Clauses that quietly limit cover
These appear in reasonable-looking contracts and are easy to miss
Ticket volume caps. “Fair usage” language, or a cap on tickets per month, with excess billable. Ask what the cap is and what your realistic volume looks like.
Time-bank contracts. Some AMCs are structured as a pool of hours. When it runs out, you are on hourly rates. Check whether unused hours roll over — usually they do not.
Response window starting on ticket acknowledgement. If the clock starts when they acknowledge rather than when you log, the SLA measures a period they control.
Exclusion of “consultation” or “advisory” work. Reasonable in principle, but broadly drafted it can exclude asking why something keeps failing.
Automatic renewal with a long notice period. Ninety-day notice on an annual contract means deciding in month nine. Diarise it.
Escalation matrix absent. If there is no named escalation path with names and numbers, then when things go badly wrong you will be escalating to whoever answers the phone.
No provision for handover on exit. When the contract ends, do you receive documentation, passwords, asset registers and configurations? A provider who cannot commit to a clean handover has designed a dependency, not a service.
Beyond fixing things when they break, a serious contract usually includes:
- Proactive monitoring with defined alert thresholds, not just reactive tickets
- Patch management — OS and firmware, on a schedule, with a documented approach to testing
- Backup verification. Note the word: verification, not just backup. An unverified backup is a hypothesis. Ask whether restores are tested and how often.
- Regular reporting — ticket volumes, response performance, recurring issues, trends
- A named technical account contact who knows your environment
- Periodic review meetings — quarterly is typical, and this is where an AMC stops being a break-fix arrangement and becomes useful
- Asset lifecycle guidance — what is aging, what should be budgeted for replacement, whenThat last point is where a good provider earns their fee. Telling you in advance that eight machines will need replacing next year is worth more than fixing them quickly when they die.
This is increasingly where AMC disputes originate, because assumptions differ. Establish in writing:
- Who owns antivirus and endpoint protection — deployment, monitoring, response?
- Who manages firewall configuration and its rule reviews?
- Who is responsible for user access — onboarding, offboarding, permission changes?
- What is the process when a security incident is suspected, and what are the timelines?
- Who handles credential management, and where are administrative passwords held?
An AMC that keeps your machines running but leaves security ownership ambiguous has left the largest risk in your environment unassigned.
Per-device. Predictable, scales cleanly, easy to audit. Watch how device categories are defined — a server and a laptop should not price the same.
Per-user. Sensible where people have multiple devices. Confirm what counts as a user.
Flat annual. Simple, but check for the caps and fair-usage language discussed above.
Time-bank. Suits organisations with genuinely low, predictable volume. Suits few others.
The structure matters less than whether it aligns incentives. Be alert to any arrangement where the provider earns more when things break more.
- Response and resolution both addressed?
- Severity levels defined by business impact, with an escalation route?
- Coverage hours explicit, including holidays and out-of-hours charging?
- On-site visits: included, capped, or chargeable — and at what attendance time?
- Exclusions read in full, especially end-of-life equipment?
- Asset schedule process defined, with scheduled reviews?
- Ticket caps or fair-usage language identified?
- Backup verification included, not just backup?
- Named escalation contacts in the document?
- Exit and handover terms specified?
- Renewal notice period diarised?
- Security ownership drawn explicitly?
If a provider engages willingly with all twelve, that is itself informative. The willingness to be pinned down is a reasonable proxy for how the relationship will run.
An AMC is not really a document about fixing computers. It is an agreement about who carries which risk, and what happens on the bad day.
The contracts that fail are rarely the ones with poor terms. They are the ones where nobody read the terms until the bad day arrived, and then found that both parties had been operating on different assumptions for eleven months.
Read the exclusions first. Ask about resolution, not just response. And make sure the asset schedule is a living document.
