ServiceNow Handover - AMS Part 2

[Gaurav Bajaj]

In previous blog, we covered few aspects of AMS functions, let’s talk about additional few things to consider.

• ServiceNow as the Support Channel

A common mistake after go-live is forgetting that ServiceNow should also be ready to support itself. By the time the project team steps back, the platform should already be set up so AMS can receive incidents related to ServiceNow, handle service requests such as user access or role assignments, and process change requests for platform fixes or enhancements.

Here is list of few things to consider.

• Incident management to setup with required categories and subcategories related to ServiceNow platform support.
• Business Services, service offering and application services to be created to ServiceNow instances in accordance with CSDM guidelines to maintain consistency with other business services and applications.
• Portal request for ServiceNow support issues needs to be in place before Go-Live. This could be a standalone request or managed with categories on a generic incident request.
• Support Groups need to be in place with required roles and access provisioned for L1-L3 Teams across various instances from development to production.
• A set of service requests needs to be also created to Support most common service request requiring ServiceNow AMS team support. Some of most common ones are – access provisioning, password reset, data and report generation request etc. Also ensure that these services are routed to desired team to work on them without triaging and assignment turnaround times.
• A dedicated knowledge base to created for Support teams so that they can review required information as well as create new knowledge articles during the incident resolution.

• Reporting & Metrics

Tracking how the AMS team is performing is critical for the success of the ServiceNow platform. Without proper visibility, it’s hard to know whether the team is meeting expectations, where bottlenecks exist, or how the platform is benefiting the business. That’s why it’s important to define and set up reporting needs before AMS operations begin.

• SLA Commitments and Compliance
  ServiceNow tickets—whether incidents, requests, or changes—are usually tied to Service Level Agreements. For example, critical incidents may need a response within 15 minutes and resolution within 2 hours, while standard access requests might be expected within 2 business days. AMS needs clear SLA definitions agreed with ServiceNow, along with dashboards that show compliance. This ensures accountability and gives early warning when SLAs are at risk of being breached.

• AMS Operational Dashboard
  Operational dashboards are designed for the AMS support team to run their day-to-day work. These dashboards should display the number of open incidents and requests, highlight SLA breaches and tickets at risk, show aging tickets that have been idle too long, and provide visibility into ServiceNow-related issues such as user access or workflow failures. A well-structured operational dashboard acts like a cockpit, helping AMS prioritize their workload and stay ahead of problems.

• AMS Executive Dashboard

While the support team needs detail, executives need a higher-level view. Executive dashboards focus on KPIs that show overall performance and value—incident resolution trends, SLA compliance percentages, request fulfillment rates, and change success rates. These dashboards help leadership understand whether ServiceNow is stable, whether the AMS team is effective, and whether the business is getting the value it expected from the platform. They are essential for building trust between IT operations and business stakeholders.

Above dashboard can be utilized during monthly steerco meetings to showcase AMS performance.

• Post-Go-Live Support

Post-go-live support should be treated as a phased transition, giving the AMS team time to build confidence before they fully take control.

The first phase is Hypercare, typically lasting two to four weeks immediately after go-live. During this time, the project team provides extra support: critical issues get priority, response times are faster, and the business has reassurance that any bumps will be quickly addressed.

The next phase is Stabilization, where the focus shifts from reactive support to steady-state operations. The AMS team gradually takes over managing incidents, requests, and changes, while the project team observes and provides guidance. This phase includes shadowing, where AMS watches and learns from the project team, and reverse-shadowing, where AMS starts taking the lead while the project team monitors gaps. This combined approach ensures AMS gains confidence and practical experience while maintaining system stability.

By the end of the stabilization phase, the AMS team has managed real tickets, resolved issues under guidance, and demonstrated they can operate the platform independently. At this point, ownership can be fully handed over.

         At the end, there are multiple other areas to ensure platform governance, updates, patching and managing backlogs and demands. We have only covered a few areas which need to be in place before we plan to transition to AMS.