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 · Accepted solution]

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

[Nicole Geske]

Wow Phil that was great information and was super helpful! Are you able to give me insight on managing duplicate issues on the service desk. For example:

Cust A, org F submits issue #1

Cust B, org F submits issue #2

Cust C, org G submits issue #3

All issues are duplicates of each other. 

Scenario 1.

• There are no concerns with all customers seeing the issue all together
• So: Mark all issues as duplicated, close two of them, leave the one customer as the reporter and put the two cust's as request participants on the one issue?

Scenario 2.

• Cust A and B are okay to see the joint issue but Cust C is not (but all issues are still duplicates)
• So: Mark them all as duplicates, close either issue #2 and add request participant to issue #1, then still manage #1 and #3 individually? 
  • Is there a better way to manage this?

Thoughts, feedback?

Thanks again!

Nicole

[Phill Fox]

Hi Nicole 

I would approach this slightly different to your two scenarios (as I tried to explain in my earlier answer). I would treat each report as an Incident and create a Problem ticket from the first one reported and then link the other 2 Incidents to the Problem ticket. 

So you would then have.
Incident 1 (Cust A, Org F)  create Problem 1

Incident 2 (Cust B, Org F)  link to Problem 1

Incident 3 (Cust C, Org G)  link to Problem 1

Now you set your permissions correctly and customers in the same organisation will be able to see each others linked Incidents on the Problem ticket but not see the linked ticket for other organisations.

So Org F would see Problem 1 with two links Incident 1 and 2
and Org G would see problem 1 with one link Incident 3

You would allow your resolution team and JSD agents to see all links.

I hope this helps clarify the scenario for you, if it does please accept my answer so that others will find it easily when searching for similar situations.

Phill
 

[Nicole Geske]

Thank-you very much 

[Lindsay Siurna]

Thanks Phil.  This was very helpful!  Who would you use as the reporter for the problem ticket?  The first person who reported Org F or someone from your own company?