Best practices in duplicate issue management Service Desk

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

1 answer

1 accepted

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

 

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

 

 

 

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
 

Thank-you very much smile

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published yesterday in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

151 views 4 7
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you