Managing Agreements

Service Level Management (SLM) covers advanced management of various agreements or service commitments between businesses and their clients.

A service commitment refers to the speed and quality of service the user expects and the provider is able to provide. Failure to meet an agreed service commitment is called a breach. The expectations of all stakeholders can be formalized and documented in the form of an agreement.

SLM in ASM Core covers three different types of agreements:

Service Level Agreements (SLAs) are agreements between a service provider and its Users. SLAs are applicable to both calls and requests. For example, you might have an agreement with your Users to respond to and fix PC service calls within a set timeframe. They can be driven off Service Levels, or configured to be applied based on individual Users, config items, organizations, locations, or types.
Operational Level Agreements (OLAs) are agreements between internal departments of a service provider. OLAs are applicable to calls, tasks, and approvals. For example, you might have an agreement that states that Third Level Support will resolve technical issues sent to them from the service desk within a certain amount of time.
Underpinning Contracts (UCs) are agreements between a service provider and the external suppliers who provide additional services or support to the service provider. UCs are applicable to calls, tasks, and approvals. For example, you might have an agreement with a hardware supplier that they will deliver computers or parts within a certain number of days from when they are ordered.

You can create and update agreements in ASM Core, and add:

You can also:

Define selection criteria for the agreement (that is, the rules that define in what situations the agreement is used)
Define thresholds for the agreement (that is, the times at which escalation and agreement breaches occur)
Define measurements and penalties for the agreement
Upload or download an attachment
Specify Agreement Stakeholders
View the audit trail for the agreement

ASM automatically applies agreements to calls based on a combination of information (the call details, IPK selection criteria, agreement selection priority, and the action performed by the analyst).

Only SLAs (Service Level Agreements) can be linked to requests.

The appropriate SLA is identified in the following way:

The system looks for an SLA assigned to the workflow template on which a request is based. If one is found, it is applied.
If no SLA has been defined in the workflow template, the first time a request is authorized ASM tries to find an SLA to apply. It checks the fields defined for the request, in a specific order defined for each field, to see if the particular entity defined is matched to an SLA as a Workflow Selection Criterion. If so, the agreement is applied.
If no matches are found for any of the fields, ASM checks for a default agreement; if one is found, it is applied.
Otherwise, no SLA is applied to the request.

Creating an Agreement

You can create three types of agreements in ASM Core: SLA, OLAs, and UCs.

Before you start

You must have Agreement New selected in the Options tab of your Service Level Management security role to create agreements.

Select New. In the submenu, scroll down and select Agreement.
You can also create an agreement from the Search window by selecting the Add New button in the left pane, or clone it from an existing agreement.
From the Select Agreement Type list, select the type of agreement you want to create. The available types are:

SLA	to create a Service Level Agreement
OLA	to create an Operational Level Agreement
UC	to create an underpinning contract

SLA

to create a Service Level Agreement

OLA

to create an Operational Level Agreement

to create an underpinning contract

4. The Agreement Details window appears. The upper part of the window contains some basic information about the agreement. The lower part contains a number of tabs, which can be selected by clicking on them. Depending on the type of agreement you are creating, some fields and explorer options are enabled or disabled.

5. Complete the agreement details.

Title

Type a name for the agreement.

Choose an appropriate name, such as Laptop Service Agreement

Reference

Type a reference code for the agreement. It can be any number of letters or numbers, up to 50 characters long.

Status

Select the current status of the agreement, using the drop-down list. The default value is Active. You can change it to inactive if appropriate.

While there can be more types of status set up, each must be considered to be active or inactive, which is shown in this field. The actual status for the agreement is selected on the Profile Info tab from the Status list.

Default

This option is only used for SLAs and is therefore disabled for OLAs and UCs.

Select the checkbox to specify that this agreement is to be considered the default Service Level Agreement by ASM Core. The system will apply the default SLA if no match is found based on the IPK or Workflow Selection Criteria for the agreement. Default SLAs can be defined when your system requirements are quite simple. These agreements are system wide agreements. Default SLAs can be used in two ways:

To set up a simple escalation strategy
For calls not specifically measured by an agreement.

Multiple default SLA agreements can exist. The default agreement with the latest End Date will be applied if no other agreement settings affect the selection, such ask IPK Status, for example.

Do not select the Default option for SLAs unless you are sure that this agreement is set up correctly as the default agreement.

Expand the Select Setting(s) section if necessary

Specify the settings for the agreement, such as locking, IPK events, or re-opening.

Additional global settings are set by your administrator through Service Level Management administration

Lock IPK SLA

Select this option to prevent an SLA that has been assigned to a call initially from being changed automatically by the system, even if call details affecting SLA selection criteria change. Clear this option to allow the IPK Selection Criteria to be reassessed each time the call is updated and saved. In this case if another SLA is matched, it is applied and the current SLA is closed.

If the original SLA was manually assigned to the call, any changes made to the call/request details affecting the selection criteria will not be considered. A manually assigned agreement can only be replaced manually.

Selecting this option does not prevent analysts from manually changing an SLA assigned to a call.

Lock Workflow SLA

This is only displayed for SLAs.

Select this option to prevent an SLA that has been assigned to a request initially from being changed automatically by the system, even if request details affecting SLA selection criteria change. Clear this option to allow the Workflow Selection Criteria to be reassessed each time the request is updated and saved. In this case if another SLA is matched, it is applied and the current SLA is closed.

If the original SLA was manually assigned to the request, any changes made to the call/request details affecting the selection criteria will not be considered. A manually assigned agreement can only be replaced manually.

Selecting this option does not prevent analysts from manually changing an SLA assigned to a request.

Start Response Immediately

This is only displayed for SLAs.

Select this option to start the Response Escalation at the time an SLA is linked to a call rather than when the First Call Back Escalation is completed or breached. Clear this option to start Response Escalation as soon as the First Call Back Escalation ends (or, at the time an SLA is linked to the call if no First Call Back Escalation is configured for the SLA).

Auto Stop Clock on Agreement Suspension

Select this option to automatically turn off the ‘clock’ (i.e. how much time has passed since the call, request, or task was logged) when a call, request, or task is suspended. The clock restarts when the call, request or task becomes active again. Clear this option to allow a suspended call, request, or task to continue running the clock, meaning escalation and agreement breach events will continue to count down and occur even though the call, request or task is suspended.

Stop Clock Reason Required

Select this option to enable the Change Reasons window to appear when an SLM clock is stopped on the agreement, forcing the analyst to provide a reason for stopping the clock.

Complete SLM IPK Events

If closure rules are used to determine the method for closing calls, these options enable you to specify when SLM events for an agreement applied to a call are closed, that is, either when the call is resolved (and forwarded to an analyst/group for closure), or when the call is closed by the analyst/group for the relevant closure rule.

On Call Resolve

Select this option to close all SLM events for the agreement when the call to which the agreement applies is resolved (and forwarded to a closure group for closure).

On Call Closure

Select this option to close all SLM events for the agreement when the call to which the agreement applies is closed by a closure group.

On Re-opening Resolved Calls

If closure rules are used to determine the method for closing calls, meaning that calls are resolved, and then closed, these options enable you to specify how SLM events are handled when a resolved call is reopened.

Resume Previous Agreement, and Include Resolved Interval

Select this option to restart any agreement previously running against the resolved call when it is reopened. All escalation and breach target times will be the same as before the call was resolved, as if the SLM clock had never stopped.

Resume Previous Agreement, and Exclude Resolved Interval

Select this option to restart any agreement previously running against the resolved call when it is reopened. All escalation and breach target times will be increased to take into account the time lapse between when the call was resolved and reopened.

Restart Previous Agreement

Select this option to restart from scratch any agreement previously running against the resolved call when it is reopened. All escalation and breach target times are restarted.

Ignore Previous Agreement

Select this option to ignore any agreement previously running against the resolved call when it is reopened. The service will look like it has been resumed and all events relating to this agreement will remain closed. However, if the call details have changed, a brand new agreement may apply to the call.

On Re-opening Closed Calls/Requests/Tasks

These options enable you to specify how SLM events are handled when a closed call, request, or task is reopened.

Resume Previous Agreement, and Include Resolved Interval

Select this option to restart any agreement previously running against the closed call/request/task when it is reopened. All escalation and breach times will be the same as before the call/request/task was closed, as though the SLM clock had never stopped.

Resume Previous Agreement, and Exclude Resolved Interval

Select this option to restart any agreement previously running against the closed call/request/task when it is reopened. All escalation and breach times will be increased to take into account the time lapse between when the call/request/task was closed and reopened.

Restart Previous Agreement

Select this option to restart from scratch any agreement previously running against the closed call/request/task when it is reopened. All escalation and breach times are restarted.

Ignore Previous Agreement

Select this option to ignore any agreement previously running against the closed call/request/task when it is reopened. The service will look like it has been resumed and all events relating to this agreement will remain closed. However, if the call/request/task details have changed, a brand new agreement may apply to the call/request/task.

6. Having completed the details, use the tabs at the bottom of the window to provide profile info, significant dates, working hours, support hours and financial information for the agreement.

7. You can also use the options in the explorer pane to:

Define selection criteria for the agreement (that is, the rules that define in what situations the agreement is used)
Define thresholds for the agreement (that is, the times at which escalation and agreement breaches occur)
Define measurements and penalties for the agreement
Upload or download an object from the agreement
Specify Agreement Stakeholders
View the audit trail for the agreement

8. When you have finished, select Ok to save the details, or Save New to save the details and display the Agreement Details window with blank fields, for creation of another agreement of the same type.

Adding Profile Information to an Agreement

The Profile Info view contains some of the basic settings for the agreement, such as type and status. It is shown by default when you first go to the Agreement Details window.

Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.
Select the Profile Info tab if necessary.
Complete the details.

Type	This list enables you to choose an agreement type. Note that while your administrator might have created many different Agreement Types, they all come under one of the three basic types of SLA, OLA and UC. The name should make it clear which of these types it is.
IPK Status	This is only available only if your system is configured for the IPK Management module. You can set an agreement to only apply to Incidents, Problems, or Known Errors, or all of the basic call statuses. Select the status you want to apply to the agreement from the list, or choose All if you want the agreement to apply regardless of the IPK status. Your system administrator may have created additional IPK statuses. If so, these will also appear in the list.
Workflow Process	You can set an agreement to apply to any workflow process that is enabled on your system. From the Workflow Process list, select the process for which you this agreement to apply, or select All if you want the agreement to apply regardless of the workflow process.

Type

This list enables you to choose an agreement type. Note that while your administrator might have created many different Agreement Types, they all come under one of the three basic types of SLA, OLA and UC. The name should make it clear which of these types it is.

IPK Status

This is only available only if your system is configured for the IPK Management module.

You can set an agreement to only apply to Incidents, Problems, or Known Errors, or all of the basic call statuses. Select the status you want to apply to the agreement from the list, or choose All if you want the agreement to apply regardless of the IPK status. Your system administrator may have created additional IPK statuses. If so, these will also appear in the list.

Workflow Process

You can set an agreement to apply to any workflow process that is enabled on your system. From the Workflow Process list, select the process for which you this agreement to apply, or select All if you want the agreement to apply regardless of the workflow process.

Adding Dates to an Agreement

You can apply certain important dates relating to the agreement.

Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.
Select the Dates tab.
The controls on this tab are date pickers.

Start Date

This is the date at which the agreement starts. ASM Core will not apply an agreement to a call if it has not yet reached its start date.

End Date

This is the end date for the agreement. Like the Start Date, an agreement will not be applied to a call if the current date is past the End Date of the agreement. The default end date is today, therefore you must select a suitable end date otherwise the agreement expires straight away.

Review Date

This is a date you can set for reviewing the agreement. The agreement will still function normally once this date is reached. The Review Date is available as a search criterion on the Agreement Search window, enabling analysts to search for agreements requiring review.

Applying Work Support Hours to an Agreement

Agreements in ASM Core can be linked to time zones. This is an important part of a global enterprise’s service level management system, because Users may be logging calls in time zones different from the time zones in which they are resolved. For this reason, you should ensure that all the agreements you create are set with the correct time zone based on the selection criteria for the agreement.

The following example illustrates how time zones interact with ASM Core’s Service Level Management system to provide global support for service commitments.

TechCorp has offices in three locations: London, Sydney and Seattle. The base of operations including the ASM Core server is in Seattle, though their IT service desk is based in Sydney. The server time zone for Pacific USA (Seattle) is GMT -8:00, London office is GMT 0:00 and Sydney office (and all their support staff) are in GMT +10:00. One of their staff is working in London and at midnight he attempts to access the company website, which is hosted in Seattle; he discovers that the web server has gone down and the website cannot be accessed.
He logs a call to the service desk in Sydney (where it is currently 10:00 am); the configuration item is identified as being a web server in Seattle, and ASM Core picks up and applies the Seattle Support Agreement. This agreement is in the Pacific USA time zone (where it is currently 4:00 pm), and has a set of working hours that specify that support is offered from 9:00 am to 5:00 pm, seven days a week.
The agreement specifies that Resolve escalation will occur two hours after the call is logged, and the agreement will be broken (that is, Resolve breach will occur) four hours after the call is logged. However, those times are based on the time zone and working hours for the Seattle Support Agreement, not for where the call was logged from (London) or logged to (Sydney).
It is currently 4:00 pm in Seattle, and with a 9:00 am to 5:00 pm set of working hours, escalation will occur at 10:00 am the next day Seattle time; one hour from 4:00 till 5:00 pm, then when work hours begin the next day at 9:00 am, the second hour (and thus resolve escalation) is at 10:00 am. The agreement will be broken if the call is not resolved two hours after that, that is, midday.
The resolve escalation and resolve breach will occur at 10:00 am and midday Seattle time, and are converted to any local analyst’s time zone, if they have one defined. The analyst in Sydney forwards it to a senior technician (also in Sydney), who opens the call and looks at the Call SLA window to check the status of the call in terms of its agreements. ASM Core shows him that resolve escalation and breach will occur at 2:00 am and 4:00 am the next day respectively; these are the Seattle times converted to local (that is, Sydney) time zone.
In London, the staff member can expect the Resolve Escalation by 6:00 pm and Resolve Breach at 8:00 pm.

Best Practice

If you are applying agreements based on User and you have some Users in time zone A and some in time zone B, you should create two agreements, one for each time zone.

This will ensure that ASM Core performs the right calculations for escalation and breach times based on the User’s expectations in their actual time zone, not the time zone where the call is being actioned.

Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.
Select the Work Hours tab.
Complete the details.

Working Hours

Select the working hours you want to apply from the drop-down list.

The entries in the drop down list are defined in the Hours Definition window.

Holidays

Select the Public Holiday calendar to apply to the agreement from the drop-down list.

The entries in the drop down list are defined in the Public Holidays Definition window.

Time Zone

Select the time zone that you want to apply to the current agreement from the drop-down list.

Escalation and breach events will be calculated based on this time zone when Default Agreement Time Zone is selected under IPK Time Zone (for calls) or Workflow Time Zone (for requests and tasks).

Override IPK Conditions

Select this option to set special working hours set special support hours for an agreement.

Default Agreement Time Zone

Select this option if you want the time zone to be the same as that specified in the Time Zone field.

If the agreement is for a call or request, you can select the time zone for the agreement to be one of the options below the IPK or Workflow Time Zone heading. Some of the fields available vary depending on the type of agreement.

SLAs – you can apply the time zone set based on a Config Item, User, or Service linked to the call, request or task to which the agreement applies.
OLAs – you can apply the time zone set based on an IPK Group (if the agreement applies to a call) or Workflow Group (if the agreement applies to a task or approval).
UCs – you can apply the time zone set based on an External Supplier or Contract.

Config Item via Agreement Identification

Select to use the same time zone as is used for the configuration item to which this agreement is applied.

The Time Zoning options for the configuration item will be used only if the call or request using the agreement has Config Item selected. It must also be listed under the IPK or Workflow Agreement Selection Criteria for the time zone to be used.

User via Agreement Identification