There is a single team dealing with queries from all 4 of the above channels, however they are not getting to all of the customers and we periodically have to just "dump & reset" the queues - not a good experience for the customers.
I have the AHTs and Monthly volumes going back over a year for each channel separately. I also know the shrinkage on the team.

Does anyone here currently plan resources for such a team? Do you build in concurrency? Are there any other factors I should be thinking about.

Thanks!

10 May 2018 10:10:26

Jonty Pearce

Editor

Call Centre Helper

Concurrency is difficult to model

The common way (not necessarily the best or most accurate) that most people tend to do this is
1. Add together all of the contact types so Total = Facebook + Twitter + Forum Community A + Forum Community B
2. Feed it into Erlang calculator
3. Apply some form of fudge factor based on concurrency. So if you have a max concurrency of 3 then a fudge factor of between 1.5 and 2.2 could be used.
This will then give a rough estimate of the numbers needed.

I'm happy to look through your reports to see if I can use our simulator to get you a more accurate figure.

10 May 2018 10:40:13

Dave Tidwell

SLA's by channel type can help too...

Hi Baldy,

To what extent do you apply acceptable SLA's to your planning for multichannel. Having deployed about 16 large scale omnichannel solutions across Three, T-Mobile, Orange, EE, Vodacom, Safaricom and others we were very careful to map the acceptable SLA's to the WFM/WFO planning templates. These are the rules of thumb that worked well; heavily tainted by the needs of your business strategy of course;

Communities tended to be tainted heavily by your 'moderator' audience. If you are using something like Lithium then the community will have its own frontend SLA's driven by moderator 'competition' and fallback to customer operations intervention only when it got heated, had no response in timeframe X and so on.

Factor those; then factor concurrency.

Are you routing omnichannel to eServices CSR's that have voice to callback; but are not on the primary voice queues? In some of our solution designs we queued eServices to agents on voice queues and pulled all outstanding eServices transactions and routed them alongside any immediate voice call; there's no point sending a voice call to a voice agent without them seeing that the customer has shouted on Twitter X times since 9am this morning....

I don't know which 'platform' you are on - but on ones like Genesys you should not be dumping your queues. If your SLA's are clearly defined then your queue should have a parking queue for those inside SLA and an automatic routing override for interctions that are close to SLA. You should also pull out all queued interactions when targeting a blended agent seat with any other form of eServices transaction in queue because they are related 95% of the time.