Understanding Trailhead Destinations

The Trailhead software package gathers information about a caller placing a Web-based request and submits it to the ICM. A script set up in the ICM receives the caller data and performs all routing logic, ensuring the call can be routed to an appropriate location. At this point, Trailhead again takes over, receiving ICM script output and providing appropriate response to the Web request.

ICM scripts route calls to call centers at different locations. The script returns labels, which are simply strings that identify each call center. With Trailhead, you set up destinations that correspond to each label. For each destination, you can specify the type of response that should be provided to the Web request (Basic Callback or Callback and Web Collaboration, as explained below).

Destinations are defined by the Trailhead.properties file on the Trailhead medium, which resides on the Media Blender server. You can set up destinations that:

Destinations that provide successful response to Web callback requests

Destinations can be set up to provide these types of response:

Basic Callback--With Basic Callback, the caller who placed a Web request receives a call back from an agent. When a destination is set up to provide Basic Callback only:

When you create destinations that provide Basic Callback, you assign them a CALLONLY destination type. This means that requests submitted to this destination are queued internally to the switch.

Basic Callback and Web Collaboration--In configurations that include the Cisco Collaboration Server (CCS), Trailhead can ensure that callers participate in a Collaboration session. Web collaboration allows callers to interact and share information with agents over the Web. The caller and agent can share Web pages, forms, or applications using a Web browser (See the CCS documentation for supported Web browsers).

When responding to a request for collaboration:

When you create destinations that provide Web Collaboration, you assign them a COLLAB destination type. This means that requests submitted to this destination are queued externally, to the Collaboration Server. See Setting destination type, in the Configuring destinations section of this guide for more information.

How destinations reflect your call centers

Trailhead Destinations do not necessarily reflect individual call centers within your enterprise. Instead, they reflect a type of response provided to incoming Web requests. For example, consider a configuration that includes these two call centers:

To accommodate this configuration, set up Trailhead destinations as follows:

This call center...

...requires this many Trailhead destinations

Boston

One destination, that provides Web Collaboration

San Jose

Two destinations. The first destination provides Web Collaboration; the other destination should provide Basic Callback for those agents who do not have access to Collaboration.

Destinations that handle situations when response is not available

You also set up destinations that correspond to ICM labels that indicate web response is not available. For example, you can set up a noagents destination to inform the caller of the situation. You could also set up a holiday destination, to handle situations when a call center is closed due to a holiday.These destinations serve URLs to callers, informing them of the reason response is unavailable. These are referred to as noncalling destinations.

Destinations that handle ring, busy, error, and default ICM conditions

The ICM script can return special terminations rather than labels. These terminations are:

Although these terminations can be used to indicate that response is not available, you can also use them to handle crank or otherwise troublesome telephone calls.