Re-routing Incident from L1 support to L2/L3 tech support - CSDM considerations

[Tom Sienkiewicz]

Hi Folks,

I'm wondering about the preferred way to route INCs to L2/L3 support. I would appreciate some feedback on the recommended setup as there seem to be multiple ways of handling it.

 Imagine an INC created by an end user. The end user specifies the impacted Service Offering. The Offering would be linked to a Team for L1 support. On the INC form, We have Business Service Offering as well as Business Service auto-populated in the respective fields. 

L2/L3 support Teams would be linked to Technical Service Offerings / CIs (mapped through Tech Service Offering/ Dynamic Group).

Now, we need to reroute this INC to L2/L3 tech support. I tried to list multiple options here with some pros/cons:

#	Setup	Pros	Cons
1	Create additional fields on INC form for Technical Service and TSO, populating those changes assignment to respective L2/L3 group	We get to keep original BS/BSO for reporting. TS/TSO is available on the form for easy reporting as well.	Adding custom fields to INC. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
2	Replace BS/BSO with TS/TSO in OOTB fields	no custom fields required, less cluttered form	We lose the BS/BSO information for easy reporting (still there's Impacted Services related list). Difficult to restrict selection of the TS/TSO that way. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
3	Manual reassignment. Do not replace BS/BSO and do not select TS/TSO, but leverage CSDM relationships to determine fitting TSO/Support group manually.	No custom fields needed We keep original BS/BSO for reporting	Manual lookup required by the Agent. We lose original assignment group from INC, need to make sure INC will be assigned back to L1 before resolution.
4	Rely on CI field for L2/L3 assignment	BS/BSO fields stay intact. Best practice says always try to have CI populated (if not automatically, then by L1 agent). It will be consistent with INC created with CI (e.g. from monitoring).	It would be difficult to route to L2/L3 if the precise CI is not known (although perhaps App Service could be a good substitute in such cases). Requires to control the reassignment back to L1 etc.
5	Leverage INC Tasks. Leave the parent INC with BS/BSO, create INC Task for L2/L3 team, put TS/TSO in the fields of that INC Task which will assign it automatically	Original INC contains BS/BSO data for easy reporting. INC stays with L1 group the whole time, no need to control reassignments. INC Task contains clear TS/TSO data.	A lot of additional setup complexity (syncing with parent INC). Seems "redundant" considering CI field. Also would make "monitoring" scenarios harder to setup (possibly having to create INC task/INC at the same time).

I'm personally leaning towards #4 (through CI, my most preferred option) or #5 (INC tasks).

How do you have this set up? Is there another option that I missed?

One additional question that I have is: what is the best way to narrow down "selectable" TSO on the Incident, would it be via BSO->lots of stuff->TSO relationships, or better via CI->Dynamic Group->TSO / CI -> App Service -> TSO relationship? Is the svc_ci_assoc table a good starting point for those lookups? Would it normally contain BS/TS/BSO/TSO or only "Infrastructure" CIs?

Many thanks!

[Mathew Hillyard]

Hi @Tom Sienkiewicz 

I too think option 4 looks the easiest. This is where the Teams related list on a CI gives you the flexibility to have many different types of support or accountability; indeed it’s a part of CSDM 5 as SN has recognised that a few reference fields on the CI form don’t suffice in more complex support situations. If the causal Vi is not entered, then you need to establish a way that support can be calculated - either through an App Service/Service Instance or a Service Offering. This does of course depend on support groups being populated across the CMDB.

I’d first of all establish the support model and incident process to work out what service fields should be mandatory or read only and therefor what information is required (see the incident leading practices blog post for an example, although your use case may need a different approach depending on what incident management does: https://www.servicenow.com/community/itsm-articles/how-to-configure-incident-management-to-align-wit....

 A final note: the fields on the incident form are not business or technical; they’re open so you can choose either when creating an incident. There are some who believe all incidents should refer to the technical but I don’t subscribe to that view as I think it is limiting and may result in a confusing and hard to understand pair of service portfolios, but ultimately the platform lets you build either way.

I hope this helps!

Mat

[Tom Sienkiewicz]

Thanks @Mathew Hillyard, I appreciate your input as always!

And yes I also think the Incident fields should not be restricted to technical service/offerings only, as when exposing the INC form to end users, we may want to also allow them to select the Business Service Offering affected, this would drive the initial routing. It cannot be expected from end users to understand the technical portfolio, and we also do not want all tickets to have to go through Service Desk first.

[Barry Kant]

I go agree, to add to that:

It might depend on how your operational model is, but the process itself is open.
I normally explain it this way:
There are incidents that are initiated from a consumer point of view (reactive tickets if you will) and I expect those to be created against a Business Offering as that includes the consumer agreements. 
There are also tickets that are initiated by a technical entry point (2nd line, monitoring, third-party). I would expect those to be created against a Technical Offering, as that includes the provider agreements. 
If the process would be dynamic it might be done via channels:
Monitoring -> TSO
2nd-line -> TSO
Self-service -> BSO
Walk-in -> BSO
Email -> BSO
Chat -> BSO
...
That would be an option to direct/filter the offerings, but again the ootb is open. 

BR,
Barry

[Tom Sienkiewicz]

Thanks Barry, good to have your opinion!