How to handle an increasing amount of support requests
Good customer service is about handling all requests in accordance with (or above) customer expectations. What are these expectations and how you can optimize your resources and processes in relation to these expectations? It can be resource intensive and costly to maintain good service. How can you resolve challenges regarding resources in relation to requests from a growing customer base?
There is always a question of whether one can exploit the resources one has even better, rather than hiring more staff. Could you be more efficient?
In basic request handling you can choose between various methods of delegation (pushing requests to users), or choosing to leave them “unassigned”, essentially moving the responsibility of picking up the requests to the users. Using the unassigned delegation method will allow the team to work more like a call-center team, picking up the request (call) which has been waiting in the queue the longest amount of time. The advantage of this method is that you reduce the risk of requests getting “stuck” because they have been assigned to someone who is very busy (i.e. with another complicated request). The downside could be that other request is more important, not being prioritized and handled first.
One of the key factors to comprehending an increase of requests is to find a way to prioritize which request to start working on first.
But it is hard to prioritize, when your inbox has 50-somewhat requests or so… Rather than selecting the last ticket registered – or the first or the one who looks most fun – it is pretty hard to choose the “correct one”. –And don’t forget – you have to prioritize all over again on the next request… and the next…
And how do you know what criteria to weight your decision on? Could it be that each support agent does their own assumptions on what is important?
You should start by defining the reasons you want to prioritize your resources on.
- Is it the customer category the customer belongs to? VIP customer gets higher attention?
- Do you want to it based on how long has the customer waited for an answer in total for that request?
- Or is it on the customers’ priority? Maybe it is the support agent’s priority?
- Or maybe you want to prioritize new request coming in, before existing request?
- Could it be smart to focus on tickets witch have been bouncing back and forth, with no closure?
- How fast did the customer respond on our last request? It is natural to think that customers who responds 2 weeks later to your mail, isn’t in a hurry to get your feedback. Maybe down prioritize those a little?
There are a lot of possible aspects to choose from. And if you want to combine them and weight them as well – there is no way your agents are able to do this manually and get any work done. Support for prioritizing tickets, based on more than just a hunch should definitely be automated by the system, and must be both scalable and team independent.
Some requests are more urgent than others, and making sure the users pick the highest priority requests first, is one of the key goals to a new and improved request prioritizing system has to address. Also, how to assign the requests to avoid that many of the request get stuck because they have been assigned to someone who is very busy.
The users should only pick requests from the queue (i.e. changing ownership from “unassigned” to themselves) when they have the capacity of handling them so that users easily can get assigned whatever request is the most urgent one right now.
When working with requests, the users could have a button which allows them to get the next request from the queue, according to how you want requests managed in your team.
The way we implemented it in our customer service solution, was to tag all request with a “Date stamp” when the request was imported in to the system. This date stamp was calculated based on the factors we chose for the team. Each rule was put in a grid, where you had a base time and the different criteria values for each “rule”.
This makes it scalable to expand and the possibilities to reuse rules cross groups. The result of the calculated time based on a rule gives a deadline; Default Response time multiplies rule values you have assigned, equals the deadline.
Request time + Base hours * Values = Deadline
An example of the grid:
|ID||Name||Base hour||Category||Customer Priority||Agents priority||New request|
An example of the calculation based on the grid:
If a VIP customer sends in a new request, and set it to be high priority at 9 O’clock:
|Registered time||Base hour * new request factor||Deadline timestamp|
|9:00||2 h. * 0.5||10:00|
9:00 + (2 h. * 0.5) = 10:00
Now each request has a deadline timestamp. All new requests are set to “unassigned”. The next request in the queue would be the request with the lowest deadline timestamp, with owner “you” (your reopened previous request) or unassigned.
A few reports with a good overview on the load ahead, the current status of request overdue (requests with a deadline timestamp lower than present time), and notifications on request about to expire, are a must to adjust our resources and to automatically prioritize our increasing amount of requests which are not handled automatically by the system. You can now “see ahead” and adjust your resources, when you need them the most.
The better we are able to meet and exceed customer expectations, the more likely it is that our customer will remain a customer. And you get happy support agents, who can focus on their work.
P.S. Download 7 free email templates for customer service guide below.