Service Level Agreements (SLAs) are used by organizations to manage the levels of service expected of the IT and to ensure optimal maintenance of critical business systems and services. SLAs are documents that are negotiated between the Service Provider and Customer departments, to identify expectations and clarify responsibilities.
This tab is used to create and modify Service Level Agreements that provide request management capabilities.
SLAs include the following elements:
Name
Service Level Manager
Priority Targets
Automated Alert Notifications
Pricing (if enabled in Admin>Setup>Billing)
Blackout Periods
Workflows.
To create a new Service Level Agreement:
* Denotes a mandatory field
Select Service >SLAs
Click New
The screen defaults to the Details tab of the SLA Editor screen.
Complete the fields, including any custom fields, as required:
SLA Editor |
|
---|---|
Details |
|
Name* |
The name to identify the SLA. |
Review Date |
Details are completed based on the Admin default settings but can be edited by the User. An Alert is sent based on the default days set in the Review SLA Alert field in Admin>Setup>Privileges>Requests. |
On Breach |
Notification can be set to Carbon Copy (CC) an email to the Team Leader when the Warning or Escalation alert is sent to the Technician assigned to the request. It should be noted that the Service Level Manager is also notified when an SLA is breached. |
Pause on Holiday |
**This option is only displayed if the Observe Public Holidays option has been enabled within the Administrator>Setup>Privileges>User tab. Enable this option, if the SLA is to be adjusted on designated Public Holidays. The Public Holidays are defined within the Administrator>Setup>Public Holidays screen and associated with requests via the assigned Technician and their associated Country. |
Customer Timezone |
When enabled, SLA times displayed within the Technician request view uses the Customer timezone. |
Timezone |
This is visible when Customer Timezone is not set and all SLA dates are calculated based on the Timezone set within this field. This is especially applicable for User Work Hours, Blackouts, which also impacts the SLA Reports. |
Requirements |
|
Availability* |
Used to state the time an Item under the SLA is required to be online. The default value is set to 97%. |
Interval Measured in |
Defines the number of days over which the Availability requirement is calculated. |
Priority |
|
Process Name |
The field is displayed when Workflows have been assigned to the SLA. If multiple Workflows have been assigned for each Process, this field allows the User to assign a default Workflow for the SLA. When a request is created using the SLA, the default Workflow is assigned to the request. |
SLM (Service Level Manager) |
|
Name |
Use the Find Service Level Manager search option, to enter the contact details of the Manager who will monitor the performance of the SLA. This is also the User who is assigned responsibility for managing the performance of external support providers when a request moves into a Workflow State that is supported by an Underpinning Contract . |
Internal Cost ^ |
|
Annual Cost ^ |
The SLA cost is calculated on the basis of what is costs the service organization to provide the service agreement, as applied on a yearly basis per User. The figure is associated with Items and used to calculate the cost of supplying a Service. This figure can be used as the basis for setting the Annual Price. The figure entered should be on a Annual Cost per User basis. |
Request Cost ^ |
Indicates the cost applied on a Per Request basis. This figure can be used as a reference for setting the Incident Price. |
Hourly Cost ^ |
Indicates the cost applied on an Hourly basis. This figure can be used as a reference for setting the Hourly Price. |
Customer Pricing ^ |
|
Annual Price ^ |
This is the charge applied to the SLA on a yearly basis and paid by the customer consuming the Service associated with the SLA. (It should be greater than the SLA Cost, as it would include the cost of servicing the SLA plus a profit margin, if relevant.) The figure is associated with Items and used to calculate the price paid by the customer for consuming a Service. The figure entered should be on a Annual Price per User basis. |
Request Price ^ |
Indicates the price paid by the customer when the SLA is applied on a Per Request basis. |
Hourly Price ^ |
Indicates the price paid by the customer when the SLA is applied on an Hourly basis. |
^ Only applicable when SLA Prices are enabled in Setup>Billing
The Targets tab is used to configure the SLA's priority Response, Restoration and Resolution Times.
To modify a Priority:
Select Service > SLAs
Select an SLA
Select the Targets tab to display the following fields:
SLA Editor |
|
---|---|
Targets |
|
Targets |
Common: Select Common if the SLA is to apply across Incidents, Requests, Problems and Change Management. Per Process: If the SLA is specific to a Process, select Per Process and choose a Process displayed in the drop-down list. |
Interval |
Define if the time is to be calculated in Hours or Minutes. |
Service Time |
|
Priority |
Urgent, High, Medium and Low. |
Milestones |
|
Initial Response |
The maximum time the Customer would wait from the point of request creation before receiving a Note update for a Technician. The Response trigger is stopped when a Note has been added to the request by the assigned Technician and an email is sent to the Customer. If the Response Time is reached, without a Note being added, the request will be escalated. |
Restoration Time |
The maximum time the Customer would wait from the time the request was created until a workaround or temporary fix has been implemented. The Restoration trigger stops by assigning the request a Workflow State that has to the SLA Restoration option set to Yes. By default, this Workflow State is Open - Restored. |
Resolution Time |
The taken time from the point of request creation until it the request is moved to a Workflow State with the SLA Resolution option set to Yes. Any of the default Workflow Exit States stop the Resolution Timer. |
Notify Override |
If the system is to override the default notification method set for a request when the Priority being edited is assigned to a request, check this option. |
Notification Type |
Set Email or SMS as the type of notification when the override action is applied to a Priority. |
Alerts |
|
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. Can be set up to 200% of the SLA. Note, Alert intervals are not cumulative. |
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. Can be set up to 200% of the SLA. |
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. Can be set up to 200% of the SLA. It should be noted that the Service Level Manager is also notified when an SLA is breached. |
Support |
|
24 x 7 |
Do not amend if the SLA is to apply 24 hours a day, 7 days a week. |
Normal Support |
Select if service hours are to be defined for the SLA. When checked, define the service hours by either selecting a template (Templates are configured by the Administrator in the Setup>Localization>Hours tab) or manually define the days and time by making selections within the drop-down lists. |
Click Edit, if not already in Edit mode
Define if the SLA applies across all Processes or to a specific Process
Define if the SLA is to be calculated in minutes or hours
Select the Priority link to customize Milestones, Alerts and Support hours
Modify the Milestone intervals for the Response Time, Restoration Time and Resolution Time, as required
The time will be set in minutes or hours, as defined for the SLA.
NOTE:Milestone intervals are not cumulative
For example, for the default Warranty SLA, the Priority of Urgent has the default Milestone times of 6, 12 and 24 hours. This means a User has 6 hours to send a response to a Customer before the Response time is breached, 12 hours from the point of request creation to meet the Restoration time, and 24 hours from the point of request creation to meet the Resolution time. It should be noted that requests may be moved to non-SLA timed States during these Milestone periods, so the 12 or 24 hours may not be consecutive hours.
Check the Notify Override option, if relevant
Set the type of notification, email or SMS, that is to be used to contact the User assigned to the request with this Priority.
Create one or multiple Reminder, Warning or Escalation Alerts, if relevant
Enter the percentage of time to elapse for an Alert to be triggered for a Milestone. Selecting Warning as the Alert will cause a warning e-mail to be sent to the request's Technician when the specified percentage of a milestone has been reached.
Selecting Escalation will trigger a request escalation to the next support layer of the Team. The escalation system will also fire if the SLA threshold is breached.
NOTE:It is recommended that reminders be sent at 50% of elapsed time and escalations at 75-80%
These figures are advisory only. The internal processes of your organization will dictate the appropriate values. The Reminder percentage must be less than the Warning or Escalation percentages.
Alerts can be set to 200% of the SLA time, which ensures notifications can be still be received against breached requests
If Alerts are not customized, the application will automatically escalate the request when the Priority milestone is breached
Click Save
Modify other Priorities as necessary.
After the Priority times and Alerts of an SLA have been configured, Support Hours can be defined. These can be set to 24 hours by 7 days a week (24 X 7), or manually adjusted to reflect the support operation open hours.
Under 24 X 7 mode, if the SLA's urgent Initial Response field is set to six hours, and an urgent request that uses the SLA is created at midnight in the assigned Technician's time zone, those six hours will expire by 6:00 AM. This is the option to use if a support operation is staffed 24 hours a day.
If a support operation is not open 24 hours a day, the request timers are not required to run when Technicians are not available. For instance, if the support hours are 9:00 AM to 5:00 PM and the SLA hours reflect this, the SLA timers of the urgent request created at midnight would not start ticking until 9:00 AM the following business day and would expire at 3:00 PM.
To define the SLA support hours:
Select Service > SLAs
Select an SLA
Click the Priority link
This will display the Details tab with Support Hours options of 24x7 and Normal
The default setting is 24 X 7, to amend the support hours select the Normal Support option
Select a template from the Apply Template drop-down options or customize Weekdays manually.
Note that the SLA timers become inactive when the support desk is closed.
Click Save.
Blackouts are 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 off-line if an Outage is needed. Within the system, when an Outage is being scheduled (Item>Details>Outages) the Blackout period is displayed, informing the User of the best time to schedule a Planned Outage.
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 is 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.
To specify an SLA Blackout:
Select Service >SLAs
Click an SLA hyperlink
Click Edit
Move to the Blackouts tab
Tick the Windows option
Set the Interval of weekly or monthly
Apply a Template or define the day and time period for the approved Blackout manually, then click
Define the preferred Timezone
This is required information to save the Blackout information.
Click Save.
To remove time-frames from the Blackout Period:
Select Service >SLAs
Click an SLA hyperlink
Click Edit
Move to the Blackouts tab
Check the box next to the Day to be deleted from the Blackout
Click Remove.
Workflows are associated with an SLA through the Workflows tab of the SLA Editor screen or within the Workflow itself. All SLAs assigned to the SLA are listed within this tab and Workflows can be added or removed within this tab, as required.
To assign a Workflow:
Select Service>SLAs
Click the relevant SLA link
Move to the Workflows tab
Click Edit
Select Add
The Available Workflow drop-down list will be displayed.
Select a Workflow
Click Save.
To remove a Workflow assignment, use the checkbox next to the relevant Workflow and click the Remove button.
The system includes a default SLA that does not include costs, called Warranty. The Warranty SLA can be used or edited as required.
The prices specified in the SLA provide the basis for fees charged for support on both a Per Request basis and on a subscription basis. The hourly rate is included for reporting purposes. Rather than an Item using an SLA, Items can be covered by maintenance contracts. A contract can cover a particular request, or exist as a subscription.
Maintenance Contracts form part of the request creation process. Requests can be entered into the system without a valid contract, but are flagged as unpaid, and are unable to be worked on until the invoice is processed. There is also a control (configured in the Billing Preferences) for the length of time an unpaid request can exist in the system.
See: Assigning an SLA to a Customer
See: Assigning an SLA to an Organizational Unit when Contracts are Disabled
If more than one process Workflow is assigned to an SLA, it is required to select a default Workflow. This default Workflow will be the Workflow assigned to a request when the SLA assigned supports more than one Workflow.
To assign a Default Workflow:
Select an SLA from the Service > SLA tab
Click Edit
Note that the system automatically assigns a default Workflow to an SLA, as Workflows are being assigned.
Within the Priority Field, use the drop-down lists to update the relevant Incident, Problem, Change and Service Request default Workflows
Click Save to apply the change.