What our customers sayIT & SupportIT SupportMicrosoft 365Server SolutionsVirtualisationCyber SecurityCyber SecurityCyber EssentialsSavvy SecureEmail SolutionsAccess ControlCCTVConnectivity & CommsBusiness Phone SystemsProfessional CommunicationNetwork & WiFiMobile ConnectivityBroadband CheckerWeb & DigitalWeb DesignAll servicesResource CentreKnowledge HubGuidesMicrosoft 365Cyber SecurityIT SupportPhones & BroadbandCCTV & Security SystemsPlanning & ProductivityAll resources by topicFree toolsPSTN Switch-Off CountdownCost of Downtime CalculatorCyber Security Self-AssessmentBroadband CheckerCompanyLocationsFAQsAboutContactGet a Quote
Managed IT

Managed IT service level agreements explained

Two business professionals reviewing documents together

A service level agreement (SLA) sets measurable commitments for the managed IT service. It should explain priorities, response times, escalation and any remedies if the provider misses a commitment.

Response is not the same as a fix

A response target measures when the provider starts the agreed action. A restoration target concerns getting a usable service back. A final resolution may take longer if it requires a vendor change or replacement equipment.

Specify whether an acknowledgement counts as a response and when the clock runs. Business-hours targets and elapsed-time targets behave differently over evenings, weekends and bank holidays.

Make priorities meaningful

PriorityIllustrative business impactAgree in advance
CriticalEssential service unavailable to many usersEmergency escalation and update frequency
HighSerious disruption with limited workaroundOwnership and restoration target
NormalOne user affected with a viable workaroundResponse and progress expectations
RequestPlanned access or equipment changeFulfilment process and lead time

These categories are examples, not industry-mandated targets. Tailor them to your business.

What guarantees should we expect

Expect specific, achievable commitments supported by the delivery model. Ask how dependencies, waiting for your approval and third-party outages are treated. Understand whether a missed target leads to service credits, escalation or other contractual remedies.

Describe the business impact when reporting a problem

An engineer needs to know whether one person has a minor inconvenience or an entire team cannot work. Include the affected system, number of people, location, when the problem began and the business activity that has stopped. Our guide to reporting an IT problem provides a practical example.

A useful update explains what has been checked, the next action, who owns it and when you will hear again.

Agree escalation and communication before an emergency

Check how to escalate a business-critical issue, which contact route applies outside normal hours and how third-party suppliers affect the resolution. Ask whether follow-up notes will record the cause, the work completed and any remaining risk. This makes service reporting more useful than a simple count of closed tickets.

Next step: test the SLA against a major outage outside office hours and ask exactly when an engineer would act.

Want to discuss your IT support requirements? Talk to the Tech Savvy Solutions team.

Related articles

Call us Get a quote