Incident Management in Technical and Business Services.

[Simpletch]

Hello,

I have a scenario where ServiceNow is solely utilized for managing the internal application requirements of a company.

The individuals reporting incidents are either internal users or vendors.

We are considering implementing service offerings for users to select from when reporting incidents.

Now, the question arises: should we opt for Technical Service offerings or Business Service offerings?

Based on various sources I've reviewed, it seems that Business Service Offerings are primarily employed when a company provides a service for sale and should only reflect the business impact of an incident. Are there any reasons why a Business Service Offering would be established for an internal application that is not associated with any service sold or provided to customers, and then populated into the Service Offering field when reporting an incident?

Thanks.

[SteveMacWWT]

Business Services & Offerings are not meant solely for providing a service for sale. These can be internal business processes as well. This would include Services, say, that HR, Facilities, or Accounting provide. 

Technical Services & Offerings are focused towards the services that IT provides for operating technology systems. 

(This is a very broad simplification, meant to get to what I believe to be the heart of Simpletech's question.)

[Barry Kant]

You can use Business Offerings as well as Technical Offerings. 
1 - Technical Offerings would eg be used when a Technical Support operator creates an Incident to work on (eg they identified an issue in a monitoring solution and made a ticket to work on it). The operators manage the IT solutions. Commitments on these offerings are about support agreements with the support teams.


2 - Business Offerings would be used by employees that consume the IT solution. I experience an issue and want to raise a ticket. Commitments on these offerings are about support agreements with the consuming parties.

BR,
Barry

[Kevin Clark1]

Hi, just digging up this random thread.  Let's say an end user has raised an incident with Business Offering which is assigned to the relevant group who owns that service.  Upon investigation, they discover that an underlying technical offering has an issue that is causing the user's incident and require the Technical Service team to do something to investigate or help resolve.    In my mental model, the incident remains with the group who owns the Business Offering (tracking the SLA and commitments of the Business offering) and then spawns some other record (incident task?) to trigger the Technical Offerings activities required to resolve the original incident.  .

[Rob Akershoek]

Yes, the use of Incident Tasks in this case would be the best way forward.  The incident is recorded against the business service offering, with the associated SLA. Assuming this is the correct service offering the incident should stay on this offering. This SLA should be monitored end-to-end till resolution.

An incident task is created to the related technical service offering (e.g. RHEL hosting) to resolve the platform issue. This incident task is assigned to the responsible platform team /group which is defined on this technical service offering with the associated task SLA. 

This way you can monitor the SLA of the "team" responsible for the technical service (e.g. response SLA) and the end-to-end SLA on the business service offering.