Home > Configuring Service Level Management
A Service Level Agreement (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.
Operational level agreements (OLAs) are similar to SLAs, except they
communicate internal team-based expectations within specific stages of
the Workflow process. Similarly, the obligations of external service providers
are specified using Underpinning Contracts (UCs). Unlike an OLA where
an appropriate Team Technician is assigned responsibility for servicing
a request, it is the responsibility of a Service Level Manager to monitor
the performance of the external service provider in relation to the business's
expectations as defined in UC Workflow States.
Workflows consist of an Entry State, one or more Transitional States
and Exit States. They define the sequence of steps that Service Desk staff
can follow when managing customer requests. Within the system, any number
of Workflows can be customized for the Incident, Problem, Change, Release
and Service Request Management Processes. Each step, or Workflow State,
defines the activity, and if relevant the OLA, with Default Team, or UC
required to successfully process the request at that step. Only after
the nominated Team Technician has successfully concluded the activity
does the request get routed to the next appropriate Workflow State. The
Workflow is deemed complete once the request enters an Exit Workflow State.
When a request is created it is assigned an SLA, and based on the assigned
SLA, a Workflow and Team. Based on the configuration of the assigned Team,
a Technician or System User is allocated the responsibility of the task.
Within Teams, escalation layers are configured for manual or automated
routing of requests. Manual routing through the escalation layers is triggered
by a Technician in the request Information screen. Automatic routing through
escalation layers is driven by the request's assigned priority relative
to the associated SLA response, restoration and resolution targets. For
each target one or more percentage triggers can be created for automated
reminders, warnings or escalations. When the request is in a Service Level
active stage of the Workflow the system monitors the percentage of time
elapsed relative the SLA triggers, and when percentage targets are met
the triggers are activated. If the SLA response, restoration or resolution
time is breached, the request is automatically escalated.
The Service Level Management module allows service level expectations
to be mapped to end-to-end business processes. In so doing, the system
performs the following Service Level Management validation:
SLA resolution time >=
Sum (Workflow States (OLA or UC resolution times)
When validating
Workflows, the 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. In such situations, the system will
warn 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.
Before requests can be processed using SLM, a Supervisor typically needs to perform the following sequence of configuration steps:
Define Technicians. Set Roles & Process permissions (Users > Users)
Define service level
managers (Users > Users)
To become a service level manager a User must be assigned the Service
Level Management Process
Establish business SLAs
a. Specify service level manager
b. Availability %
c. Warning and breach notifications
d. Set priority targets
e. Specify blackout periods
Setup OLAs
a. Specify service level manager
b. Set service targets
Setup Underpinning Contracts (UCs)
a. Specify service level manager
b. Specify Vendor
c. Set service targets
Define Workflows
a. Name the process and associate it with one of the ITIL processes
b. Optionally modify default open and close states { you might need to come back to this once all states have been defined}
c. Specify SLA for the Workflow from Step 3.
d. For each Workflow State, specify:
i. Is the Workflow State active?
ii. Is the State an entry or exit state?
iii. The Contract Type: None / OLA / UC
Specify an OLA if the OLA Contract Type is set.
Select a default Team, that has been assigned the OLA.
Specify a UC, if the UC contract type has been selected.
iv. Should the SLA timer continue counting time when the request has entered this State?
v. Should the State be used to measure SLA restoration or resolution time (for reporting purposes only)
vi. Specify relevant next / previous States to define the end-to-end Workflow.
To prevent the SLA target from being
breached, the contract time will be calculated when
an OLA or UC is assigned to a State.
e. Update 6b, if required.
Define the Teams
a. Specify Technicians
b. Specify OLAs
c. Specify Workflows
d. Define escalation layers or work groups
Make any modifications to the Workflow State
a. Specify a default Team to provide support
for specific States {review 6diii 1a)
After SLAs, Workflows and Teams have been defined, the Service Desk is able to use the system to efficiently process Incident, Problem, RFC and Service Requests according to organizational standards and procedures.
The following steps outline the process of generating and managing an Incident in the system:
Within the Operations > Incident tab select the New button:
a. Assign a Customer
b. Select an Item, which include Services within Service Catalog
c. Profile the request
i. Select a Classification
ii. Enter Description of the request
iii. Complete any custom fields
d. If the proactive analysis option is enabled,
proposed solutions will be available within the Analysis Tab. If a relevant
Solution is proposed, apply the Solution to close the request. Otherwise,
click ‘Next’ to move to the Summary tab of the request screen.
In the Summary Information screen, confirm:
a. SLA
b. Workflow
i. A list of Workflows options is derived based on the SLA selected
ii. If a Workflow has not been assigned to the SLA, then the system default Workflow is assigned to the Incident
c. Team
i. A list of Team options will be derived based on the Workflow selected
ii. If a Team has not been assigned to the Workflow, then the CI’s default Team is assigned to manage the Incident
d. Technician
e. Request Urgency / Impact / Priority
f. Notifications
g. Workflow State (= Status)
h. Add Note(s), and apply private/public visibility and Customer email distribution options
i. Upload attachments
j. Access Audit trail details
k. Access Impact information (i.e., Service
Targets, SLA breaches, Item Relationships, Planned Outages, Contract Monitor)
Perform analysis within the Analysis tab
a. Allows the system to recommend a proposed Workaround or Solution
b. Search Workarounds / Solutions
c. Raise new Workaround / Solution
d. Raise a new Problem and link it to the request
e. Raise a new RFC and link it to the request
f. If the request is related to other Incidents,
Problems, Change or Service Requests, view all related requests within
the Related sidebar in the Summary screen.
Save the request
Group similar or related
requests using the Link option and manage the collective from the
Group tab or selecting the Group # link in the List View, if this
option has been defined for the customized view.