Most managed IT agreements are written to be signed, not read. They run long on liability language and short on the parts that matter when a server is down at 7am: what is in scope, what is billed extra, and how quickly a human picks up the ticket.
This post walks through the sections a service agreement needs, in the order you should check them. Use it whether you are writing one for your own clients or reading one a provider sent you.
Scope: name the devices, sites and systems
Scope should be a list, not a paragraph. A sentence like 'support for the client's IT environment' means everyone will argue later about whether the label printer, the owner's home Wi-Fi, or the legacy accounting server is included. Write the inventory into the agreement or attach it as a schedule that both sides update.
Count things. Number of users, number of managed endpoints, number of servers (physical and virtual), number of network devices, number of sites. Say which cloud tenants are covered (Microsoft 365, Google Workspace, AWS, Azure) and who holds the admin credentials for each.
- Endpoints: workstations and laptops running the RMM agent, with an OS floor (for example, Windows 11 and macOS current minus two)
- Servers: named hosts, hypervisors, and the backup system that protects them
- Network: firewalls, switches, access points, and the ISP handoff at each site
- Cloud: identity tenant, email, file storage, line-of-business SaaS the provider administers
- People: who at the client can open tickets, approve spend, and authorize account changes
Exclusions and the 'out of scope' rate
The exclusions section is where good agreements earn their keep. It protects the client from surprise invoices and protects the provider from unpaid projects that sneak in as tickets. Be specific and boring.
Common exclusions: new site buildouts, hardware purchases, migrations between platforms, custom development, work caused by unsupported software, and anything the client's own staff changed without telling anyone. Each of those is a project with a quote, not a ticket.
Then state the hourly or project rate that applies when something falls outside scope, and require written approval before that rate is billed. That single sentence prevents most billing disputes.
Response targets, severity levels and hours
Define severity before defining response. Critical means the business cannot operate: email is down for everyone, the ERP is unreachable, a site has no internet. High means a department is blocked. Normal means one person is blocked with a workaround. Low is a request or a question.
Attach a response target to each level and be clear that response means a technician has acknowledged and started work, not that the issue is fixed. Resolution time depends on the cause and cannot be promised honestly for every case. A provider that runs a 24/7 desk can commit to a short critical response target, under 15 minutes for example, but only if the after-hours path is written down: what number to call, what happens if nobody answers, and who escalates.
Also state coverage hours for non-critical work. If normal tickets are handled 8am to 6pm on business days, say so, along with the holiday calendar you follow.
Security, backups and the boring obligations
Managed IT without a security baseline is just break-fix with a monthly fee. The agreement should list the minimum controls the provider maintains on every managed device: endpoint protection, patching cadence, disk encryption, MFA on all admin accounts, and a documented backup schedule with a tested restore.
Write down the backup retention and where copies live. Write down who is notified after a security incident and how quickly. Write down that the client owns all documentation, credentials and configuration, and that the provider hands them over within a fixed number of days at termination. That last clause is what makes it possible to leave a bad provider without starting from zero.
- Patch cadence for workstations, servers and network firmware
- Backup schedule, retention, offsite copy, and restore test frequency
- Incident notification timeline and who receives it
- Ownership of documentation and admin credentials
- Offboarding handover: what is delivered, in what format, within how many days
Term, pricing structure and review cadence
Per-seat, per-device, or flat monthly pricing all work. What matters is that the unit is defined and the count is reconciled on a schedule, usually quarterly. Say how adding a user mid-month is billed and when a removed user stops being charged.
Set a review meeting into the agreement itself. A quarterly review with a fixed agenda, ticket volume, open risks, hardware age, upcoming renewals, keeps both sides honest and turns the contract into a working relationship instead of a document in a drawer. If you want a template to start from, RackLedge is happy to share the structure we use.
Frequently asked questions
Should the agreement include a guaranteed resolution time?
Only for narrow, well-understood cases such as password resets or new user setup. For outages, promise a response target and an escalation path. A resolution guarantee on unknown failures is either meaningless or priced very high.
What is the difference between a service agreement and an SLA?
The service agreement is the whole contract: scope, price, term, obligations. The SLA is the section inside it that defines severity levels and response targets, and what happens when they are missed.
How long should the initial term be?
Twelve months is common because onboarding takes real effort on both sides. Insist on a termination-for-cause clause and a clear handover obligation so the term is not a trap.
Takeaway
A good managed IT agreement is mostly lists: what is covered, what is not, how severity is defined, and what the provider maintains on every device. If you cannot find those lists, ask for them before you sign. The contract that is easiest to read is usually the one that is easiest to live with.