What do companies do regarding SLAs and the transfer of Incidents between groups?

[degregod]

Looking for suggestions on how to handle SLAs when Incidents get transferred between groups.   Here is our process:   1st, An Incident is opened through the Helpdesk or Self Service   2nd, it is transferred to a Group.   Sometimes, however, it is transferred to the wrong Group.   Our SLA is based on: from the creation date to the closure date.  

So, for example, if the SLA for a Medium is 5 days (40 hours), and the Incident was erroneously transferred to an incorrect Group and after the 6th day that Group transfers it to the correct Group, the correct Group is receiving it after the SLA has already been breached and no matter what they do they cannot fulfill the SLA.  

Does anybody have suggestions on how they handle this within ServiceNow so that time spent in an incorrect Group is not counted against the correct Group?

[Brad Tilton]

Hi Dave,

The SLA is really an agreement between IT and the Business, and the end user doesn't really care who it's assigned to, so I don't think you would want to reset an SLA based on an incorrect assignment. You could, however, run some inactivity rules or something against an incident that has been reassigned to a group, but no one has taken ownership of it by adding themselves to the assigned to field. That might help your issue of it sitting in the wrong queue for too long.

[degregod]

Thanks for the quick reply.   You're right that the SLA is between IT and the Business, but Management is running Metrics against the SLAs and therefore Groups are being held accountable for meeting SLAs and the metrics are affected by cases where a Group doesn't even have the opportunity to meet the SLA.   In my search I did come across the Activity Monitor idea.

http://wiki.servicenow.com/index.php?title=Setting_Inactivity_Monitors#gsc.tab=0

Thanks for reinforcing that possibility.

[Brad Tilton]

I realize this is a lot easier said that done, but I think instead of trying to change your SLAs so the groups don't get dinged, you'd be better off long term trying to fix the root issue of incidents getting assigned to the wrong groups. I think inactivity monitors and setting up some reminders would be one way to do that. You might also try to flag incidents that were assigned to more than 2 groups using some sort of reassignment counter field and filter those out of your reports to management.

[mollyclark7]

I agree - I was a former customer and we ran into similar issues. I would recommend using breached SLAs as a sign that "something went wrong", not necessarily as a sign that "the resolver group did something wrong."

Report on reassignment count and try breaking that down by things like category/subcategory/affected CI (maybe some services are not well documented and require escalation too often, or escalation paths aren't clear? etc). You can also use metric definitions to automatically capture the amount of time an incident spent with each group.