A service agreement is a contract. And a contract, as we saw earlier, is essentially a set of complementary promises.
So a service agreement is really a set of promises between a provider and a consumer. Not a technical specification, not a piece of legal boilerplate: a set of promises.
Take a typical IT service. The provider might promise things like this:
- We promise to prevent unauthorized access.
- We promise to keep your information safe.
- We promise to maintain the service according to vendor best practices.
- We promise to keep a spare copy of your data off site.
- We promise to add resources as needed.
- We promise to apply updates and improvements.
- We promise to have trained staff that reacts timely and professionally.
None of these promises are self-evident. Each one could fail, or be broken. Each one is, in other words, also a risk.
This works the other way around too. Within a large organization, one team is often the provider and another the consumer of the very same kind of promises. That means internal teams need internal service agreements as well, even if nobody bothered to write them down.
We’ll come back to how these promises get quantified, measured, and enforced later. They can become service levels, key performance indicators, and penalties. For now, the point to take away is simpler: a service agreement is a contract, and a contract is a set of promises.