How Zylinc distributes inquiries to agents

Dette emne er fortrinsvis for administratorer og/eller folk som bestyrer en Zylinc-løsning

With a Zylinc solution, you have complete control over how your solution distributes incoming inquiries to agents on queues (on voice queues this is known as call routing).

You can configure distribution of calls and other inquiries to suit your organization's exact needs, through both agent- and queue-related settings.

For example, you can define agents as primary, secondary, and standby, and that will affect how Zylinc distributes inquiries to them. Likewise, queue settings like caller-rated distribution (also known as VIP routing), failover, etc. affect how Zylinc distributes inquiries.

You can define agents as primary, secondary, and standby, and that will affect how Zylinc distributes inquiries to them.

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 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 first distributes inquiries to the primary agents

When only secondary agents are available, Zylinc 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, 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?LukketTo 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 Zylinc Contact Center and Service Center 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 either Active Directory integration or CSV import. Then verify that they have working phones, etc., and that they're mapped to a profile that supports agents, for example a Zylinc Service Center profile.

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:

You can associate each agent with skills to ensure that Zylinc distributes inquiries that match the skills to certain agents with special knowledge.

Skills can be anything. When you've determined the relevant skills in your organization, you give each agent a value that indicates their level of the skill.

You can set up skill levels for individual agents and skill requirements for individual voice queues.

When you enable skill-based routing, the Zylinc solution creates a table almost like the one in the illustration.

Let’s look at the principles behind the illustration’s table:

Agent A has a motorcycle skill of 7. On the queue, motorcycle skills have an importance of 5, so the Zylinc solution multiplies the agent’s skill (7) with the skill’s importance (5), and gets 35.
Agent A has no truck skills, so we don’t need to calculate anything there, which means that Agent A ends up with an overall skill level of 35.

Agent B has a motorcycle skill of 5. The Zylinc solution multiplies that with the skill’s importance (5), and gets 25.
Agent B also has a truck skill of 3. On the queue, truck skills have an importance of 2, so the Zylinc solution multiplies the skill (3) with the importance (2), and gets 6.
25 plus 6 gives Agent B an overall skill level of 31.

The Zylinc solution performs similar calculations for agents C and D.

When a call comes in, and you use skill-based routing on a queue, Zylinc will first look for the primary agent who has the highest overall skill level, and who is available. If it doesn't find anybody, Zylinc will look among secondary agents who are available, and if it doesn't find anybody there either, it uses the normal distribution method (for example longest idle).

It’s important to remember that it’s the agents’ overall skill levels that the Zylinc solution looks for when it distributes calls to agents, not their individual skills (motorcycle and truck skills in this example).

So, if the queue gets a motorcycle-related call (like in the illustration), and all four agents are available, Agent A will get that call, because Agent A is 1) primary, 2) available, and 3) has the highest overall skill level.

However, if the queue gets a truck-related call, and all four agents are available, Agent A will also get that call, even though Agent B and Agent C know more about trucks than Agent A. Again, this is because Agent A is 1) primary, 2) available, and 3) has the highest overall skill level.

By default, the Zylinc solution keeps caller waiting times as short as possible.

For example, when an agent in automatic mode (that's when the system automatically allocates calls to the agent) becomes idle (that is ready to answer new calls), and there are calls waiting on multiple queues that the agent monitors, the Zylinc solution will select the next call that the agent will get based on how long the call has waited.

However, when you use skill-based routing, making a call go to the available agent with the highest overall skill level can sometimes be more important than how long the call has waited.

That's why its also possible to make agent skills rank higher than how long a call has waited. When you choose that, the Zylinc solution will select the next call for the agent based on how high the agent's overall skill level is. This feature works across queues; you can't specify this behavior for specific queues.

To keep things simple, the illustration in the previous only showed groups of primary and secondary agents. However, there may also be standby agents, who are only called into action if a certain threshold is reached on the queue (see Primary, secondary, and standby agents in the previous).

If such standby agents are called into action, they'll instantly become primary agents. If those standby agents have skills, that fact can affect the original skills hierarchy on the queue: The Zylinc solution may have to rewrite its table of agents’ overall skills, so to speak.

This is not a problem at all. It's just something that you need to be aware of.

To define skill levels for an agent:

  1. In the Administration Portal menu, select USERS > Agents
  2. Click the name of the required agent
  3. Scroll down to the Skill Based routing section, and specify skills, and the agent's level for each skill
  4. When ready, click Save

To define how important skills are on a voice queue:

  1. In the Administration Portal menu, select QUEUES > Voice Queues
  2. Click the name of the required queue
  3. In the top right corner of the page, click ADVANCED
  4. Scroll down to the Skill Based routing section, and specify skills, and how important each skill is for the queue
  5. When ready, click Save

To enable the feature that makes skill-based routing treat agents' overall skill levels as more important than how long calls have waited:

  1. In the Administration Portal menu, select CLIENTS > General Settings
  2. Scroll down to the Queue Default Settings section, and enable Skillbased Routing
  3. When ready, click Save

With historical routing, you can distribute inquiries from a given person to the agent who handled the previous inquiry from that person, provided that the agent is logged-in and active on the queue.

For calls, Zylinc uses the A-number of the caller to identify the caller.

For e-mail inquiries, historical routing ensures that e-mail conversations between particular inquirers and agents are possible. This works based on either the e-mail address of the sender or reference tags in the e-mail header.

For chat inquiries, Zylinc uses the information that people specify when they request to chat.

You can specify a limit for how long back in time you want the Zylinc solution to look.

Setup is slightly different depending on the type of queue:

  1. In the Administration Portal menu, select QUEUES > Voice Queues

  2. Click the name of the required queue.

  3. In the Call Distribution section, look for Historical Routing.

  4. You enable the feature in the On Number field. If you select -default-, it'll use the settings defined under CLIENTS > General Settings, in the Queue Default Settings section's Number/Address fields.

    You can specify a Limit for how many minutes back in time the system should look for the agent. A limit of 0 means that there's no limit.

    Calls distributed by historical routing are treated as returned calls, which means that they'll take priority over other calls that wait in the queue

  5. When ready, click Save.

  1. In the Administration Portal menu, select QUEUES > Chat Queues

  2. Click the name of the required queue.

  3. In the Call Distribution section, look for Historical Routing.

  4. You enable the feature in the On Address field. If you select -default-, it'll use the settings defined under CLIENTS > General Settings, in the Queue Default Settings section's Number/Address fields.

    You can specify a Limit for how many minutes back in time the system should look for the agent. A limit of 0 means that there's no limit.

    Chat requests that are distributed with historical routing take priority over other chat requests that wait in the queue.

  5. When ready, click Save.

  1. In the Administration Portal menu, select QUEUES > Mail Queues

  2. Click the name of the required queue.

  3. In the Call Distribution section, look for Historical Routing.

  4. You enable the feature in the On Address field. If you select -default-, it'll use the settings defined under CLIENTS > General Settings, in the Queue Default Settings section's Number/Address fields.

    You can specify a Limit for how many minutes back in time the system should look for the agent. A limit of 0 means that there's no limit.

    With On Mail-Tag, you can distribute replies to e-mails that have already been handled by an agent to the same agent, based on a private/hidden tag in the mail header.

    E-mails that are distributed with historical routing take priority over other e-mails that wait in the queue.

  5. When ready, click Save.

If an agent who monitors multiple queues becomes available to handle a call, and several of the monitored queues have calls waiting, Zylinc distributes the calls based on a weighting logic:

Example:
Queue A, weighting 2: Call waited 2:00 min. Call rating 2×2 = 4
Queue B, weighting 4: Call waited 1:25 min. Call rating 4×1.25 = 5
Queue C, weighting 6: Call waited 1:00 min. Call rating 6×1 = 6

In the example, the call in Queue A has waited the longest, but because of the weighting of Queue C, Zylinc will first distribute the call from Queue C.

Calls in queues with no weight are always served last, regardless of waiting time.

If a caller is transferred from one queue to another, the caller's initial queue waiting time is credited to the next queue:

Hvis du omstiller et opkald til en anden kø, vil den, der ringer, blive kompenseret for den tid, de allerede har ventet i den første kø. Eksempel: En person venter i fem minutter i kø 1, før vedkommendes opkald bliver besvaret. Nu finder du ud af, at du ikke er den helt rette til at svare på personens spørgsmål, så du omstiller opkaldet til kø 2. Fordi personen allerede har ventet fem minutter i kø 1, får vedkommende automatisk fem minutters “kredit” på kø 2, så vedkommende kommer foran andre, der har ventet mindre end fem minutter i kø 2.

Crediting of initial queue waiting time is a system-wide feature. You can't limit it to certain queues, and you can't disable it.

To set up the weight of a queue:

  1. In the Administration Portal menu, select QUEUES and then either Voice Queues, Chat Queues, or Mail Queues
  2. Click the name of the required queue
  3. In the Call Distribution section, select the required weight
  4. Click Save

Crediting of initial queue waiting time is a system-wide feature, so you don't need to set that up.

With caller-rated distribution, you can prioritize callers based on their phone number. You can use this to prioritize important callers (VIP routing), but also to deprioritize less important callers.

You can enable caller-rated distribution on a per-queue basis. When Zylinc distributes calls, it'll then consider the A-number rating before waiting time. This means that callers with higher rating will be placed in front of callers with lower rating, regardless of the waiting time. Calls will still also be prioritized based on waiting time, but only when comparing calls with same rating.

The higher the number, the higher the priority: If a caller’s A-number isn't defined, the caller will get a rating of 0. Callers with a rating of a positive number will be prioritized over callers without a rating, and callers without a rating will be prioritized over callers who have a negative rating.

Information about caller ratings is retrieved from either:

  • Web service lookup (real-time)

  • Database lookup (real-time)

  • File (.csv) lookup (real-time)

  • Zylinc directory lookup

  • .csv import as new contacts or as additional information about existing contacts/users

  • Edited in Zylinc program, for example by a supervisor

To avoid starvation of deprioritized callers, you can set up a timeout on the negative rating. After the timeout, deprioritized callers will be handled in the same way as callers without prioritization.

See Use A-numbers to change incoming calls' priority.

With caller-rated queueing, you can automatically move callers to another queue based on their phone numbers.

You can enable caller-rated queueing on a per-queue basis based on the following settings:

  • Never

  • If Available: Only move call if the target queue is open and monitored

  • Always: Always move the call, regardless of the status of the target queue

Information about caller ratings is retrieved from either:

  • Web service lookup (real-time)

  • Database lookup (real-time)

  • File (.csv) lookup (real-time)

  • Zylinc directory lookup

  • .csv import as new contacts or as additional information about existing contacts/users

  • Edited in Zylinc program, for example by a supervisor

See Use A-numbers to send incoming calls to specific queues.

Each voice queue and chat queue can have separate settings for how to handle incoming inquiries in cases where no agent can handle them.

Because you often need to have different settings for inside and outside of opening hours, the Zylinc failover settings are divided into:

  • Failover—queue open

    • Queue is open, but it has been unmonitored for a period of time
    • Queue is open, but it has reached its limit

  • Failover—queue closed

You can cover these scenarios:

  • Forward call to another queue
  • Forward call to a number
  • Disconnect call
  • Optionally, play an announcement before any of the above

There is a difference between a call being forwarded to another queue and a call being forwarded to the number of another queue. The latter is considered a new call when it's placed in queue, whereas the first will keep settings from the original queue. This means that when a call is forwarded to another queue; settings such as language, music on hold, failover settings, and announcements from the first queue still apply. From the second queue, only settings related to call distribution, such as weighting, will be used. Opening hours of both queues will be validated but if the queue is closed the action to take will in both cases be decided by the settings of the first queue.

Setup is slightly different depending on the type of queue:

  1. In the Administration Portal menu, select QUEUES > Voice Queues

  2. Click the name of the required queue.

  3. In the Failover - Queue Open section, specify how the queue should handle exception scenarios during its opening hours, for example if the number of calls in the queue exceeds the limits that you specified in the Thresholds section, or if there are no agents on the queue:

    • Unmonitored Queue: What to do if there are no longer any agents on the queue, even though the queue's supposed to be open. Select Failover Action to send calls to the queue that you can specify in the following field. Select Queue Calls to keep calls in the queue and ignore the following failover settings when the queue is open.

    • Failover queue: Alternative queue to send calls to if you've selected Failover Action in the previous. Settings for the original queue, such as language, announcements, etc., will be kept when calls are moved to the alternative queue.

      Make sure that the alternative queue has opening hours that match those of the original queue.

      You can't cascade calls across multiple alternative 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.

      If transferred calls should use settings from the alternative queue, use failover forwarding (see the following) and a local extension in the SIP trunk instead.

    • Failover Announcement: An announcement that's played to callers in case of failover. If you've specified an alternative queue in the previous, the failover announcement is only played if the alternative queue is also closed or doesn't have any agents.

    • Failover Forwarding: Lets you forward calls to a specific number, rather than to an alternative queue. If you've specified a failover announcement in the previous, the announcement will be played before calls are forwarded. Also specify the SIP Trunk to use for the forwarding number. If you're going to forward calls to a number that's within the Zylinc system, select - Local Extension -.

    • Failover IVR: Lets you send calls to an IVR menu. Settings for the original queue, such as language, announcements, etc., will be kept when calls are moved. That in turn means that if a call ends up in another queue after the IVR menu, the call will use settings from the original queue.

      If transferred calls should use settings from the alternative queue, use failover forwarding (see the previous) to the IVR number and a local extension in the SIP trunk instead.

  4. In the Failover - Queue Closed section, specify how the queue should handle exception scenarios outside of its opening hours, for example if someone calls the queue when it's closed.

    • Queue: Alternative queue to send calls to when the original queue is closed. Settings for the original queue, such as language, announcements, etc., will be kept when calls are moved to the alternative queue.

      Make sure that the alternative queue is open when the original queue is closed.

      You can't cascade calls across multiple alternative 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.

      If transferred calls should use settings from the alternative queue, use forwarding (see the following) and a local extension in the SIP trunk instead.

    • Closure Announcement: An announcement that's played to callers when the queue is closed. If you've specified an alternative queue in the previous, the closure announcement is only played if the alternative queue is also closed or doesn't have any agents.

    • Forwarding: Lets you forward calls to a specific number, rather than to an alternative queue. If you've specified a closure announcement in the previous, the announcement will be played before calls are forwarded. Also specify the SIP Trunk to use for the forwarding number. If you're going to forward calls to a number that's within the Zylinc system, select - Local Extension -.

    • IVR: Lets you send calls to an IVR menu. Settings for the original queue, such as language, announcements, etc., will be kept when calls are moved. That in turn means that if a call ends up in another queue after the IVR menu, the call will use settings from the original queue.

      If transferred calls should use settings from the alternative queue, use forwarding (see the previous) to the IVR number and a local extension in the SIP trunk instead.

  5. When ready, click Save.

  1. In the Administration Portal menu, select QUEUES > Chat Queues

  2. Click the name of the required queue.

  3. Scroll down to the Failover - Queue Open section.

    • Unmonitored Queue: What to do if there are no longer any agents on the queue, even though the queue's supposed to be open. Select Failover Action to display one of the texts that you can specify in the following fields. Select Queue Calls to keep chat requests in the queue and not display any of the texts.

    • Queue Full Text: Specify the text announcement that inquirers should see if the queue has reached the maximum allowed number of chat requests.

    You can use the variable $queue$ to insert the queue's name in the text announcements.

  4. In the Failover - Queue Closed section, specify the text announcement that inquirers should see when the queue is closed.

  5. When ready, click Save.

You can distribute inquiries 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.

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 on the three language -specific queues, so that they always fail over to the fourth queue.

All administrator-defined queues are considered public. In addition, each agent also has their own virtual private queue. Whether a call is in a private or in a public queue is indicated in the queue overview in the agent's Zylinc program.

The following rules apply for the relationship between public and private queues:

  • If no agent is available in automatic mode, inquiries are always placed in the public queue.
  • When an inquiry is distributed to an agent, it's taken out of the public queue.
  • If an agent transfers an inquiry, and the transfer fails, the inquiry is always returned to the private queue, if the original agent still monitors it (that is, they're either available, unavailable, or busy). If the original agent no longer monitors the queue, the inquiry is returned to the public queue that it came from.
  • Upon Private Queue Timeout, a returned inquiry in the private queue is placed in the public queue that it came from.

Queue timeout settings can also affect how inquiries are distributed:

  • Public timeout: Determines the amount of time for which inquiries are kept in a queue after the last agent has logged out of the specific queue.

  • Private (moved) timeout Determines the amount of time for which inquiries are kept in a private queue before they're made available on other queues.

  • Private (callbacks) timeout: Determines the amount of time for which callbacks are kept in a private queue before they're made available on other queues. This timeout setting is only available on voice queues.

  1. In the Administration Portal menu, select QUEUES and then either Voice Queues, Chat Queues, or Mail Queues.
  2. Click the name of the required queue.

  3. In the Timers section, specify how long inquiries should be kept under specific circumstances:

    • Public: The amount of time that inquiries should be kept in the queue after the last agent has logged out of the queue.

    • Private (Moved): The amount of time that inquiries that have been placed in an agent's private queue should be kept in the private queue before being made publicly available to other agents on the queue. An inquiry is typically placed in a private queue if one agent (A) answers the inquiry, and then transfers it to another agent (B). The inquiry will then be in agent B's private queue.

    • Private (Callbacks): This timeout setting is only available on voice queues. The amount of time that callbacks that have been placed in an agent's private queue should be kept in the private queue before being made publicly available to other agents on the queue. A callback can only end up in an agent's private queue if it's been transferred from another agent before calling.

    If you select - default -, the Zylinc solution will use the global timers that you can manage under CLIENTS > Global Timers.

  4. Click Save

The following timeout settings affect the distribution of inquiries. You can define those timeouts globally for all queues.

  • Manual Mode Idle Timeout: Determines the period of time that an agent in manual mode should be allowed to ignore calls in the queue. On timeout, the agent is forced into the unavailable status. The timer is started for all agents in manual mode when a call enters the queue, and it's stopped every time the queue is emptied or an agent answers a call.

  • Unavailable Timeout: Determines the period of time that agents can be in unavailable status before the Action on timeout is applied.

  • Action on timeout: Determines what should happen to agents after the Unavailable Timeout. They can either be disconnected or returned to available status.

Each Zylinc client profile, for example Service Center, uses a timer profile that determines the timeouts. Thus, the timeouts in the timer profile will apply for all agents who use the client profile, for example for all agents who use Service Center.

  1. In the Administration Portal menu, select CLIENTS > Timer Profiles
  2. On the bottom part of the page, locate the required client profile, for example Service Center, and check which timer profile it uses
  3. Then, in the upper part of the page, click the name of the timer profile, and edit the timeouts as required
  4. Click Save

Queues' states, directly or indirectly, affect how Zylinc distributes inquiries.

A public queue can be in one of the following states:

  • Open
  • Monitored: At least one agent monitors the queue
  • Unmonitored: No agents monitor the queue
  • Closing: Queue is about to be closed, but existing calls are still handled
  • Closed: Queue is closed, and no calls will be handled

A private queue can be in one of the following states:

  • Monitored: The agent is logged in
  • Unmonitored: The agent has recently logged out
  • Closed: The agent has been logged out for a while

In Zylinc Attendant Console and Service Center, agents can select which working mode they prefer: Automatic, manual, or Follow Me (which is a special kind of automatic mode).

In other Zylinc clients, agents always work in automatic mode.

In automatic mode, Zylinc offers calls to agents as soon as they become available. Automatic mode is useful if inquiries should always be answered in the order they appear, and if agents prefer to not have to select inquiries from queues themselves. Automatic mode can also be useful during busy hours, because it ensures that inquiries are offered to agents as soon as they arrive.

Calls are offered on a per-agent basis in one of two ways:

  • Route offered calls: Call is immediately distributed to the agent's phone when being offered, the phone will ring, and when the agent accepts the call, the phone is automatically answered.

    Advantages: Calls can be accepted on the phone. Less delay when agent accepts call.

  • Offer calls before routing: Call is first offered in the agent's Zylinc program, and when the agent accepts the call, the call is distributed to the phone and automatically answered.

    Advantages: Calls aren't taken out of the queue when offered. Better support for phones where the call can't be controlled by Zylinc.

A general setting Show Offered Calls in Auto-mode allows other agents to pick up (“steal”) the call, even if the call is being offered to an agent. You can use that setting to optimize answering of calls, because the agent that wants the call doesn’t have to wait for No Answer timeout, if the agent who's being offered the call is unavailable.

When agents work in automatic mode, the following call distribution order applies:

  1. Primary

  2. Secondary

  3. Primary - Follow Me

  4. Secondary - Follow Me

  5. Standby

  6. Standby - Follow Me

This, for example, means that calls are routed to an available secondary agent before an available primary agent in Follow Me mode.

This behavior can be changed per queue, so that agents in Follow Me mode are treated as working in automatic mode, that is calls will be distributed to agents in Follow Me mode, even if agents who work in manual mode are available. To do that in the Zylinc Administration Portal, select QUEUES > Voice Queues > [required queue], then scroll down to the Call Distribution section, and select Automatic next to Follow Me Priority. Remember to save your change.

In manual mode, agents must manually select calls from the queue. Manual mode is useful if agents prefer to have control of the order in which they answer calls.

Follow Me is a special mode that lets agents handle incoming calls without having to sit at their desks. It's primarily intended for agents with other tasks than answering calls, but it's also useful if agents simply need to be able to handle calls during breaks.

In Follow Me mode, Zylinc automatically distributes calls to the agent, and the agent can answer calls and transfer them if required.

Agents in Follow Me mode are always prioritized lower than automatic mode, because in Follow Me mode agents have fewer features available.

A setting called Follow Me Priority, which is configured per queue, decides if agents in Follow Me mode should automatically receive calls if other agents are logged in to the queue in manual mode. If Follow Me Priority isn't set to Automatic, any agent who monitors the queue (even an inactive agent) is prioritized higher.

Agents' states, directly or indirectly, affect how inquiries are distributed.

An agent's user state describes the availability of the agent, whereas an agent's user work state describes which monitoring mode the agent is in.

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 automatic mode, Zylinc 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 automatic mode, or because a call has been in a queue for longer than Manual Mode Idle Timeout (see Agent timeouts) allows. In older versions, this state was called Unavailable.

    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 unavailable.

  • 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 user 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 he or she monitors.

  • 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, wallboards, etc. The system ignores this agent, and calls will be sent to failover logic if no other agents are in active or standby modes. In older versions, this state was called Monitoring, and it was only used by system clients.

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

By default, Attendant Console and Service Center agents enter the Inactive state when they select Logout or Inactive, whereas Contact Center agents enter the InactiveQC state. You can change this behavior in the Administration Portal.

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.

Aggregated state is what's used by Zylinc Wallboard.