Working with problem and incident tickets

Have more questions? Submit a request

73 Comments

  • Graeme Carmichael
    Comment actions Permalink

    Leander

    I would suggest it is safer to create a separate problem ticket. That keeps all your customer facing tickets as incidents. When you look at the incident tab, you are being consistent and all the customer incidents are listed there. There is nothing special about the fist customer that raises the ticket, so you do not want to be processing that ticket differently from all the other incidents.

    Having a separate problem ticket also allows you to make notes and reassignments without the risk of the customer being accidentally updated or notified of comments that may confuse them. It also gives you the option of different business rules and notifications for problem tickets. Again, you may want to keep these notifications internal.

    The risk of accidentally looping in the first customer can be higher if you CC users into the problem ticket.

    If you have Insights and are concerned about duplicate tickets,  you can exclude the problem ticket types from your counts.

    You can of course keep the problem ticket as the first ticket, but keeping it separate gives more options.

    1
  • Heather Rommel
    Comment actions Permalink

    Am I the only one that needs to be able to report out on not just the total number of incidents linked to a problem ticket but also their statuses? In a perfect world, we would solve the problem ticket and have it cascade down but our business process is that we check with each customer that our workaround and perm fix went in as expected, leaving us with some solved incidents, some pending incidents and some open incidents. We need to be able to easily report to managers what the current status is. I can't seem to create a view for this.  And there's no way to sort the incidents by status.

    Am I missing something?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Heather!

    I did some testing in my own Zendesk was able to create a View that will show these tickets, so you should definitely be able to do this as well. I've included some screenshots of how I built it.

    Here, you can see where I specified the ticket type, and which statuses should be shown:

     

    Here, I've grouped the tickets by status so they'll automatically be sorted, and then set so they're listed in order of what was most recently updated. Of course, you can adjust that part however you'd like.

     

    And here is what it'll look like in action.

    Let me know if you have any questions or problems!

    0
  • Heather Rommel
    Comment actions Permalink

    Hi Jesse, That's really helpful except it shows all incidents. I'm looking for a way to view all incidents linked to a particular Problem ticket. So, if we cannot reorder the list of Incidents when we are looking at the Problem ticket, I'm stuck with looking for a solution through creating a view.  The view you did is wonderful but it lacks the ability to identify 

    1) if it's linked to a problem ticket

    2) if linked to a problem ticket, what is the problem ticket number

    Otherwise, your view is essentially a list of all unsolved incident tickets which unfortunately doesn't narrow it down for us!

    Any other ideas?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Heather! Apologies if I misunderstood your initial question!

    I would say that your best bet would be to create a custom field that contains the problem ticket number, and then add that custom field to your view. Then you'll be able to either create a view for each problem ticket, or just sort by that field in your normal view.

    I know it's a pretty manual solution, but it sounds like you link all your tickets to problem tickets so it would be pretty easy to set up macros your agents can use to ensure that the field is populated correctly. It'd just need to be a drop-down field, rather than free-text.

    0
  • Dave Tonks
    Comment actions Permalink

    Sorry - this may have already been covered, but say you had a problem/root cause ticket (created by us), but we have a workaround in place - those tickets are incidents that get raised and solved as they come in.

    If we link those incident tickets to the problem ticket (to track impact), when it eventually gets solved by our Development Team, all the incidents linked to it (now closed), do they all get reopened? Or would the linked incidents only get updated when the comment/status of the problem ticket if they are still open?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hey Dave! Welcome to the Community, and thanks for the head-scratcher!

    I can say for certain that if you update that Problem ticket with an internal comment, nothing will happen with the Solved Incidents. 

    Outside of that, I'll need to do some testing on my end to see how this would work in action. I'll let you know what I figure out!

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Dave, just following up here.

    I tested this in my own instance with a Problem ticket that had a Solved incident, a Closed incident, and an On-Hold incident linked to it. I Solved the Problem ticket with a public comment; here's what happened:

    The Solved ticket was not updated. The ticket status was not changed. No public comment was added. No email notification was sent.

    Closed tickets can't be modified in any way, so in this case I was testing for a Follow-up ticket. A Follow-up ticket was not created. No email notification was sent.

    The On-hold ticket was updated as expected, and an email notification was sent.

    Based on this test, it looks like Solved or Closed incident tickets will not be re-opened and updated, nor will they generate any notification to the end-user.

    However, I would strongly recommend testing this in your production instance to make sure it behaves the same way for you. I did this testing with no custom fields, and only one custom trigger (which was used to immediately close one of the incidents for testing, prior to solving thre problem ticket). Depending on your set up your mileage may vary.

    Let me know if you have any other questions!

    1
  • Dave Tonks
    Comment actions Permalink

    This is really useful Jessie, thankyou very much for investigating! As suggested I'll check this on our own environment, but if successful it means we can do a lot more with tracking repeat incidents.

     

    Thanks again!

    Dave.

    0
  • Ramon Martínez
    Comment actions Permalink

    Hi,

    Something I have been trying to do lately is see whether when you solve a problem ticket, tags get propagated to the incident tickets and I have found it is not the case.

    Is it that the case? Am I missing something?

    Best,

    Ramon

    0
  • Jimmy Rufo
    Comment actions Permalink

    Why can't we just link incident tickets to other incidents, and be able to show the link within each ticket?  Thats low hanging fruit that Zendesk has never been able to implement.  See Atlassian JIRA functionality regarding what I'm talking about.

    0
  • Nicole - Community Manager
    Comment actions Permalink

    Hey Jimmy - 

    I'm not sure I understand what you mean. Can you give an example of your use case? 

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Ramon!

    You're correct: when you solve a Problem ticket, the public comment is inherited and the status of each incident is changed to Solved, but no other ticket attributes are inherited. Is there a particular workflow you're trying to accomplish?

    0
  • Aswin Kannan
    Comment actions Permalink

    How to ensure that Incident tickets are not solved without linking to a Problem? Is there a report I can create in Insights to find out the Incident tickets without a Problem linked to them?

    0
  • Aswin Kannan
    Comment actions Permalink

    Another thing. I want to bifurcate the Problem tickets into two:

    1. Problem with Incidents
    2. Problem without Incidents

    I cannot figure out how to do this in Insights. Can someone help?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Aswin!

    We'll need to see about getting an Insights expert in here to see how to report on that information. I'll try to get someone in here ASAP.

    As far as making sure an Incident isn't solved without being attached to a Problem...you could create a trigger that adds an "incident" tag when a ticket type is updated to Incident, and then a second trigger that tests for that tag and re-opens the ticket when it's set to Solved when the tag is present. When the ticket is re-opened, you could add a private note remind the agent to select a Problem from the list and change the status to On-hold, or change the ticket type if it's not actually an Incident.

    There are a couple sticky parts to this though. Firstly, there's no way for a trigger to actually test for whether a Problem ticket has been selected from the dropdown on an Incident. Secondly, you'd need to figure out how and when to remove the "incident" tag so it doesn't get re-opened when the Incident is solved with the Problem ticket. You'll want to take that into consideration...it might require some macros and custom fields. 

     

     

    0
  • Dan Cooper
    Comment actions Permalink

    Hi Aswin, 

    The simplest way I can think of to show Problems with Incidents and Problems without would be to build the following report: 

    What: 

    # Incidents

    How: 

    Ticket Problem

    Filter:

    Ticket Type | Is | Problem, Incident

     

    Then sort the # Incidents column to show the highest value at the top. This would include all problems, but at some point in the report the # incidents would change to 0.  If you needed a clear divide, you could create two reports and on the second add to your filter a numeric filter that is set to look at Ticket Problems where the # Incidents is equal to 0. 

     

     

    0
  • Aswin Kannan
    Comment actions Permalink

    Hi Daniel - I have tried that, but I cannot do it channel-wise. I've found another workaround by adding tags and triggers, and now I'm reporting using tags. It works as expected, but still I think it'd be easier do to this via Zendesk Insights.

    For Incidents that are Solved without a Problem ticket, I'm running a report everyday and talking to the agents to eradicate that practice gradually.

    0
  • Dan Cooper
    Comment actions Permalink

    You could potentially add Ticket via under How to give you the channel (assuming you just mean web, email, api, etc).  

    0
  • Graeme Carmichael
    Comment actions Permalink

    Gurunn

    Rather than click the down arrow, you need to click on the Edit X ticket(s) part:

    0
  • Heather Rommel
    Comment actions Permalink

    To be fair, if you have more than 30 incidents, you'll need to select and edit all on each screen of 30 incidents. Next page, next page, next page....

    0
  • Gurunn
    Comment actions Permalink

    Thanks for the clarification Graeme. I just figured it out after I had posted the comment :)

    0
  • Eitan Blumin
    Comment actions Permalink

    Hi,

    I would like to ask how should we combine our usage of Incidents & Problems, with our SLA policies?

    Let's say, for example, that we have SLA set up with a certain maximum time between replies.
    When we link an incident to a problem ticket, my assumption is that we're expected to work on the Problem ticket from that point on. Posting comments, updates, and so on.

    But other than the eventual solving of the Problem ticket, nothing is propagated to the linked incidents. So, as a result, these incident tickets breach their SLA (because they're not being updated - the Problem tickets are being updated instead).

    I hoped that there's a way to make SLA ignore incident tickets that were linked to a problem, but unfortunately, I found no way to add such a filter.

    Not as a trigger either. I couldn't find any built-in automated way to identify whether an incident ticket is linked to a problem or not.

    Closest thing we could do at this point is add a Macro that adds a tag to the incident ticket, which then the SLA filter can ignore. But this hardly feels like the right way to go about this.

    Is there a better / more correct way to make this work?

    Thanks

    0
  • Ricky Davis
    Comment actions Permalink

    Hey, Eitan!

    I hope all is well.

    You can work on Incident tickets that are linked from within the Problem ticket itself! To access this area, click on the Incidents tab in the Problem ticket:

    This will allow you to make updates to those tickets while updating your SLAs to not breach (or add tags so the SLA is ignored). You can even update the entire list as bulk!

    This should help with locating incidents and avoiding SLA breaches. I hope you find it useful!

    0
  • Samer Najjar
    Comment actions Permalink

    Hello,


    Would this work in the instance of having our Level 2 support creating a problem ticket then allowing all Level 1 agents that receive calls to that Problem ticket. Then once the issue is resolved and the Level 2 agents send an email closing out the problem ticket and the level 1 agents dont have to touch it after that? Or does it work on a person by person basis? We also would not want our Level 1 reps creating a Problem ticket. Only Team Leads and Level 2 Care employees. I appreciate the help.

    0
  • Patrick Bosmans
    Comment actions Permalink

    Hello Samer,

     

    Yes, you could have the Problem Ticket be solved by the Level 2 agent and all incidents, that may be held by Level 1 agents, connected to the Problem ticket will close out with one last update from the Problem Ticket.  

    With this workflow, your Level 1 agents can still update the requesters as necessary, and work the incidents as would be required,

    0
  • Jaïs Pingouroux
    Comment actions Permalink

    Hi folks,

    I was wondering if it was possible to copy custom fields (or apply some tags) to all incidents linked with a problem upon solving the problem?

    I was a sub-status custom field and when I solve a problem with incidents attached, I'd like the same custom field to be applied to all the attached incidents. Is that possible?

    0
  • Jessie Schutz
    Comment actions Permalink

    Hi Jaïs!

    I would think you'd be able to do this with a trigger. Setting it up with conditions of Type > is > Incident and Status > changed to > Solved and then indicating what the custom fields should be in the action section should get you where you need to go.

    0
  • Jaïs Pingouroux
    Comment actions Permalink

    Hi Jessie, thanks for your answer, but I don't think it works.

    If I do this, the trigger will SET the custom field to a defined value not based on the parent problem value.

    Writing several triggers would not work either for there doesn't seem to be a condition where I can access the custom field value of the parent problem for an incident.

    Do you see what I mean?

    0
  • Brett - Community Manager
    Comment actions Permalink

    Hi Jaïs,

    Thanks for the clarification! As it turns out, there's no way to set ticket fields based off ticket fields set within another ticket on your account. This includes incidents attached to problem tickets. These fields would need to be manually set by the agents on the account or through a trigger based on conditions within that particular ticket.

    Let us know if you have any other questions for us!

    1

Please sign in to leave a comment.

Powered by Zendesk