A service level agreement is often reduced to one promise: “critical tickets answered within fifteen minutes.” That number may look reassuring, but it says little about whether the problem will be restored, who decides that it is critical or what happens outside office hours. A useful managed IT support SLA turns expectations into an operating […]
A service level agreement is often reduced to one promise: “critical tickets answered within fifteen minutes.” That number may look reassuring, but it says little about whether the problem will be restored, who decides that it is critical or what happens outside office hours.
A useful managed IT support SLA turns expectations into an operating agreement. It defines the services covered, the responsibilities of both parties, how incidents are prioritised and how performance will be reviewed. The aim is not to create penalties for every delay. It is to reduce ambiguity when technology affects the business.
Define the covered service clearly
Begin with a service catalogue. List the users, locations, devices, applications, networks and cloud platforms included. State support hours, time zones and channels. Identify exclusions such as unsupported software, personal devices or project work that requires a separate quotation.
Clarify whether the provider supplies a help desk only or also performs monitoring, patching, backup checks, identity administration, vendor coordination, security response and strategic planning. “Managed IT” can describe very different services.
The agreement should also explain how new users, sites or systems enter scope. Without a change process, the provider may be held responsible for technology it has never assessed, while the customer assumes it is covered.
Separate response, restoration and resolution
These terms measure different things:
- Response time is how quickly the provider acknowledges the request and begins appropriate triage.
- Restoration time is how quickly an acceptable service or workaround is returned.
- Resolution time is when the underlying issue is fully corrected and the ticket can close.
A provider can meet a response target by sending an automated acknowledgement while the business remains unable to work. For important services, restoration is often the more meaningful measure.
Not every incident can have a guaranteed resolution time. Third-party vendors, replacement hardware and complex investigations introduce dependencies. The SLA should require communication, escalation and active ownership even when the final resolution is outside the provider’s direct control.
Use business-based priority definitions
Priority should reflect impact and urgency, not how loudly someone reports a problem. Define categories with examples.
Priority 1: Critical business outage
Examples include a company-wide inability to work, a critical production service unavailable, a suspected major security incident or loss of an essential site connection with no workaround. This priority normally requires continuous attention and senior escalation.
Priority 2: Major degradation
A department or important function is significantly affected, but operations continue through a limited workaround. Examples could include widespread application errors or a key integration failure.
Priority 3: Standard incident
A user or small group is affected and a reasonable workaround exists. Most day-to-day support requests fit here.
Priority 4: Request or planned change
Examples include new-user setup, access changes, software installation, advice and non-urgent configuration. These should have fulfilment targets rather than incident-restoration targets.
Document who may declare a critical incident and how incorrectly prioritised tickets will be handled.
Make escalation and communication explicit
The customer should know what happens when progress stalls. Define operational and management escalation routes, including contacts for out-of-hours critical incidents. State how often updates will be provided at each priority.
For a serious incident, communication matters even when the technical position has not changed. A useful update states the current impact, actions underway, dependencies, next decision and time of the next update.
Agree which customer representatives can approve disruptive actions, emergency changes or service restoration with reduced functionality.
Document shared responsibilities
Managed services are a partnership. The provider may monitor backups, but the customer must identify which data and recovery targets matter. The provider may maintain devices, but users must make them available for updates. The provider can remove leaver access promptly only when the business supplies reliable notification.
List customer responsibilities such as maintaining authorised contacts, approving changes, providing accurate asset information and following security requirements. Also list provider responsibilities for documentation, access control, staff competence, subcontractors and service continuity.
This division is especially important for Microsoft 365, Google Workspace and cloud services, where the platform provider, managed service provider and customer each control different parts of the environment.
Include security and incident boundaries
The agreement should describe how security events are reported, triaged and escalated. Clarify whether the service includes endpoint monitoring, identity alerts, firewall events, vulnerability remediation or full incident response.
Specify controls for provider access: named accounts, multi-factor authentication, least privilege, logging and prompt removal when staff change. Agree notification expectations for suspected compromise and how evidence will be preserved.
Do not assume a general help-desk SLA includes forensic investigation, regulatory advice or cyber-recovery work. If those services are needed, define them or arrange a separate response agreement.
Cover planned maintenance and change
Set expectations for routine maintenance windows, emergency changes and customer notification. Define which changes are pre-approved and which require explicit authorisation. Important changes should have a rollback approach and an owner.
Maintenance exclusions should be reasonable and visible. An SLA loses value if almost every interruption is excluded. Conversely, the provider should not be penalised for approved maintenance or customer-requested delays.
Measure outcomes, not ticket activity
A monthly report should help leaders decide whether service is improving. Useful measures include:
- service availability for agreed critical systems;
- response and restoration performance by priority;
- reopened and recurring incidents;
- ageing requests and unresolved problems;
- user satisfaction and complaint themes;
- patch and endpoint compliance;
- backup exceptions and restore-test outcomes;
- security incidents and overdue actions;
- changes completed successfully;
- improvement actions with owners and dates.
Raw ticket volume can mislead. A rising number may reflect growth, better reporting or a recurring technical weakness. Discuss trends and business impact.
Define remedies and review
Service credits may be appropriate, but they rarely recover the cost of disruption. More important remedies include root-cause analysis, an improvement plan, additional oversight and the right to terminate after persistent material failure.
Review the SLA at least annually and when the business changes significantly. New offices, cloud migrations, acquisitions and changes in operating hours can make an old agreement irrelevant.
Questions to ask before signing
- Which systems and users are actually covered?
- Are targets based on response, restoration or resolution?
- How are impact and priority decided?
- What happens outside standard support hours?
- Who owns communication during a major incident?
- Which security and recovery activities are included?
- What depends on the customer or another vendor?
- How will recurring problems and improvement work be tracked?
A strong SLA cannot guarantee that technology will never fail. It can ensure that responsibilities, priorities and decisions remain clear when it does.
Kashinbu provides managed IT support built around transparent scope, practical escalation and measurable improvement across users, cloud services and infrastructure. Talk to Kashinbu about reviewing your current support model or defining an SLA for a growing operation.
Turn the insight into a practical plan.
Discuss your goals with a Kashinbu specialist and identify the next useful step.
