Routing Multiple Collaborations to Experienced Agents

Routing Help Seeker (customer) to CS (agent) concurrently

  • ISS/ admin can update This number for an individual CS based on need.

Routing needs to be individual-based i.e a new CS (agent) might only take one but an experienced CS takes 2. This requirement could affect service delivery/ amount of contacts answered.

Will consider this feature in the future release. It’s not available for now.
For now, the agent can change his state to not-ready when he cannot handle more requests.

What we are discussing within the team is listed below. We’ll embed channel differentiation first ( certain chat channel being more rapid), and in a second phase velocity differentiation per agent). This second feature is likely to become available in Q4/2020 or Q1/2021

Routing criteria for chat

The number of parallel chat sessions should be determined individually per agent and chat channel dependent on the following criteria:

Media dependent routing

A table will indicate how many chat sessions a beginner agent should be able to handle in parallel. In this table, one should be able to set the number of parallel sessions per agent per channel.

Depending on chat channel type (many SMS sessions, few Webchat sessions)

Based on agent speed. This is in addition to usual skills/ attributes

This multiplying factor will enable an experienced agent to handle more chat sessions in parallel than a beginner agent. This multiplying factor exists once per agent, independently of all other agent skills. This factor reduces the Erlang load of chat channels for a specific agent.

Example calculation of workload per agent:

Example base parallel sessions: SMS: 4, Whatsapp: 2, webchat: 1 (which is to say that an SMS session occupies 0.25 Erlang, Whatsapp 0.5 Erlang, Webchat 1 Erlang)

  • A beginner would get either
    • four SMS, two Whatsapp
    • one webchat session.
  • An intermediate with level 1.5 would get either
    • 6 SMS
    • 3 Whatsapp
    • 1.5 chat
    • 4 SMS and 2 Whatsapp
    • 1 Whatsapp and 1 Webchat
  • An sprinter with level 2 would get either
    • 8 SMS
    • 4 whatsapp
    • 2 webchat
    • 4 SMS and 2 Whatsapp
    • 2 Whatsapp and 1 Webchat

=> the routing engine will continuously calculate the current workload per agent, and assign tasks to agents based on their current workload.

=> This might replace the current “routable” parameter which is currently between 0 and 1

Erlang calculation

We might also want to do an Erlang calculation: How many Erlangs of traffic do we have overall in the call center (counting each call at 1 Erlang, and in the example above each SMS session at 0.25 Erlang).

If the total Erlang chat traffic for agents is lower than the overall chat Erlang traffic, chats from one agent are distributed to other agents, and that agent is freed to pick up voice calls.

The Erlang traffic for each agent is continuously updated