Matching Contact Attributes

When a home user asks to open a chat session, the web interface asks them to fill in some identifying information, such as an e-mail address, phone number, first name, last name, an so on.

This identifying information becomes part of the user data that is associated with the interaction. The web interface relays this user data to Chat Server, which sends it to UCS.

UCS then uses the following algorithm to check whether the home user matches any of the people that are represented as contacts in the database.

Attribute Name	Search Order
EmailAddress	0
PhoneNumber	1
FirstName	2
LastName	2

UCS is hard-coded to use this algorithm with interactions coming from Genesys media servers, namely e-mail, chat, and callback interactions. For other media, the algorithm can be customized.

For example, if the user data includes an attribute called EmailAddress, UCS looks for a contact in its database whose EmailAddress attribute has the same value as the user data attribute. (For details on the structure of this part of the UCS database, see the "Contact Package" chapter in eServices 8.0 Selected Conceptual Data Models for the UCS Database.) The name of the user data attribute must match the database exactly and is case sensitive. For example, if the submitted user data is email_address, UCS will not try to match its value with the stored value of EmailAddress.

If UCS finds no matching contact, it creates a new one using the user data (see See Contact Identification and Creation for more information).

For either a matching contact or a new one, UCS sends the following data about the contact for this interaction to Chat Server:

• The matched attribute (if not e-mail address, then phone number, and so on).
  
• The attribute ContactID.
  
• All other attributes of this contact that UCS has stored in its database, except:
  
Important
Note: If a user enters data that matches an attribute name in the UCS Contacts table, UCS returns the value of the attribute entered by the user, not the value from the Contacts table. UCS does not modify the value in the Contacts table. See the example below for more information.

This example illustrates this potential problem.

1. Home user Steve Jones wants to open a chat session. In the web interface, he types in his correct e-mail address sjones@here, then erroneously types his first name as Speve.
   
2. UCS finds a contact record for sjones@here.
   
3. UCS returns data to Chat Server about an existing contact whose e-mail address is sjones@here and whose first name is Speve. UCS has the correct first name, Steve, in its database, but the user data preempts the correct data with Speve for the purposes of this chat interaction.
   
4. The system uses Speve (user data) to generate the message prompt that marks the home user in the chat display. As a result, the chat session displays something like this:
   14:52:20 SpeveJ has joined the session
   14:52:30 SpeveJ > Hi.
5. The Agent Desktop displays the incorrect first name (in the user data on the lower left pane) and the correct first name (on the Customer Records pane on the right). The agent sees the incorrect first name and opens the chat session by typing, “Hello Speve, how can I help you?”
   
6. The interaction passes through a strategy that generates an automatic response, which opens, “It was good chatting with you, Speve.”
   

To avoid this type of problem, be sure that the system (including strategies and desktop) and its users refer to the UCS database, rather than user data, for contact attributes. The system will always generate the message prompt with user data (SpeveJ in the example), so the agent must look at the Customer Records (right-hand pane of the Desktop) for the contact name.

It is also advisable to closely monitor the inventory of contact attributes that can become user data.