IT Support Agreement Checklist Template

Phase 1: Service Scope Definition

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

Phase 2: Service Hours & Availability Commitments

• 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

Phase 3: Priority Matrix & Response/Resolution Commitments

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

Phase 4: Escalation Procedures

• 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

Phase 5: Metrics, Reporting & Transparency

• 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

Phase 6: Exception Management & SLA Exclusions

• 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