Service level agreementFrom Wikipedia, the free encyclopedia(Redirected from Service Level Agreement) Jump to: navigation, search

/wiki/Image:Ambox_conten

t.png /wiki/Image:Ambox_content.png

This article or section is missing citations or needs footnotes.Using inline citations helps guard against copyright violations and factual inaccuracies. (April 2007)

A service level agreement (frequently abbreviated as SLA) is a part of a service contract where the level of service is formally defined. In practice, the term SLA is sometimes used to refer to the contracted delivery time (of the service) or performance.

Contents[hide]

1 Description 2 Common metrics 3 Typical contents 4 In outsourcing 5 References

[edit] DescriptionA Service Level Agreement (SLA) is a negotiated agreement between two parties where one is the customer and the other is the service provider. This can be a legally binding formal or informal 'contract'(see internal department relationships). Contracts between the service provider and other third parties are often (incorrectly) also called SLAs — as the level of service has been set by the (principal) customer there can be no 'agreement' between third parties (these agreements are simply a 'contract').The SLA records a common understanding about services, priorities, responsibilities, guarantees and warranties. Each area of service scope should have the 'level of service' defined. The SLA may specify the levels of availability, serviceability, performance, operation, or other attributes of the service such as billing. The 'level of service' can also be specified as 'target' and 'minimum', which allows customers to informed what to expect (the minimum), whilst providing a measurable (average) target value that shows the level of organisation performance. In some contracts penalties may be agreed in the case of non compliance of the SLA (but see 'internal' customers below).It is important to note that the 'agreement' relates to the services the customer receives, and not how the service provider delivers that service.SLAs have been used since late 1980s by fixed line telecom operators as part of their contracts with their corporate customers. This practice has spread such that now it is common for a customer to engage a service provider by including a Service Level Agreement in a wide range of service contracts, in practically all industries and markets. Internal departments in larger

organisations (such as IT, HR and Real Estate) have adopted the idea of using service level agreements with their 'internal' customers — users in other departments within the same organisation. One benefit of this can be to enable the quality of service to be benchmarked with that agreed across multiple locations or between different business units. This internal benchmarking can also be used to market test and provide a value comparison between an in-house department and an external service provider.Service Level Agreements are by their nature 'output' based - the result of the service as received by the customer is the subject of the 'agreement'. The (expert) service provider can demonstrate their value by organising themselves with ingenuity, capability and knowledge to deliver the service required, perhaps in an innovative way. Organisations can also specify the way the service is to be delivered, through a specification (a service level specification) and using subordinate 'objectives' other than those related to the level of service. This type of agreement is known as an 'input' SLA. This latter type of requirement has become obsolete as organisations become more demanding and shift the delivery methodology risk on to the service provider.

[edit] Common metricsService Level Agreements can contain numerous service performance metrics with corresponding service level objectives. A common case in IT Service Management is a call center or service desk. Metrics commonly agreed to in these cases include:

ABA (Abandon Rate): Percentage of calls abandoned while waiting to be answered. ASA (Average Speed to Answer): Average time (usually in seconds) it takes for a call to be

answered by the service desk. TSF (Time Service Factor): Percentage of calls answered within a definite timeframe, e.g.

80% in 20 seconds. FCR (First Call Resolution): Percentage of incoming calls that can be resolved without the

use of a callback, or without having the caller call back the helpdesk to finish resolving the case.

TAT (Turn Around Time): Time taken to complete a certain task. Uptime Agreements are another very common metric, often used for data services such as shared hosting, virtual private servers and dedicated servers. Common agreements include percentage of network uptime, power uptime, amount of scheduled maintenance windows etc.Many SLAs track to the ITIL specifications when applied to IT services.

[edit] Typical contentsSLAs commonly include segments to address: a definition of services; performance measurement; problem management; customer duties; warranties; disaster recovery; termination of agreement.[1]

[edit] In outsourcingOutsourcing involves the transfer of responsibility from an organization to a supplier.The management of this new arrangement is through a contract that may include a Service Level Agreement (SLA).The contract may involve financial penalties and the right to terminate if SLAs are consistently missed. Setting, tracking and managing SLAs is an important part of Outsourcing Relationship Management (ORM) discipline. It is typical that specific SLAs are

negotiated up front as part of the outsourcing contract and they are utilized as one of the primary tools of outsourcing governance.

UptimeFrom Wikipedia, the free encyclopediaJump to: navigation, search Uptime is a measure of the time a computer system has been "up" and running. It came into use to describe the opposite of downtime, times when a system was not operational. The uptime and reliability of computer and communications facilities is sometimes measured in nines (similar to the unit of metallic purity). "Five nines" means 99.999% availability, which translates to a total downtime of approximately five minutes and fifteen seconds per year.

\ Total downtime (HH:MM:SS)

Availability per day per month per year

99.999% 00:00:00.4 00:00:26 00:05:15

99.99% 00:00:08 00:04:22 00:52:35

99.9% 00:01:26 00:43:49 08:45:56

99% 00:14:23 07:18:17 87:39:29

It is often used as a measure of computer operating system reliability and stability, in that this time represents the time a computer can be left unattended without crashing, or needing to be rebooted for administrative or maintenance purposes. Conversely, long uptime can indicate negligence, because critical updates can sometimes require reboots.

Contents[hide]

1 Records and comparisons 2 Determining system uptime 3 See also 4 References 5 External links

[edit] Records and comparisonsThe Uptime-Project, collected data on uptimes from users until 1 March 2007, and the current record for longest uptime is 11 years, 303 days, 20 hours and 57 minutes on a computer running OpenVMS. Rumours mention in January 2008 that Irish Rail had an OpenVMS machine up for 18 years[1], and was restarted just for Y2K tests.Netcraft maintains the uptime records for many thousands of web hosting computers.The uptime of a personal computer is sometimes displayed as a badge of honour on an email signature or web site/forum. This was especially true in the Windows 9x days[citation needed], where Windows NT and Windows 2000 users would boast of uptimes of more than 30 days, whereas many real-world Windows 9x installations crashed more often. In more recent times very long uptimes for home users with Windows NT and Windows 2000 machines are less

striking because the Windows 9x line has been replaced by the Windows NT-based Windows XP.

[edit] Determining system uptimeUsers of Windows XP Professional, Windows Server 2003 and Windows Vista systems can type systeminfo at the Command Prompt to display all system information, including the System Up Time. Windows Vista Business 64bit does not have an "Up Time" variable but rather "System Boot Time".C:\> systeminfo | find "Up Time"System Up Time: 0 Days, 8 Hours, 7 Minutes, 19 Seconds

Service Level Management - ITIL V2From IT Process WikiJump to: navigation, search

diese Seite auf Deutsch

ITIL Version: ITIL Version 2 (ITIL V2) Process-Objective: Service Level Management has the tasks of maintaining the IT Organisation's Service Catalogue and reaching binding agreements for internal and external Service Performances. At the interface with the client, Service Level Agreements are agreed. The Service Level Manager is responsible for the monitoring of the agreed quality parameters and where necessary resorts to counter-measures. The adequate provision of internal IT Services is secured via Operational Level Agreements and Underpinning Contracts (OLAs/UCs). Part of: Service Delivery Process Owner: Service Level Manager

Contents[hide]

1 Sub-Processes 2 Involved Roles 3 Related Checklists and KPIs

3.1 Checklists 3.2 KPIs

4 Related ITIL Glossary Terms

[edit] Sub-Processes/index.php/Image:Overview_slm.jpg

/index.php/Image:Overview_slm.jpg

Overview of Service Level Management Maintain Structures for Service Level Management

Process objective: The multitude of documents used within Service Level Management are to be adjusted in such a manner, that they correspond to the requirements of new or changed IT Services.

Define Service Requirements Process objective: Requirements from the client viewpoint with regards to a new or altered IT Service are to be documented and submitted to an initial evaluation, so that alternatives may be developed at an early stage for requirements which are not technically or economically feasable.

Create Service Specification Sheet Process objective: The requirements of a new or altered IT Service are described in more detail, and specifications are drawn up as to how the Service is created from an IT viewpoint and how the invoicing takes place.

Negotiate and agree Contractual Regulations for the Service Process objective: Finalisation of binding agreements to an IT Service between the IT Organisation and the client-side, a well as ensuring sufficient Service Levels with internal and external Service providers, which support the provision of the Service.

Prepare Service Implementation Process objective: Identification of preconditions, which must be established for the implementation of the new or altered Service, so that a correspondoing Change Request may be compiled.

Commission Service Implementation Process objective: After clearance of the Change, the implementation of the IT Service is to be planned in further detail; the Service Level Manager subsequently commissions the technical experts in Application or Infrastructure Management to start the implementation.

Carry out Service Level Reporting Process objective: It is to be given account of the attained Service quality as well as potential counter-measures for the correction of infringements to the agreed Service Levels.

Process Complaints and Carry out SLA Reviews Process objective: Investigation of the agreed Service Levels, in order to ensure that the SLAs are still adequate for client requirements; processing of complaints and where necessary, assume corrective measures.

[edit] Involved RolesCapacity Manager Client (Contract Partner) Financial Manager IT Service Continuity Manager Service Level Manager

[edit] Related Checklists and KPIs

[edit] Checklists Checklist Service Level Requirements (SLR) Checklist Service Specification Sheet Checklist Service Level Agreement (SLA) Checklist Operational Level Agreement (OLA) Checklist Underpinning Contract (UC) Checklist Service Catalogue Checklist Service Level Report Checklist Protocol SLA Review Checklist Service Quality Plan (SQP) Checklist Service Improvement Plan (SIP)

[edit] KPIs Key Performance Indicators "Service Level Management" according to ITIL V2

[edit] Related ITIL Glossary TermsService Level Requirements (SLR) Service Specification Sheet Service Level Agreement (SLA) Service Catalogue Operational Level Agreement (OLA) Underpinning Contract (UC) Service Quality Plan (SQP) Service Improvement Program (SIP) Service Level Report

Retrieved from "http://wiki.en.it-processmaps.com/index.php/Service_Level_Management_-_ITIL_V2"

KPIs Service Level Managementdiese Seite auf

Deutsch

ITIL Process: Service Delivery - Service Level Management

Key performance Indicator (KPI) Definition

Service Elements in SLAs Number of service elements included in SLAs

Service Elements with OLAs/UCs

Number of Service Elements in SLAs which are secured by corresponding OLAs/UCs

Monitored SLAs Number of monitored SLAs, where weak-spots and counter-measures are reported

SLAs under Review Number of SLAs which are regularly reviewed

Fulfilment of Service Levels Number of SLA elements where the agreed service levels are fulfilled

Number of Shortcomings Number of shortcomings in the service provision, which are identified and addressed in an improvement plan

[edit] Service Level Requirements (SLR)

← The Service Level Requirements document contains the requirements for a service from the client viewpoint, defining detailed service level targets, mutual responsibilities, and other requirements specific to a certain (group of) customers.

Service Specification Sheet

← The Service Specification Sheets lays out in detail how the customer requirements can be fulfilled from the viewpoint of the IT Organisation.

← In particular, it references the internal IT Service components used to build the new or changed Service required by the customer (i.e. the necessary services provided from within the IT Organisation or from external Service Suppliers).

← This document may also list further consequences related to the provision of the IT Service, such as required resources and skills.

[edit] Service Catalogue

← A database or structured document with information about all live services, including those available for deployment.

← The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services.

← The Service Catalogue includes information about deliverables, prices, contact points, ordering and request processes.

Operational Level Agreement (OLA)

← An agreement between an IT service provider and another part of the same organization.

← An OLA supports the IT service provider's delivery of services to customers. ← The OLA defines the goods or services to be provided and the responsibilities

of both parties.

← For example there could be an OLA - between the IT service provider and a procurement department to obtain hardware in agreed times - between the Service Desk and a support group to provide Incident resolution in agreed times.

← see also: ITIL Checklist SLA - OLA - UC

Underpinning Contract (UC)

← A contract between an IT service provider and a third party. ← The third party provides services that support the delivery of a service to a

customer. ← The Underpinning Contract defines targets and responsibilities that are

required to meet agreed Service Level targets in an SLA. ← see also: ITIL Checklist SLA - OLA - UC

Service Level Report

← The Service Level Report gives insight into a service provider's ability to deliver the agreed service quality.

← To this purpose, it compares the agreed and actually achieved service levels, and also includes information on the usage of services, ongoing measures for service improvement, and any exceptional events.

← A Service Level Report is issued by the service provider for its customers, IT management and other Service Management processes.

← A similar report is also created by an external service supplier to document its achieved service performance.

http://www.itil-process-wiki.org/index.php?title=Main_Page

Service Level ManagementFrom ITIL Process WIKIJump to: navigation, search

Contents[hide]

1 Description/Summary 2 Objectives 3 Roles & Functions

3.1 Service Level Management specific roles 3.1.1 Static Process Roles 3.1.2 Dynamic Process Roles

3.2 Service Specific Roles 3.3 Customer Specific Roles

4 Information artifacts 5 Key Concepts

5.1 Service Levels 5.2 Service Quality Plan 5.3 Service Improvement Porgramm 5.4 Cost/ price simulations

6 Process 6.1 High Level Process Flow Chart 6.2 Critical Success Factors 6.3 Performance Indicators (KPI) 6.4 Process Trigger

6.4.1 Event Trigger 6.4.2 Time Trigger

6.5 Process Specific Rules 6.6 Process Activities

6.6.1 SL Design 6.6.2 SL implementation and review 6.6.3 SL cancellation

Description/Summary Service Level Management (SLM) Process is defining, etsblishing, monotoring and optimizing service quality and service levels of services agreeed with the customer. Objectives and framework of the service levels and service quality are defined in the Service Level Management Process. Service Level Management in ...

ITIL V3: COBIT: ISO/IEC 20000:

Objectives The purpose of IT Service Level Management Process is to provide quality of service agreed with the customer and to imporve the service quality as a balance between value of customer and service quality improvement costs Service Level Management contributes to an integrated Service Management approach by achieving the following goals:

Establishing and assuring the ciontracted service quality

Roles & Functions

Service Level Management specific roles

Static Process Roles See Service Level section, Service Level Management Roles x Person for details Service Level Management Process Owner

Initiator of the process, accountable for defining the process strategic goals and allocating all required process resources. See Continual Process Improvement Management for a detailed description of these activities.

Service Level Management Process Manager (SL Manager) Manager of the entire process, responsible for its effectiveness and efficiency. Team leader of the function "Service Level Management Team". See Continual Process Improvement Management for a detailed description of these activities.

Service Level Management Team Team associated to the Service Level Management Process.

Dynamic Process Roles These roles are dynamically created during the Service Level Management Process. See the process-specific or activity-specific rules for details. Service Level Management Owner

The attribute in the records contains the value of the Role/Function currently accountable for the Service (but NOT for the Service Level Management Process). The Service Level Management Owner can be changed with the help of a hierarchical Escalation. The content or partner related organization of supply is depending on strategic definition in supply strategy.

Service Level Management Agent The attribute in the records contains the value of the Role/Function currently responsible for the activity or task within an activity of the Service Level Management Management. The Service Level Management Agent can be changed with the help of a functional Escalation, if permitted by the rules.

Service Specific Roles Roles depending on the affected service are found in the Supply Strategy or Policy Definition.

Customer Specific Roles Customer SL Manager

Person acting as the SL owner for specific customer defined by historic relationship with customer or sales and distribution strategy

Information artifacts This section describes information/data required or recorded by the process. Typically the SLA process is based on the SL specification:

Customer unique ID: Identification of customer Service: definition of service regarded Service levels: Service levels agreed for the service Tolerances: Tolerance levels for the SL defined Definition of terms: Definition of terms to describe the SL

Key Concepts

Service Levels Quality of service can be defined my diverse metrics and descriptions. The ideas behind is to describe the quality of the agreed service. Numerous possibilities for service level definitions are possible and depend typically of the service content:

Hours of operations for IT operations Duration of support team issue solution for support teams Number of bugs per line of code in case of software delivered Other

Typically this metrics need a reference like time period, number of customer, number of users etc. E.g. the SL for IT operations of an IT system could be defined as follows:

24 hours / 7 days operation 99% availability of the system Non availability only on 2 hours per month

The basic service is described in the Service Agreement, that is defined in the Service Agreement Management Process.

Service Quality Plan Plan how to deliver the agreed quality for each service. Steps and actions are defined for internal and external service suplier.

Service Improvement Porgramm In case of low service quality an SIP is defined to impeove the quality fo service.

Cost/ price simulations For the definition of best price of service/ cost of service relation for the customer and the organization, simulations are often done, involving the review of all costs-related to service and the price that should be requested from the customer. This simulation is supported by SL Process with costs, all other variables and the customer negotiations can be supported by CRM Process, SL Agreement Management Process and Service Design Process.

Process

High Level Process Flow Chart This chart illustrates the Supply Management process and its activities.

Critical Success Factors Critical Success Factors (CSF):

Clear defined metrics and processes Established efficient monitoring process

Performance Indicators (KPI)Service levels exceeded Incidents Customer staisfaction

Process Trigger

Event Trigger

Time Trigger Permanent review of service quality

Process Specific Rulesevery service level agreement has defined service levels service levels are monitored service levels are permanently improved

Note: for the different types of rules see Rules.

Process Activities

SL Design This activity supports the SL Agreement Management process by defining:

technical aspects internally possible service levels and costs for these service levels possible new service levels, upgraded service levels, existing service levels

commercial aspects costs of possible service levels and their combinations

If new service levels or service level combinations are requested, SL Management requests internal resources and experts for support in definition of costs and efforts. Activity Specific Rules

provide cost/ SL relations set status on "designed"

SL implementation and review Agreed service levels for services are provided to this activity in the service catalogue. This activity supports the SL Agreement Management process by monitoring the service quality reviewing:

issues problems customer records

and auditing existing services and service levels. In case of service issues the Issue or Problem Management are triggered and the CRM management is informed. A SIP is established, implemented and reviewed. This activity is provided as long as there is agreement cancellation. Activity Specific Rules

provide review on agreed service levels in case service in cancelled:

set status on "end of service", trigger next activity

SL cancellation SL Agreement Management informs the SL Management in case of contract cancellations. SL Management stops the review of SL quality. Activity Specific Rules

in case of SL Agreement cancellation stop review on agreed service levels set status on "cancelled"

Retrieved from "http://www.itil-process-wiki.org/index.php?title=Service_Level_Management"

Service Level Agreement ManagementFrom ITIL Process WIKIJump to: navigation, search

Contents[hide]

1 Description/Summary 2 Objectives 3 Roles

3.1 Service Level Agreement Management Specific Roles 3.1.1 Static Process Roles 3.1.2 Dynamic Process Roles

3.2 Service Specific Roles 3.3 Customer Specific Roles

4 Information artifacts 4.1 Customer Requirement 4.2 The Service Agreement Record 4.3 Service Catalog 4.4 Service Agreement Record attributes mapped to activities 4.5 Additional Information Items

5 Key Concepts 5.1 Status of Service Agreements

6 Process 6.1 High Level Process Flow Chart 6.2 Critical Success Factors 6.3 Performance Indicators (KPI) 6.4 Process Trigger

6.4.1 Event Trigger 6.4.2 Time Trigger

6.5 Process Specific Rules 6.6 Process Activities

6.6.1 Requirements Engineering 6.6.2 SLA Negotiation 6.6.3 SLA Agreement 6.6.4 SLA Monitoring 6.6.5 SLA Expiration

Description/Summary Service Level Agreement Management is responsible for establishing, reviewing and cancellation of Service Level Agreements (SLAs) with customer. Service Level Agreements

are based on Service Design are negotiated and agreed with the customer need the Supply Management Process for the supply of services (agreed in supplier

contracts)on service levels (SLAs) from external partners (if needed) need the Supply Management Process for the supply of services (agreed in UCs) on service

levels (OLAs) from internal partners (if needed) Service Level Agreement Management in ...

ITIL V2: part of Service Delivery ITIL V3: part of Service Design ISO/IEC 20000: part of Service Delivery Processes COBIT:

Objectives The purpose of Service Level Agreement Management is to manage Service Level Agreements in a way that customer requirements are reflected and contracts are coordinated and harmonized. Basic requirement is to balance the value and quality for the customer with the costs of service. Service Agreement Management contributes to an integrated Service Management approach by achieving the following goals:

Every service provided to a customer is covered by an SLA containing a description of the guaranteed and agreed service level.

To achieve the service level targets, OLAs and UCs are established in support of the SLAs by the Supply Management Process.

Roles

Service Level Agreement Management Specific Roles

Static Process Roles The following roles are deployed within the Service Agreement Management process:

Process Owner: Initiator of the process, responsible for defining its strategic goals and allocating all require resources

Process Manager (Service Level Agreement Process Manager) Manager of the entire process, responsible for its effectiveness and efficiency

Process Staff (Service Level Agreement Process Staff) Manager of the entire process, responsible for its effectiveness and efficiency

Dynamic Process Roles

Service Specific Roles

Customer Specific Roles

Information artifacts

Customer Requirement Formal standardized document to collect all relevant information on customer requirement for a commercial and technical feasibility study:

Unique identifier requirement/ customer Status Identifier of the service owner Service concerned (minimum one service should be mentioned) if possible Detailed requirement description (technical aspects, commercial aspects, other) Other relevant information

The Service Agreement Record The service record is the record holding any management-relevant information of a specific service agreement. The following attributes must be considered for a service record:

Unique identifier Status Identifier of the service owner Contract partners Terms and conditions Service concerned (minimum one service should be mentioned) Detailed service description Detailed description of prerequisites to be provided by customer Links to related Service Level Agreements Responsible Service Level Agreement Staff Signatures Dates of Signing

Rules of cancellation or prolongation Rules and processes for changes in agreement Other rules Specific rules to be integrated in an agreement resulting from regional legislation

Service Catalog Service catalog provides the range of services provided. Each service within the catalog typically includes:

Service description Existing SLAs for the services Service owner, sponsor, staff Costs/ Prices Other operating procedures

Service Agreement Record attributes mapped to activities For icon descriptions see Record attributes X activities or refer to the "mouse-over" explanations.

Additional Information Items Service Level Agreement (SLA)

See Service Level Management Process

Key Concepts

Status of Service Agreements Service Agreements may have different status, depending on the life cycle of the agreement:

planned: agreement planned, no agreement defined under negotiation: draft version of agreement written, agreement in progress but not valid under review: draft version of agreement written, agreement in progress but not valid signed: end version of agreement signed, agreement valid regarding te agreed time periods of

validation canceled: agreement cancelled, not valid not active: agreement out of validation time period, agreement not valid

Process

High Level Process Flow Chart This chart illustrates the Service Agreement Management process and its activities as well as the status model reflected by the service record evolution.

/index.php?title=Image:SLA_management_images_main.gif

/index.php?title=Image:SLA_management_images_main.gif

Critical Success Factors Well defined process and roles Clearly defined responsibilities for design and signing of agreements on both sides Will to agree All agreement details should be part of the written agreement

Performance Indicators (KPI)

Process Trigger

Event Trigger Process is triggered by new agreements or agreements required to be changed. Process is triggered by customer request or request from CRM Process.

Time Trigger

Process Specific Rules

Process Activities

Requirements Engineering Service Level Agreement Staff forms together with the CRM Staff a team and decide on who is the requirements engineering agent. This agent gets in contact with the customer and defines customer requirements. This person needs to be an expert concerning the service offered by the company, to match customer requirements with existing services or to define if required services are possible to be delivered in commercial and technical view. A close cooperation with the Service Design Process, CRM and all Operation Processes is necessary. The final regiments need to be written and agreed with the customer. An requirement document is provided. Activity Specific Rules:

define requirement with customer check requirement with internal processes if

technical deliverable commercial feasible

support a business case definition together with CRM process set status on "engineered"

SLA Negotiation Requirements are prices and then discussed with the customer. Different options of service delivery are discussed. In addition for each service a service level is defined, proceed and discussed. This pricing of diverse service levels is supported by the Service Level Management Process. A final agreement version is distributed and discussed between all involved parties. Activity Specific Rules:

trigger Service Level Management Process for price information on diverse Service level of Service to customer

combine all information to offer/ agreement discuss with customer if final version agreed - provide final contract version to all parties for signing set status on "negotiated"

SLA Agreement Final version of the contract is checked by all parties including now the check layer. Final version is distributed, signed and documented in the contract/ agreement data base (see CRM Process). Activity Specific Rules:

Provide final check of agreement including check by law Sign contract Document contract by providing is to the CRM Process Set status on "agreed"

SLA Monitoring Existing agreements need to be monitored:

All aspects NOT involving the service quality are monitored by the CRM process All service quality concerning aspects are monitored by Service Level Management Process

Activity Specific Rules: monitor quality of service -> trigger Service Level Management Process for monitoring,

recive and anlyse information monitor all other contract aspects -> trigger CRM Process, recive and analyse information monitor agreement for end of service (based on date, conditions or customer request) if end of service

set status on "end of service" continue with next activity

SLA Expiration Contract cancellation is done in the CRM Process due to complete legal situation in case of contract cancellation. Service Level Agreement Management is triggered by CRM process and the monitoring of a agreement is stopped. Activity Specific Rules:

stop monitoring of agreement on trigger from CRM process set agreement on "expired"

Retrieved from "http://www.itil-process-wiki.org/index.php?title=Service_Level_Agreement_Management"