Using incident tasks vs child incidents for incident management and multiple vendors are involved?

[Suggy]

Hello,

The customer has outsourced their IT support and operations to two vendors/service providers.

There are some applications for which certain troubleshooting scenarios can be handled by "Vendor/service provider 1". Sometimes they would need further investigation  to be done by "vendor/service provider 2" or additional info would be required by "vendor/service provider 2".

In this case how the incident should be handled?

Available options

Reassign the incident from "vendor/service provider 1"  to "vendor/service provider 2"?

or

use incident task?

or

create child incident?

or

any other solution?

[Uncle Rob]

This is the vital essence of why Incident Tasks were created.

You keep ownership of the Incident with your core team.  This is especially critical if multiple parties will be involved.  YOU need maximal accountability to your customer.  YOU need to be orchestrating activity between the vendors as you can't count on them to do it for you.
So send Incident Tasks out to any and all sub-components of work, be that vendors or other internal teams.

Make sure you get your OLAs defined well!

[Suggy]

Hi @Uncle Rob In the scenario that I have described, its about two different service providers involved. 

Incident lies with 'Service provider one'..

When they need more info from 'Service provider two', you are suggesting to create the incident task and assign to them right? In this case, it shouldnt be OLA right? It should either be SLA or UC correct?

[Uncle Rob]

I still think whomever is interfacing with the end consumer needs the Incident.  Everything subservient to that incident is an incident_task (assuming we're not dealing with systems integrations here).  SLAs, OLAs, UCs shouldn't care what task type it is.  

SLAs are between an organization and the consumer.  If that agreement requires involvement of other parties, that's where OLAs come in.  Sum of the OLAs necessary to deliver the service = SLA.
Nobody has any business building an SLA without first considering OLAs for other teams involved.

[Suggy]

One of the blog says not to use Incident task for such situations 🙂

https://plat4mation.com/blog/non-sense-incident-tasks/#:~:text=In%20heavily%20customized%20instances....

I understand it has got its own pros and cons.

If anyone has got any experience around this topic, please do share!!!

Thanks in advance 🙂

[Uncle Rob · Accepted solution]

I have a ton of respect for the author and company, but there's a LOT of stuff in that article which is opinion stated as fact, without backup.  Also understand, they're not providing you an alternative for your scenario... so its only looking at the costs and not the benefits.

I have experience here and while the author is right... Incident Tasks DO have more administrative load, that doesn't make them de facto inefficient.  It really depends on what you're optimizing for.

In the scenario you describe there are multiple separately assignable components of work, each with their own states.  That is *exactly* what Incident Task was created for.