Xurrent Help

Service Level Agreement

A service level agreement (SLA) is an agreement that is established between a service provider and a customer for a specific service. An SLA describes the minimum level at which the service is to be made available by the provider to the customer. It also describes the minimum level of support that the provider is to offer the customer in case of a service degradation or outage. Prerequisites, limitations, charges, penalties, etc. may also be specified in an SLA.

In Xurrent all the details of an SLA are actually defined in a service offering that is linked to an SLA. Registering a new SLA is therefore essentially a matter of selecting:

  • the customer,
  • the service offering that describes the level at which the customer wants to subscribe to the service
  • the service instance that the provider will use to deliver the service to the customer, and
  • the date at which the SLA is to become effective.

An SLA provides coverage for the users of the service. Coverage can be defined in an SLA for:

  • all people who are registered in the Xurrent account of the customer
  • all people who work for a specific organization, or any organization hierarchically below it
  • all people who work for a specific organization
  • all people who are stationed at a specific site
  • all people who work for a specific organization and who are stationed at a specific site
  • manually selected people
  • all people who have been linked as a user to a CI of the service instance that is used to deliver the service
  • all members of the teams that use the service instance to underpin other service instances that these teams are responsible for supporting.

This last option is used to specify that a service instance has been obtained by a service provider to support one or more of the service provider’s service instances. For example, the Application Development team may need to set up a development environment for a new service that it has been asked to build. To create the service instance that will become the development environment for this new service, the Application Development team asks the Unix team to provide a new Unix service instance and they ask the Database Administration team to provide a new Oracle database service instance. The Application Development team does this by selecting a service offering for the Unix service, as well as a service offering for the database service.

After the Unix team has made the new Unix service instance available and Database Administration has configured a new Oracle database instance on it, the Application Development team is able to add its software to complete the development service instance of the new service.

Child Service Instances

To ensure that the Application Development team knows what level of service it can expect from the new Unix service instance, the Unix team registers a new SLA for the new Unix service instance and relates the service offering to it that the Application Development team had selected. In this SLA it is specified that it covers the support team of the new development service instance. The Database Administration team registers a similar SLA for the new database service instance. This allows the Application Development team members to use Xurrent to submit requests for the new Unix and database service instances and it ensures that the new SLAs are used to track the actual level of service that these two service instances deliver.

By registering these two SLAs, the new Unix and database service instances have been related to the new service instance of the Application Development team as ‘child’ service instances. This indicates that the new development service instance requires the Unix and database service instances to be available in order to function properly. As service instances are linked in this fashion, a service hierarchy is documented which Xurrent uses to determine how an incident affecting a child service instance affects its parent service instance(s).

Impact Calculation

To help Xurrent determine the impact of service instances higher up the service hierarchy, customers can indicate in their SLAs (or OLAs, or underpinning contracts) whether a parent service instance will be down or degraded when the child service instance is down. In most cases, a parent service instance will be down when one of its child service instances is down. In the example above, the development service instance will be down when either the Unix or the database service instance is down. However, there are situations that may cause a parent service instance to merely be degraded when a specific child service instance becomes unavailable. This could be the case, for example, when the reporting functionality of a service is running on a separate Unix service instance. When this Unix service instance is down, the reporting functionality will no longer be available, but the core functionality of the service should still be working properly.

SLA Administration

One SLA must be established for every combination of a service instance and a customer that uses the service instance.

An SLA is always established between two organizations. The customer and provider organizations may belong to the same account. On the other hand, these organizations may also belong to different accounts. In such a case, the service provider registers the SLA. In order to establish an SLA with a customer organization of another account, a trust relation needs to exist between your organization’s account and the customer’s account.

When the customer organization of an SLA belongs to another account, then people with the Service Level Manager role of the customer’s account are able to specify the customer representative and the coverage of the SLA.

Only a person who has the Service Level Manager role of an account can maintain the SLAs of that account.

The Service Level Agreement Fields page provides field utilization guidelines for each field of the Service Level Agreement form.

Billable SLA

To make it easier for Managed Service Providers to use the Xurrent data to generate invoices for their customers via an integration with their invoicing tool, the concept of a Billable SLA is introduced.

A billable SLA is an SLA that is linked to a service offering with effort classes. When a specialist is registering time on a request, the Xurrent platform will check whether a billable SLA is active for the given request. If so, the effort classes related to the service offering of the billable SLA are shown. If no billable SLA is found, the effort classes that are linked to the timesheet of the organization of the specialist will be shown.