Framework for Determining Resourcing Requirements for L&R and Dotcom Queue
Problem Statement
As the amount of work has increased in the dotcom queue (and the recent taking on of ownership of L&R related work), we need to ensure we have enough people focusing on these 2 queues to support customers and meet SLA's.
-
What is the problem?
If we do not have enough people focusing on these 2 queues, it starts to overwhelm the few that are focusing on the queue while decreasing both SSAT and SLA attainment (i.e. we have more breaches).
-
Why is this a problem?
As a Support team, our focus is on helping customers when they experience a problem. If we are unable to balance the workload across enough people, we perform worse (and therefore create an undesirable customer experience) and increase workload and stress on those with the knowledge/access to do the work that is needed.
Proposal
As an MVC, we can use the current KPI of average monthly tickets closed per Support Engineer and the average of incoming tickets for the last 6 months to determine the number of Support Engineers needed to manage the workload in the Dotcom and L&R queues.
Breaking this down between Dotcom and L&R while using the framework above gives us the following number of Support Engineers:
Dotcom: 1,242 avg tickets per month / 65 tickets per month = 19 Support Engineers
L&R: 532 avg tickets per month / 65 tickets per month = 8 Support Engineers
Following a distribution ratio of 2:2:1 between AMER:EMEA:APAC for the required Support Engineers gives us the below:
Dotcom:
| Region | No. of Support Engineers |
|---|---|
| AMER | 7 |
| EMEA | 7 |
| APAC | 5 |
L&R:
| Region | No. of Support Engineers |
|---|---|
| AMER | 3 |
| EMEA | 3 |
| APAC | 2 |
DRI
Required Resources
Where we do not have enough Support Engineers that can dedicate 100% of their time to these respective queues, we will need to target new hires to onboard and be dedicated to these queues for the foreseeable future.
Things to consider
- The amount of tickets coming in to the L&R queue is increasing month on month which an average does not take into account. Likewise, there is a longer term effort to reduce frequency of problems that customers experience, which should (at a minimum) arrest the rate of increase of problems surfaced in this queue.
- The framework proposed does not take into account work in Issues.
- This proposal will seem at first glance to be in direct opposition of the coalescing of roles. While further work is being done to support the coalescing, this proposal will ensure that (until such time that we have further broken down the lines of distinction between the queues) we have enough people to focus on the tickets that are still coming in to these queues. In other words, this is a short-medium term solution while longer term solutions are defined and implemented.
- We will need to ensure appropriate access to various systems needed to do the work in these queues is granted to the Support Engineers who will be focused on this work.
- SLA's have not yet been agreed to on Issues, and further refinement for L&R tickets is needed.
Desired Outcome
-
What does success look like?
- SSAT of 95% is achieved and maintained for tickets in these queues.
- SLA's are achieved and maintained for tickets in these queues.
-
How do we measure success?
By monitoring SSAT, SLA and number of breaches.
-
Where would future feedback go?
For the proposal on the framework of how to calculate the number of required Support Engineers, please comment on this issue.
If you have more specific feedback related to the number of required Support Engineers dedicated to Dotcom and L&R queues, please comment on issue #2615 (closed).