Feature Request: Tiered Support Models

Not Yet Reviewed

There are two primary ways that support teams operate. They are:

  1. Tiered Support Teams, i.e. Tier 1, Tier 2, Tier 3/Level 1, Level 2, Level 3

  2. Swarming, i.e. Find the right person, and that person engages all the other people that are needed as needed

For all intents and purposes, enterprises typically favor a Tiered Support model as it allows for better management and organization.

Currently, within xM, the only way to configure this is to embed the Tiered Support designation into the Group name itself, i.e. Firewall-Tier-1, Firewall-Tier-2, etc.

This raises some initial issues such as:

  • Since the group names have the tier designation, there exists the possibility that lower tiers of support will not be enagaged because there is a perception that the incident requires a higher tier of support

  • Currently, there are no ways for a lower tier group to “engage” their higher tiers of support. Lack empowerment.

For this enhancement, there are a number of prerequisites and features to enable a Tiered Support model.

  • There needs to be a concept of a Team. A team then is comprised of a group of individual Support Groups.

  • Support Groups need to have tags to identify the tier of support.

  • When an event is triggered for a support group, that event needs to have a way to “escalate” to higher tiers of support within the Team

  • RBAC needs to be in place to ensure that higher tiers of support cannot be directly engaged, i.e. an event triggered directly to that group, unless the person making the request is already in the Team (any tier of support) or in an Incident Manager/Commander role. The intent here is to prevent bypass by anyone outside of the Team or who would have a role as an Incident Manager/Commander.

  • Reporting needs to be possible to indicate the time between when the lower tier if support is engaged to when they trigger an event to a higher tier of support.

  • Would need to be able to seamlessly integrate with common CRM tools like serviceNOW as it relates to support groups, how they are organized, and how they can be kept in sync with xM.

The concept of a Team would be laid out similarly to:

Firewall (Team)

– Support (Tier 1 tag)

– SME (Tier 2 tag)

– Developer (Tier 3 tag)

– Management (Tier 4 tag)

From a process flow, any incident can be allowed to “page out” any Team’s group that has a “Tier 1” tag. They can see the other groups, but would not be able to directly page them.

The Tier 1 group once they receive the page, can decide if they are able to resolve the issue or if they need to engage higher tiers of support. From the event that they responded to, there should be an option to “Escalate to….” that gets automatically populated based on the Team’s groups and the tiers that they have specified. That Tier 1 group can then “page out” any of their higher tiers of support. This creates a culture where we are empowering our first lines of support to have the tools to resolve any issue--even if that means bringing in others to support a resolution.

As an incident manager/commander, you now have more capabilities to understand the various types of resources that are part of a Team. This gives you the ability to page out specifically the Developer group of resources, or the management tier if there needs to be representation or decisions made that the lower tiers of support cannot provide.



Date Votes

Please sign in to leave a comment.

  • Hi George - we are looking into this request and how it would play with our current behaviors.

    We are currently redoing our on-call scheduling and are working with customers on changes to the existing UI, as well as some new "end of escalation behaviors" and on/off duty designation.

    My initial take of your request is that while it is related to on-call scheduling, it is a new concept that sits above our on-call scheduling. The escalations that are expected to happen within the on-call scheduling would exist within a tier. And the new concept (let's call it "Support Process") would be a new item that is essentially a linked list of groups, starting with your first tier and continuing to your final tier. We handle the usual automated escalation across the on-call resources in the group within the tier. And users within the tier and other designated users would be able to push an alert to a higher tier when they deem it necessary.

    Does that track?

  • Doug, you are correct, this is separate from the work that you are doing with on-call scheduling; however, the "end of escalation behaviors" is a required change in order to support an "escalation by the responder to their next level support for the same INC". 

    I think that tracks. The outcomes we want to support are:

    • If I'm an incident manager, I need to know what your higher tiers of support are up to and including your backstop, aka some manager or executive team that is ultimately accountable, as well as being able to engage those higher tiers if I have appropriate RBAC or that I am in that "chain of escalation". 
    • As a manager, I need to empower my first line of support to make informed decisions on when they need to involve more people
    • As a data analyst, I need to have a better way to view the lifecycle of an incident from when a group was paged, to when we got to the right person to restore the incident and all the events in-between

    The last bit would be to ensure that we have solid integration plans with popular platforms such as Salesforce/ServiceNOW so that how groups are organized there to ensure that bi-directional CRUD operations can occur leveraging native capabilities in both systems. 


Didn't find what you were looking for?

New post