Service Level Management

[kumkumr]

Service Level Management (SLM) is a critical component of ServiceNow's IT Service Management
(ITSM) capabilities. It enables organizations to define, track, and manage service levels for their
services, ensuring that services are delivered within agreed-upon timeframes and quality
standards.

Agreements are divided into 3 : -

1.SLA(Service Level Agreement) :- agreement between Client/Customer and Service Provider.
2.OLA( Operational Level Agreement) :- agreement between internal organization and service
provider.
3.UC ( Underpinning Contract) :- agreement between service provider and Vendor. Ex:-Company is
taking laptop from 3rd party to fulfill their service to the client.

Responsive SLA:
A Responsive SLA measures the time it takes for a service desk to respond to a customer's request
or incident. It focuses on the initial response time, which is the time it takes for the service desk to
acknowledge the customer's request and provide an initial response. The responsive SLA is
typically used to measure the service desk's ability to quickly acknowledge and respond to
customer requests.


Resolution SLA:
A Resolution SLA measures the time it takes to resolve an incident, problem, or change request. It
focuses on the time it takes to restore normal service operation or to complete a change request.
The resolution SLA is typically used to measure the service desk's ability to quickly resolve
customer issues and restore normal service operation.

Retroactive SLA:
In ServiceNow, retroactive SLA allows you to adjust the SLA timing to count from when the incident
was first created, rather than from when the incident's priority changed. This reflects the actual
time the user contacted you. You can use the retroactive pause property to apply pause times to
the new SLA1.

Retroactive Start in SLA:
Retroactive starts means that from when it will take effect.
For e.g. If any SLA get cancelled or completed in any record and due to some condition same SLA
get attach to the same record again. Then through retroactive start we can decide that from when
new SLA will start or what would be its start triggering point.

[GlideFather]

Hi @kumkumr,

I have reviewed your post about SLA management and I have a few questions/remarks.

• First of all, do oyu really think SLA is related to ITSM only? You can set SLA to ANY table including custom ones, no? Your post seems to claim it is exlcussive to ITSM and nothing else... 

• "Agreements are divided into 3 : -" - into 3 what?
• There's no mention about conditions when to start, pause, stop or reset the SLA,
• No mention about schedules, timezones, duration (example: Priority 1 x Priority 5)...
• I also miss some definition what the SLA actually does,
• No reminders/notifications (50, 75, 100 % breach time)

I don't know what source you used but it seems to me that you wrote something about SLA without looking at it:

Maybe what could make your post a little bit better is to add some screenshots or graphics (Canva or something, it's easy to use) to explain some use case. You mentioned ITSM, so something like "Incident with Priority 1 is created, the SLA response and resolution starts both running, Assigned to is populated, response is stopped, resolution continues, ... agent needs more time, set the state on hold, the resolution is also stopped, end user answers the clock is ticking again... then there's weekend so the sla is stopped again" soemthing like this to actually explain what the SLA is about.

But what I missed the most is definition of the SLA. Do we have it just because? or why do we?

Last but not least the formatting.. It always looks better to have some bolds, underlines.

Let me know what do you think about these points