What to Put in a Managed IT SLA Before Signing

An IT support proposal may promise a “fast response” while leaving the buyer to decide what fast means when the office server is down. Before signing a managed IT service-level agreement (SLA), describe the devices and hours covered, the route for each incident, and the evidence you will receive afterward. A Biñan office with a checkout counter, remote staff, and a shared server needs more than one generic response rule.

Define exactly what is covered

Start with an inventory: locations, employees, desktops, laptops, network devices, servers, cloud accounts, and business applications. Mark the owner of each item. A provider cannot fairly accept responsibility for an unnamed third-party application, a modem controlled by the internet provider, or a device outside the agreed site without an explicit provision.

Record the support window in Philippine time, the contact channels, and the authorized people who may open a ticket. State whether monitoring, remote troubleshooting, on-site visits, security updates, backup checks, and vendor coordination are included. “Managed” is not a complete scope definition. A contract should say which activities are scheduled, which are triggered by alerts, and which require separate approval.

The principle is similar to Microsoft’s explanation of service-level agreements: read the metric, the covered service, the period, and the exclusions. Microsoft’s page describes Azure availability agreements, so it does not supply response targets for an office helpdesk. Your own contract must define those targets.

Give incident levels business meanings

Severity should reflect the effect on operations. A single employee locked out of email, a checkout unable to take orders, and a failed server serving every department require different handling. Define levels with examples from your workplace, then specify who can raise or change the severity. A ticket system that automatically labels every request “urgent” offers little guidance.

Use four separate clocks. Acknowledgment means the request was received. Response means a qualified person began diagnosis and contacted the reporter. Workaround restores a usable business process, perhaps by an approved manual procedure. Resolution fixes the underlying issue and closes the ticket after confirmation. If a contract promises only “response,” ask what action starts that clock and what stops it.

For a proposed after-hours level, write its actual coverage window and contact route. A monitoring alert does not by itself mean someone is staffed to respond at night. Do not assume 24-hour coverage, an on-site arrival time, or a guaranteed fix unless those terms appear in the specific offer.

Check the path from remote diagnosis to on-site work

A support desk may solve a locked account remotely; a failed switch may require someone in the building. For each priority, ask when remote work begins, what triggers an on-site visit, whether travel time counts toward the target, and who can authorize a hardware purchase. List the branch addresses, access hours, and a local contact who can open the server room or provide a spare device.

Write the escalation route as names or roles, not “escalate as needed.” It should cover an unavailable first contact, a prolonged incident, a vendor-controlled fault, and a decision that the business must make. If the ISP controls the last-mile connection, who calls it, keeps the ticket number, and updates the office? If a cloud vendor has an outage, who confirms its status and coordinates a workaround?

Use this clause review matrix

Compare each candidate agreement line by line. Fill “missing” rather than guessing what a sales conversation meant.

Clause	Question to answer in the signed document	Evidence to request
Asset scope	Which sites, devices, accounts, and applications?	Attached inventory and change process
Coverage	Which days, hours, holidays, and channels?	Published support schedule
Priority	Who assigns levels and by what business impact?	Example incident classifications
Response	What starts and stops each clock?	Ticket timestamps and status history
Workaround and resolution	What counts as restored service and final closure?	Confirmation from the business owner
On-site support	What triggers a visit and who pays for travel or parts?	Location and cost clauses
Escalation	When do the manager and outside vendors join?	Named roles and contact route
Routine work	Which patch, backup, and monitoring checks are included?	Schedule and exception record
Exclusions	Which failures, products, and circumstances are outside scope?	Explicit exclusion list
Exit	How are credentials, records, and documentation returned?	Handover format and deadline

Do not copy a vendor’s target into the table without checking its conditions. A “four-hour response,” for example, might be measured only during business hours and only after a valid ticket reaches a named portal. Replace the example with the precise wording from the offer you are reviewing.

Make reporting and exit part of the service

Request a monthly report showing opened and closed tickets, priority, elapsed response, repeated faults, unresolved risks, and planned improvement actions. A count alone will not tell you whether the same Wi-Fi fault disrupted a branch every Monday. Agree on a review meeting or written action owner so recurring work is visible.

Specify what happens when the agreement ends. The business should know how it will receive device inventory, network diagrams, backup locations, administrator access, vendor contacts, and open-ticket history. Set a controlled process for transferring credentials; do not ask providers to email passwords in plain text. Clarify who removes provider access once the transition is complete.

Our managed IT outsourcing service covers support and monitoring activities that can be scoped to an organization’s needs. If you have a site and device inventory, share it with us. We can use it to discuss a coverage matrix and the SLA terms that matter to your operations.