Use Cases

Streamline service delivery and ensure timely resolution of requests by effectively managing Service Level Agreements.

Service Level Agreements (SLAs) and Operational Level Agreements (OLAs) are vital for defining and maintaining service quality. This document illustrates practical scenarios within ServiceOps, focusing on SLA computation, due dates, and escalation processes.

Use Case 1: SLA and OLA Type - Software Installation Request

Scenario: A marketing team member submits a request to install specialized design software (e.g., "Graphic Design Suite Pro") on their workstation. While important for their role, it is not a critical business function that would halt operations if delayed by a few hours. The IT department needs to ensure a quick acknowledgment (response) and complete the installation within a reasonable timeframe (resolution), coordinating with a software deployment specialist.

This use case demonstrates how ServiceOps automatically calculates SLA due dates, triggers escalations for impending or breached targets, and manages internal team commitments through OLAs for such routine software installation requests.

SLA Configuration:

An SLA is configured with the following settings to handle low-impact software installation requests:

• Name: Software Installation Request Handling
• Type: SLA and OLA
• Module: Request
• Operational Hours Type: Business Hours (Applicable until a technician group is assigned; also applies if an assigned technician group lacks specific business hours).
• Description: This SLA is designed for low-impact software installation requests, ensuring quick acknowledgment and resolution with escalations to higher levels.
• Conditions: SLA is effective when the request Impact is Low, Category is Software Installation, and Service is Desktop Support.
• Max Response Time: 10 minutes
• Response Escalation:
  • Escalation 1: Before 5 minutes
  • Action 1: Set Priority to Medium.
• Max Resolution Time: 15 minutes
  • Escalation 1: Before 5 minutes
  • Action 1: Send Escalation Email to Technician and set Priority to High.
• Operational Level Agreement: Enabled
  • OLA 1 Time: 6 minutes
  • Technician Group: IT Support Group

Application to a Software Installation Request:

Upon creation of a Software Installation Request, the configured SLA is automatically applied.

SLA Due Date Calculation (Default Business Hours): Initially, if no specific technician group is assigned, the system calculates the SLA due date based on predefined Default Business Hours (e.g., Mon-Fri, 10:00 AM to 06:00 PM). For a request created on Nov 28, 2025 12:16 PM, with a Max Resolution Time of 15 minutes, the SLA due date for the software installation is set to Nov 28, 2025 12:31 PM.

SLA Escalation Trigger: If the software installation request response time exceeds the calculated due date, the SLA escalates. This typically involves an automatic change in the request's Priority to Medium and a visual indication of the First Response Overdue.

Impact of Technician Group Business Hours: When a Technician Group with specific operational hours (e.g., 24x7) is assigned to the request, the SLA dynamically recalculates the due date. The 15-minute resolution time is then counted based on the technician group's working hours, which adjusts the Overdue Period accordingly for the software installation.

Operational Level Agreement (OLA) for Software Packaging: An OLA, set to 6 minutes, is introduced for the IT Support Group (assigned as the Technician Group) to manage their internal commitment for preparing the software package. When this OLA is applied (e.g., on Nov 28, 2025 12:32 PM), its due date is established for 6 minutes later, i.e., Nov 28, 2025 12:38 PM.

OLA Violation Notification: In the event of an OLA violation by the IT Support Group, the OLA Overdue time is prominently displayed in red, signaling a breach to relevant stakeholders.

All comprehensive SLA and OLA details, including their real-time status and timelines for the software installation request, are accessible within the dedicated SLA tab of the request.

Use Case 2: SLA Type - Critical Incident Response

Scenario: A high-priority server outage is reported, impacting critical business operations. The IT team needs to respond and resolve this issue within a very tight timeframe to minimize downtime.

SLA Configuration:

• SLA Name: Critical Server Outage SLA
• SLA Type: SLA and OLA
• Module: Request
• Operational Hours Type: Calendar Hours (24/7)
• Description: This SLA is designed for high-priority server outages, ensuring rapid response and resolution with multiple escalation levels and cumulative penalties to minimize downtime.
• Conditions:
  • Impact is On Users
  • Urgency is High
  • Category is Server Issue
  • Service is Production Environment
• Max Response Time: 15 minutes
  • Response Escalation 1 (Before 5 minutes): Send an Escalation Email to Technician's Manager, change Priority to Urgent.
  • Response Escalation 2 (After 5 minutes): Send an Escalation Email to Department Head.
• Max Resolution Time: 2 hours
  • Resolution Escalation 1 (Before 30 minutes): Send an Escalation Email to Technician.
  • Penalty Type: Cumulative
    • Penalty 1: From: 0 To: 1 Hour, Cost: 500 USD per Hour (Apply penalty once for configured unit: Enabled)
    • Penalty 2: From: 1 To: 2 Hours, Cost: 1000 USD per Hour (Apply penalty once for configured unit: Enabled)

Explanation: This SLA ensures that critical server outages receive immediate attention. The 24/7 operational hours reflect the urgency. Multiple escalation levels ensure that if the initial response or resolution targets are missed, higher-level personnel are informed, and additional actions are triggered to accelerate resolution. The cumulative penalty highlights the financial impact of prolonged downtime.

Now, create a request with the following details:

• Impact: On Users
• Urgency: High
• Category: Server Issue
• Service: Production Environment

The SLA will get applied to it as shown below.

Also, you can view the Audit Trail for the request to see the SLA details as shown below.

Use Case 3: OLA Type - Internal Team Collaboration (Service Request)

Scenario: A user reports a critical bug in the application, and the Support team needs to coordinate with the Development, QA, and Infrastructure teams to resolve it. The SLA for this request is defined by the customer, but the internal team collaboration needs to be managed efficiently.

The initial configuration for the "Critical Bug Resolution SLA" is shown below.

SLA Configuration:

An SLA, named "Critical Bug Resolution SLA", is configured with the following settings to manage this critical bug resolution request:

• SLA Name: Critical Bug Resolution SLA

• SLA Type: SLA and OLA

• Module: Request

• Operational Hours Type: Business Hours

• Description: This SLA is designed for critical bug resolution requests, ensuring efficient coordination between internal teams and escalation to higher levels.

• Conditions:

  • Impact is On Users
  • Urgency is High
  • Category is Software Bug
  • Subject contains Critical Bug

• Max Response Time: 30 minutes

• Max Resolution Time: 8 hours

• Operational Level Agreement (OLA): Three distinct OLAs are defined to track the performance of various internal teams:

  • OLA 1 (Development Team):
    • Time: 2 hours
    • Technician Group: Development Team
  • OLA 2 (QA Team):
    • Time: 4 hours
    • Technician Group: QA Team
  • OLA 3 (Infrastructure Team):
    • Time: 1 hour
    • Technician Group: Infrastructure Team

• Overall OLA Escalation:

  • Escalation 1 (Before 30 Minutes):
    • Action 1: Send an Escalation Email to Department Head

Explanation of OLA Tracking (SLA History View):

The image below, illustrating the SLA History for a "Critical Bug Resolution SLA", demonstrates how these internal OLAs are tracked in real-time. Each entry provides a clear overview of the status and performance of the involved technician groups.

As depicted in the SLA History:

• Multiple OLA Entries: The system displays separate entries for each configured OLA, such as for the QA Team, Development Team, and Infrastructure Team. Each entry specifies the Type as OLA and the Target as Resolution.
• Real-time Status and Progress: Each OLA shows its Status (e.g., Running, Paused), Elapsed Time, Due In (if applicable), and SLA Percentage. For instance, the QA Team's OLA shows 3.1% SLA Percentage and 5 minutes 49 seconds Due In, while the Development and Infrastructure teams' OLAs are Paused with their respective Elapsed Time and SLA Percentage.
• Breached SLA for First Response: The history also includes an entry for the main SLA for First Response, which is shown as Breached with 216.67% SLA Percentage and 5 minutes 50 seconds Breached Duration, indicating a delay in initial response by the QA Team.
• Comprehensive Overview: This detailed history ensures transparency and accountability for each internal team's contribution to resolving the critical bug, ultimately supporting the timely fulfillment of the customer-facing SLA.

Use Case 4: UC Type - Vendor-Dependent Hardware Repair (Service Request)

Scenario: A user's laptop requires a hardware repair that necessitates sending it to an external vendor. This is typically initiated as a Service Request. The Underpinning Contract (UC) SLA needs to account for the vendor's turnaround time.

Create an SLA under Hardware Repair Service Request as shown below.

SLA Configuration:

• SLA Name: Hardware Repair (Vendor Dependent) SLA
• SLA Type: UC (Underpinning Contract)
• Module: Request
• Operational Hours Type: Calendar Hours (24/7, for tracking vendor time)
• Description: This SLA is designed for hardware repair requests, ensuring timely vendor engagement and resolution with escalations and penalties.
• Conditions:
  • Category is Hardware
  • Subject contains Hardware Repair
• Owner: LA Larry (larry@motadata.com)
• Vendor: DELL
• Max Resolution Time: 1 Hour
  • Escalation 1:Time: Before 10 Minutes
    • Action 1: Set Technician Group To IT Procurement Team
    • Action 2: Send an Escalation Email to Technician
  • Escalation 2:
    • Time: After 10 Minutes
    • Action 1: Send an Escalation Email to Technician
• Penalty Type: Cumulative
  • Penalty 1: From: 0 Hours To: 1 Hours, Cost: 20.00 USD per Hour
  • Penalty 2: From: 1 Hours To: 2 Hours, Cost: 50.00 USD per Hour

Explanation: This use case demonstrates an Underpinning Contract (UC) which focuses on external vendor performance for a Service Request. The SLA is triggered by the request type, category, and subject, are configured in the UI. A specific internal owner, Larry, is assigned to oversee the process. The Max Resolution Time is set to 1 hour.

note

Underpinning Contracts (UC) are active only when the ticket status is configured for UC tracking. If a ticket transitions to a status that is not configured for UC (e.g., "Pending"), the UC timer will automatically pause. It will resume running only when the ticket status changes back to a configured, active status (e.g., "In Progress"). For more details, please refer to the Request Status section.

The escalation rules are configured as follows:

• Escalation 1 triggers 10 minutes before the resolution due date, setting the technician group to "IT Procurement Team" and sending an escalation email to the technician, allowing proactive follow-up with the vendor.

• Escalation 2 triggers 10 minutes after the resolution due date, sending another escalation email to the technician to alert them of the breach.

The cumulative penalty structure is applied to the vendor, with increasing costs for delays: 20 USD per hour for the first 1 hour overdue, and 50 USD per hour for delays between 1 and 2 hours, highlighting the contractual obligations and financial repercussions for delays.

Related Sections

• Configuring Service Level Agreements
• Request Management Setup