Structuring your Service Level Agreement

This is another in the series of Service Level Management posts I’ve been writing – the last one was on the subject of initial statistics (I'll pick up more about why the initial statistics are needed in later posts). I’ve also posted about defining the services you deliver.

If you are trying to create a Service Level Agreement (SLA) from scratch, there are a few ways I’ve seen of structuring your document.

Based on Services

You can structure your SLA around services, using the Service Catalog as a start point. To give you ideas, here’s an example based on an Invoicing System:


Major Incident: System down, with no availability to users, or significant business process impact with no workaround. High Priority Incident: System available, but with some significant business process impact for which a short-term workaround is available Regular Incident: No significant business process impact, or a small (less than 4) number of users affected


System is required from 8:00 to 18:00 Mon-Fri, excluding public holidays

Service Level Targets:

Major Incident: Achieve 90% resolution within 4 working hours
High Priority: Achieve 90% resolution within 8 working hours
Regular Incident: Achieve 90% resolution within 12 working hours

Notice that what I’ve written above is specific to a particular service, defines ‘grades’ of Incident by severity, and sets targets for Incident resolution. If you are preparing a real SLA for a customer, you’ll need more detail than I have created above. Issues such as reporting intervals, type of metrics to be used, escalation and others may need to be taken into account.

The above example does raise a question it is worth stopping for a moment to consider. If our Invoicing System is delivered over the network, and our network fails, is this an Incident affecting the Invoicing System or Network? If the Invoicing business process is affected then the answer is both and the Incident would be classed as a Major Incident.

Serio users taken note: this is exactly when Incidents can be logged against multiple Systems – so that, for reporting purposes, a single Incident can have multiple affects.

Based on Customer Groups

In addition to services, you can use different customer groups – by departments if you are providing support internally, or by company if you support external customers. Here each group is often a budget holder, which allows for negotiation to take place on service and costs.

In a customer-group model, each group has their own specific SLA (which is often broken down again into services). The SLA specifies clearly to which Incidents it will apply, and tries to anticipate any confusion that might arise when a single Incident affects multiple groups.