Best practices in duplicate issue management Service Desk

Nicole Geske

If there are multiple issues submitted to the Service Desk with different reporters - how is this best managed? Some times it would be okay for reporters to see each others requests, but not always, depends on the nature of the request. Any help would be appreciated. Perhaps there is some existing documentation or customer who has shared their best practices. 

TIA,

Nicole

Phill Fox

Hi Nicole Geske

If you follow the ITIL principles then each issue submitted to the Service Desk is an Incident which will be resolved with an appropriate timescale. The resolution can be a simple fix, a workaround, a link to an existing known Problem or the creation of a new known Problem.

I would use the two different issuetypes to handle this. 

1. Incidents - raised by customers through JIRA Service Desk
2. Problems - used by the resolution team to track progress on resolution

Once you have these set up then it is simple to handle the two different timescales for resolution independently. You can then decide whether you will allow the reporters to see the problem ticket and also which linked incidents they can see. I would however suggest that it also makes sense to consider automated actions to copy messages from the Problem ticket back to all the linked Incidents using the JSD automation functionality.

You can further extend this principle to have a third issuetype - Remedial Action to split out the actions needed to correct data or processes that have been impacted by the problem; again allowing this resolution to take place against a different timescale. 

So putting all of that in to context here is what could happen for an escalating incident where a workaround is identified prior to resolution.

1. First Incident is reported
2. Triage team check against known problems and do not find it. Nor do they know a simple fix/workaround
3. Triage team raise a new Problem ticket and link to the 1st Incident ticket.
4. Second (and subesquent) Incident is reported. This is linked to the existing Problem ticket.
5. Resolution team have now started working on the Problem ticket. They identify a workaround for the problem and publish this on the Problem ticket. This workaround is then automatically updated on all linked Incidents. With the workaround it may be possible to close the Incident ticket(s) as the user now has a means of avoiding the problem.
6. Resolution team now identify some Remedial Action and raise the Remedial Action ticket. This is linked to the Problem ticket.
7. The Problem ticket is now completed and can be scheduled for release and closure.
8. The Remedial Action ticket can now be actioned following the resolution of the underpinning Problem.

Clearly this is just one example of what could happen but I hope it provides a flow for managing different types of activity with different timelines using JIRA and the power of Issuetypes; issue links and the automation of JSD.

 

Phill