An omnichannel platform is a unified system that enables businesses to provide a seamless and consistent customer experience across multiple channels and touchpoints. It integrates various communication channels, such as websites, mobile apps, social media, email, phone, and physical stores, into a cohesive platform.
The fundamental concept behind an omnichannel platform is to ensure that customers can engage with a business through their preferred channel, while enjoying a consistent and personalized experience, irrespective of the channel chosen. This allows customers to initiate an interaction on one channel and effortlessly transition to another without any disruption or loss of information.
From the perspective of customer service agents, this translates into a streamlined workflow. All contacts from different channels converge onto a single platform and are automatically assigned to available agents based on predefined prioritization settings. Consequently, agent occupancy tends to be higher, eliminating the need for blended skills and creating shifts accordingly.
However, planning for omnichannel setups can present challenges. This is primarily due to variations in service levels, productivity, and potentially occupancy assumptions across different channels, despite their integration into a single platform. A logical approach would involve performing calculations for each channel sequentially, utilizing unoccupied full-time equivalents (FTEs) for subsequent channels. This assumes that the system settings allow for contacts to be sent in the same order whenever multiple contacts are received from different channels.
Table 1. shows an example scenario of a queue with two channels (phone calls, emails) with the following productivity assumptions.
In Table 2. we see the hourly arrival rate per channel for the first 8 hours of the day.
Phone calls have a shorter SLA time. This means that we can assume phone calls to be the priority channel. The headcount requirement can be defined using standard Erlang C calculators. I use RWFM, a package I have developed for WFM calculations. Are you new to R? Here is a short tutorial. Here is another article to get you started with RWFM
Install RWFM from its GitHub Repository.
Load the input data and calculate the necessary fields
Agents required for phone calls, their expected occupancy
The difference from 80% occupancy target means that some of their time can be spent on handling email contacts. First of all how many of those FTE’s will be idle in every interval? And how many emails can they solve? Note that 3600 is the number of seconds in 1 hour.
Keep in mind that we were able to save an average of 1.54 FTEs in every interval. You can expect higher savings for larger call centers with more channels.
How many more agents do we need to solve the remaining emails?
Unlike live contacts, we don’t need Erlang calculators for email contacts. Remember that the service level time assumption was 24 hours for emails. For such relaxed service level definition, it is fair to ignore simply multiply the workload by the handle time and then divide by the occupied time length to calculate the headcount requirement.
I hope this article serves as a source of inspiration for you to explore the benefits of adopting omnichannel platforms. If you are already utilizing such a platform, I trust that my approach to planning will prove valuable to you. I welcome your feedback and thoughts on the matter. Find me at LinkedIn.