Service Level Agreement (SLA), Operation Level Agreement (OLA), Underpinning Contract (UC)
Support Agreements - SLA, OLA, UC - Defined
A Service Level Agreement (SLA) is a contract between an internal service provider and an external end customer. Service Level Agreements define the range and quality of the covered services. Within the Service Desk, SLAs especially define the time spans in which tickets must be accepted and solved in order to avoid escalation.
An Operation Level Agreement (OLA) is an agreement between an internal service provider and an internal customer. Operation Level Agreements define the range and quality of the covered services.
An Underpinning Contract (UC) is a contract between an external provider and an internal end customer. Underpinning Contracts define the range and scope of the covered services.
As defined by ITIL, we differentiate in Service Level Management between the following support agreements:
Service Level Agreement (SLA)
A support contract agreed between the customers and the Service Desk.
Operation Level Agreement (OLA):
A support contract agreed between the internal IT departments (e.g., Network Management and IT Operations ).
Underpinning Contract (UC):
A support contract agreed between the Service Desk and external suppliers.
SLA consists of multiple Service Levels (SLs) which define the exact time frames for "Reaction Time" and "Solution Time". Furthermore, every Service Level is related to the ticket type and a priority the SL applies to. Service Levels also contain information about which Service Time Profile is valid - within which times a customer can rely on this specific support.
Besides the Service Levels, the SLA also specify entitlement and scope of the support contract. Only entitled persons, organizational units or locations are allowed to engage the agreed service. The SLA's scope defines exactly which services or assets are covered. Combining scope and entitlement allows defining very specialized support contracts for almost any customer - supplier constellation.
Furthermore, SLA will hold information about the ensured availability of covered services or assets and the agreed fulfillment regarding ticket processing. This information is gathered by several reports and allows quick and easy measuring of how well the support quality is met.
Upon creation of new tickets, these should be related to the appropriate SLA. Considering the entitlement and scope of active SLA, it is possible that various different SLA could be applied for a single ticket. In this case, the Service Desk will help the support staff by proposing that SLA with the most critical solution time. This is also done automatically, if a ticket is being created by a customer via Self Service Portal or from an incoming e-mail.
The following sections will provide detailed background information, tips and hints for a successful usage of support contracts.
General Contract Information
In this form, the general attributes of a SLA/OLA/UC are defined. Beside the contract's Title, the most important information is the Status. Only an active SLA/OLA/UC will be considered upon ticket creation. For UCs there is also the possibility to define the supplier the contract is agreed with.
Organizational Unit, Cost Center, and Location | If you create a new configuration item, you can link it by using a corresponding button to the respective organizational unit, cost center, and location. For existing configuration items, the ownership cannot be changed. |
Title | Title that is displayed on the corresponding search page in Matrix42 Software Asset and Service Management. |
Contract Number | Number that identifies this agreement in your company. |
Status | Displays the current status of the agreement and, therefore, maps the contract development. |
Contract Responsible Person | Employee of your company who is responsible for this agreement. |
Fulfillment Responsible Role | Role in your company that is responsible for this agreement. |
Description | Detailed description of the agreement, such as additional remarks about the contents or conditions of the contract. |
Journal | Comments about your activities that are related to this configuration item. You cannot change the journal entries after they are made. |
Contract Period
On the Period dialog page, the specified dates of an SLA/OLA/UC can be entered. Effective date and Expiration date have impact on the contract's status once they are reached. The status of an active SLA will be automatically changed to Expired, if the expiration date has passed.
Valid from | Date on which the contractual agreement takes effect. Depending on the effective date, the status is automatically monitored by the system to map contract development. |
Valid until | Date on which the contractual agreement expires. Depending on the expiration date, the status is automatically calculated by the system to map contract development. |
Original Expiration Date | Original date on which the contractual agreement expires. |
Unlimited Validity | Select this option if this contract is valid for an indefinite time period. |
Send Expiry Mail | Select this option to get an email reminder from the system when the agreement expires. |
Mail Number of Days Before Expiration | The reminder is sent this number of days before the contract expires. If you enter 0, the reminder is sent on the day the agreement expires. |
Expiration Mail Recipient | Persons to which the expiration reminder should be sent. |
Reminder Copy | Persons to which a copy of the reminder email should be sent. |
Renews Upon Expiration | Select this option to renew the agreement automatically. |
Renewal Period | The agreement is renewed by the entered time period. |
Time Unit: | Unit of time for renewal of the agreement. |
Cancelation | Cancelation modalities for this agreement. Example: 4 (= Cancelation Period) Weeks (= Time Unit) to the end of the quarter (= By). |
Other settings under Cancelation: | |
First Cancelation Date | First possible cancelation date. |
Canceled by | Date on which the agreement was canceled (status = Canceled). |
Send Cancelation Mail | Select this option to have an email reminder sent when this agreement can be canceled. |
Mail Number of Days… | The reminder is sent this number of days before the cancellation date. |
Cancelation Mail Recipient | Persons to which the cancellation reminder should be sent. |
Reminder Copy | Persons to which a copy of the reminder email should be sent. |
Categories
The Categories dialog page allows you to define Categories covered by the support contract.
Categories | Categories that are covered by the SLA/OLA/UC. |
If no category is defined, the contract covers all categories (only eventual asset scope, service scope and entitlement restrictions will be applied). If one or more categories are defined, the contract will only cover those specified categories.
Examples
- A new SLA must cover all categories: Define nothing at all
- A new SLA must cover the Active Directory category: Define the Active Directory category and nothing else.
Entitlement
The Entitlement dialog page allows you to define who is allowed to engage the support covered by this contract. A SLA/OLA/UC can be entitled to persons, organizational units, or locations.
Locations | Persons that are assigned to this location are authorized to use this SLA/OLA/UC. |
Organizational Units | Persons that are assigned to this organizational unit are authorized to use this SLA/OLA/UC. |
Users | Persons that are authorized to use this SLA/OLA/UC. |
If neither a location nor an organizational unit or user is selected, the contract is valid for all users of the company (only eventual service scope, asset scope, and category scope restrictions will be applied). If locations, organizational units or users are defined, the contract is only valid for those specified persons or persons belonging either to a specified location or organizational unit.
Examples
- A new SLA must be valid for everyone: Define nothing at all.
- A new SLA must only be valid for the Frankfurt location: Define only the Frankfurt location and nothing else.
- A new SLA must be valid for the Frankfurt location and also the VIP user Mike: Define the Frankfurt location and the user Mike.
- A new SLA must be valid for the Frankfurt location, the Development organizational unit and the VIP user Mike: Define the Frankfurt location, the Development organizational unit, and the employee Mike.
- A new SLA must only be valid for user Mike: Define only the employee Mike and nothing else.
Asset Scope
The Asset Scope dialog page allows you to define Assets or Stock Keeping Units covered by the support contract.
Stock Keeping Units | All assets assigned to these stock keeping units are covered by the SLA/OLA/UC. |
Assets | Assets that are covered by the SLA/OLA/UC. |
If neither a stock keeping unit (SKU) nor an asset is defined, the contract covers all assets and SKUs (only eventual service scope, category scope and entitlement restrictions will be applied). If SKUs or Assets are defined, the contract will only cover those specified assets or assets belonging to a specified SKUs.
Examples
- A new SLA must cover all SKUs and assets: Define nothing at all.
- A new SLA must cover only the SKU Server: Define only the SKU Server and nothing else.
- A new SLA must cover the SKU Server and also the MIKES_PC asset: Define the SKU Server and the MIKES_PC asset.
- A new SLA must cover only the MIKES_PC asset: Define the MIKES_PC asset and nothing else.
Service Scope
The Service Scope dialog page allows you to define Services and/or Service Types covered by the support contract.
Service Types | Services of these types are covered by this SLA/OLA/UC. |
Services | Services that are covered by this SLA/OLA/UC. |
If neither a service type nor a service is defined, the contract covers all services and service types (only eventual asset scope, category scope, and entitlement restrictions will be applied). If service types or services are defined, the contract will only cover those specified services and/or services of a specified service type.
Examples
- A new SLA must cover all service types and services: Define nothing at all.
- A new SLA must cover the services of type Software: Define the Software service type and nothing else.
- A new SLA must cover the service of the Software type and also the User Account service: Define the Software service type and the User Account service.
Combining Entitlement and Scopes
While using support contracts within the Service Level Management and ticket processing, it is most likely that you will need to set up specific combinations of entitlement and scopes. Please read the following examples for a better understanding of the interaction.
Examples
- A new SLA covering Hardware services must be offered to the legal unit Imago Verum Inc.:
In Entitlement, define the organizational unit Image Verum Inc.
In Service Scope, define the service type Hardware - A new SLA covering the E-Mail service must be offered to the VIP users Mike and Tim:
In Entitlement, define the users Mike and Tim
In Service Scope, define the service E-Mail - A new SLA must cover the service Database Engine on the machine VIRTUAL_SERVER:
In Asset Scope, define the asset VIRTUAL_SERVER
In Service Scope, define the service Database Engine - A new SLA must cover all assets from SKU Lenovo T61 which are offered in the Service Catalog as service Standard Notebook:
In Asset Scope, define the SKU Lenovo T61
In Service Scope, define the service Standard Notebook
Fulfillment
The Fulfillment dialog page allows you to define the target values for First Shot Rate, Reaction Rate, and Solution Rate. For each of these values, the upper and lower thresholds should also be defined. These values will be monitored in the Service Level Fulfillment report allowing which allows you to evaluate if the support staff achieved the agreed service quality.
Although the Bonus and Malus values are not computed directly, they are important information of conventional contracts and will help with increasing motivation.
First Shot Rate: Ratio of total number of tickets to the number of tickets that were closed with the reason Directly Solved.
Acceptable Over Fulfillment (%) | Maximum threshold above which the proportion is not supposed to rise. |
FSR Bonus | Optional monetary compensation in case of over-compliance. |
Target Fulfillment (%) | Agreed target value for the proportion. |
Acceptable Under Fulfillment (%) | Minimum threshold below which the proportion is not supposed to fall. |
FSR Penalty | Optional monetary deduction in case of under-compliance. |
Reaction Rate: Ratio of total number of tickets to the number of tickets the reaction time of which has escalated.
Acceptable Over Fulfillment (%) | Maximum threshold above which the proportion is not supposed to rise. |
RR Bonus | Optional monetary compensation in case of over-compliance. |
Target Fulfillment (%) | Agreed target value for the proportion. |
Acceptable Under Fulfillment (%) | Minimum threshold below which the proportion is not supposed to fall. |
RR Penalty | Optional monetary deduction in case of under-compliance. |
Solution: Ratio of total number of tickets to the number of tickets the solution time of which has escalated.
Acceptable Over Fulfillment (%) | Maximum threshold above which the proportion is not supposed to rise. |
Sol Bonus | Optional monetary compensation in case of over-compliance. |
Target Fulfillment (%) | Agreed target value for the proportion. |
Acceptable Under Fulfillment (%) | Minimum threshold below which the proportion is not supposed to fall. |
Sol Penalty | Optional monetary deduction in case of under-compliance. |
Service Levels
The Service Levels dialog page allows you to define the different service levels (SLs) that are applicable to a contract. Support contracts can contain multiple Service Levels, one for each existing combination of Ticket Type and Priority, e. g. "High Priority Incidents".
Only one Ticket Type can be defined in the same SLA.
For the definition of Service Levels, the Reaction Time, the Solution Time and the respective Service Time Profile are mandatory, which will be used for calculation of the ticket's actual escalation points.
Service Levels | Add the agreed ticket type, priority, service time profile, description, and reaction and solution times. |
Service Time Profiles
The Service Time Profiles (STPs) can define the actual working times of a single support team or whole service desk. For support desks that are spread over different countries, these Service Time Profiles contain vital information about different working times, time zones and holidays of these locations. For the calculation of ticket escalation points, the matching Service Level (by priority and ticket type) including its Service Time Profile will be used from the SLA which is assigned to the ticket.
Working times are those hours within the days of a week which are marked as “Active Service Times”. Those days which have at least one hour of “Active Service Time” are called working days (or business days). Those days which have no “Active Service Time” at all, are non-working days. Service Times are related to countries which again define a set of holidays. The holidays of the selected country will overwrite working days, the holiday's attribute “Use in escalations” is set. The escalation points are always aligned to the Time Zones of Service Time Profiles, and will therefore always be within the active working times.
Examples
Imagine the following situation: a support desk is working 24 h, 7 days a week. As the company has sites all over the world, there are three different support centers in Germany, Japan, and the United States which are rotationally on duty. Each support center has a day time shift of 8 hours - 9 to 5 local time. All three support centers offer support for the same services.
Set up three different Service Time Profiles
Service Time Profile 1: Daytime Shift Japan
Service Time Profile 2: Daytime Shift Germany
Service Time Profile 3: Daytime Shift USA
Define similar Service Level Agreements
Define three similar Service Level Agreements with the desired entitlement, scope, and fulfillment. To simplify this example, these SLAs will be defined for all users, assets, and services, and only one Service Level will be defined for incidents with high priority.
Service Level Agreement “SLA Japan”:
Service Level for high priority incidents and STP “Daytime Shift Japan”. Reaction Time is 1 hour and Solution Time 3 hours.
Service Level Agreement “SLA Germany”:
Service Level for high priority incidents and STP “Daytime Shift Germany”. Reaction Time is 1 hour and Solution Time 3 hours.
Service Level Agreement “SLA USA”:
Service Level for high priority incidents and STP “Daytime Shift USA”. Reaction Time is 1 hour and Solution Time 3 hours.
Track and Process Tickets
Incident 1
User Barbara who is located in Germany reports an incident with high priority on 5/4/2010 at 11:05 AM (GMT+1). When the support staff clicks the “Set SLA” action (or simply saves the ticket), Service Store applies the “SLA Germany” as the SLA with the most critical solution point.
Reaction Point: 5/4/2010 12:05 PM (GMT +1) / Solution Point: 5/4/2010 2:05 PM (GMT +1)
Incident 2
User Barbara who is located in Germany reports an incident with high priority on 5/4/2010 at 5:24 PM (GMT+1). When the support staff clicks the “Set SLA” action (or simply saves the ticket), Service Store applies the “SLA USA” as the SLA with the most critical solution point.
Reaction Point: 5/4/2010 6:24 PM (GMT +1) / Solution Point: 5/4/2010 8:24 PM (GMT +1)
Incident 3
User Barbara who is located in Germany reports an incident with high priority at 5/4/2010 3:29 AM (GMT+1). When the support staff presses the “Set SLA” action (or simply saves the ticket), Service Store applies the “SLA Japan” as the SLA with the most critical solution point.
Reaction Point: 5/4/2010 6:24 AM (GMT +1) / Solution Point: 5/4/2010 8:24 AM (GMT +1)
Availability
Target Availability
Ensured Availability (%) | Target value for average availability of services. |
Meantime Between Failures (MTBF) in Days | Target value for average time between service faults. |
Meantime Between Service Incidents (MTBSI) in Days | Target value for average incident-free time of services (time between two incidents). |
Meantime to Restore Service (MTRS) in Days | Target value for average time that is needed to restore services (until a failed service is available again). |
Capacity
Minimal Amount Users | Target value for the minimum required number of users of this service. |
Capacity Maximal Users | Target value for the maximum permitted number of users of this service. |
Attachments
For the SLA/OLA/UC, copies of digital documents can be saved and later reopened.
Appointments
On the Appointments dialog page, you can manage Appointments that are related to this SLA/OLA/UC.
Notes
On the Notes dialog page, you can manage Notes and Memos that are related to this agreement.
Incidents
On the Incidents dialog page, you can manage Incidents that are handled under this SLA/OLA/UC.
Problems
On the Problems dialog page, you can manage Problems that are handled under this SLA/OLA/UC. Problems are derived from incidents if these cannot be solved immediately.
Changes
On the Changes dialog page, you can manage Service activities, such as solving a problem, that result in changes.
Tasks
On the Tasks dialog page, you can manage Tasks that were created in this context.
Actions
In the action pane, you can access the actions that are available for the support contact.
Create Task | Create a task from an SLA/OLA/UC. The task is then automatically linked to this support contract. |
Edit | Open the SLA/OLA/UC for editing. |
Delete | Delete the SLA/OLA/UC. |
History | View the history of the SLA/OLA/UC related transactions. |
Export | Export the SLA/OLA/UC to an XML file, with or without the N:M Relations. |