In your callback script, you can establish criteria for offering a caller a courtesy callback. Examples of callback criteria include:

• Number of minutes a customer is expected to be waiting in queue that exceeds a maximum number of minutes (based on your average call handling time per customer)

  Note	The included example scripts use this method for determining callback eligibility.

• Assigned status of a customer (gold customers may be offered the opportunity to be called back instead of remaining on the line)

• The service a customer has requested (sales calls, or system upgrades, for example, may be established as callback criteria)

If the caller decides to be called back by the system, they leave their name and phone number. Their request remains in the system and the EWT fires when the system places a callback to the caller. The caller answers the call and confirms that they are the original caller, and the system connects the caller to the agent after a short wait.

Note	Courtesy Callback is supported for IP originated calls as well.

A typical use of the Courtesy Callback feature follows this pattern:

1. The caller arrives at Unified CVP and the call is treated in the IVR environment.

2. The Call Studio and Packaged CCE Courtesy Callback scripts determine if the caller is eligible for a callback based on the rules of your organization (such as in the prior list of conditions).

3. If a courtesy callback can be offered, the system tells the caller the approximate wait time and offers to call the customer back when an agent is available.

4. If the caller chooses not to use the callback feature, queuing continues as usual.

   Otherwise, the call continues as indicated in the remaining steps.

5. If the caller chooses to receive a callback, the system prompts the caller to record their name and to key in their phone number.

6. The system writes a database record to log the callback information.

   Note	If the database is not accessible, then the caller is not offered a callback and they are placed in queue.

7. The caller is disconnected from the TDM side of the call. However, the IP side of the call in Unified CVP and Packaged CCEis still active. This keeps the call in the same queue position. No queue music is played, so Voice XML gateway resources used during this time are less than if the caller had actually been in queue.

8. When an agent in the service/skill category the caller is waiting for is close to being available (as determined by your callback scripts), then the system calls the person back. The recorded name is announced when the callback is made to insure the correct person accepts the call.

9. The system asks the caller, through an IVR session, to confirm that they are the person who was waiting for the call and that they are ready for the callback.

   If the system cannot reach the callback number provided by the caller (for example, the line is busy, RNA, network problems, etc.) or if the caller do not confirm they are the caller, then the call is not sent to an agent. The agent is always guaranteed that someone is there waiting when they take the call. The system assumes that the caller is already on the line by the time the agent gets the call.

   This feature is called preemptive callback as the system assumes that the caller is already on the line by the time the agent gets the call and that the caller has to wait minimal time in queue before speaking to an agent.

10. The system presents the call context on the agent screen-pop, as usual.

In the event that the caller cannot be reached after a configurable maximum number and frequency of retries, the callback is stopped and the database status is updated appropriately. You can run reports to determine if any manual callbacks are necessary based on your business rules.

See the Configuration and Administration Guide for Cisco Unified Customer Voice Portal http://www.cisco.com/en/US/products/sw/custcosw/ps1006/products_installation_and_configuration_guides_list.html guide which provides a call flow description of the function of the scripts that provide the Courtesy Callback feature.

The following design considerations apply for Courtesy Callback feature:

• During Courtesy Callback, callback is made using the same Ingress Gateway through which the call arrived.

  Note	In Courtesy Callback, outbound calls cannot be made using any other Egress Gateway.

• Calls that allow Callback must be queued using a Unified CVP VXML Server.

• The Unified CVP Reporting Server is a prerequisite for Courtesy Callback.

• Answering machine detection is not available for this feature. During the callback, the best that can be done is to prompt the caller with a brief IVR session and acknowledge with DTMF that they are ready to take the call.

• Calls that are transferred to agents using DTMF *8, TBCT, or hookflash cannot use the Courtesy Callback feature.

• Callbacks are a best-effort function. After a limited number of attempts to reach a caller during a callback, the callback is terminated and marked as failed.

• Customers must configure the allowed or blocked numbers that Callback is allowed to place calls through the Unified CVP Operations Console.

• Media inactivity detection feature on the VXML Gateway can impact waiting callback calls. For more information, see the Configuration Guide for Cisco Unified Customer Voice Portal (CVP).

• Courtesy Callback requires an accurate EWT calculation for its optimal behavior.

  Consider the following recommendations to optimize the EWT, when using Precision Queues for Courtesy Callback :

  • Queue the calls to a single Precision Queue

  • Do not include a Consider If expression when you configure a step.

  • Do not include a wait time between steps or use only one step in the Precision Queue.

The following discussion provides an overview of the scripts used for the courtesy callback feature. There are nine numbered blocks, or sets of blocks, identified in the following figure.

Note	In the following example, the yellow comment blocks describe first the value being set and then the place where the value is being sent.

The following bullets provide descriptions for the numbered blocks in the preceding graphic:

• Block 1: Enable callback or shut it off.

• Block 2: Compute average wait time. Once the caller is in queue, calculate the Estimated Wait Time (EWT) for that queue and place the value in ToExtVXML[0].

  If there is poor statistical sampling because of sparse queues and the wait time cannot be calculated in the VXML Server, use the ICM-calculated estimated wait time.

  One method of calculating EWT (the method used in this example) is:

  
                              ValidValue(((SkillGroup.%1%.RouterCallsQNow+1)
                              *
                              (ValidValue(SkillGroup.%1%.AvgHandledCallsTimeTo5,20))
                              /max(
                              SkillGroup.%1%.Ready,
                              (SkillGroup.%1%.TalkingIn
                              +
                              SkillGroup.%1%.TalkingOut
                              +
                              SkillGroup.%1%.TalkingOther))
                              ),100)
  
                                  

  Modify this method if you are looking at multiple skill groups (when queuing to multiple skills).

• Block 3: Set up parameters to be passed.

• Block 4: Run this block and prompt the caller. If the caller does not accept the offer for a callback, keep the caller in the queue and provide queue music.

• Block 5: Set up variables. Call flow returns to this block if the caller elects to receive a callback. Otherwise, the call remains queuing in the queuing application (BillingQueue in this example) on the VXML Server.

• Block 6: Run external to Callback engine to keep the call alive. If the agent becomes available and there is no caller, then agent can't interrupt (do not want an agent to pick up and have no one there).

• Block 7: Has the caller rejected the callback call? If no, then go to block 8.

• Block 8: Compute average wait time, as in block 2.

• Block 9: Set up variables.

• Block 10: Put caller briefly into queue (after caller accepts the actual callback call).