Intro
The IT Service Management (ITSM) solution in ServiceNow provides scalable workflows to manage and deliver IT services to your users all through a single cloud-based platform. The ITSM solution can help increase your agents' productivity, resolve issues quickly, and improve user satisfaction. Also, powered by platform native AI, you can quickly accelerate technology changes and view recommended actions for incoming tickets or requests and drive self-service and automation through enterprise chatbot technology. The NOW platform also provides users access to ITSM via mobile or web-portal interfaces.
The Now Platform was built for the cloud and has its own shared data model, AI, and workflow automation that are leveraged by many IT applications. The combination of the ServiceNow platform and applications helps you increase productivity by automatically identifying and resolving issues, which reduces the negative business impacts of unplanned, non-strategic work.
The platform has been designed to
- Enhance the service experience
- Consolidate IT services
- Improve IT productivity
- Provide mobile connectivity
- Gain visibility into processes and services
About this last point in order to get new insights into processes and services, ServiceNow provides several applications, Service Level Management (SLM) is one of them.
This article highlights an SLM free plugin commonly installed but not known/used but very valuable for customers and usually requested to be implemented.
Service Level Management
The ServiceNow® Service Level Management (SLM) application helps to gather service requirements as well as monitor and report with regards to agreed service levels (SLAs). SLM can be used across the organization in departments such as HR, Facilities, and IT.
Service Level Managers are responsible for negotiating a set of agreements between a service provider and customer that define the scope, quality, and speed of the services being provided and ensuring that the agreed service levels are met.
Setting an SLA in the platform it's an easy configuration task for an administrator.
The user navigates to
-
Start condition - Define the conditions under which the SLA is attached.
-
Pause condition - Define the conditions under which the SLA suspends increasing elapsed time.
-
Stop condition - Define the conditions under which the SLA completes. If all these conditions match, then the task SLA completes regardless of whether it is breached.
-
Reset condition - Determines whether the existing task is canceled or completed on task SLA reset. Defines the conditions under which the running SLA is canceled or completed and a new SLA is attached. For a new SLA to be attached, the start condition must match.
SLA Breakdown a better way of analyzing SLAs
Understanding the status of SLAs is quite useful for managers and support agents alike. On the other hand, the system at this level is not able to give more details or provide more evidence about the approach followed internally by the different groups to complete the tasks.
It is possible in fact that incident tasks are repeatedly passed from one support team to another, creating what is sometimes called a “ping pong” scenario.
Most often this is not a lack of accountability or skills within individual teams. Each team genuinely fails to see the incident as relevant to their technical silo. They each feel perfectly legitimate in either assigning the ticket to another team or even assigning it back to the team they took it from. Unfortunately for the end-user, the tasks are not resolved whilst the reassignments continue. The situation can easily escalate into SLA breaches, financial penalties, and certainly unhappy end-users.
IT service management (ITSM) has been around for a long while, and there are known mitigations to handle these situations. Good ITSM practice would dictate some type of built-in mechanisms to better analyze the interactions between groups and get a broader and granular view of the time spent by each group/member and their impact on the overall SLA status.
In the past, I've seen this request as a common requirement for customers and a source of problems for developers/consultants because of the implication of customizing the SLAs engine available in ServiceNow.
Luckily for you, this functionality has been implemented and included in ServiceNow a few years ago (London release) and is free and available for everyone to be used.
The plugin responsible to give you this capability is named Service Level Agreement (SLA) breakdowns. Using SLA breakdown, the service owner or service desk manager can see detailed task ownership and SLA duration related data for any task SLA record associated with a task. This helps determine which teams and users are contributing to SLA compliance.
In order to see the functionality in action, the admin must include a new related list usually not visible named ''SLA Breakdown by Assignment->Task" on the task's form.
If a breakdown is already set for the SLA definitions the user will be able to see a different level of details compared with a classic Task SLA.
Here's an example set on 'Incident'.
For each support group and group member assigned to the task is possible to know exactly for how long they have been working on the task.
In the next image, you have a good example. The incident started assigned to the 'Hardware' support group and worked by a couple of members before being redirected to the 'Network' support group.
After a small amount of time spent unassigned, has been evaluated by one member and reassigned to the 'Database' support group.
SLA Breakdown set up.
Creating an SLA breakdown is exactly like setting an SLA definition. A Simple work of configuration.
The admin must navigate under 'Service Level Management' > 'Breakdowns' > 'Breakdowns definitions'
On the form, fill in the following fields.
- Name - Name of the SLA breakdown.
- Task table - Table on which the definition is applicable.
- SLA breakdown table Table where the SLA breakdown data is stored.
After the creation, of the SLA Breakdown Definition, two new related lists appear.
The first one 'SLA Breakdown Definition Fields' sets the fields that will be followed by the breakdown, the second one 'SLA definition' the SLAs that will be affected by the breakdowns.
When setting 'SLA Breakdown Definition Fields' you can select between 'assigned to' and 'assigned group'
According to the selection, the system shows the matching fields in the task record table that can be mapped to the breakdown field.
Final step. Link the SLA/s that should require to be broken down.
IMPORTANT. For this example, a new SLA definition affecting the 'Problem' task table has been created. In ServiceNow baseline does not exist.
Cheers
r0b0
