Architecture

The figure below shows the main eServices components.  

eServices Architecture

Important

For simplicity, not all connections and details are included in the figure. For example, many components (including Web API Server) connect to Stat Server.

Interaction processing generally proceeds according to the type of interaction. The following sections describe how five of the most common interaction types (e-mail, chat, SMS, MMS, and web callback) are processed.

Processing E-Mail

1. E-mail interactions arrive in one of two ways:
   
   • If the customer sends ordinary e-mail, the interaction arrives via the enterprise mail server.
     
   • If the customer sends e-mail from a web site (by filling out a web form), the interaction arrives via the Web API Server.
     
2. E-mail Server stores the body of the interaction in the Universal Contact Server database, and then sends operational data on the interaction to Interaction Server.
   
3. Interaction Server parks the interaction’s operational data in its cache and starts processing the data according to an interaction workflow.
   
4. What happens next depends on the interaction workflow and the routing strategies that it contains. The system may:
   
   • Apply a screening rule.
     
   • Assign the interaction to one or more categories (if Content Analyzer is present).
     
   • Generate an automatic response.
     
   • Route the interaction to an agent’s desktop, possibly also sending an automatic acknowledgment to the customer.
     
   A supervisor may intervene at various points as long as the interaction’s operational data remains in the Interaction Server’s cache and the interaction is not being actively worked on by the Routing components.
5. The agent receives the interaction.
   
6. The agent may then:
   

• Simply reply to the interaction.
  
• 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.
  
• Transfer the interaction to another agent.
  
• Produce a collaborative response by consulting with other agents.
  
• Return the interaction to the system for further processing.
  

When the agent or agents finally release the reply (typically to an Outbound queue in the Interaction Server cache), the interaction workflow may route it to a senior agent or supervisor for QA review. The reviewer decides whether to let the reply continue through the outbound part of the interaction workflow, return it to the agent for revision, or take other action.

Processing Chat

1. Chat interactions begin processing when the Web Client submits a customer’s chat request to Chat Server.
   
2. Chat Server creates a chat session and asks Universal Contact Server to create an interaction record.
   
3. Chat Server submits the interaction to Interaction Server.
   
4. Interaction Server places the interaction in its initial queue and begins processing it according to an interaction workflow.
   
5. The 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 interaction, but eventually they select an agent who is available for chat sessions and send an invitation to that agent to participate in a chat session.
   
6. The agent connects to the chat session and accepts the invitation.
   
7. Agent and customer conduct a chat session (exchange with messages and notifications).
   
8. The chat session ends (by agent request).
   
9. Chat Server writes the content of the chat session to the Universal Contact Server database and updates the interaction in Interaction Server.
   
10. Any postprocessing occurs; for example, a transcript of the chat session is e-mailed to the customer.
    

Processing SMS Messages

SMS messages arrive when a mobile client sends an SMS message to a phone number of a Contact Center. Genesys SMS Server is a recipient and handler of SMS messages.

SMS Server supports two operational modes:

Paging mode refers to receiving an individual SMS message from a mobile client and sending back an agent’s response (paging inbound), or sending an individual SMS message to a mobile client on a Contact Center initiative (paging outbound).

Session (chat) mode refers to creating and keeping an interactive conversation between a mobile client and an agent in the form of a conventional chat session. All messages received and sent during this session are associated with one interaction, which corresponds to this SMS session.

Paging Mode

Paging mode incorporates capabilities to send and receive individual SMS messages. SMS server:

• Submits the incoming SMS messages to Interaction Server as a new interaction.
  
• Sends SMS messages to mobile clients on requests from an agent, routing strategy, or application.
  

Session Mode

This mode supports an interactive conversation between a client and an agent:

• For an incoming SMS message, SMS Server checks if the mobile client is participating in an active SMS session (Chat Server session).
  
• If a session is found, the SMS Server forwards the message to the session.
  
• If a session is not found, SMS Server creates a new SMS session. SMS Server:
  
  • Requests Chat Server initiate a chat session.
    
  • Stores a record about this session.
    
  • Starts forwarding incoming and outgoing messages between the mobile client and the Chat Server session.
    

Processing MMS Messages

MMS messages arrive when a mobile client sends an MMS message to a phone number of a Contact Center. Genesys SMS Server is a recipient and handler of MMS messages. MMS messages can include a subject, text parts, multimedia parts, and a presentation scenario specified in an SMIL (Synchronized Multimedia Integration Language) part of an MMS message. SMS Server supports inbound mode for MMS messages.

Inbound mode refers to receiving an individual MMS message from a movable client and submitting it to Interaction Server as a new interaction.

Processing Web Callback

1. A customer schedules web callback in the Web Callback sample application.
   
2. An interaction is created in Interaction Server and placed in the queue.
   
3. The interaction is processed by the web callback application business process.
   
4. Optional: An acknowledgement e-mail is sent to the customer.
   
5. Optional: An interaction is created in Universal Contact Server database by the business process.
   
6. The customer can reschedule or cancel the web callback.
   
7. The web callback interaction is delivered to an agent at the scheduled time.
   
8. The agent calls the customer.
   
9. If the agent is unable to reach the customer, the agent can reschedule the web callback and the process returns to See The customer can reschedule or cancel the web callback..
   
10. The agent can “mark done” the web callback interaction.
    

Processing Social Media

For information about processing Social Media, refer to the eServices Social Media Solution Guide, available on the Genesys Documentation Wiki.