---
title: "What your IT support contract actually promises"
url: "https://sovereos.com/blog/what-your-it-support-contract-actually-promises"
description: "Most support contracts measure how fast the supplier replies, not how fast things work again. Where the promise and the expectation part, and what to ask for."
---

# What your IT support contract actually promises

October 8, 2026·3 min read·Editorial team

Two young colleagues read a printed page together at a round wooden table, one pointing at it with a pencil, with a glass-fronted server rack and other staff in the background.

Monday, twenty to nine. The shared mailbox that receives customer orders stops receiving anything. A ticket goes in. A few minutes later an automated reply confirms it has been logged as a normal priority incident. The contract promises a response for that priority within the same business day, and the supplier keeps that promise: an engineer replies before lunch and asks for a screenshot.

The mailbox works again on Wednesday afternoon. Two days of orders went to phone and personal mail. Every term of the contract was honoured.

The cause is not a bad supplier. Most support contracts measure what the supplier controls — how quickly they acknowledge a ticket — and let the supplier decide how serious your problem is. What the business actually cares about, how long until it works again, is often not in the contract at all.

## Where the promise and the expectation part ways

**Response, not resolution.** A response time is met by a reply. Check whether a target for restoring service exists anywhere in the contract, and if it does, whether it is a commitment or an aim.

**The supplier sets the severity.** Priority is defined by technical criteria, such as how many users are affected, rather than by what stopped. The orders mailbox is one mailbox, so it is never critical, even on the day it is the most important system in the building.

**The clock stops.** Business hours only, paused while the ticket is waiting for the customer, suspended when a third party is involved. Each pause is reasonable on its own, and together they can make any timeline fit.

**Exclusions do the heavy lifting.** The line-of-business software, the supplier’s own suppliers, anything that is not on the asset list, which nobody has updated since the contract was signed.

**Knowledge stays with the supplier.** Fixes happen in their ticket system and in their engineers’ heads. Documentation is not a deliverable, so after three years the company knows less about its own estate than it did at the start. The single point of failure described in [your continuity plan is one person](https://sovereos.com/blog/your-continuity-plan-is-one-person) has not gone away. It has moved to an outside company.

**The exit is undefined.** What gets handed over at the end, in what form, within what window, and whether the administrator accounts are even registered to you.

## What to ask for instead

**Severity defined in your terms.** List the handful of things that stop the business — taking orders, invoicing, payroll, the warehouse system, mail — and agree that any of them failing is top severity, however many people it affects.

**Restoration targets for those.** Time until the business can work again, by a workaround if necessary, not time until the first reply. A supplier who will not commit to a number should at least commit to a process: who is called, how often you are updated, and when it escalates.

**A named engineer.** Somebody who knows your environment, with a named deputy, rather than whoever picks the ticket from a shared queue.

**Documentation as a deliverable.** Every change and every significant fix written into a knowledge base the company owns and can read, reviewed together once a quarter.

**Credentials in your hands.** Administrative accounts registered to the company, the supplier’s access granted per person and revocable on the day the relationship ends.

**The exit clause, agreed at the start.** What is handed over, in what format, within what window and at what cost. The reasoning is in [nobody can price the exit](https://sovereos.com/blog/nobody-can-price-the-exit): a cost nobody has stated is a cost the other side gets to set later.

We use the same list as a guide in designing our own contracts, with support terms meant to sit [next to the exit terms](https://sovereos.com/) rather than in a separate schedule. We are pre-launch with no client contracts yet, and the details are agreed in each contract separately, so treat this as a checklist rather than a reference.

## The test

Take your current support contract and find the page that answers each of these:

1.  What is the target for restoring service, not for responding?
2.  Who decides the priority of a ticket?
3.  When does the clock stop?
4.  What is excluded?
5.  Who owns the documentation produced while supporting you?
6.  Are the administrator accounts registered to your company?
7.  What happens to your data, configuration and credentials when the contract ends?

Write the page number next to each answer. If more than two of them say “not in the contract”, you are not buying the outcome you think you are buying. That is worth knowing before the renewal date, not on the Monday the orders mailbox goes quiet.

-   SLA
-   managed services
-   IT support
-   contracts

## Keep reading

-   [How to build an agent factory for company IT, stage by stage](https://sovereos.com/blog/how-to-build-an-agent-factory-for-company-it)
-   [Your agent factory runs at a vendor. Who owns what it learns?](https://sovereos.com/blog/who-owns-your-agent-factory)