TECHNICAL LIBRARY

Genesys interactions guide_v1.0

1. Contact Center & IP Telephony Architect Genesys Interactions Guide
2. Contact Center & IP Telephony Architect Table of Contains
1. Genesys General Voice Interaction Flow ...................................................... 3
2. Sample Interaction Flow, Enterprise Routing ................................................. 4
3. Sample Interaction Flow, Network Routing ................................................... 5
4. T-Server Functional Steps - a Sample Call .................................................... 7
5. Functional T-Server Steps ....................................................................... 8
6. Processing E-Mail Interactions .................................................................. 8
7. Processing Web Media Interactions............................................................. 9
8. Multimedia Interactions Architecture........................................................ 10
9. Sample Call Flow with Centralized CPD Server ............................................. 10
10. Data Flow Scenarios Predictive Mode (or Progressive Mode) .......................... 11
11. Data Flow Scenarios Preview Mode........................................................ 13
12. GVP: NE Call Session Flow .................................................................. 15
3. Contact Center & IP Telephony Architect
1. Genesys General Voice Interaction FlowRouting Steps:To understand routing architectural functionality, the flow breaks routing down into tenbasic steps: 1. Call Arrival 2. Collect Digits (CED) (optional) 3. Route Request 4. Database Lookup (optional) 5. Target Sub-List 6. Target Selection 7. Request Route Call 8. Call Routed 9. Screen Pop 10. Monitor StrategyExample: The Call Flow in Detail:The steps are explained in detail below.1. Call Arrival:As soon as a call comes into the switch, T-Server creates a unique record for the call whichit maintains until the call is released. T-Server tracks the status of every call through eachstep of the process and provides updated information to all relevant client applications.2. Collect Digits (optional):In this example, assume the switch has been programmed to send all incoming calls to aninteractive voice response unit (IVR) for the collection of customer entered digits (CED).The call has not yet hit a Genesys routing point, so the switch is still controlling theprocessing of the call. Assume also that the IVR prompts for the customer’s account numberthen sends the call back to a route point (6660) on the switch.3. Route Request:Since 6660 is our special route point, the switch sends a message that gets interpreted byT-Server as an EventRouteRequest message. T-Server attaches the CED to the call recordand passes the route request message on to all the client applications that registered toreceive messages regarding DN 6660. Since URS registered DN 6660, as a client of T-Serverit receives the message it has been waiting for, EventRouteRequest.4. Database Lookup (optional)Assume the strategy instructs URS to route each call according to the caller’s customerservice level, derived from the customer database. Through a DB Server connection to thecustomer database, URS looks up the customer’s record and evaluates certain fieldsspecified in the strategy. In our example, the AcctNum field is compared to theCallerEntered Digits to look up the customer’s record and then the Tier field is used todetermine the customer service level (Platinum, Regular, or null). Assume the caller has acustomer service level of Regular.5. Target Sub-List:Based on the results of the database lookup, URS proceeds to the next step of the strategy,target selection. Assume the strategy specifies that callers with a Regular customer servicelevel must be routed to Agent Group B. URS determines the subset of qualified targets.Having limited the possible targets to the agents of Group B, URS requests the status ofthose agents (e.g., WaitForNextCall or NotReadyForNextCall) and receives the statusmessages from Stat Server.
4. Contact Center & IP Telephony ArchitectIn addition, URS can request statistical values from Stat Server in its quest for the bestagent. In our example, we want to select the agent who has been available for the longestperiod of time, so URS requests the statistical value (Maximum) TimeInReadyState for allthe agents in available status. Stat Server provides those values.6. Target Selection:In order to select a specific target, URS uses strategy instructions and relies on theinformation it receives from Stat Server. URS evaluates each call independently and appliesthe status information and the statistical values it requested from Stat Server to determinethe best target. In this example, there are only two agents available and only one of themis a member of Agent Group B. In a real world agent-group routing scenario, URS wouldtake advantage of the complex capabilities of both the strategy and the data provided byStat Server to route the call to the best agent. URS selects Agent 2 as the best target.7. RequestRouteCall:Once it has selected a target, URS sends a RequestRouteCall message to TServer. Thismessage includes the target specification (DN). T-Server forwards the request to theswitch.8. Call Routed:The switch routes the voice portion of the call to the DN specified by TServer (which wasselected by URS). In this example, it is the extension DN where Agent 2 is logged in, DN6002. T-Server distributes the call detail, including the TEvent structure, to all the clientapplications that registered for DN 6002.9. Screen Pop:One of the applications that registered for messages about DN 6002 is Agent 2’s DesktopApplication. Depending on the functionality of Agent 2’s soft phone, the TEvent structurecan be converted into a screen pop which arrives at the same time as the call. The screenpop can contain all the customer data T-Server attached to the call including thecustomer’s account number, name, address, customer service level, phone number, and soon.10. Monitor Strategy:From the IRD Loading List (accessed from the Monitoring shortcut bar), you can monitorUniversal Routing Server and routing points. You can also open a Trace View window fromeither the Loading list or the Strategies list and view call counts and percentages for eachobject in a strategy. For instance, you could see at a glance how many Platinum calls havebeen routed, or what percentages of all calls are being routed to a queue.2. Sample Interaction Flow, Enterprise RoutingThis sample interaction flow explains how components function with each other when acustomer contacts a business that uses Enterprise Routing. Understand these steps.Customer Contact:1. A customer contacts a business and the interaction enters the premise PBX switch system.2. The PBX switches requests routing instructions from the T-Server, which creates a unique identifier for the interaction.3. T-Server converts the request to a TCP/IP message (the language understood by Genesys applications) and passes the request to Universal Routing Server (URS).URS Execution:
5. Contact Center & IP Telephony Architect4. URS executes the routing strategy designed in Interaction Routing Designer. The strategy includes instructions to collect customer-entered information. According to the sample flow, URS first sends the interaction to an IVR to prompt the customer to enter an account number and language preference.5. Customer enters the account number and a French language preference and the IVR attaches this data to the interaction. IVR routes the interaction back to URS.6. URS queries the customer database through the DB Server to determine the identity of the customer.7. The strategy attaches the database information about the customer to the interaction.8. URS queries Stat Server to determine which French-speaking agent is available.9. URS learns from Stat Server that one or more agents are available and determines the agent to whom the interaction should be routed.10. URS sends a RequestRouteCall message to the T-Server. The message contains the agent information (DN, Connection ID) and the collected customer information.11. T-Server tells the switch to route the interaction to the Agent DN.12. The PBX routes the interaction to the agent while T-Server provides the attached customer information to the agents desktop application. “Sample Interaction Flow, Enterprise Routing”3. Sample Interaction Flow, Network RoutingGenesys Network Routing provides the environment for routing interactions from a toll-freenetwork to enterprise premise switches. This sample interaction flow explains howcomponents function together when a customer contacts a business that uses NetworkRouting.
6. Contact Center & IP Telephony ArchitectCustomer Contact:1. A customer contacts a business through a Network Switch.2. An interaction notification enters the Service Control Point (SCP) from a Network Switch.3. Based on the Service Number dialed, the SCP determines where to trigger a routing request. The SCP generates a routing request to Network TServer. The ANI, CED (caller- entered-digits), and DNIS are passed to the T-Server in the request along with other attached interaction data.4. Network T-Server sends an EventRouteRequest message to Universal Routing Server (URS).5. URS executes the strategy. The ANI, CED, DNIS, and other attached data are passed in the request.URS and Target-Selection Analysis:6. URS consults Stat Server to determine the availability of the targets based on the skill and proficiency level requirements of the routing strategy.7. URS learns from Stat Server that one or more of the targets are available, for example, an agent with DN 4444 on premise switch 2.8. URS selects a target and from the data returned by Stat Server determines which premise T-Server will need to be consulted for an external routing point. URS passes interaction information (Agent DN, Connection ID, User Data) directly to the Network T- Server.9. The Network T-Server communicates with the premise T-Server to determine which external routing point, for example, 9999, should be reserved to receive the interaction and returns that DN to the Universal Routing Server.10. URS then consults the Switch Access Code tables from the network switch to premise switch 2 for target type Target Agent. The table has a value of [DN.DL] in the Destination Source field. URS consults the DN group associated with the external routing point supplied by the premise T-Server in Step 7 (DN 9999). The DN group contains a single Network Destination type DN defined for the network switch. This completes the network number translation process.Interaction Routing:11. URS sends a RequestRouteCall message to the Network T-Server for the derived destination. The RequestRouteCall message contains the DL produced by URS in Step 9.12. The Network T-Server tells the Service Control Point to send the interaction to the derived destination for the target by the trunk that the Network Destination points to.13. The Service Control Point instructs the Network Switch to route the interaction using the given Network Destination.14. The interaction arrives at External Routing Point 9999 on the destination premise switch.15. The premise switch sends the interaction arrival message to the premise TServer. The rest of the interaction flow is now entirely controlled by the premise T-Server.
7. Contact Center & IP Telephony Architect16. Since the premise T-Server knows the target agent DN, the premise TServer instructs the switch to route the interaction to agent DN 4444.17. The interaction is routed to the agent DN. “Sample Interaction Flow, Network Routing”4. T-Server Functional Steps - a Sample CallThe following example outlines some basic steps that T-Server might take when a callarrives from outside the contact center. In this scenario, T-Server starts tracking the calleven before it is delivered to the agent. T-Server then informs the selected agent that acall has arrived. When the switch delivers the call to the agent’s extension, T-Serverpresents account information, collected at an Interactive Voice Response (IVR) unit, to theagent at the agent desktop application.Step 1When the call arrives at the switch, T-Server creates a call in its internal structure. T-Server assigns the call a unique identifier, connection ID.Step 2The switch delivers the call to an Interactive Voice Response (IVR) unit, which beginsautomated interactions with the caller.Step 3IVR acquires user information from the caller through prompts and requests T-Server toattach that information to the call. T-Server updates the call with the user information.Step 4IVR sends the call to an ACD (Automated Call Distribution) queue.
8. Contact Center & IP Telephony ArchitectStep 5The ACD unit distributes the call to an available agent logged in to a particular DN(directory number).Step 6T-Server notifies the agent desktop application that the call is ringing on the agent’s DN.The notification event contains call data including ANI, DNIS, and account information thatthe IVR has collected.Step 7The agent desktop application presents the account information, including the name of theperson whose account this is, on the agent’s screen, so that the agent answering the callhas all the relevant information.These seven steps illustrate just a small part of T-Server’s bridging, messaging, andinteraction-processing capabilities.5. Functional T-Server Steps6. Processing E-Mail InteractionsStep 1E-mail interactions arrive in one of two ways: a. If the customer sends ordinary e-mail, the interaction arrives via the enterprise mail server. b. If the customer sends e-mail from a web site (by filling out a web form), the interaction arrives via the Web API Server.Step 2E-mail Server Java stores the body of the interaction in the Universal Contact Serverdatabase, and then sends operational data on the interaction to Interaction Server.Step 3
9. Contact Center & IP Telephony ArchitectInteraction Server parks the interaction’s operational data in its cache and starts processingthe data according to an interaction workflow.Step 4What happens next depends on the interaction workflow and the routing strategies that itcontains. The system may: o Apply a screening rule. o Assign the interaction to one or more categories (if Content Analyzer is present). o Generate an automatic response. o Route the interaction to an agent’s desktop, possibly also sending an automatic acknowledgment to the customer.A supervisor may intervene at various points using Ad Hoc Management for as long as theinteraction’s operational data remains in the Interaction Server’s cache and the interactionis not being actively worked on by the Routing components.Step 5The agent receives the interaction.Step 6The agent may then: o Simply reply to the interaction. o Reply making use of a standard response. With the Content Analyzer option, the interaction may have arrived already equipped with a category assignment and associated suggested response. Otherwise, the agent may search manually for a category with suggested response. o Transfer the interaction to another agent. o Produce a collaborative response by consulting with other agents. o Return the interaction to the system for further processing.Step 7When the agent or agents finally release the reply (typically to an outbound queue in theInteraction Server cache), the interaction workflow may route it to a senior agent orsupervisor for QA review. The reviewer decides whether to let the reply continue throughthe outbound part of the interaction workflow, return it to the agent for revision, or takeother action.7. Processing Web Media InteractionsStep 1Chat interactions begin processing when the Web Client submits a customer’s chat requestto Chat Server.Step 2Chat Server creates a chat session and asks Universal Contact Server to create aninteraction record.Step 3Chat Server submits the interaction to Interaction Server.Step 4Interaction Server places the interaction in its initial queue and begins processing itaccording to an interaction workflow.Step 5The interaction workflow and its component routing strategies may do various things,including sending a message to a customer prior to an agent actually handling the
10. Contact Center & IP Telephony Architectinteraction, but eventually they select an agent who is available for chat sessions and sendan invitation to that agent to participate in a chat session.Step 6The agent accepts the invitation and connects to the chat session.Step 7Agent and customer conduct a chat session.Step 8The chat session ends.Step 9Chat Server writes the content of the chat session to the Universal Contact Serverdatabase.Step 10Any post processing occurs; for example, a transcript of the chat session is e-mailed to thecustomer.8. Multimedia Interactions Architecture9. Sample Call Flow with Centralized CPD ServerThe following is a sample call flow using a centralized CPD Server. In this example, Steps 1through 7 occur at the central location in a wide-area network (WAN).1. The OCS sends a dial request to the CPD Server. (Both the OCS and CPD Server are at the central location.)2. CPD Server sends a dial request to its Dialogic board.3. The Dialogic board dials the customer’s number. A switch conveys the call to the customer, while the Dialogic board performs call progress detection.
11. Contact Center & IP Telephony Architect4. After receiving an Answer call result, the CPD Server transfers the call to a Routing Point.5. A T-Server, that is monitoring the switch to which it is linked (by a CTI link), informs the Router about the call at the Routing Point.6. The routing strategy at the central location determines how to route the call. In this example, the routing strategy determines that the call should be routed to an agent at an outlying site.7. The Router sends the call to Inter Server Call Control (ISCC), an external routing feature of T-Server.8. ISCC sends the call to a second switch that is being monitored by a second T-Server. The second switch relays the call to an ACD Queue for a group of agents.In this step, the second switch, the T-Server that monitors it, and the group of agentsassociated with the ACD Queue, are all at an outlying location in the network.10. Data Flow Scenarios Predictive Mode (orProgressive Mode)The following is a typical data flow scenario for Predictive mode or Progressive mode:1. When an outbound campaign is started, OCS places the call.2. If the call is answered by a “live” voice, it is connected to an agent. User data attached to the call is delivered to the agent’s desktop.3. The agent updates the user data and the call result. The agent then either processes the call or, if requested by the customer, reschedules the call for a later time as a personal or campaign callback.The data flow for a typical Predictive mode or Progressive mode call. In this instance, theswitch has Call Progress Detection (CPD) capability, and T-Server requests the switch to dialthe customer number. Alternatively, you could configure the system with the CPD Server,which uses a Dialogic board to dial the call. In either case, the agent is already logged in tothe system.
12. Contact Center & IP Telephony Architect “Predictive Mode Data Flow”1. OCS sends a request to the database to retrieve a record.2. A record is sent back to OCS, which forwards it to T-Server along with a request to initiate a call.3. T-Server initiates the call.4. T-Server, or another device, interprets the call and determines that the call should be forwarded to an agent. The call result information goes back to OCS.5. At the same time, T-Server transfers the call and customer-specific information to an agent. The agent and the customer are now connected.6. The customer provides data to the agent, who updates the record. This information might include a rescheduled call date and time, a do not call back request, or other data. The agent sends the updated record to OCS.7. After receiving the request, OCS sends an acknowledgment or error message back to the agent.1. Note: The agent can update the record as many times as necessary. With each update, OCS stores the data to its internal buffer and responds with an acknowledgment or error message.8. When the agent and customer have finished, and the call ends, the agent sends the final event to OCS that the record is completed.9. OCS responds to the agent desktop with either an acknowledgement that the transaction is complete or with an error message.
13. Contact Center & IP Telephony Architect10. At the same time, the final update goes to the database.11. Data Flow Scenarios Preview ModeThe following is a typical data flow scenario for Preview mode:1. The agent requests that Preview mode begin.2. The agent requests a preview record.3. The agent either rejects the record or makes the call. o If the agent rejects the record, it is returned to OCS. The agent then has two choices: o Request the end of Preview dialing mode and log out. o Return to Step 2. o If the agent makes the call and if the customer requests no further calls for this campaign or no more calls ever, the agent requests OCS to mark the record as RecordCancel or DoNotCall. The agent then has two choices: o Return to Step 2. o Request the end of Preview dialing mode and log out. o If the call reaches the customer, the agent updates the call results and custom fields. Next, the agent can terminate the call, sending the final call transaction back to OCS, or the customer can ask to reschedule the call. The agent then receives the rescheduled record. The agent then has two choices: o Return to Step 2. o Request the end of Preview dialing mode and log out. o If the call does not reach the customer, the agent can call an alternate (chained) record. o If there are additional records in the chain, the agent requests a chained preview record and returns the beginning of this Step 3. o If there are no additional records in the chain, the agent updates the call results and custom fields, sending the final call transaction back to OCS. The agent then has two choices: o Return to Step 2. o Request the end of Preview dialing mode and log out.The data flow for Preview mode starts differently from that of the data flow for Predictivemode or Progressive mode, but is identical once the agent is connected to the customer.The data flow for a typical Preview mode call. The agent is already logged in to the system.
14. Contact Center & IP Telephony Architect “Preview Mode Data Flow”1. The agent reports to OCS that he or she is ready to begin work in Preview mode.2. OCS sends back an acknowledgment or error message.3. The database sends a record or records to OCS, which forwards the records to the agent. These records might include previously scheduled calls.4. The agent signals T-Server to initiate a call. T-Server initiates the call.5. T-Server determines that the call is connected and signals the agent. The agent determines the status of the connection (fax, answering machine, modem, or customer). If the call is connected to a customer, the agent proceeds with the call.6. The customer provides data to the agent, who updates the record. This information might include a rescheduled call date and time, a Do Not Call request, or other data. The agent sends the updated record to OCS.7. OCS either sends an acknowledgment or error message back to the agent.1. Note: The agent can update the record as many times as necessary. With each update, OCS stores the data to its internal buffer and responds with an acknowledgment or error message (Steps 6 through 8).8. When the agent and customer have finished, and the call is terminated, the agent sends the final event to OCS that the record is completed.9. OCS sends the agent either an acknowledgment that the transaction is complete or an error message.10. At the same time, OCS sends the final update to the database.
15. Contact Center & IP Telephony Architect12. GVP:Call Session FlowA typical GVP call session flow is:1. A user initiates a call using an analog or digital or VoIP phone and the call lands on the VCS or IPCS.2. VCS/IPCS communicates with Dispenser to get http address of the voice application associated with the call.3. VCS/IPCS contacts Policy Manager to confirm the customers (and application) have enough available ports provisioned to accept the call.4. VCS/IPCS contacts Web Server via http. Notice that the VCS/IPCS requests an ASP or JSP page. These pages produce VoiceXML when the web server processes them as shown in this example. The pages can also be coded in VoiceXML.5. Web server produces VoiceXML pages.6. VCS/IPCS carries out the instructions in the VoiceXML pages.