Sizing your team

Here at Deskflows we say: “agility is different from speed”.

In other words, it is necessary to think less about functions and more about roles: enable the agent to navigate between different levels, acting on different demands, prioritizing according to an objective criterion.

Therefore, sectioning your process based on these roles, or categories, is one of the most important steps when thinking about an agile process. Agility, in this case, is the ability to act directly on the bottlenecks, which is possible thanks to agents with dynamic roles.

We have some very interesting content that talk a little more about why invest in bottlenecks (and not in the process as a whole) or about SLA (an important prioritization criterion), but today our aim is different.

In this article, we will introduce our “process-sizing” methodology.

Basically, after organizing your tickets in different process queues, you will be able to work with more accurate average times, estimating how many items can wait with the lowest risk of violating service terms.

We will approach our methodology in two parts: demand calculation and capacity calculation. At the end we will understand when to use one or the other to generate alerts of potential bottlenecks.

Demand calculation

The first step, more intuitive, is to calculate the average demand in each division of your service. Do you know how many items each level receives per hour? Without this number, it will be very difficult to find the root cause when your team is overloaded or idle. A lot of time is likely to be spent on activities that do not generate productivity.

Total tickets, agents and service hours

How many tickets does your team receive in a month? How many does each queue receive per hour? These are essential numbers to design your team, but unfortunately, few leaders really keep pace according the demand.

Even more interesting than monitoring the total demand is to determine the number per agent, a data that will already give a first indication of the workload to which your team is exposed.

But this is only part of the analysis. In some cases, especially where teams feel more overwhelmed, keeping up with demand is insufficient.

Here is the “other side of the coin”.

Capacity calculation

Touch time, wait time and efficiency

To measure the team’s capacity, it is very important to understand some process productivity variables:

Touch time: period of time the ticket is actually being handled, an average of the work times required for each. It measures the agent’s effort on a specific item, not the waiting time;

SLA period: is the specific tolerance time for a queue. For example, if a customer can wait for a demand from that queue for 2 hours, then this is its SLA (regardless of the agent’s effort);

Agent time allocation: percentage of time devoted to handling queue tickets, if the agent divides time between other processes.

Effective agents: average number of agents working in the queue at any given time (what percentage of the total team is normally available to answer queue items).

Example: if the team has 10 people divided between levels N1, N2 and N3, with 2 being exclusive to N3, levels N1 and N2 will have “effective agents” in 80% (or 8 agents), but they can have an “allocated time” per agent less than 100%, if these agents also help in N3.

Process SLA

In order to scale the team in terms of productivity, understanding and, above all, using the SLA concept is crucial.

Basically, we will calculate how many tickets you can resolve within an “SLA period”, to understand what queue size you may be at risk of not delivering a new ticket within the time limit.

Actual capacity

The total resolution time of a call, on average, takes into account not only the touch time, but the time and agents allocated. This is a time that will be much closer to reality if the process is divided into categories of tickets. For each category, or queue, we can consider a specific resolution time and SLA, which is closely related to the priority of that type of demand.

So, we can calculate how many tickets you have the capacity to answer within an SLA period. This measure is important because, considering the moment when a new item is received, there should be a smaller number of tickets in the queue with respect to the maximum resolution capacity within the newcomer’s due date.

This is the premise of our capability alert .

Demand vs. Capacity analysis

So far, we have been able to calculate the open call rate and capacity flow . Each of these rates can be used to configure alerts or alarms , so that the team is notified when a certain queue reaches its maximum size.

So, which of the two parameters (demand or capacity) should be evaluated? This is what we will see next.

Alerts and Alarms

The great advantage of performing a team sizing analysis is to have a more accurate answer of the ideal size that your team should have, without the risk of wasting resources or overloading your agents. Having the right team to deliver what your routine requires with quality is a productivity differential that will certainly make a substantial difference in your results and in your relationship with your client.

So, how to do this analysis? Basically, there are two situations in which your team can be placed, after calculating demand versus production:

Oversized team: occurs when its actual flow capacity is superior to its demand, that is, the team is able to deliver more than is requested , on average.

Under-dimensioned team: occurs when its actual flow capacity is less than its demand, that is, the team has a maximum delivery less than would be necessary to meet all requests received, on average.

Note that if your team is “left over” from demand, it is not necessary to monitor production capacity as closely, and you must set your alarms to monitor demand . As long as the demand is below or even equal to the average you used in the calculations, you will be sure that there will be no problems with the delivery capacity. There will only be risk in the event of an unexpected increase in incoming calls, and therefore this demand should trigger an alarm.

If your team has an excessive workload, and may not be able to deliver the same flow of calls received, it will be much more critical to monitor capacity . Action plans will be needed, such as increasing the number of agents, automating procedures or improving the design of the process, but above all, you will need to monitor in real time the size of the queue at your service levels, so that agents are directed to the bottleneck. The principle is simple: if you have few resources, you should direct them to what is most important at the moment.

Finally, a monitoring of frequency and duration of alarms will be welcome, very important for the adoption of standards that make sense for its operation and to indicate any necessary improvements. Alarms that go off too often and / or take too long to resolve can indicate very strict criteria or need for hiring, for example, and alarms that do not go off may indicate that team sizing can be reviewed and that staff can be less allocated to that one queue.

Conclusion

Finally, to understand and mainly act on the productivity of your service team, it is necessary to understand it as a state machine. This makes the constant monitoring of these queues an extremely important tool to understand if the team size is adequate for the reality of the process or if it needs to be revised! In addition, it is possible to quickly detect if there is an anomaly in the process or if the demand is far out of schedule, making the team react more quickly to these bottlenecks.

Did you like our article? How about a free tool to experience what you’ve learned?

Did you know that deskflows has a simple and free calculator that can help you calculate your team sizing right now?