SLA in ServiceNow – a curse or blessing?

SLA in ServiceNow, and in general, introduces contractual responsibility for providing your service within a specified time – it’s definitely a binding element of the contract with the customer. From the Support Team’s perspective, the SLA (Service Level Agreement) configuration mainly applies to the Incident Management or Service Request Fulfillment. It allows the customer to measure response time and resolution time.

ServiceNow SLA definitions

SLA values stored in the contract can be simply transferred to ServiceNow, where they’re defined in an intuitive way. The configuration of relevant records enables easy monitoring of SLA status from the record level. SLA definitions in ServiceNow depend on the terms of the contract signed with the customer. The negotiations of this part are crucial to finding the values satisfying for both parties to the contract.

Every definition is built mainly per ticket priority or type. ServiceNow offers great SLA configuration options that include i.e.:

  • Naming,
  • Building comprehensive start, stop, pause, reset conditions and workflow,
  • Determining duration values in the chosen schedule.

SLA definitions in the system are fully reflected and adapted to the needs of customers, both those less and more demanding.

The response time may start from the ticket’s creation and stop at the start of the initial analysis. This means status change and new comment addition. The resolution time may start from the ticket’s creation (and include response time) or from the moment when the response time stops. Resolution time stops when the ticket is closed.

SLA in ServiceNow projects - condition start and stop

SLA for Change Management

Due to the specifics of the Change Management process, there are difficulties in measuring and keeping SLA times for normal changes. It makes more sense for the standard changes that have their own clear definitions and their implementation time is similar. The complexity of normal changes can be quite different. It can affect their implementation and testing time. Every normal change needs a separate analysis and estimate.

SLA reporting

To measure SLA effectively, it’s also worth implementing appropriate reports for team leaders on the supplier side, supporters, and the customer. Each of the report observers may have different needs but the goal is always the same – the provision of a high-quality solution, in a timely manner. The SLA reports need to be based on the task_sla table that stores all SLA records generated for individual tickets.

In the beginning, it’s worth considering which reports will allow every observer to identify inconsistencies and problems. They should be intuitive and user friendly. Regular tracking of SLA:

  • Helps to avoid breaches,
  • Prevents payment of contractual penalties,
  • Nurtures customer satisfaction.

SLA advantages by role

Depending on your role, the use of SLA brings a number of advantages.

For customer:

  1. Control of response time that helps update the tickets and informing end-users about the work progress on a regular basis,
  2. Control of resolution time that helps provide critical solutions quickly enough,
  3. Assurance of work continuity within important areas,
  4. Awareness of the process and working on tickets in a specific order, in accordance with the priority.

For team leader on the supplier side:

  1. Identification of the problematic areas in teamwork (e.g. overloaded people, the need for internal knowledge transfers, communication issues) and providing improvements,
  2. Identification of the problematic areas in the used tools (e.g. illegible reports) and providing improvements,
  3. Building a transparent relationship with the customer,
  4. Quick response to problems in providing solutions for the tickets or updating them.

For supporters:

  1. Work prioritization for better time management,
  2. An easy indication of tickets that require quick response and are critical for the customer.

Work on SLA is more and more often a standard in our ServiceNow support services delivery. If you decide on this cooperation model, we always properly cater for it in the contract to the benefit of both your organization and SPOC.

Release Management in ServiceNow

Release Management in ServiceNow (and other cloud systems) is the key to success in implementing changes. It supports Change Management and organizes the process of uploading any modifications to the production environment.

Release Management – introduction

Release Management first requires a remote session with the customer to identify customer’s needs and expectations. Based on these, we make the following decisions:

  1. How often should the upload take place?
    Frequency can depend on change queue volume. We recommend a weekly basis to keep implementation continuity. However, if the customer wants to upload changes with a different frequency, we can adjust the plan.
  2. What is the best day of the week and time to upload the changes?
    To reduce the impact on the instance users, while choosing the best date and time, we consider different time zones and customer’s availability.
  3. How much time before release the customer should confirm upload of the change to the production instance?
    We highly encourage customers to test every change in the UAT state and confirm if it works properly or not. Moreover, we recommend to determine the final release scope 1 business day before the release date.
  4. What are the other expectations related to the process?
    We need to know what are the other suggestions and how we can include them in the process.

After the session with the customer and discussing all details, we can prepare a draft proposal of a process version. The customer reviews it, and either proposes own corrections or accepts the prepared plan.

Change Management

We group normal changes in releases. Incident resolution and urgent changes are uploaded to production as soon as possible to fix the system failure or implement a business-relevant modification. We use our version of Release Management in ServiceNow instance which is a very convenient tool to take control over the changes and keep the customer informed.

Releases should have a consistent naming convention. Every release should have a unique name, assigned person responsible for managing it on the SPOC side and set date. Every change request record has the “Release” field on the form to provide the proper release number. All changes within a release, can be checked in the release record from Related List.

Release & change planning

On our side, we can see release size based on changes estimates and developers involved in changes implementation. It’s good to plan releases at the beginning of the month, and organize them in the system to observe the delays that may affect the original plan.

The customer should early confirm all changes  in the UAT state, to make us able to upload it properly to the production instance. In case of confirmation delay, we recommend its upload in the next planned release.

If the customer finds any bug, our Maintenance & Development Team implements fixes as soon as possible, implementing the change in the next release. The fixes application time depends on issues complexity.

Release & change implementation

We upload all the changes in maintenance windows first agreed with the customer. Thus the instance users know when they can expect system modifications. If any changes in the release are not uploaded to the production instance, we move them to another release record.

Release reporting

The release manager on the SPOC side provides Release Notes to the customer. The notes contain information about the implemented changes, possible conflicts or issues, and the list of unimplemented changes with the reasons.

All information is visible on the ServiceNow instance – releases have states and fields providing customer with relevant information.

Benefits of Release Management

Release Management brings a number of benefits to each organization:

  1. We take control over changes uploaded to production instance what reduces the risk of unexpected incidents.
  2. We keep the customer informed. It generates the satisfaction – the customer knows which changes were implemented and which were not, knowing the reasons why that happened.
  3. Instance users know when they can expect changes in the system.
  4. If something happens, we can identify faster which change solution was the exact source of the issue.
  5. We can track which changes got stuck in states, e.g. UAT for a long time and speed up the customer’s actions.

Discuss your release management case