Facebook vs. Twitter
Back to Articles

How to Measure Webchat Concurrency

How many customers can one operator handle? We decided to get down to some hard maths

November 17th, 2016

1450

Abbey Brown



Gone are the days where an operator picks up the phone and talks to one customer for 30 minutes, whilst the call queue bubbles over and drops callers here and everywhere. This is a new age of CS where customers expect an answer in less than 10 seconds, and businesses can expect operators to handle multiple contacts simultaneously. But hold your horses; how many customers can you pile on one operator before they start to drown? More, but also less, than you think.

Example: A Frontline CS Team

We’ve heard rumour that after 50 seconds waiting in a chat queue, customer satisfaction drops. We looked at average response times in addition to first response, and the rumours don’t fall far from the truth. Handling time matters to customers – they want their interaction to be speedy, and who blames them? Time is of the essence!

From a CPC (cost per contact) perspective, you want your operators to be able to juggle as high a chat concurrency as possible. 

From a CPC (cost per contact) perspective, you want your operators to be able to juggle as high a chat concurrency as possible.

But in an era where customer experience and centricity is the lofty goal of a moral business, you also want the highest quality. So what we wanted to know is whether chat capacity (the maximum number of chats a webchat operator can have open at once) had an impact on response times. And in short, it did. Groans from the CS budget, we hear you.

If we’re going to agree that 50 seconds is the turning point where customers start to lose their patience, then we ideally want to steer clear, right? We found that when operators had a concurrency of 3, 4 and 5 chats they sat happy with their average response time under 50 seconds – under 45 seconds, actually! But something interesting happens after five because suddenly, response times nosedive to a whopping 70 seconds. Wow! Our operators are good multi-taskers, but 6 chats was just too much. Our bad, lunch is on us.

We found that when operators had a concurrency of 3, 4 and 5 chats they sat happy with their average response time under 50 seconds.

So this line of thinking had us wondering about other factors. What else does high concurrency mess with? A KPI we’re always waving around in our webchat teams is chats per hour.

On investigation, with a chat capacity of 6 operators were not only slower, they got through fewer chats per hour too.

This doesn’t really seem surprising – while an operator on 6 is still handling their first round of chats, an operator on 5 could’ve moved onto their second. This tells us that when operators are handling 6 or more customers at once, things get messy and slow for everyone.

But, it’s probably best to point out that on a chat capacity lower than 5, operators were (again) getting through fewer chats per hour. Their mates on 5 were obviously working at optimal efficiency, whilst 2, 3 and 4 had time to twiddle their thumbs and look at pictures of cats. Not ideal. 5 looks like a happy medium, right?

Kind of. We recommend a pretty strict internal rating system for all of our clients, and that they take a long hard look at customer experience from all aspects: conversational, operator, team, skill, brand, product and company. Taking that ‘long hard look’ should always involve internal feedback to operators to keep things travelling upwards. We noticed that our operators’ internal quality rating tended to be higher the fewer chats they were handling.

The quality difference between 1, 2 and 3 concurrent chats is minimal. But at 4 and 5, it starts on a downward path that we are not okay with. So the turning point in internal quality sits somewhere between 4 and 5 – depending on the individual operator being measured.

 

And what did the customer think of all of this? To be honest, they didn’t seem to mind what we did with chat capacity – our operators continued to be as friendly and resourceful as they always have been no matter how many chats they handled, and didn’t outwardly show customers the strain of working under pressure. 

The quality difference between 1, 2 and 3 concurrent chats is minimal. But at 4 and 5, it starts on a downward path.

This was great to see – go us, go us! Then, we reasonably agreed that whether we could get away with it or not, a stressed-out webchat team does not a happy team make.

So, for this team, it looks like four or five chats at once is where operators, customers and clients meet in the middle. Efficiency balances with quality. We knocked the proverbial nail on its proverbial head.

Yeah cool story, now what?

This example, whilst obviously specific in nature, tells us a lot about not just how to optimise chat capacity in a given team, but a few things about the team itself. For one, it tells us how complex customer contacts are in that specific team. A team that handles simpler interactions can (and we’ve seen it) handle a lot more than 5 without seeing any compromise. Compare your complaints department to your FAQs. Two different kettles of fish.

It also tells us that it is possible to talk to more than one customer at once without destroying the personal, friendly customer service that you’re trying to provide. There’s no need to proudly declare ‘we focus on individuals, one at a time’ anymore – because it’s no longer detrimental to the customer experience.

And lastly, this tells us that man we need to move as much of our CS contacts to webchat as possible – in a climate where email responses take up to 48 hours anyway, why not?

NEWSLETTER

Improve your customer experience with insights from our monthly newsletter. Subscribe today to get started.

Stay Updated
Please type a valid email
About the author

Abbey Brown
Position of Head of Marketing