Working with problem and incident tickets Follow

Comments

31 comments

  • Avatar
    Jessie Schutz

    Hey Adam! Thanks for clarifying.

    If you update the problem ticket and do not set the status to solved, the incident tickets won't be updated. However, you can bulk update your incidents really easily.

    In your problem ticket, you'll see a button at the top with the number of linked incidents in red. If you click on that, it'll take you to a list of all the incidents. You can select all of them (or 100 at a time if there are a large number of them), and click the black Edit Tickets button in the upper right corner of the screen. From here, you can type one update and have it applied to all the incidents, without having to change the status on anything.

    Let me know if you have any other questions!

  • Avatar
    Kelly D (Edited )

    I'd love for "Problems" to be immediately publishable/viewable from the help centre or community. A live "service status" or "issues" feed is important for transparency with customers. We seem to be able to get close to this using a market place add on to publish tickets as a help centre article, but this is just a workaround.

  • Avatar
    Jessie Schutz

    Hi Kelly!

    There isn't native functionality to accomplish this, but you can definitely put something like this together using our API. You can find more information about our API here: https://developer.zendesk.com/

    If you don't have the resources availble to build this internally, just send an email over to support@zendesk.com and we can get you in touch with our Partner Services team. They'll be able to help you find a vendor who can give you an estimate to build it for you!

  • Avatar
    Robert McGinily

    @Jessie 

     

    Thanks for the tip for updating 100 incident tickets at a time. The issue that we come across with having millions of users is that updating 100 tickets at a time is extremely time consuming.

     

    Even if we solve the problem ticket which updates the thousands of linked incident tickets. Then we have to reopen incidents at a rate of 100 tickets. 

    Is there any way we can increase the 100 limit or allow an update to be applied in a pending state which would mirror this across the linked incidents? 

  • Avatar
    Jessie Schutz

    Hi Robert!

    It's not possible to update more than 100 tickets at time in the user interface, but I can definitely see the need in your use case.

    The best option for you is going to be to update those tickets using our API. You can find out more about this here: https://developer.zendesk.com

    Please let me know if you have any other questions!

  • Avatar
    Robert Rawlins

    @Kelly + @Jessie I'm currently working on something along these lines. If you're interested in talking it through please do drop me a note. robert (at) sorryapp (dot) com

  • Avatar
    Anthony Bryant

    Make sure to click Update to save the changes to the ticket.

    where is this located?

  • Avatar
    Graeme Carmichael

    Anthony

    I suspect that this article is a little out of date. Look for the SUBMIT button and that should update the tickets.

     

  • Avatar
    Melanie Adams

    We love the feature that exists allowing us to solve a problem ticket and send out mass communication to all incidents so the customers also know it was resolved.  However, what if their zendesk record doesn't have an email attached, and only a phone number. They would not receive the message and know it was resolved.  Is there anyway to know that specific incidents don't have an email attached when you're looking at them from the problem ticket view?  Any suggestions on how to help this scenario?  

    We support our customers via phone and email so if they call in the incident, this is how we land in this scenario. 

  • Avatar
    Jessie Schutz

    Hi Melanie!

    I think the easiest way to work around this is to have your agents ask your customers for their email address when they call in about the problem. Then you can notify them of the resolution via email.

    There isn't any trigger condition that tests for whether a requester email is present on a ticket or not, so you wouldn't be able to use that as a way to tag the tickets to add to a view. It might be possible to do so using an API call, though...that's out of my depth, but someone else in the Community might be able to help you!

  • Avatar
    EricBenson

    Just to be clear. Do public comments on the problem ticket also get sent to the requesters of the linked tickets?

  • Avatar
    Bradley Weismann

    What happens to the linked incidents if I merge two Problem Tickets together?

  • Avatar
    Graeme Carmichael

    Brad W

    When you merge two problem tickets, one of the problems will then have a closed status. This closed ticket will still have its original linked incidents. So the linked incidents are not transferred to any other problem ticket.

    If you want the linked incidents to be associated with the other problem ticket, you can batch process them. On the ticket batch update screen, change the type field from 'No Change' to 'Incident'. This will display the linked problem field. You can now set the link to your target problem ticket.

  • Avatar
    Graeme Carmichael

    @Eric Benson

    Public comments on the problem ticket do not normally get sent to the requester of the linked tickets. This allows you to keep details of he problem separate from your customer tickets. There may be many details and a different workflow for the problem ticket that you do not want you requesters to be troubled with.

    The exception is when you first solve the problem ticket. Public comment when setting the problem to solved will also update the incidents.

  • Avatar
    Matt Flowitt

    Is there currently a way to replicate the problem/incident flow for other uses? 

    I want to keep the existing problem/incident flow in place but I'd like to duplicate it for "feature requests" to replace problems, and then tack on additional requests for the same feature as the replacement for the "incident" type. 

    I've tried searching the knowledge base and played around with custom fields but I don't see a way to do this. This would be extremely useful for helping me to track how many people make the request as this is what really helps me to push them through with our developers. 

    Right now I haven't found a good alternative for doing this. 

  • Avatar
    DJ Jimenez (Edited )

    Would it be possible to link incidents from the problem instead of a problem in the incident?

    Use case - it is possible for customers to send in tickets at the moment a problem occurs. As we're writing up the problem ticket, we'd want to add the incident ticket(s) right there and then.

    Something like this mock-up:



  • Avatar
    Jessie Schutz

    Hey Matt!

    Interesting question! It's not possible to re-create a different version of the Problem/Incident relationship, but you can still use it for a feature request workflow like what you described. You could use tags to identify feature requests so you can put them in their own view. You could even put a process in place where something like [Feature Request] is added to the front of the subject line on the Problem ticket so they're easily identified.

  • Avatar
    Matt Flowitt (Edited )

    Hey Jessie, 

    Based on your and one of your colleague's recommendations this is what I have done.

    I've added a custom field with a couple of categories. In my case, it's "feature request" and "annoyances".

    I have now set up 3 views, one for problems, one for feature requests and one for annoyances. Each designed to view the "problem" tickets of various kinds, excluding the others.

    E.g. Conditions are "problem" ticket with "Feature Request" in the custom field. 

    I am now able to replicate the problem/incident flow for these 2 other varieties without negating the effectiveness of the original flow (my major concern!). This gives me a great method to track both quantitative data alongside the qualitative which is great for allowing me to push for these things to be implemented internally. I'm not sure if it's the case for other support departments out there but the first question (rightfully or wrongfully) out of anyone's mouth when I mention feature request is "How many requests?". 

    Thanks for the help! I'm looking forward to seeing it in action!

     

    P.S This has the added benefit of giving me a running list of individuals that requested the feature. That way, when it's implemented, I can mass email them to let them know!

  • Avatar
    Jessie Schutz

    Hey Matt!

    Thank you so much for sharing your workflow! If you're interested, you could definitely write this up (with screenshots, etc) and post it to our Tips & Tricks section to help other members of the Community. Plus you'll get swag!

  • Avatar
    Jessie Schutz

    Hey DJ!

    That's a really interesting idea. I did some poking around in our Product Feedback forum and I don't see another post about this. I'd definitely encourage you to post your suggestion (along with your detailed use case) over there to make sure our Product Managers see it, and other users can add their own votes and use cases as well.

  • Avatar
    Ben Speich

    So to help my brain figure the flow out. What happens if I solve a problem and later have another ticket that qualifies as an incident. Would I still link it? 

  • Avatar
    Jessie Schutz

    Hey Ben!

    I think that'll probably depend on the situation. In general, the only reason you'd Solve a Problem ticket is because the issue is resolved. If the issue is resolved, theoretically you wouldn't continue to get tickets about it.

    In the event that you think it's fixed so you solve the Problem ticket, but then find out that it's not actually fixed, you'd re-open the Problem ticket and continue linking the ticket reporting the issue until it's actually resolved.

    If you resolve an issue and close the Problem ticket and then receive another ticket reporting the same issue after the Problem ticket has gone from Solved to Closed, you wouldn't be able to link the Incident anyway. In that case, once you've confirmed that the original issue is re-surfacing, you'd want to create a new Problem ticket (probably a follow-up from the original Problem ticket) and start linking incidents again.

    Does that make sense?

  • Avatar
    Ben Speich

    Yep.

    I am thinking more of long term trending. Using the example of say WIFI being down somewhere and someone logs the complaint, and simply restarting the router solved the problem. Then as you say, the ticket goes to Closed, but then the issue comes up again. How could we track that this is recurring and over say a certain period understand that perhaps the router is actually going bad. In our business we have hardware that we manufacture and want to be able to track if there are issues with certain parts and would require a recall, but this would be after several months. So trying to figure out if linking problems and incidents would be the proper way or if we try to use tags in someway or if we should link Zendesk to Bugzilla or some other tracking program 

  • Avatar
    Jessie Schutz

    Hey Ben,

    So if you're looking at tracking issues with one specific router, as in one customer reporting repeating issues with this one piece of hardware, I don't think that the Problem/Incident function is really going to get you where you want to go. You'd theoretically have tons of open Problem tickets and it would get really messy.

    You could potentially put together some kind of workflow using tags, although I'm not really sure what that would look like. It would probably require some trial and error to get it dialed in.

    If there are other solutions that already do what you want that you can integrate with Zendesk, that would probably be the easiest option. I'd definitely recommend that you check out our App Marketplace to see if there's anything there that catches your eye.

  • Avatar
    Crawford Philleo

    Hi! I thought I would be clever and build a dynamic content placeholder for a 'problem solved' macro to use when solving a problem and linked incident tickets. Using liquid markup, I wrote the macro to say one thing for the problem ticket (something generic, like "Problem solved - here's what we did" using placeholders for custom fields that hold notes), and then it would say something else for the customer's affected in incident tickets.

    I just did a test, and only the placeholder appears in the comment, which also populated the notify requester triggered e-mail

    Did I do something wrong?

  • Avatar
    Keith @ Zendesk

    Hey Crawford,

    In order to see what might be going on, I would need to see the set up on your account.  Would you mind if we create a Ticket out of this and work from there?  I'd also need your Zendesk Subdomain to proceed.

    Let us know what other questions you might have and if we can be of assistance.

    Thanks!

  • Avatar
    Crawford Philleo

    Hey Keith, a ticket would be great. How should I open one? I have more questions about this, I can't seem to get liquid markup to work with related Incident tickets in general.

     

    Thanks!

  • Avatar
    Jessie Schutz

    Hey Crawford, I see you were able to get that ticket submitted. Feel free to come back and let us know what you found out!

  • Avatar
    Crawford Philleo

    Yeah, I figured out that typing the actual placeholder into the comment box on the problem ticket will carry over with liquid to your related incidents. However, I don't like doing this, because it defeats the purpose of setting up a macro.

    Rather, I want my macro (or dynamic content placeholder) to contain the liquid markup, run it on the problem ticket, solve, then have the liquid carry through to the related incident tickets. Not sure if there's a solution here, but hopeful - thanks!

  • Avatar
    Leander Stellemans (Edited )

    Why is it necessary to create your own problem ticket? It sounds more logical to me to mark the first ticket about the problem as the problem ticket and mark future tickets about the same problem as incidents and relate them to the problem. What are the arguments against this?

    With an extra ticket (the problem ticket on my own name) i create duplicate tickets.

Please sign in to leave a comment.

Powered by Zendesk