Best Practices to Prioritize Support Requests

What Clients Do You Prioritize?

Imagine you’re working as customer support for a company, and this company has not set any internal guidelines for how to prioritize your incoming tickets. Client A emails one moment, but then a few minutes later, Client B emails but says theirs is really urgent. Is it really urgent? Or are they just saying that? Maybe Client A was more urgent, but was just more relaxed in their tone when they emailed you about it?

How would you know which client to prioritize first and start supporting? The one that came in first? Or the one that declares themselves as urgent? Or another method entirely? This is where the importance of having an internal system to prioritize incoming requests comes into play.

There are many different ways to prioritize these requests, however, the way that I almost always come back to is a “Priority Matrix”. Much like the Eisenhower Matrix, which I have written about here as a method for prioritizing your own day to day tasks, the Priority Matrix for Support is helpful when broken into categories.

How to Build a Matrix?

A matrix is helpful when you have at least two categories clearly defined It’s even more helpful if you have more than that. One category that a Support Matrix definitely needs is “Impact”. What is the impact to the business? To the client? Is it urgent? Is it not? This is one category.

From there, you can be more specific within that category of “Impact” and break up the description of impact as it corresponds to each “tier” of clients that you have. Let’s say you have 3 tiers of clients who we will call, Small, Medium and Large for the purpose of this article. That would be details that could be accounted for in the “Impact” category.

Another category could be a simple numbered system of 1-3 or 1-5 with 3 or 5 being the highest. Let’s use 1-5 for this example.

Now that you have both categories clearly defined, you can start filling in the cells and what the criteria for each will be.

Some common criteria you will want to consider are:

• Business impact (does it cost you or the client money? Are either of you losing money if this doesn’t get solved?)
• Urgency (will the issue get worse if it’s not solved asap? Or can it wait a bit?)
• Client’s desired importance and priority level. (If the client is adamant it’s urgent, it’s always best to see if you can help accommodate this - or at least do preliminary troubleshooting to see if it is urgent)

Let’s start at the top and work our way down. A request that is critical and impacts revenue or other key business operations for any duration of time, can be considered 5. If this comes from a Large client, then this is priority number 1 for the whole support team. This may look like the below on your matrix:

You can then build off of the levels from there. Level 4 could be “Urgent” requests from non top tier clients:

Level 3 could be “Medium” requests from a top tier client and need to be solved, but not asap:

Level 2 could be “Low” priority requests from top tier clients, but “Medium” for other clients:

And finally, Level 1 could be “Low” level requests from non top tier clients:

Once you have all the levels clearly defined, we can assign priority levels based off of the urgency and impact of the requests and cross reference to the tiers. For example, if the same urgency and kind of request comes in from a Small client and Large client at the same time, then we take the revenue and tier sizes into consideration and assign the Large client a higher priority than the Small client.

This does not mean that Small clients never get their requests handled, rather there should still be an SLA (Service Level Agreement) that ensures you still assist all clients within the window of this SLA for them. Some clients, or tiers, may have a shorter first response SLA, which can then help with prioritization even more. Continuing the example above, you would still prioritize the Large client first, but this may be even more obvious if they have an initial touch response time limit of 6 business hours whereas a Small client may have 24 hours. This allows you to prioritize the Large client guilt free, and still have time to assist the Small client within their SLA window.

How Can You Use Support Matrixes?

Let’s break this down with a few more scenarios.

Scenario A)

Assume you are a member of a support team for an e-commerce company. A Medium client has reached out with saying that their storefront is down and none of their customers can check out. Meanwhile, at the exact same time, a Large client has reached out about making some small design changes on their theme. Which one would you prioritize higher given everything we have discussed today?

While the Large client technically does bring in more revenue for your business, the fact for this scenario is that the Medium client is experiencing a critical incident with business being negatively impacted. For this scenario, you’d want to help the Medium client first, while also making sure to at least get an initial response to the Large client with their SLA window.

Scenario B)

You run a solo digital agency that creates websites for different ma and pop stores around your province or state. A Medium client reaches out and casually mentions that there is a small bug on their website and it only happens on Safari. You test on several different devices and with your VPN and determine that everything is working as expected on the website so you tell the client it is a local issue and advise them on how to fix this for themselves and that ended up solving it! You effectively prioritized this one as 2 or 3, depending on your criteria and scale used.

The next day, another Medium client reaches out with a full caps email that says “URGENT! EMERGENCY!” You open the email as quick as you can and realize that it’s a similar looking but different bug, that is also impacting Safari for them. While you are investigating, the client sends 5 more follow up emails expressing the urgency of this bug. You follow the same steps as yesterday and determine that it’s indeed another local issue, and you advise them as such and this does solve the issue for them. When this email came in, you prioritized it as a critical or level 5 issue, because of the language and urgency expressed, but once you dug into it, you downgraded it to a 2-3, just like the one yesterday. Was this the right decision?

Yes, it was. The only difference here is that you would perhaps send a quicker initial touch email to let the client know you are looking into to calm their nerves. Once you’ve determined it’s not a bug on the site, you continue the empathy to let them know you understand the urgency and the importance of this for them, but also clearly point out how to solve this.

Despite the differences in language and urgency, both of these emails can correctly be prioritized at the same level (once initial investigations have been completed). Please note, that 2 similar looking bugs may also indicate a trend so always do keep that in mind but that is out of scope for this example.

Scenario C)

Returning to our e-commerce scenario, let’s say it’s a new day and a Large and Medium client reach out at similar times, with the Medium client coming in just a bit earlier. Both of them are experiencing slow site loading issues for all of their customers and their staff. Definitely not a local issue here, but which one would you prioritize higher and why?

Assuming the Medium client reached out only a little bit earlier and not a whole day or more, you would prioritize the Large client. This is because the timeline is similar and the issue and impact is similar, so this means that the next deciding factor is revenue. And since the Large client brings in more revenue, they are prioritized first (with chances being for this issue that a fix for one would be a fix for all).

Final Words: A Matrix Works for Clients Too

Last but not least, a Priority Matrix isn’t just helpful for support teams but can be helpful for developers, managers and more. It can also be helpful if you’re a client who works with a third party support team too!

For example, if you rely on another company for support for some aspect of your business, let’s say website maintenance and improvements, such as OneCare, then it makes it easier for everyone involved if you can create your own matrix for all your backlog or feature requests that you want done. And then when you communicate with the third party support team, you can tell them that item xyz is a high priority task, whereas item abc is a low priority. This saves the back and forth between you two, especially when you have multiple requests going on at the same time. It also helps you have a singular team or POC who can triage and communicate these requests to the third party support team so everyone is aware of timelines and budgets. An example of this can be seen below:

Well, there you have it. If you’re a customer support team, I highly recommend setting up a Priority Matrix to prioritize incoming request, but even if you’re not, there is a good chance that a Priority Matrix will work in some form for you too!

---