Sorry, your browser doesn't support all of the technology used on this site. Please upgrade to the latest version of Internet Explorer, Chrome, Safari, or Firefox for a better experience.


What To Do When Your Queue Blows Up



It happens to the best and the brightest. You’re sitting at your desk on a typical day, answering questions and monitoring your community, when all of the sudden, the tickets come pouring in. In an instant, your usual workday has become a chaotic mess of overwhelming need. And as the queue backs up, you begin to sweat. Boom.

This, my support friends, is what it’s like when your queue blows up. If it hasn’t happened to you yet, it will. If it’s happened to you before, it will surely happen again. Don’t worry. Take a deep breath and follow these steps.

Look for the very first report of volume spike:
Volume spikes are typically an internal error. It’s usually an indicator that your client’s website is down, their app is broken, or a critical feature is not working. Knowing the exact time of the first report is always helpful to pin down the code push that caused it, or what was happening when the server that went down.

If the spike is caused by a community issue, such as an unpopular product change, the first report is not as important; rather the specific reasons why the product change is causing problems is most useful to record.

Check all known issues or bugs before reporting:
Keep in in mind the first ticket of a queue blow up may not actually be the first time the problem has occurred. The issue could have presented itself earlier. Check all bug reports for similar issues, and try to find the true first case. If the problem is one that’s already been reported to the Development team, then you don’t need to re-report it; just alert the team to the severity of the issue so that they can properly prioritize fixing it.

Reproduce, research, report:
Reporting an issue isn’t the first step. First, try to reproduce it yourself. Do your own testing and see if you experience the same problem. If you can, then there’s a good chance that the issue isn’t an isolated occurrence. Educate yourself on the exact nature of the problem so you can provide clear details to the developers. Offer a sense of scope as well, along with a rough estimate of the TOTAL amount of tickets with this issue. Screenshots, links, and a layman’s description are all good ideas. Once you have this info, you’re ready to report the problem.

Take action, and support your community:
Once the issue is confirmed, convey that to the community, even if it’s not fixed. Thank them, and let them know that people are working to fix it. Also, use whatever appropriate tagging your ticket system provides. That way you can reach back out to those who’ve written in and let them know that the issue is resolved.

Support your Support:
Informing your customers is only one part of the equation. The other part is letting your support team know what’s happening. Keeping your team up-to-date will prevent redundant reporting and testing. It also will help your team respond quickly to inquiries about the same issue.

Post Mortem:
Depending on the scope and nature of the issue (especially if the spike was caused by a community issue), schedule a time to have a conversation with your support to see what can be done to prevent the issue in the future. Keep in mind, this isn’t a time to point fingers; rather, it’s a time for facts to be shared and open dialogues to flow so that everyone can grow as community servers.

Queue blow-up will happen, it’s how you respond to them that will set you apart from your competitors. How do you handle queue blow ups? We’d love to hear your tips!


Are you ready to discuss your support needs?

We'd love to hear from you!