Virtual Queue Tutorial Bright Pattern Documentation Generated: 11/01/2024 12:02 am

Content is available under license unless otherwise noted.

Overview

Virtual Queueing, also referred to as Callback Option, is an enhancement of the regular automatic call distribution method (ACD) used in inbound call centers. During periods of significant wait times, this option allows customers to hang up the call while keeping their position in the service queue and to receive a callback when it is their turn to be connected to an agent. The benefits of using the virtual queueing include:

• improved customer satisfaction – after requesting a callback customers get back to their normal activities instead of being tied on the phone
• reduced abandonment rates – customers who can continue their normal activities are less likely to abandon their service requests (i.e., to ignore the callback)
• reduced talk time – customers waiting in a virtual queue are less likely to spend any time venting their frustration with a long wait when they are finally connected to an agent
• lower telco costs – customers waiting in a virtual queue do not occupy physical voice channels

ServicePattern Virtual Queue works in the following way:

For each incoming service call, the system calculates its estimated waiting time in queue (EWT). If this time exceeds a threshold EWT value pre-configured for the given service, the system notifies the calling customer about the wait time and offers him the option of receiving a callback when it is his turn to be connected to an agent. The customer can request the callback to be made to the phone he is calling from or to a different number that he can enter using the keypad of his phone. The original live call is then disconnected while customer’s position in the service queue is maintained by the system as if he remained on the line (hence the name Virtual Queueing). When it is customer’s turn to be connected to an agent, the system makes an outbound call to the designated callback number. Upon answer this call is connected to an available agent. To the agent, the answered callback appears as a regular incoming call.

Because callbacks may not always be answered immediately, and sometimes not at all, the system does not explicitly “reserve” agents for callback attempts. (Doing so would affect agent availability and increase the overall queueing times.) Instead, the system constantly re-calculates the EWT of a virtual call to allow for maximum precision in predicting the moment when an agent will become available to take this call.

If an agent becomes available for a given virtual call before the estimated wait time, the callback is made at the moment when the agent becomes available. Otherwise, the callback attempt is made a few seconds before EWT expiration based on the prediction that an agent will have become available by the time the callback is answered by the customer. If an agent does not become available at that time, the answered call is placed in the first position in the service queue to be connected to the next available agent. An IVR announcement can be played for the answered callback to prevent the customer from hanging up a call if it cannot be immediately connected to an agent.

Subsequent processing of answered callbacks delivered to agents is no different from processing of calls waiting in the queue.

Configuration

To configure a virtual queue (VQ) for your existing inbound voice services, follow these steps:

Step 1. In the Contact Center Administrator application, navigate to Scenarios > Voice, and open the scenario that is used for distribution of calls to the services for which you would like to enable VQ.

Step 2. Using the Save As button, save this scenario under a new name.

Step 3. Within this new scenario, select the Find Agent block that is used to distribute calls to a particular service for which you would like to enable VQ.

Step 4. In the Virtual Queue option section of this Find Agent block, select the checkbox and specify the estimated wait time (EWT) threshold; the VQ option will be offered only if the EWT of a given call exceeds the threshold value entered here.

Virtual Queue option in Find Agent block

Step 5. Select the Callback button, i.e., the dial pad digit that the caller will press to accept the VQ option.

Step 6. Create the EWT Announcement (if not created already), e.g., “The estimated waiting time is; Estimated Waiting Time;” where Estimated Waiting Time is a voice segment of the EWT type.

EWT Announcement

Step 7. Create the Virtual Queue availability announcement that will be used to offer the VQ option to the caller, e.g., “To hang up now and have us call you back once a representative is available, press [digit] at any time” where digit is the digit selected in step 5.

Step 8. For the Callback exit of the Find Agent block, insert a Request Callback block and define its parameters:

• Confirmation prompt - confirms the callback request, e.g., “Thank you. We will call you back.”

• Callback phone - specifies the phone number that the callback will be made to. If callbacks will always be made to the phone that was used to make the original call, you can use the $(item.from) variable here, which is the Caller ID of the original call. If, however, you want to give the customer a choice of providing another phone number for callback, you should use a combination of scenario blocks Set Variable, Menu, and Collect Digits as illustrated in the example offered in this tutorial. In this case, set the Callback phone to the new variable you define in the Set Variable block.

• Cancel request after specifies the amount of time after which the virtual calls will be terminated if no matching agents are found.

• Start dialing specifies how far in advance of the EWT expiration moment the callback attempt will be made. Note that if an agent becomes available earlier for the given call, the callback will be placed at that moment.

• No Answer Timeout specifies how long the block will wait for the customer to answer the callback attempt before taking the No Answer exit.

Request Callback block

Step 9. The normal exit of the Request Callback block is taken when the callback attempt is answered before the specified No Answer Timeout expires. Instead of connecting the answered call directly to the Find Agent block for immediate distribution to an agent, it is a good practice to use an IVR prompt to announce to the customer that this is his requested callback. This explains the purpose of the call to the customer and, more importantly, prepares him for a possible short waiting time in case an agent is not immediately available. The example below uses the Menu block to make such an announcement and to wait for customer’s confirmation before passing this call to the Find Agent block for distribution.

Step 10. Use the conditional exits of the Request Callback block to define what happens when the callback attempt meets various ‘abnormal’ conditions, such as No Answer or Busy. In the example below, the call is terminated under any such conditions. You can define a different type of reaction, such as a repeated callback attempt in case of No Answer.

Step 11. Repeat steps 4 through 10 for other Find Agent blocks of this scenario that are used to distribute calls to other services for which you would like to enable VQ.

Step 12. Save the new scenario.

Step 13. To complete the remaining VQ configuration steps, open the Contact Center Administration application.

Step 14. As with any other significant service configuration change, the new scenario should be first tried in a test environment. Create a test dial-in scenario entry, associate it with your new scenario and make some test calls imitating various VQ conditions to make sure everything works as you expect.

Step 15. Pick a time when your call center is closed for business and replace your current production scenario with the VQ-enabled one in the dial-in scenario entries where the current scenario is used. (These scenario entries will appear in the Scenario Entries tab when you select your current scenario in the Scenarios > Voice list view. To make the replacement, click one of the listed dial-in scenario entries and select the new scenario from the Scenario drop-down list.)

Step 16. The configured VQ will not be operational until it is explicitly activated for the desired services. To activate the VQ function for a particular service for which it was configured as described above, select the Enable callback functionality checkbox in the Properties tab of that service. Before you activate the VQ function for all other services where it may have been configured, consider using the Virtual Queue Report to monitor VQ performance within the service where it has been activated and to adjust its parameters if necessary. See section Reporting for more information.

Scenario Example

The screenshot below shows a fragment of an inbound voice scenario with VQ-related logic. This scenario is based on the Virtual Queue (Callback) scenario template. You can open this template in the Scenario Builder application and review the settings of each block involved in this scenario.

The main scenario flow is briefly explained below:

• The Virtual Queue option is offered in the Find Agent block as described in section Configuration.
• Callers that prefer to wait online will remain in the Find Agent block until it is their turn to be connected. Callers that accept the Virtual Queue option exit this block via the Callback exit.
• The callback number is initially set to the value of $(item.from) which is the caller ID of the original call.
• The scenario then uses a few If blocks to ensure the caller ID is dialable and is not a 1-900 number. Note that the length() function is used to check the number of digits.
• The Menu block that follows will ask the caller to choose the callback number (either use the current phone or enter a different call back phone number).
• If the caller selects a different callback phone number, the Collect Digits block is used next to collect the new number followed by a few If blocks to ensure the entered number is dialable and is not a 1-900 number. Note that the length() function is used to check the number of digits.
• Once the callback number is identified, the call is passed to the Request Callback block. This block confirms the request, disconnects the original call, places the associated callback request in the virtual queue, waits for a matching agent, and makes the callback when an agent becomes available or EWT expires.
• The Menu block that follows announces the purpose of the call to the party that answers the callback attempt. This is done to make sure the call is connected to the right party.
• The call is then handed over to the Find Agent block for distribution to an agent. Note that if despite the EWT prediction no agents are immediately available, the call will be placed in the first position in the service queue to be picked up by the next agent who becomes available.
• As usual, the Connect Call is used to connect the call to the agent identified by the Find Agent block.

Reporting

The general real-time and historical service metrics treat virtual calls as if they were regular inbound calls waiting in the physical queue. Calls that select the Virtual Queue option are counted as Queued. Successful callbacks (i.e., answered by customers and connected to agents) are counted as Answered, while unsuccessful callbacks (unanswered, busy, or answered but abandoned before being connected to agents) are counted as Abandoned in Queue.

In addition, both real-time and historical reporting functions provide a number of metrics that focus specifically on the VQ functions.

To illustrate the above, let’s consider the following example:

100 customers have called a service since the start of the day up to the present moment.

• 40 of those customers have selected the VQ option, of which:
  • 25 answered the callbacks and were connected to agents
  • 1 answered the callback but hang up before being connected to an agent
  • 3 did not answer when called back
  • 1 was busy when called back
  • 10 are still waiting for a callback at the present moment
• 60 of those customers have selected to remain on the line, of which:
  • 40 were connected to agents
  • 12 abandoned their call attempts after waiting for a while in the queue
  • 8 are still waiting in the queue at the present moment

The real-time service metrics view will show the following numbers for this service (only the relevant metrics are listed):

• IN Received = 100
• IN Queued = 100
• IN Queue Abandoned = 17 (3+1+1+12)
• IN Handled = 65 (25+40)
• IN ASA = (sum of wait times of the 65 answered calls) / 65
• IN Waiting = 18 (10+8)
• IN Max Wait = the current waiting time of the longest of the 18 calls currently waiting in queue
• CB Requested = 40
• CB Waiting = 10

For the formal definitions of the above real-time metrics, see section List of Service Metrics of the ServicePattern Supervisor Guide.

Now let’s assume that all of the live and virtual calls that were waiting in the queue in the above example were eventually connected to agents and that no other calls were made to the service on that day.

The historical Service Metrics Report for that day will show the following numbers for this service (only the relevant metrics are listed):

• Number of Calls Received = 100
• Queued = 100
• Abandoned = 17 (3+1+1+12)
• Abandonment Time = (sum of time in queue of the 17 abandoned calls) / 17
• Answered = 83 (25+40+10+8)
• Average Speed of Answer = sum of wait times of the 83 answered calls / 83

The historical Virtual Queue Report for that day will show the following numbers for this service:

• Callbacks Requested = 40
• Callbacks Requested Ratio = 40% (40/100)
• Callbacks Busy = 1
• Callbacks Busy Ratio = 2.5% (1/40)
• Callbacks No Answer = 3
• Callbacks No Answer Ratio = 7.5% (3/40)
• Callbacks Answered = 35
• Callbacks Answered Ratio = 87.5% (35/40)
• Average Wait Time to Callback = (sum of time in queue of the 40 virtual calls) / 40
• Average Callback Dialing Time = (sum of dialing times of the 35 answered callbacks) / 35
• Average Agent Answer Time = (sum of connection times of the 35 answered callbacks) / 35
• Callbacks Abandoned = 1 (1/40)
• Callbacks Abandoned Ratio = 2.5%