- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
2 hours ago
One of the most frequent hurdles for people new to ServiceNow involves understanding the various types of time-based commitments. If you have an IT service management background, you probably know the term, but seeing how the platform handles it can feel like learning a new language. You need to know exactly what is an SLA in ServiceNow and how it differs from other internal or external promises. Translating these core concepts into platform behavior is the first step toward mastering the system.
This guide is specifically for ITSM professionals who are making the transition to the ServiceNow platform.
Get Started with a ServiceNow Personal Developer Instance (PDI)
Before you start clicking through menus, you need a safe place to practice. ServiceNow provides a Personal Developer Instance (PDI) at no cost. All you need is an email address to register. This environment allows you to explore every corner of the platform without the fear of breaking production data.
If you don't have one yet, you can follow a step-by-step PDI setup tutorial to get your environment ready. Once you're in, you can install specific features or modules to see how they function. Most PDIs come with IT service management (ITSM) and standard platform capabilities pre-loaded. This gives you access to demo data, which is perfect for seeing how active service levels look on a real incident ticket.
Using a PDI lets you:
- Experiment with different trigger conditions.
- See how workflows behave when a deadline passes.
- Practice building reports based on time-based targets.
Navigating to SLA Modules in ServiceNow
Finding your way around the platform starts with the application menu on the left side of your screen. ServiceNow uses a keyword-driven search, so you can simply type "SLA" into the navigator. Depending on what you have installed, you'll see several modules.
The Service Level Management module usually sits at the top. While ITSM is its most common home, the SLA engine is actually a platform capability. This means you can use these time-based measurements for almost any task in the system, from HR cases to facility requests.
To see the building blocks of these measurements, click on SLA Definitions. This page displays the rules the system uses to track time. If you right-click the headers and filter for incident tickets, you can see the out-of-the-box examples that ServiceNow provides. These examples show how the platform handles various priorities and service types.
SLA Basics: Your Time-Based Promise to the Business
A Service Level Agreement (SLA) is a commitment made between a service provider and a customer. In ServiceNow, an SLA measures how long it takes for an incident or task to meet a specific expectation. It focuses on the external promise made to the business.
What an SLA Measures
The platform tracks two primary types of expectations for incidents:
- Response Time: How quickly the team acknowledges the issue.
- Resolution Time: How quickly the team fixes the problem.
For example, a Priority 1 incident might require a response within 15 minutes and a resolution within an hour. The SLA answers a simple question: Did we meet what we promised to the business? These records attach to incident tickets immediately upon creation and stop running only when the required outcome happens.
Key SLA Configurations
When you open an SLA definition, you'll see several fields that dictate its behavior. You can set the duration, such as a two-hour window, and choose an operating model or schedule. This schedule ensures the "clock" only runs during business hours if that's what your contract specifies.
ServiceNow uses a workflow-driven engine for these records. By default, the system triggers actions when certain milestones are hit:
- The 50% Mark: The system might send a courtesy notification to the assigned user.
- The 75% Mark: An escalation email might go to a manager.
- The 100% Mark: The SLA is marked as "Breached," and senior leadership may be notified.
You can also set conditions for when the clock should start, pause, or stop. For instance, if you're waiting for a customer to provide more information, you can set the state to "On Hold," which pauses the SLA duration. This ensures your team isn't penalized for delays they don't control.
OLA: Holding Internal Teams Accountable
An Operational Level Agreement (OLA) is a time-based commitment between internal groups. While the SLA tracks the promise to the customer, the OLA tracks the handoffs between departments. It answers the question: Did the supporting team do their part so the overall SLA could be met?
Imagine a Priority 1 incident assigned to the database team. Even if the customer has a one-hour resolution SLA, the database team might have a 20-minute OLA to finish their investigation. This isn't a promise made to the business; it's a tool for internal accountability.
| Feature | SLA (Service Level Agreement) | OLA (Operational Level Agreement) |
|---|---|---|
| Audience | External (Customer/Business) | Internal (Support Teams) |
| Focus | Overall outcome and satisfaction | Internal efficiency and handoffs |
| Visibility | Reported to the business | Used for internal management |
In ServiceNow, OLAs use the same engine as SLAs but are scoped to specific assignment groups. This setup helps you avoid the "blame game." If a ticket breaches its SLA, you can look at the OLAs to see exactly which team held the ticket for too long.
Underpinning Contracts: Tracking Vendor Promises
If your service relies on a third party, such as an internet provider or a software vendor, you use an Underpinning Contract. This tracks the commitment made by that external supplier. It operates using the same logic as the other two types but is tied to vendor performance.
If a critical network switch fails and you must call the manufacturer, the Underpinning Contract measures their response. ServiceNow can tie these contracts to specific Configuration Items (CIs) in your CMDB. For example, if a specific server fails, the system automatically knows which vendor contract applies.
This allows you to connect incident performance directly to supplier management. If your business is constantly breaching SLAs because a vendor is slow, you'll have the data to prove it during your next contract review.
How the Three Agreements Work Together
The true power of ServiceNow is how it manages all three of these agreements on a single incident ticket. They all run simultaneously, but they answer different questions about the life of the ticket.
- SLA: Did we meet the business expectation?
- OLA: Did our internal teams perform as expected?
- Underpinning Contract: Did the supplier meet their obligation?
Consider a scenario where a company's website goes down. An incident is logged, and the SLA starts counting down its one-hour resolution target. The service desk assigns it to the web team, which triggers an OLA. If the web team discovers the issue is actually with the cloud hosting provider, they reach out for support, which starts the Underpinning Contract timer.
If you only use SLAs, you lose visibility into why things are failing. If you mix everything into one bucket, your reporting becomes a mess of meaningless numbers. By separating these three concepts, ServiceNow gives you end-to-end visibility into your service delivery.
Know Your Agreements
Understanding these distinctions is vital for any ServiceNow professional. The platform doesn't invent these concepts; it simply gives you the tools to make them operational. If you bring clear ITIL thinking into the platform, the system becomes an incredibly powerful asset. Without that clarity, the data just becomes noise.
To summarize the three main types:
- SLA: An external commitment to the business or customer.
- OLA: An internal commitment between support teams.
- Underpinning Contract: An external commitment made by a supplier.
Mastering these agreements ensures you can provide the transparency and accountability your organization needs to thrive.
How is your team currently tracking internal handoffs? Implementing OLAs might be the easiest way to clarify your team's workload and improve your overall service numbers.