Even distribution of chats among agents

Last update: 21.02.2023

By default, new and reactivated chats are not distributed among agents and go directly to the "New" tab. For a chat to be fixated to a particular agent and moved to the "Mine" tab, the agent must respond to the customer or take the chat via the link in the lower left corner:

7a31c7022e96cd56ccd601b3900fac81.gif

Previously, there was no way to automatically distribute and fixate incoming chats to specific agents, and this revealed several problematic scenarios:

1. Some agents were not keen to pick up new chats and thought their colleagues would do so. As a result, chats could go unanswered for long periods of time as each agent hoped that another would take over;

2. In certain cases (major client, billing questions, technical issues) it is preferable to have the chat go straight to one of the two or three agents who can help the customer quicker and better than others;

3. If there are a large number of new chats coming into Deskie, agents who already correspond with customers are hampered by constantly popping up browser notifications of new chats.

These problems can now be solved with a new action in the rules — "Fixate chat to". It is important not to confuse this action with the designation of an assignee. "Fixate chat to" is similar to "take chat" — it is not the same as designating an assignee. With this action, new chats go directly to the "Mine" tab of a certain agent, skipping the "New" tab.

When a chat is fixated to an agent through rules, standard push notifications are not sent to them when a new chat arrives or a completed chat is activated. If they are needed, add the action Send browser notification toassignee in the chat distribution rules.

(!) Note: The "Fixate chat to" action does NOT take into account agents with the "view-only" access level, as they cannot work with active chats.

Let's take a closer look at the possible use cases.

Distribution of chats among all agents

This distribution type is suitable for small companies where agents respond to all incoming chats regardless of their group. With this setting, incoming chats are evenly (alphabetically) fixated to agents who are available.

c846c3f7cdec59d745e9bbec803fdb1f.png

Note: The agent’s availability is determined by access to cases and active chats in the status settings configured for this agent. If an agent is in a status with the "viewing and handling" option selected for cases and/or active chats, he/she is considered as available. If "view-only" or "no access" options are selected in the status settings for cases and/or active chats, the agent is considered as unavailable.

If there may be a situation where an agent is fixated to a chat, but does not respond before it is automatically ended, you can slightly change this rule so the assignee is set first, and then the chat is fixated to him/her. In this case, agents with the "view-only" access level must be excluded from the "Assign to" action, otherwise, they will be set as assignees without the ability to work with chats.

bea516a4bed99fc2e3bc88ab0e4dcf92.png

As a result, when the chat is ended automatically, the case created by the chat will have an assignee, and agents don't have to decide who should respond to the customer.

Fixating the newly activated chat to the assignee

If an agent ends a chat in the "Open" or "Pending" status, a new message from the customer does not create a new chat, but reactivates the current one. In this case it makes sense to fixate the chat to the assignee and send a notification about the reactivated chat only to them, so as not to distract other agents from their work. To implement this logic, create a rule for updated cases:

aafb3199ed0eea9c099ac846ea863f98.png

If the assignee is not available, then the chat is displayed in the "New" tab of other agents who have access to the chat channel and group.

For cases when a customer sends new messages in a case or an active chat and the assignee is unavailable create a new rule that resets the current assignee and sets a new one from the list of available agents.

ad994902c4c87d94015511564170ba13.png

Distributing chats among agents of a specific group

This option is suitable when you want to distribute chats only between agents who have access to a certain group:

c90dd9c489cb5560e55fd9ba9990aaea.png

If necessary, you can specify multiple groups in the "Assign to" action.

Distribution of cases among specific agents

This distribution type is useful when a large number of agents (including managers and senior executives) have access to a channel or group, but only some of them process cases:

726dc3e962eddda366e9d95c7fdaf783.png

If none of the specified agents is available, then the chat goes to the "New" tab for other agents who have access to the chat channel and group.

Distribution of cases among agents in a specific status

When distributing chats you can take into account specific statuses of agents. For example, you can create a separate status "Training" for new agents and use the rules to distribute simple chats among agents who have this status.

047e47563c843c71d2a58651a8748fe7.png

If in the "Assign to" actions you select specific agents or groups which they have access to, then the logical operator OR is used between these options. For example, when you select two groups, the agents who have access to them are assigned in alphabetical order.

But if you add agent statuses to actions, then the logical operator AND is working between the options by group/agent and status — so the status accounting becomes mandatory.

Let's take a look at some examples.

a) This rule distributes chats among agents with the access to the "Billing" group and the "Training" status set in their account:

5cfacf7956fb6d62f780e8c176632413.png

b) And this rule distributes chats among specific agents if they have the "Training" status set. If some of the specified agents change their status, the rule is not distributing chats among them:

4fde3a2aecc7f760249dd5819d85de50.png

Was this article helpful?