LinkedIn
Copied!

Table of Contents

Call flow for Cisco ICM integration

The following image presents a graphical overview of a call flow.

Cisco call engine flow diagram

Call flow overview

For this scenario, a call moves through the system according to the diagram above. The relevant steps in the call flow are numbered and corresponded to the following steps. Some steps include events that occur simultaneously in different parts of the system. The steps for these events have the same number. For example, step seven appears three times in the diagram. The call flow consists of the following steps:

  1. The call comes into the PBX/ACD from the PSTN.
  2. As soon as the call arrives at the PBX/ACD, it is routed to the IVR (also called a VRU).
  3. Caller identification, such as account number, is gathered in the IVR. The caller proceeds with automated IVR inquiries such as account balance. This information is typically obtained from various backend systems or databases.
  4. When the caller chooses to speak with an agent, the IVR passes information about the call in progress to the Cisco ICM via the Cisco Peripheral Gateway (PG). This is commonly known as attaching data to the call. Typically, the information sent by the IVR includes:
    • Caller identification such as Account Number.
    • Indication of what the caller was doing when he opted out (for example, a Balance Inquiry). This is commonly referred to as “last action.”
    • Verify flag indicating whether the caller successfully provided authentication information, such as a PIN number, to the IVR.
    • Any other information that could be used in a call routing decision. For example, if the IVR menu includes an alternate language selection, it would include the customer’s language selection.
    The call is transferred to a routing point in the PBX/ACD, which the Cisco Intelligent Contact management (ICM) system is controlling.
  5. The call arrives at the PBX/ACD routing point which is under the control of the Cisco ICM. The ICM begins executing its routing logic to deal with the incoming call.
  6. The ICM script calls the Pega Call ICM application gateway to retrieve additional data to be used to enhance or personalize routing. This message contains the caller information collected by the IVR and attached to the call in Step 4. The Pega Platform system that receives this request uses the information from the IVR to gather the customer data from backend systems needed for the call routing decision, screen pop, and subsequent servicing of the caller. This process is commonly referred to as prefetching since caller information is collected before the call reaches a CSR. The prefetched data is stored in Pega Call.

    This step does not occur automatically. You must add a step to the ICM script.
  7. The ICM application gateway passes customer information to the ICM, where it is made available to the ICM script in the form of Cisco call variables. The ICM uses this information with the information it already has to control the routing of the call and sends routing instructions to the PBX/ACD. The call is transferred to a queue where it waits for an available Customer Service Representative (CSR).

  8. When a CSR becomes available, the PBX/ACD delivers the call to the CSR. At the same time, the PBX/ACD sends a message by way of the Peripheral Gateway (PG) to the Pega Call CTI Link engine indicating which CSR received the call A screen pop containing the customer information from the IVR and back-end systems is sent to the CSR’s workstation. The screen pop is displayed at the workstation as a separate window alerting the CSR to the new call. Clicking appropriate buttons in the screen-pop window allows the CSR to begin servicing the call.

Suggest Edit

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.