Service Level Agreements (SLA) Use Cases

Service Level Agreements (SLA) Use Cases

Service Level Agreements (SLA)

Incident 

Incident SLAs are customer-specific, not site-specific. However, you can set SLAs for specific sites under Conditions.

Use case: Define an SLA for specific impact and urgency 

Scenario:
Restrict Zylker's users from marking low-impact, low-urgency requests (like access grant, password reset) as high priority to eliminate unintended SLA violations.
Action: 
  1. Specify impact and urgency criteria for the SLA.
  2. Set resolution time for the chosen impact and urgency. You can choose to include operational hours for resolution time.
  3. If required, you can define escalations and emails to be sent when response/resolution time has elapsed.
Sample Configuration:
Section
Fields and Values
Conditions
When request arrives - Apply conditions based on criteria
Condition - Impact is Low AND Urgency is Low.
Any request matching the above conditions should be:
Responded within - 1 Day
Resolved within - 6 Days
Should be resolved irrespective of operational hours - Enable the checkbox
Including holidays - Enable the checkbox
Including weekends - Enable the checkbox
If resolution time has elapsed
Enable Level 1 Escalation - Enable the checkbox
Escalate before 1 hour
Escalate To - $TicketOwner, Department Incharge of Technician
Custom Action 1 – Field Update > Priority: High
Custom Action 2 – Notification > select the relevant escalation notification template.
 
 
To ensure requests are addressed within the defined response time, go to Setup > General Settings > Advanced Portal Settings and configure as shown:

What are the different ways can technicians respond to a request without SLA violation?

Technicians can:
  1. Reply to a request manually by clicking Reply all or Reply in the request details page.
  2. Reply to the automated emails they receive in their mail box.
  3. Add a note to the request.
  4. Add a work log or resolution to set the first response time.

Service Request

Service request SLAs are not customer-specific and site-specific. However, you can set SLAs for specific sites or customers under Conditions. 

Use case: Allow users to choose an SLA  

Scenario:
Enable users to choose the appropriate SLA while submitting a service request for urgent service needs (Example: software installation for a critical project)
Prerequisites: 
  1. Create service request SLAs under Setup > Automation > Service Level Agreements > Service Request.
  2. Allow end users to select SLA while creating a service request under Setup > General Settings > Advanced Portal Settings.
Action
  1. Associate the service request template with one or more SLAs under Setup > Automation > Service Level Agreements > Service Request.
  1. If needed, enable Make this as default SLA to overwrite the default SLA already associated with the chosen template.
 
Post Action:
From the service request form, users can:
  1. Click Select SLA and select the relevant SLA from the available SLAs.
  1. Remove or change the selected SLA as required.
  1.  If users do not select any SLA, the default SLA marked for the template will be applied. 

SLA Breach Indicators

First Response Time Violated
Not responded within the defined response time
Request Nearing Due By Time
Almost 70 % of the due time is reached
SLA Violated
Not resolved within the defined resolution time

    • Related Articles

    • Service Level Agreements

      A service level agreement (SLA) is an official commitment between a service provider and the customer. In ServiceDesk Plus, you can set up SLAs exclusively for incident/service requests. You can also configure escalation rules to notify technicians ...

    • Workflows Use Cases

      Workflows Pointers Workflows can be configured for All Customers as well as for a specific customer, but not site-specific. This setting is module-specific. Separate workflows for incident requests and service requests can be configured. If an asset ...

    • Notification Rules Use Cases

      Notification Rules Pointers Supported Modules: Requests, Problems, Changes, Projects, Release, Solutions, Assets, Purchase, Contracts, Tasks, and other general events. Supported Notifications: Email, SMS, and Push. Actionable Messages can be enabled ...

    • Triggers Use Cases

      Triggers Pointers Triggers can be configured for All Customers or a specific customer. Once configured, the Customer cannot be changed. Triggers are module-specific and not site-specific. However, you can configure for specific sites of customers ...

    • Closure Rules Use Cases

      Closure Rules Pointers Closure rules automate the collection of vital details and execute relevant actions before a record can be closed in the service desk. Closure rules are not customer-specific. Supported Modules: Requests, Problems, Changes, ...