IT Support Agreement Checklist Template

What the IT Support Agreement Checklist Covers

1. 1
   Phase 1

   Phase 1: Service Scope Definition

   6 tasks

   The most valuable sentence in any support agreement is “Out of scope.” Clarity about what is not covered prevents scope creep, misaligned expectations, and the disputes that follow when a customer raises a request that the support team believes is out of scope.

   • Define covered services — specific systems, applications, infrastructure components, and end-user devices covered under the agreement; explicit list not general categories
   • Define explicitly out-of-scope services — what the agreement does NOT cover; personal devices, unsupported software versions, custom in-house applications without support contracts
   • Define covered users — who is eligible to raise support requests? All employees? Named contacts only? Specific locations?
   • Define geographic scope — which sites, offices, or regions are covered; remote workers; cloud-only vs on-premises
   • Confirm coverage for third-party applications — how vendor applications are handled: triage to vendor, manage on the customer’s behalf, or not supported
   • Document what constitutes a “supported configuration” — which OS versions, browsers, and application versions are supported
2. 2
   Phase 2

   Phase 2: Service Hours & Availability Commitments

   6 tasks

   • Define standard service hours — the hours during which full support is available; typically business hours in the customer’s time zone
   • Define out-of-hours coverage — what support is available outside standard hours? Emergency P1 only? Full coverage? How is it accessed?
   • Define public holiday coverage — which public holidays affect service hours; advance notice to customers; emergency coverage during public holidays
   • Define system availability commitments — uptime targets for managed infrastructure where applicable; how uptime is calculated and measured
   • Define planned maintenance windows — when scheduled maintenance may occur; advance notice requirements; whether maintenance windows are excluded from availability calculations
   • Define SLA clock behaviour — whether SLA timers run in business hours or calendar hours; when clocks are paused (awaiting customer response); how holidays affect targets
3. 3
   Phase 3

   Phase 3: Priority Matrix & Response/Resolution Commitments

   6 tasks

   Specific, numeric commitments are the heart of the SLA. “As soon as possible” is not an SLA commitment. “15 minutes within service hours” is.

   • Define the priority levels — P1 through P4 with clear, unambiguous definitions of what qualifies as each priority
   • Define response time for each priority — P1: 15 minutes. P2: 1 hour. P3: 4 hours. P4: 1 business day.
   • Define resolution time for each priority — P1: 4 hours. P2: 8 hours. P3: 1 business day. P4: 3–5 business days.
   • Define how priority is determined — who assigns priority; the criteria used; what happens if customer and provider disagree on the priority level
   • Define the consequences of SLA breach — service credits, reporting obligations, or formal review trigger; SLA without consequence is advisory only
   • Confirm Tier 1/2/3 escalation timelines — how long a ticket stays at each tier before mandatory escalation; tied to resolution targets
4. 4
   Phase 4

   Phase 4: Escalation Procedures

   5 tasks

   • Define the technical escalation path — Tier 1 → Tier 2 → Tier 3 → Vendor; with timing for each escalation trigger
   • Define the management escalation path — when does a ticket escalate to IT management? A named escalation contact for the customer to reach
   • Define the P1 war-room protocol — how a major incident is declared and who is assembled; customer contact during a P1
   • Confirm vendor escalation contacts — who escalates to which vendor; contact details and reference numbers for each key vendor relationship
   • Define customer escalation rights — the customer’s right to escalate to senior management contacts; how to exercise this right; response commitment on management escalation
5. 5
   Phase 5

   Phase 5: Metrics, Reporting & Transparency

   5 tasks

   • Define the SLA metrics to be tracked — at minimum: SLA compliance rate by priority, MTTR by priority, ticket volume by category, and CSAT score
   • Define the reporting frequency — monthly service review report as standard
   • Define the report contents — what data the monthly report includes; agreed with the customer in advance; SLA performance against target, ticket volume trends, and any ongoing known issues
   • Define the service review cadence — monthly or quarterly review meeting between IT provider and customer; agenda, attendees, and follow-up process
   • Define how SLA breaches are reported — immediate notification when a P1 or P2 SLA is breached; summary of all breaches in the monthly report with root cause and corrective action
6. 6
   Phase 6

   Phase 6: Exception Management & SLA Exclusions

   5 tasks

   • Define exclusions from SLA calculations — incidents caused by customer actions outside the agreed scope; third-party failures outside the provider’s control; planned maintenance windows
   • Define force majeure provisions — events beyond either party’s control; natural disasters, major utility outages
   • Define customer obligations — timely response to information requests; access for remote or on-site support; compliance with security policies
   • Define the SLA clock pause policy — SLA timers are paused when awaiting information or access from the customer; the pause period is documented in the ticket
   • Document how disputed priority assignments are resolved — the process for resolving disagreement about whether a ticket was correctly prioritised
7. 7
   Phase 7

   Phase 7: SLA Review & Ongoing Maintenance

   5 tasks

   • Conduct an annual SLA review — are the commitments still appropriate? Has the scope changed? Are the targets achievable given current capacity?
   • Review following any significant change — infrastructure changes, new services, changes in business criticality, or significant changes in incident volume
   • Review OLAs and UCs — confirm internal and vendor commitments still support the customer-facing SLA; renegotiate if the dependency chain has weakened
   • Issue a formal SLA amendment — any changes to commitments documented formally and signed by both parties; verbal agreements to “be flexible” are not SLA amendments
   • Review SLA performance data — has the SLA been consistently met? If not, are targets realistic or does capacity need to change?