Technical Services/Business Services in Incident management

[Kristoffer Pari]

Hi,

i have a case where ServiceNow is used purely for managing a Company internal Application needs. 

Users who report e.g. incidents are internal users or vendors. 

We would like to use service offering in some cases for users to choose when reporting incidents. 

Now the question is, should i use Technical Service offerings or Business Service offerings?

From different materials i have read, i get the understanding that Business Service Offerings are used mainly when you have a service that a company Sells and should only show the Business Impact for a incident? Are there any reason why a Business Service Offering  would be created for a internal Application if it is not related to any sold/provided customer faced service, and populated to the Service offering field on a incident?

Regards,
Kristoffer

[Kristoffer Pari]

Hi, as per ServiceNow, each Application should be related to a Technical Service Offering that indicates who is responsible of maintaining and supporting the Application Service (Application). As in this ServiceNow example, the Application itself is linked to a Technical Service Offering called ServiceNow Prod. This give you the Support group (Incident) and technical approval group (change) and other information such as Availability and SLA/OLA. 

My initial thought of this was that ok, then i get a lot of duplicate information as my Business Service Offerings are supported by the same teams, but after a lot of thinking this makes sense, as there might be cases where the actual Business Services are supported by a first line team for example. Also if you have a issue with the platform itself or a platform application, you need to have a technical service, as the issue is not directly linked to a specific Business Service Offering. In this case, the business service and offering are of course impacted. 

[Jonathan CABY]

Hi,

This topic is quite hard to understand, and it seems to me that there are lacks of information from ServiceNow.

I need to be sure if I understand it well, if you may help me.
It is possible that I will repeat things people have already said above. Apologies if so.

About Technical Services and Business Services:

• Business Services are used when an Incident is initiated for a Business user, means that they would have to select it in their Incident form, right ?
• Technical Services are used when an Incident is initiated by a Technical user.

In the Business user case, the Incident should never be reassociated to a Technical Service by an agent.

Could we use Service Offering to help with that?
I mean that Business users should have only subscribed to Business Service Offerings, right ?
So, if a Business user is not subscribed to any Technical Service Offering, an Incident for which he's the caller shouldn't be associable to a Technical Service, right?

More over, everybody is actually a Business User, even IT members. So everybody should have subscribed to a Business Service Offerings.
Only specific people could also be Technical Users that could have subscribed to Technical Service Offerings. (IT members, stakeholders,...)

So Technical Services should only be associable to Incidents for which the Caller has subscribed to a Technical Service Offering. Is that make sense?

About Support chain:

My company Group has currently a support chain based on a Level model, but it is not implemented in ServiceNow and we have a lot of issues to know to which group this or that Incident should be escalated to because this information is not in the platform. So we need to import this information, in a way or an other. And it seems that ServiceNow doesn't offer OOTB solutions for the Level model of support chain.

Our context is : we have first points of contact, expert teams and admin teams for several cases :

• for all the Group (by default)
• for some subsidiaries
• for a specific population
• for some localizations
• for some Business Services (Competence Centers)

How could the CSDM help us to manually or automatically assign Incidents?

I understand that when a Business User initiates an incident for himselft, selecting the Business Service he thinks that is impacted, the Incident would be assigned to the Business Service's Support Group.

How could we assure that Incident will be assigned to the right first point of contact, according to the Business User's company, population and localization?
Would the Business User also have to select the Business Service Offering in the Incident form to obtain the Business Service Offering's Support Group ?

Following that, if the agent of the first point of contact doesn't reach to solve the Incident (considering the Business Service selected by the Business User is the right one), what does the agent have to do to escalate the Incident to an expert team ? 

• Using leveled Business Service Offerings for each level of support ?
• Select a Configuration Item of the Business Service to obtain its Support Group ? (but the Support Group would be unique, not fitting with the Business User's context...)
• Something else ?

[Barry Kant]

Good day Jonathan,

there is an option that you can relate Business Service Offerings to Technical Service Offerings, which is used in Service Portfolio Managenent, and primarily used in Service Owner workspace. It is a concept of underpinning service, or a Service De-compositioning. It is not so much described in CSDM, however it is standard I would say.

I drafted the picture above to show it. 

If I have a ticket registered from a Business User and I am the agent the related downstream CI Relations show me the underpinning Technical Service Offerings. 

As an agent I would like to use the Support Groups of these Technical Service Offerings to route the ticket to next support parties. So it shows the support chain for this ticket. 

Why you shouldn't change the Offering in the Incident itself?

If you change the Offering from a Business Offering to a Technical Offering, then the SLA is cancelled. You will not have the SLM measurements you want. 

The other way is valid as well. How do you measure the OLAs/UCs in this way?

The easiest way is to use task tickets, as then it measures on a separate ticket.

You can also measure on a Assignment Group level, but I doubt if Windows Gold and Windows Bronze will have different support groups, so it needs more context for those measurements. 

I have not a final answer how to do best E2E SLM in a single record (SLA/OLA/UC) myself. 

This Service de-compositioning I use for the routing part espessially when the underlaying infrastructure is not of a mature/trustful state it allows me to offer agent a good routing option based on the content of the ticket.

Best regards,

Barry

[Jonathan CABY]

Thank you for your quick answer @Barry Kant 

We don't want to user Incident Tasks because the first points of contact are not the Single Points Of Contact. End users can be contacted by experts and admins if it is necessary, the first points of contact are not intermediate between them and the end users.

So the Incident record can be escalated, and OLAs have to be bounded to it.

I was thinking about the following :

A Business User creates an Incident for himself, and only the Business Service Offering is asked to him. We can admit that the Business Service should be also automatically selected in back-end.

With this first step, we can easily have the first point of contact with the help of the Service Offering dedicated to : the impacted Business Service and the context of the user (company and/or location and/or department,...).

An agent of the first point of contact takes the incident and performs a first diagnosis.

He could use the related CIs of the Business Service Offering to select the CI for the Incident.

I can say without any doubts that the related CIs of the Business Service Offering should only be those directly or indirectly related to the support of the specific need of this Business User.

Use case 1 : If the issue is about a bug on the Outlook client deployed on his computer, and no one else is impacted. The agent could have enough hability and authorization to solve by reinstalling the software.

The Configuration Item to select could be Outlook client, a Desktop Software class CI with no dedicated Support Group.
Why no dedicated Support Group ? Because this CI could be linked to other Business Service Offerings created for other Business Users who may have a different first point of contact.

Use case 2 : If the issue is about a bug on the Outlook client deployed on his computer, and some or all of his colleagues are impacted. The agent doesn't have enough hability or authorization to solve the Incident. The Incident must be escalated to the Packaging team.

The Configuration Item to select could be Outlook client package N°XXX, a Package class CI with a dedicated Support Group. The Support Group would be the Packaging team.

And if we have a different Outlook client package - deployed to other Business Users - supported by a different Packaging team, then we would need a dedicated CI for this package with this different Packaging team as Support Group.

We don't replace the Business Service Offering. We have the right first point of contact. We can escalate to specific Support Group with the CI.

[GailFrem]

I'm happy I found this thread. I currently live in Bruxelles, and I've got my Belgium dual citizenship two years ago. Our business is going pretty well here, but I must admit I have also encountered similar problems, and am still searching for a solution. These look like pretty good models, although they didn't bring me enough clarity regarding the difference between Technical and Business Services in incident management.
I liked the idea that the best starting point for an incident creation would be the application service.