SLM - 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:

  1. The system looks for an SLA assigned to the workflow template on which a request is based. If one is found, it is applied.

  2. 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.

  3. If no matches are found for any of the fields, ASM checks for a default agreement; if one is found, it is applied.

  4. 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.

  1. Select Menu> New. In the submenu, scroll down and select Agreement.

  2. 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.

  3. From the Select Agreement Type list, select the type of agreement you want to create. The available types are:

Type
Description

OLA

To create an Operational Level Agreement (by and between teams)

UC

To create an underpinning contract (between third parties and your organization)

SLA

To Create a Service Level Agreement (between you and your customers)

Other Agreement Types can be defined by your System Administrator, such as XLA's, however they will still need to fall into one of the 3 core categories of OLA, UC, or SLA.

  1. The Agreement Details window appears.

    1. The upper part of the window contains some basic information about the agreement.

    2. 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.

The Agreement Details, Configure your Agreement

  1. Title - Type a name for the agreement. Choose an appropriate name, such as Laptop Service Agreement Reference

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

  3. 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.

  4. Set as Global Default Agreement "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.

These agreements are system wide agreements. The system will apply the default SLA if no match is found based on the IPK or Workflow Selection Criteria for the agreement.

Multiple default SLA agreements can exist.

  1. 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.

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

Select Settings Options

  1. 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.

  2. Lock Workflow SLA - 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.

  3. Start Response Immediately - 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).

  4. Auto Stop Clock on Agreement Suspension - Select this option to automatically turn off the ‘clock’ when a call, request, or task is suspended (using the Defer screen) or a configured status change occurs on a call.

    NOTE: Once an agreement is attached to a call, it begins running against a ‘clock’. ASM continually monitors the amount of time the agreement has been in effect and checks if any events are scheduled to occur. An agreement may trigger a number of events such as different types and levels of escalations and breach.

    • 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.

  1. 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.

  2. 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.

  3. 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.

  1. Description - Include the parameters and expected behavior of the agreement in the description. In the future and for troubleshooting purposes understanding what the intended behavor was as compared to the configuration will assist in administration and maintenance of the SLA.

  1. 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.

  2. Use the options in the explorer pane to:

    1. Define selection criteria for the agreement (that is, the rules that define in what situations the agreement is used)

    2. Define thresholds for the agreement (that is, the times at which escalation and agreement breaches occur)

    3. Define measurements and penalties for the agreement

    4. Upload or download an object from the agreement

    5. Specify Agreement Stakeholders

    6. View the audit trail for the agreement

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.

  1. Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.

  2. Select the Profile Info tab if necessary.

  3. Complete the details.

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.

  1. Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.

  2. Select the Dates tab.

  3. 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.

  1. Display the Agreement Details window, if it is not already visible on screen, by searching for the agreement.

  2. Select the Work Hours tab.

  3. 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.

      1. 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.

      2. 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).

      3. 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 - This option is only displayed for SLAs. Select to use the same time zone as is used for the User for whom this agreement is applicable. The Time Zoning options for the User will be used only if the call or request using the agreement has User selected. It must also be listed under the IPK or Workflow Agreement Selection Criteria for the time zone to be used.

    • Service via Agreement Identification - This option is only displayed for SLAs. Select to use the same time zone as is used for the service for which this agreement is applicable. The Time Zoning options for the service will be used only if the call or request using the agreement has the service selected. It must also be listed under the IPK or Workflow Agreement Selection Criteria for the time zone to be used.

    • Config Item of the Call - This option is only displayed for SLAs. Select to use the same time zone as is used for the config item identified in the call.

    • User of the Call - This option is only displayed for SLAs. Select to use the same time zone as is used for the User identified in the call.

    • Service of the Call - This option is only displayed for SLAs. Select to use the same time zone as is used for the service identified in the call.

    • User of the Request - This option is only displayed for SLAs. Select to use the same time zone as is used for the User identified in the request.

    • IPK Group via Agreement Identification - This option is only displayed for OLAs. Select to make the time zone to be the same as that specified for the IPK group in the Selection Criteria of the agreement.

    • Workflow Group via Agreement Identification - This option is only displayed for OLAs. Select to make the time zone to be the same as that specified for the workflow group in the Selection Criteria of the agreement.

    • External Supplier via Agreement Identification - This option is only displayed for UCs. Select to make the time zone to be the same as that specified for the External Supplier in the Selection Criteria of the agreement.

    • Contract via Agreement Identification - This option is only displayed for UCs. Select to make the time zone to be the same as that specified for the Contract in the Selection Criteria of the agreement.

Setting Special Working Hours for an Agreement

Before you start

IPK Thresholds must be configured to set special IPK working hours.

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

You must have Agreement Update selected in the same tab to update the information.

  1. Display the Agreement Details window, if it is not already visible on screen

  2. Select the Work Hours tab.

  3. Click the Edit icon if the agreement is not already in Edit mode.

  4. Select Override IPK Conditions. The Special Working Hours window appears.

  5. Select the Matrix.

  6. Set the X, Y and Z dimensions to invoke the set of special working hours to be added to the list of special working hours.

  7. Select Save to save the details.

Adding Financial Information to an Agreement

You can enter financial information relating to the agreement.

Financial data such as payment types is only stored as text fields attached to an agreement. If you want certain calculations to be performed with your agreements based on payments, contact Alemba® Professional Services to discuss.

  1. Display the Agreement Details window, if it is not already visible on screen.

  2. Select the Financials tab.

  3. Complete the details.

    • Payment Type - Use the drop-down list to choose a payment type (Yearly, Monthly, Once-off, etc.) to attach to the agreement.

    • Price - You can type a price for the payment.

    • Total Spent - Type a running total for the payments on the agreement.

  4. Select Save to save the details.

  1. 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.

Agreement Details Explorer Options

The Agreement Details explorer pane consists of the following options:

IPK and Workflow Selection Criteria

Agreements have selection criteria attached to them. These are rules which tell ASM Core when to apply the agreement. Agreements are selected and applied to calls, requests, and tasks based on the IPK and Workflow selection criteria, respectively. Updates to call or request details may trigger a new agreement to be applied to the call/request, if these details affect the selection criteria.

IPK and Workflow Thresholds

Thresholds define the points at which an agreement should start escalation events, and the point at which an agreement is breached. You can define IPK and Workflow Thresholds for SLAs, OLAs, and UCs.

Service Items

You can link and remove service items (that is, services, service actions, and service bundles) to and from the current agreement.

Audit

All changes to an item in the CMDB (such as config item, agreement, or User) can be seen at a glance on the Audit Trail window. Changes may range from a rename of a config item, upload of an object or deletion of an object.

To enable auditing, the system administrator must select the option in the Audit Trail section on the CMDB Settings window.

An entry is made in the audit trail table for the creation of a CMDB item.

Measurements

You can record measurements against an agreement.

Stakeholders

Stakeholders are Users, organizations, other support analysts or groups who have an interest in the agreement. They may be related to it or a call or request to which the current agreement is applied, and need to be kept informed of developments. Use the Stakeholder explorer option to link stakeholders to the current agreement.

Searching for an Agreement

  1. Select Search from the main menu. From the submenu, select Agreements.

  2. The Agreement Search window is divided into two panes. You can select the criteria for the search in the left frame. The results are displayed in the right pane. You can apply as many filters as you wish (some of the fields require you to select a check box for that criteria to apply).

SLA
Select to filter your search by SLA

OLA

Select to filter your search by OLA

UC

Select to filter your search by UC

Active

Select to search for active agreements, that is agreements with an end date later than today

Deleted

Select to search for agreements that have been created, and subsequently deleted

Include Deleted Field Values

Select to include deleted values in the other search criteria lists so that these values can be included in your search

Partition

This is only visible if your system is partitioned and you have access to more than one partition.

Select the partition to search for agreements created in the partitions to which you have access.

Agreement Ref

This is the reference number assigned to the agreement. Select the checkbox and then type the agreement ref. If you do not know the reference number, you can use the wildcard symbol % to retrieve all the agreements defined on your system.

Title

This is the name of the agreement. Select the checkbox and then type the title. If you do not know the title, you can use the wildcard symbol % to retrieve all the agreements defined on your system.

  1. To add more fields to your search criteria, select at the top of the pane and configure your search criteria.

  2. Select Search. The results are displayed in a browse table located in the right hand pane.

  3. When the browse table appears, the following buttons are available in addition to the standard ones.

to clone the selected agreement and create a new one.

Double-clicking an entity in the search results will open it. Alternately, select the entity and then this button on the toolbar to open the item.

Additional Search Criteria

By configuring your search criteria, you can add more fields to your search criteria panel, including:

Agreement Status

The current status of the agreement

External Supplier

If you want to locate a UC, you can search by the external supplier you have specified in the UC selection criteria.

Contract

If you want to locate a UC, you can search by the contract you have specified in the UC selection criteria.

IPK Group, Workflow Group

Use these fields to locate OLAs that have the select group identified as the agreement group in the OLA selection criteria.

Date From and Date To

You can use various date fields to search for agreements, such as Start Date, Review Date, Created Date, or Updated Date.

Created By

Select the name of the analyst who created the agreement(s) you want to locate.

Updated By

Select the name of the analyst who last edited the agreement(s) you want to locate.

Call Type Selection Criteria

Select a value for the issue Type, if it has been set as an IPK selection criterion on the agreement(s) you want to locate.

Request Type Selection Criteria

Select the request type value, if it has been set as a selection criterion on the agreement(s) you want to locate.

Source

Select the source from which the agreement was created, such as ASM Core, or API.

[CMDB Item] Selection Criteria

Specify CMDB items linked to the agreement you want to locate.

User/Organization/Location Selection Criteria

Select the name of the User, organization, or location if it has been set up as a selection criterion on the agreement(s) you want to locate.

Cloning an Agreement

  1. Select the agreement you want to clone from the browse table, and select the Clone icon.

  1. When the new agreement's details are displayed on the screen, select the Edit icon if necessary to activate the fields.

  1. Update the details as necessary.

  2. 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.

Updating an Agreement

  1. Select the agreement you want to update from the browse table, and select the Action icon or double-click the agreement title.

  1. When the details are displayed on the screen, select the Edit icon if necessary to activate the fields.

  2. Update the details as necessary

  3. 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.

Deleting an Agreement

  1. Select the agreement you want to delete from the browse table, and select the Delete icon.

  1. Confirm the deletion.

Deleted agreements are not removed from calls, requests, or tasks they were assigned to before the agreement was deleted.

If there are active events at the time of deletion, they will continue to count down until the agreement events are completed.

PreviousDisplaying OutagesNextDefining Agreement Thresholds

Last updated

Was this helpful?