Problem-and-incident tickets are useful when a problem or service interruption is reported by more than one person. For example, when the wireless network in an office stops working, several people might file tickets. You can treat the tickets as incident reports. Instead of handling each ticket separately, you can link the tickets to one problem ticket, and then solve the problem ticket to solve all the incident tickets.
Here's the general workflow:
- Identify a service interruption or problem that's causing people to file tickets.
- Create your own ticket to address the problem.
- Change the other tickets to incident tickets and link them to your problem ticket.
- Solve the problem ticket.
When you solve the problem ticket, the status of all the incident tickets is automatically set to solved. The comment added to the problem ticket when solved will be added to all incident tickets that are not yet closed.
Refrain from solving any of the incident tickets directly. Solving an incident ticket still leaves the other tickets unsolved. Save work by solving only the problem ticket. It automatically solves all the linked incident tickets. When the problem ticket is solved, any empty required fields on linked incident tickets are ignored and tickets are solved anyway.
To create problem-and-incident tickets
- After identifying a problem that's causing people to file tickets, create your own ticket describing the problem and set the ticket type to Problem.
- For every other ticket reporting the same problem, set the ticket type to Incident and link it to the problem ticket.
After you set the type to Incident, a second menu appears that lets you link the incident to a problem ticket.
Make sure to click Update to save the changes to the ticket.
- Solve the problem ticket.
The problem ticket has a link to a view of linked tickets so you can review the incident reports.
Solving the problem ticket solves all the incident tickets linked to it. Only the comment added when solving the problem ticket will be included in all linked incident tickets.
Tip: Use dynamic content placeholders to personalize the comment for wide distribution. Example:
For more information, see Using placeholders.
If you decide to reopen the solved problem ticket, the incident tickets aren't updated. They stay solved. If you solved a problem ticket prematurely or if you need to communicate something more to the requesters, you can easily reopen the incident tickets before solving the problem ticket again. Click the Incidents tab when viewing the problem ticket and bulk edit all of the tickets. Submit the tickets as open and proceed with re-solving the problem ticket.
Related topics
Comments
52 comments
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!
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.
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!
@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?
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!
@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
Make sure to click Update to save the changes to the ticket.
where is this located?
Anthony
I suspect that this article is a little out of date. Look for the SUBMIT button and that should update the tickets.
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.
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!
Just to be clear. Do public comments on the problem ticket also get sent to the requesters of the linked tickets?
What happens to the linked incidents if I merge two Problem Tickets together?
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.
@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.
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.
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:
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.
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!
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!
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.
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?
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?
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
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.
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?
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!
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!
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!
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!
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.