Genesys General Voice Interaction Flow

Routing Steps: To understand routing architectural functionality, the flow breaks routing down into ten basic 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 Strategy

 Example: 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 which it maintains until the call is released. T-Server tracks the status of every call through each step 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 an interactive 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 the processing of the call. Assume also that the IVR prompts for the customer’s account number then 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 by T-Server as an EventRouteRequest message. T-Server attaches the CED to the call record and passes the route request message on to all the client applications that registered to receive messages regarding DN 6660. Since URS registered DN 6660, as a client of T-Server it 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 customer service level, derived from the customer database. Through a DB Server connection to the customer database, URS looks up the customer’s record and evaluates certain fields specified in the strategy. In our example, the AcctNum field is compared to the CallerEntered Digits to look up the customer’s record and then the Tier field is used to determine the customer service level (Platinum, Regular, or null). Assume the caller has a customer 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 service level 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 of those agents (e.g., WaitForNextCall or NotReadyForNextCall) and receives the status messages from Stat Server. In addition, URS can request statistical values from Stat Server in its quest for the best agent. In our example, we want to select the agent who has been available for the longest period of time, so URS requests the statistical value (Maximum) TimeInReadyState for all the 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 the information it receives from Stat Server. URS evaluates each call independently and applies the status information and the statistical values it requested from Stat Server to determine the best target. In this example, there are only two agents available and only one of them is a member of Agent Group B. In a real world agent-group routing scenario, URS would take advantage of the complex capabilities of both the strategy and the data provided by Stat 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. This message includes the target specification (DN). T-Server forwards the request to the switch. 

8. Call Routed:The switch routes the voice portion of the call to the DN specified by TServer (which was selected by URS). In this example, it is the extension DN where Agent 2 is logged in, DN 6002. T-Server distributes the call detail, including the TEvent structure, to all the client applications that registered for DN 6002. 

9. Screen Pop:One of the applications that registered for messages about DN 6002 is Agent 2’s Desktop Application. Depending on the functionality of Agent 2’s soft phone, the TEvent structure can be converted into a screen pop which arrives at the same time as the call. The screen pop can contain all the customer data T-Server attached to the call including the customer’s account number, name, address, customer service level, phone number, and so on. 

10. Monitor Strategy:From the IRD Loading List (accessed from the Monitoring shortcut bar), you can monitor Universal Routing Server and routing points. You can also open a Trace View window from either the Loading list or the Strategies list and view call counts and percentages for each object in a strategy. For instance, you could see at a glance how many Platinum calls have been routed, or what percentages of all calls are being routed to a queue.