Workflow and ServiceDesk Community

 View Only
  • 1.  Question about SLA Breach Escalation

    Posted Jan 21, 2013 10:11 PM

    The managers in my DEV department want to have the following set up...4 groups, DEVQ, DEV 1, DEV 2, and DEV 3.  There are two managers and they both want to be in the DEVQ group.  After the tickets are triaged by Support, they want any ticket going to a DEV team to be assigned to the DEVQ group and then they will assign out to DEV 1, DEV 2 and DEV 3. If a ticket is not picked up by a developer and the SLA is reached for that group, then they want the ticket to be escalated BACK to DEVQ.  I am not sure if SD will work this way and thus is my question, does anyone know if it can?  My suggestion 8is to have another group (DEV Managers) created and use that group to escalate to in case of SLA breaches.  Going back to DEVQ seems more like a DE-escalation to me, but this is teh behavior being requested.

    Thoughts \ Suggestions?

     

    Thank You



  • 2.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 08:59 AM

    I'll preface this with "I am not an ITIL expert" just to make it clear that I could be way off base from that point of view.

    If this is the process in your organization, then that's what SD should do. Is it a bit odd, yes, I think so. I think my big question is why isn't support just assign the ticket to one of the dev groups based on some standard factor (e.g., number of existing assigned tickets). Why is DEVQ getting involved at the beginning? That seems a bit like micromanagement to me.



  • 3.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 10:21 AM

    I hear ya, however the DEV managers want to be able to assign out the tickets based on the specific skill sets for each of the developers, hence the need for a DEVQ group.  Support will assign any DEV ticket to the DEVQ, but then the managers will assess the issue and assign out to the developers based on the issue\skill set match. 



  • 4.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 11:08 AM

    That seems reasonable. I tend to think of escalations as maybe not elevating to another level per se, but as a way to make sure that a ticket is completed in a timely manner. I'm sure that's not ITIL compliant, but if you think of it that way, the process of going back to the managers will ensure that the work gets done. If this is what they want/need for their workflow, I can think of worse things.



  • 5.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 11:52 AM

    True, and yeah, we are not sticking to the ITIL format to the letter as well.  I was just curious to know if anyone has tried going from one group, then assign to another and if it breaches SLA then send it back to the original group.  It still makes more sence to me to send UP to a manager group than BACK to a Q group, but we will try,  Our implementation is still an infant, we just got SD installed and I am in the process of creating the groups and assigning members now, so no tickets are present.  Its nice to have the ability to test some things at this stage, what I don't want is to go live and have workflows stuck in infinite loops due to a situation like this, which I could easliy see happneing smiley



  • 6.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 12:45 PM

    As far as functionality, yes, I've done exactly this and it worked for me. Granted that was SD 7.1, but I wouldn't expect a change in 7.5.



  • 7.  RE: Question about SLA Breach Escalation

    Posted Jan 22, 2013 12:50 PM

    Great, we will give it a try.  Thank you Michael, much appreciated for all the input.