Parent and Child ticket defintions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-22-2014 08:50 AM
Sometimes the classification of an incidnet ticket as a parent or a child ticket can get a little squishy. Does anybody have a clear and concise definiton they use for each?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-11-2015 04:18 PM
Steve,
There are a number of different misconceptions about what the definition is between parent and child incidents and different organizations define them differently. Leading practice by mature organizations and my recommendation is to define a child incident as an incident that needs to be resolved before another incident can be resolved / closed. Confused?
Let me give you an example: Susie Sample calls your service desk because an on-premise hosted application is down and she isn't able to access it. After the service desk troubleshoots and confirms the issue is not access related and determines it is an application issue they would escalate to the application support team. The application support team looks at the incident and realizes one of the servers is down. In order to troubleshoot the server they rely on the server team to fix the server. They open an incident to the server team to restore the server service (this incident would be the child incident to the parent incident Susie Sample reported). Many organizations would reroute the original incident (this is not a good practice). Once the server team has restored service they resolve the incident, the application team can confirm resolution and the child incident can be closed. The application team can then contact Susie and ensure she is able to log into the application and continue her work. She confirms she is back up and running and the application team can resolve the parent incident. Susie can confirm resolution and the incident can be closed.
There is also the idea of duplicate incidents. Say after Susie calls, 40 more people call about this application issue. These would be considered duplicates and the sheer quantity might cause an escalation in the impact / urgency of the incident. These incidents could be related as duplicates or the callers could be informed it is a known issue and marked as duplicated and closed right away be the service desk. This process would need to be dictated in your incident management process and many organizations handle this differently.
John
