You might have come across service guarantees every day, right from an e-commerce store promising same day delivery or your neighborhood pizza shop promising 30 minutes delivery to your cloud services provider guaranteeing 99% up time. The intent with any of these service promises is to set the correct customer expectations, monitor, maintain and improve the alignment between business activities and service quality. If the expectations are not defined, the standard service level expectation from your customers will be “Now” or in some cases “Yesterday”. Hence it is very important to identify, define & agree on levels of service you can offer.

This is no different for your IT organization, Service Level Management(SLM) is a key component of your overall service strategy. The main aim of SLM is to maintain and improve service quality through a constant cycle of agreeing, monitoring, reporting and improving the current levels of service and to improve alignment between business and IT.

Let's take an example of an Organization "XYZ corp". This organization has several departments, has several customers(end users) from each of these departments, and has external vendors/suppliers from where they procure equipment and have equipment support contracts. And the IT service desk of XYZ corp has several teams such as OS support team, server support team, network support team etc.

Now let's look at the definitions

A Service Level Agreement (SLA) is a formal, negotiated contract that outlines service level expectations and clarifies responsibilities between the Service Desk and its Customers (End users). In simple words an SLA is a business contract that specifies service level expectations around critical infrastructure and business services. Typically, they refer to response, restoration and resolution targets that the Service Desk needs to meet.

In our example SLA is between the IT service desk and customers from these departments.

An Operational Level Agreement (OLA) is an internally negotiated document that identifies the service level expectations between the Service Desk and the Technical Support Teams. In simpler words OLAs are similar to SLAs, except they communicate internal team based expectations within specific stages of the Workflow process.And typically OLAs are signed off before SLAs

In our example OLAs can be between internal support teams such as between server support team and network support team.

An Underpinning Contract(UC) enables the Service Desk to monitor and maintain control of requests that are forwarded to external service and support providers. In simple words the obligations of external service providers are specified using Underpinning Contracts (UCs).

In our example, UC is between IT service desk and vendors/suppliers.

In Novell Service Desk, a Service Level Agreement (SLA) can be assigned to a Customer, Organizational Unit or an Item. An SLA is assigned to a Workflow i.e. Workflows are where SLA timers stop/start. You can specify the expected response, restoration & resolution time. To successfully meet SLA expectations, NSD allows you to associate each Workflow State of a request with an Operational Level Agreement (OLA) or Underpinning Contract (UC)



So, when a request is created, NSD checks if any of these elements have an SLA. The business logic applied to assign an SLA to a request is as follows:

• • If the Customer has an SLA then assign this to the request

• • If the Customer does not have an SLA but the Organizational Unit does, assign this to the request

• • If the Customer or Organizational Unit does not have an SLA but the Item does, then assign this to the request

• • If none of the above elements have an SLA, the system Default SLA as defined by Admin in Setup page under Privileges Requests tab, is assigned to the request.

When Billing is enabled, the system checks that a maintenance contract is in place during the request creation process and assigns a Status of Pending - No Contract when an SLA contract is non-existent or expired. To assign an SLA in this situation, the Technician can create a Per Item or Per Request SLA Contract within the Contract tab of the request Information screen.

Novell Service Desk gives you the option of using multiple SLAs to guide response timeframes for the variety of situations your technicians face. Designing SLAs with varying levels of granularity allows you to compartmentalize tasks and corresponding response times. You can also automatically escalate older tasks, so that no service request goes unresolved. It includes:

Targets, Priorities & support hours: SLA can be defined for specific process such as Incident or SR or can be common for all requests. You can also define priorities such as Urgent, High, Medium etc for each SLA. And you can define support hours for each SLA.

Triggers & Alerts: A Request's Service Level Agreement can include trigger points that set the rate at which automated escalations will occur for Request. Auto-escalation is triggered when the number of support hours specified for either an Request Service Level Response, Restoration or Resolution time is exceeded and the SLA Trigger action is set to Escalate. When it is escalated, the request is reassigned to a Technician in the next escalation level and an email is sent to the newly assigned Technician. This process repeats itself until either the Request Status changes to an inactive State, for example, Closed - Resolved, On Hold, Closed or until all of the Team's available escalation layers are exhausted.

Three types of alerts can be set:

• • Reminder: Sends a reminder email to the Technician when the defined percentage of time elapses for a Response, Restoration or Resolution target that has not been met on a request

• • Warning: Sends a warning email to the Technician when the defined percentage of time elapses for a Response, Restoration or Resolution target that has not been met on a request

• • Escalation: Escalates the request to a higher escalation layer when the defined percentage of time elapses for a Response, Restoration or Resolution target that has not been met on a request

Blackouts: A Blackout Period is based on an agreement between the Customer and the Service Desk regarding set times that the Customer has no service expectations. This can also be the preferred time for Item upgrades and maintenance as they will not affect service availability. A Blackout Period can be specified within an SLA. During this time the SLA is viewed as inactive and its measuring time is stopped. OLAs that underpin a Workflow State that apply an SLA with a Blackout Period, also adopt the Blackout Period.
Blackouts are typically used as part of Change and Configuration Management to advise Users about the appropriate periods of time that an Item associated with an SLA should be scheduled to be taken offline if an Outage is needed. When an Outage is being scheduled on an item the Blackout period is displayed, informing the end user of the best time to schedule a Planned Outage



Few points to note while setting SLAs:

• • A good SLA at the minimum has clearly mentioned targets, defined priority levels, support days & hours, response/resolution times and escalation triggers

• • Response Restoration < Resolution

• • Too many SLAs applied all over the place makes it difficult to troubleshoot. NSD's order of preference is Customer, Org unit, Item if nothing else then default

• • SLA resolution time >= Sum {Workflow States (OLA or UC resolution times)} i.e. make sure that your OLAs and UCs fit within the agreed upon SLA window

• • When validating Workflows, NSD system disallows adding States to a Workflow that will force the sum of the Workflow State resolution timers for OLAs and UCs to breach the SLAs resolution timers and warns the service level manager to either increase the SLA resolution targets or select a more appropriate UC or OLA that will fall within the SLA targets.

• • It is recommended that reminders be sent at 50% of elapsed time and escalations at 75-80%. Alerts can be set to 200% of the SLA time, which ensures notifications can be still be received against breached requests

• • SLA as a process might need continuous monitoring, when unacceptable levels of service are noted throughout the service cycle, action can be taken to re-align expectations with actual service delivery results. It may be challenging to get the SLAs, OLAs & UCs right in the first iteration, it may be time consuming process, but if you do it right the effort is worthwhile

• • Use Workflow states effectively to stop SLAs ticking the time when the technician is a waiting for customer response