Chat Logic: What Operator Receives the Next Chat?

A recurring question among our users: “If we are online in the Chat Panel with multiple operators, what determines which operator receives the next chat?”

This is governed by the internal logic of our chat system, which reflects how we think live chat should be done. Here are the rules that decide who will be the next lucky operator:

1. Operator grouping

This is an obvious one. Every Chat Widget is connected to one Operator Group. When a chat is started through a Chat Widget, it is referred to one of the online operators in the connected group. Unless you have the Group Select function enabled, in which case the visitor gets to choose the group he’d like to chat with.

So this determines which group gets the chat. But from there, which exact operator gets it?

2. Sticky chat

Userlike is a tool that forges long-term customer relationships through instant communication. We want to make it easier to build up personal relationships with your web visitors. This is hard when your visitor is connected with another support operator every time he returns to your website. That’s where sticky chat comes in. The sticky chat rule favors a chat connection between visitors and operators that have chatted before. This makes it easier to build up real relationships with your visitors.

3. Available chat slots

I’ve been arguing to adjust the wording here for a while because I find a decent pronunciation difficult. Either way, the number of available slots is the second most important rule when it comes to chat delegation. The operator with the most available slots will receive the next chat.

This way the system guides chats to those operators that are least busy, promoting a balanced workload and the likely shortest response time for web visitors.

Note that adjusting the maximum number of chat slots downwards for a specific operator reduces his chances for receiving the next chat (if the chat slots of the fellow operators aren’t adjusted downwards as well).

Some make use of this to favor specific operators with many chat slots to receive the bulk of the chats. Other chat operators with fewer slots then only jump in when the chat load gets too high, or they function as ‘experts’ to whom chats are forwarded from the ‘bulk’ operators when they require some extra care.

4. Longest idle time

All else being equal, the next chat will be delegated to the operator that hasn’t been chatting for the longest time.

Those are the rules behind our chat delegation. They are listed here in order of importance, which means that for example sticky chat is overruled by the available chat slot rule.

These rules reflect how we think live chat should be done, which is:

• Fast - Speed is one of chat’s main advantages over phone or email. That’s why our chats are guided immediately to an operator that is in the best position to answer it quickly.
• Efficient - Phone and email are terribly inefficient and expensive. Live chat allows you to serve more people in a better way, so let’s keep things efficient.
• Personal - Combining the low-barrier nature of email with the speed of phone, live chat is the optimal tool to start personal relationships with your web visitors.

There are two questions we regularly hear from users, often from those that switched to us from other live chat providers:

"Why don’t you offer a visitor select feature?"

With visitor select you see a list of your web visitors and can start a chat by clicking on them. Sounds like a good feature at first sight, but it goes against our value of ‘efficient chatting’.

We think it’s great to proactively engage your web visitors, but think this should be done through automatic chat triggers based on defined web visitor behavior (e.g. time spent on the page). So like our ‘proactive chat’ feature does it.

We think it’s woefully inefficient to sit and watch your web visitors, starting a chat with them when it ‘feels right’. Be respectful of your own time and don’t risk starting a chat on an inappropriate/suboptimal moment.

"Why don’t you put visitors in a queue, notify all operators when a chat comes in, and let it be answered by the one that is up to it?"

The idea behind this feature is that only the ones that are ‘not busy’ answer the chat, so that the busy ones can focus on their work. However, through its practical outcomes this goes against our value of ‘fast chat’.

In practice, your visitor is left waiting in a queue while the operators are arguing over who is least busy, waiting for one of their colleagues to answer. Or you have one operator who wants to be the nice/hardworking guy/girl, accepting all the chats. Again, this leads to a suboptimal situation of unevenly distributed chats and slower response times.

We prefer our setup: you are only online when you are available to chat and receive the chat based on objective factors that govern what is most efficient and fair to the team. In case you forgot to log off, you can set the chat to forward to your fellow operator after a certain time of inactivity.

We hope you can find yourself in our ‘chat logic’. We are always looking to optimize, so be sure to let us know if you have questions or suggestions.

About Userlike

Userlike is live chat software for websites, allowing companies to chat with their (potential) customers directly over the website. Look here for more information.