At Kustomer, our Support team uses an internal instance to message clients, respond to critical issues, and track problems and their resolutions. We call our internal instance of Kustomer: “Kustomer Alpha”.
Years ago, our Support team was small. We used searches within Kustomer Alpha to self-assign conversations and didn’t rely on other automations, like Queues and Routing (QnR). We knew that we were growing quickly and needed to keep pace with the expansion of not only our Support team (which went from 5 to 25) but also the increase in the number of conversations from our clients.
Since that time, we’ve taken an iterative approach to build out and configure Kustomer Alpha to work for every team at Kustomer. We’ve come a long way in perfecting Kustomer Alpha to ultimately reduce the amount of time it takes to solve a problem. We’ve added workflows, configured business rules, revamped our chat flow, and even custom built the insight details card for conversations to pull in the most relevant information for CX, Sales, Product, and Engineering teams.
One of our biggest hurdles was our transition from using searches to QnR. Like the other changes we made to Kustomer Alpha, we took an iterative approach and made slight changes and tweaks over time. While we are always looking for improvements, our current setup of Queues and Routing provides flexibility for our team, allows us to scale easily, and efficiently routes conversations to the right people. While our setup may not be the best for every client, the structure we’ve put in place and the concepts we’ve applied are beneficial insights for any company, regardless of size.
Before we share these insights and what we learned, let’s first cover some important QnR terms.
Capacity - This is the amount of conversations an agent can have in their inbox at one time. Keep in mind that each conversation will have a different weight so the total number of conversations an agent can have at one time depends on the weight of each of those conversations. This is similar to the weight limit on a bridge. If the weight limit is 500kg and 5 trucks each weighing 100kg want to go on the bridge, you can only have 5 trucks on the bridge at one time. If the weight limit on the bridge is 100kg and the weight of each car is 10kg, then you can only have 10 cars on the bridge at one time.
Weight - This is the total allocation of space a conversation takes up in an agent's inbox. This the weight of a vehicle on the bridge we talked about above. The heavier the vehicle, the less capacity there is for other cars to go on the bridge.
Now let’s take a look at the team set up we designed for Kustomer Alpha and how we’ve configured the naming, capacity, and weight of conversations for those teams.
Currently, we have 5 teams:
The first team on this list, Team 0, is only used as our Training team. When we onboard a new support engineer and they go through our training modules, they are added to this team so that when they set themselves to “Available” and start receiving conversations from clients, they only get one conversation at a time. This helps them ease their way into answering questions, handling conversations, and understanding our processes. Once they are ready, they are added to the 100% capacity team.
Teams 1 through 4 have varying levels of capacity. Each team name has a percentage (50%, 75%, etc.) to indicate the percent (out of 50) that they will have their capacity set to. While someone on the 100% capacity team will have a capacity of 50, someone on the 50% capacity team will have a capacity of 25. With each conversation weight equal to 4, that works out to be 13* open conversations for the 100% team and 7* open conversations for the 50% team.
*When Kustomer decides to add to an agents capacity (by routing a conversation), it will always add a conversation and increase the total capacity even if adding to the capacity will put them above their available capacity. For example, our 100% team can have 12 open conversations at one time which puts them at a capacity of 48/50 (12 x 4 is 48). Since there’s 2 available, Kustomer will route another conversation to the agent making their total number of conversations 13 and their capacity 52/50. For the 50% team an agent can have 6 open conversations which puts them at a capacity of 24/25 (6 x 4 is 24). Since there is 1 available, we will route another conversation making it 7 conversations and a capacity of 28/25.
While traditionally team names indicate a skill or location (Orders, Returns / France, US East) we felt that it was more helpful to the support engineer to know and understand their overall capacity for conversations, especially if they needed to switch to another team with lower capacity. This was also helpful for management to understand at a glance (by viewing team pulse) how the team was distributed throughout the day (how many people were at 100% capacity, how many people were at 50% capacity, etc.).
While most people on our team spend 100% of their time handling conversations, there are others who work on projects, handle more complex issues, or need to limit their overall workload to help reduce stress. In response to those needs, managers can work with a support engineer to add them to teams with less capacity or ask them to switch their team to one that has less capacity.
While this setup helps us to scale down and dedicate more time to projects, it also helps us to scale in the opposite direction. For example, if there’s a sudden increase in conversation volume, we can switch support engineers to a higher capacity team (100%) or ask them to make the change themselves.
Both conversation volume and an agent’s current workload is always fluctuating. The above approach allows flexibility for both the agent and the administrator and allows for any company of any size to flexibly scale its operations to support the demand.