Matching Contact Attributes
When a home user asks to open a chat session, the web interface gets him or her to fill in some identifying information, such as e-mail address, phone number, first name, last name, and so on.
This identifying information becomes a part of the user data that is associated with the interaction. The web interface relays this user data to Chat Server, and Chat Server sends it to UCS.
UCS then looks to see if the home user matches any of the people that it has represented as contacts in its database. It does this according to the following algorithm:
|
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.
So 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 be exactly EmailAddress —if it is email_address or anything else, 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 Contact Identification and Contact Creation for more information).
For either a matching contact or a new one, UCS sends the following, as 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:
- If any user data has an attribute name that matches an attribute name in the UCS Contacts table, UCS returns the value of the attribute from the user data, not the value from the Contacts table. It does not modify the value in the Contacts table.
The last point can cause a problem, as in the following example:
-
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.
-
UCS finds a contact record for sjones@here.
-
UCS returns to Chat Server data about an existing contact whose e-mail address is sjones@here and whose first name is Speve. UCS still has the correct first name Steve in its database, but the user data, with the erroneous Speve, preempts the correct data for the purposes of this chat interaction.
-
The system uses the 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 the following:
14:52:20 SpeveJ has joined the session
14:52:30 SpeveJ > Hi. -
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?”
-
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) as well as its users refer to the UCS database, rather than user data, for contact attributes. In the example just cited, the agent must be sure to look at the Customer Records (right-hand) pane of the Desktop for the name of the contact. However, it is not possible to avoid the use by the system of user data to generate the message prompt (SpeveJ in the example).
It is also advisable to closely monitor the inventory of contact attributes that can become user data.