Dealing with ticket storms
Currently all the support we do is via support requests being submitted in dribs and drabs for a multitude of different problems. We have never had to deal with a major incident where a server has gone down and we suddenly had 100 tickets all for the same reason. Ie. 100 people saying I can’t access xzy.
We are launching a new server based product next year and it’s likely that we’ll start to see server incidents where we have a flurry of users all reporting the same issue in a short space of time. With that in mind, I wanted to put something in place where we didn’t have to reply to each ticket individually to provide updates, and instead of group all the tickets together when they come in and provide just one update to all customers at the same time.
I can think of various way to do it, but before I over engineer something, I wondered what other people were doing to manage this.
-
Hey Lester -
Thanks for the question! We do have functionality in the product to deal with just this sort of issue, it's called problem and incident tickets. Basically, you're able to create a "problem" ticket for the issue, and then as new tickets come in, you link those incidents to the problem. Then, when you update the problem ticket, it will update all of those incident tickets.
You can learn more about these things via the following article:
Working with problem and incident tickets
There's also a good community discussion on the topic:
Zendesk on Zendesk: Lifecycle of a Problem (and Incident) ticket
Check those out and let us know what other questions arise. And if any community members have insights on how you handle problems and incidents, please share your experiences!
-
Thanks Nicole. I'll take a look at that.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
2 Kommentare