Call distribution principles

When you assign agents to queues, you can define the agents as either primary or secondary for each queue.

Primary and secondary roles are only relevant when agents work in automatic mode, not if agents manually select the inquiries that they want to answer.

Zylinc Novus always considers primary agents first. It'll only consider secondary agents if no primary agents are available.

When primary and secondary agents are both available, Zylinc Novus first distributes inquiries to the primary agents

When only secondary agents are available, Zylinc Novus distributes inquiries to them

If an agent becomes available, and that agent monitors several queues with waiting inquiries, the inquiry from the queue with the highest priority will be routed to the agent, independently of primary and secondary settings. If several queues have the same priority, then Zylinc selects the queue that hasn’t been attended for the longest time.

If you use skill-based routing (part of the queue's advanced settings), it'll take precedence over these policies.

If you define agents as standby on a queue, those agents will only get inquiries from that queue, and subsequently answer them, if a certain threshold is reached. You can base the threshold on any combination of:

• Number of inquiries that wait in the queue
• Number of inquiries that have waited in the queue for more than a specified number of seconds
• The fact that no other agents monitor the queue

When standby agents are called into action on a queue, they become primary agents on that queue for as long as their help is required.

If agents are standby on some queues and primary/secondary on other queues, they'll get inquiries from the queues on which they're primary/secondary. Only when the threshold is exceeded, they'll will also get inquiries from the other queues.

As with primary and secondary agents, inquiries will also be prioritized according to queue priority.

What if the queue balances on the threshold?To avoid that agents go on and off a queue all the time, you can specify an activation threshold as well as a deactivation threshold.

In the Web Agent, agents can themselves select to go in standby mode, in which case they'll go standby on all queues that they subscribe to, regardless of how they've been defined.

First, verify that you've added the people who should work as agents to your Zylinc solution. You can do that through Active Directory integration. Then verify that they have working phones, etc., and that they're mapped to a role that supports agents, typically the User role.

Then, when you've added a queue and defined its basic settings, you can add agents to the queue, and select whether they should be primary, secondary, or standby agents:

1. Log in to your Novus Configuration Manager, and, in the Contact center and PBX configuration section, select Agents.

2. Next to the name of the required agent, click Edit.

3. If the agent hasn't been assigned any queues yet, click the + button in the Agent queue memberships section.

4. In the Queue name field, make sure that you've selected the required queue.

5. In the Subscription role field, select Primary, Secondary, or Standby. If the agent is assigned to multiple queues, make sure to specify a subscription role for each queue.

   Here, we only focus on how to make the agent primary, secondary, or standby on queues. Remember that the agent configuration contains many other important settings.

6. When you're ready, remember to click Save.

1. Log in to your Novus Configuration Manager, and, in the Contact center and PBX configuration section, select Queues.

2. Next to the name of the required queue, click Edit.

3. In the Weight field, specify the required queue weight as a number between 1 and 1000000 (one million). The higher the number, the greater the weight.

   Here, we only focus on how to specify the queue weight. Remember that the queue configuration contains many other important settings.

4. When you're ready, remember to click Save.

1. Log in to your Novus Configuration Manager.

   • If you want your failover to forward calls to another queue, go to the next step

   • If you want your failover to forward calls to an extension, go to step 4

2. On the Configuration Manager home page, in the Contact center and PBX configuration section, select Queues.

3. In the list of queues, copy the name of the queue that you want your failover to forward calls to (that is the queue that should be the destination of the failover).

   

   If you plan to set up several failovers, for example because you want to fail over to one queue if the original queue is open and to another queue if the original queue is closed, you can save time if you copy all required destination queue names and paste them into a text file.

4. On the Configuration Manager home page, in the Contact center and PBX configuration section, select Queue failover.

5. Click Create new, and specify a descriptive name for your new configuration.

6. If you want your failover to forward calls to a queue, paste the name of the queue that should be the destination of the failover into the Name of the queue to send calls to field.

   Settings of the original queue, such as language, announcements, etc., will be kept when calls are forwarded to the destination queue.

   You can't cascade calls across multiple queues: It's possible to send calls from queue A to queue B, but you can't send them from queue A to queue B and then on to queue C.

   You can also choose to forward calls to an extension instead of a queue. In that case you don't need to specify a queue name.

7. In the Failover announcement section, select which audio announcement you want, and whether it should be a system announcement or a custom announcement.

   If you don't want an announcement to be played before the failover, select --- None ---.

8. If you want to forward calls to an extension rather than to a queue, enter the number of the extension in the Address (extension) to forward calls to field.

9. If you selected the extension option in the previous step, select the SIP trunk to use when forwarding a call.

   If you're going to forward calls to an extension that's within the Zylinc Novus system, you don't need to select a SIP trunk.

10. Click Save, and return to the Configuration Manager home page.

11. In the Contact center and PBX configuration section, select Queues. Then click Edit next to the name of the queue that the failover should be performed on (that is the queue that should be the source of the failover).

12. In the Failover thresholds section, select your required failover criteria (that is when the failover should be triggered).

    Example: The field When to fail over inquiries after queue becomes unmonitored determines how long to wait before failing over if there are no longer any agents on the queue, even though the queue's supposed to be open. You enter the waiting time value in the format hh:mm:ss, for example 00:01:10 for one minute and ten seconds.

13. Scroll down the page until you see the Failover behavior while queue is open field, and select the required failover destination.

    When you select failover while the queue is open, it's important that the destination is accessible during the source queue's opening hours.

14. If you want failover when the queue is closed, select the required failover destination in the Failover behavior when queue is closed field.

    When you select failover when the queue is closed, it's important that the destination is accessible when the source queue is closed.

15. When you're ready, remember to click Save.

You can use failover to distribute calls from multiple individual queues to one common queue, for example in a multi-language environment. This way, you can set up distribution rules where inquiries are handled in one common queue, but with settings from the individual queue that they came in on.

Set it up

This works based on the failover settings described in the previous.

Example: You have three language-specific queues, one for English, one for German, and one for French. You set up those three queues to fail over to a fourth multi-language queue if there are no agents on the three language-specific queues during opening hours. You then deliberately use no agents and a very short failover threshold on the three language-specific queues, so that they always fail over to the fourth queue.

Queue timeouts are determined by queue timer configurations that are assigned to one or more queues.

1. Log in to your Novus Configuration Manager, and, in the Contact center and PBX configuration section, select Queue timers.

2. Click Edit next to the name of the required queue timer configuration, or click Create new.

3. Specify the required timeout values.

4. When you're ready, remember to click Save.

If you created a new queue timer configuration, remember to assign it to the required queues.

Agent timeouts are determined by agent timer configurations that are assigned to one or more agents.

1. Log in to your Novus Configuration Manager, and, in the Contact center and PBX configuration section, select Agent timers.

2. Click Edit next to the name of the required agent timer configuration, or click Create new.

3. Specify the required timeout values.

4. When you're ready, remember to click Save.

If you created a new agent timer configuration, remember to assign it to the required agents.

User state describes if an agent is handling a call, and which stage of the handling process the agent is involved in.

When an agent is in offer mode, Zylinc Novus distributes calls according to the following states:

• Idle: Ready to answer calls.

• Unreachable: This state is reached either because the agent didn't answer a call in offer mode, or because a call has been in a queue for longer than allowed.

  Unreachable is considered a temporary state where the agent can still answer calls, and as such the system will still consider a queue to be monitored even if all agents are unreachable. Unreachable agents may, however, get their sessions terminated after a while (see Agent timeouts).

• Busy: On the phone.

• Active: A variation of Busy. The agent is handling one or more chat inquiries, but can still accept additional chat inquiries.

• Wrapup: The agent has just ended a call and isn't yet ready for the next call.

• Offline: The agent is logged in but not monitoring any queues.

An agent's user state is always visible to other agents.

User work state describes which monitoring mode the agent is in. The work state is only changed when the agent explicitly does so. It's never changed based on the call handling.

The possible states are:

• Inactive: Application is started, and subscriptions to queues are started. The system ignores the agent in question, and calls will be sent to failover logic if no other agents are in active or standby modes.

• InactiveQC: Application is started, and subscriptions to queues are started. The system will consider the queues to be monitored, and it'll not send calls to failover as long as at least one agent is in this state.

• Active: Agent is logged in and ready to receive calls on the queues that they monitor.

• Standby: Agent is logged in, but standby mode is activated. The agent will only receive calls from queues where thresholds are exceeded.

• Stealth: Application is started, and subscriptions to all queues are started. Agents in this state will not be visible to other agents. The system ignores this agent, and calls will be sent to failover logic if no other agents are in active or standby modes.

• Offline: Agent's Zylinc program isn't started.

Aggregated state is a combination of agent user state and agent user work state:

If agent user state is idle, and agent user work state is not active, then agent user work state is shown. In all other cases, agent user state is shown.