Contact Identification

Purpose: Provides a high-level description of Context Services method of identifying customers, and contrasts it with the way that UCS (without CS) does so.

If either method produces a unique match for the incoming customer data, there is of course no problem. The differences become relevant when there are multiple matches or when there is no match.

Multiple Matches Found

If UCS tries to identify a customer, and receives more than one match in return:

• In UCS, there are various possibilities depending on the entity that requested the identification. For example, UCS selects the first customer in the returned list if it is responding to E-mail Server. A description of all possible scenarios can be found in the "Contact Identification and Creation" chapter of the eServices 8.0 User’s Guide.
• In UCS/CS, you define arbitrary identification keys (such as e-mail address, last_name + first_name, and so on). If you attempt to identify by e-mail address, for example, and this maps to more than one customer, the application receives complete profiles for all matched customers. This gives the application the opportunity to disambiguate.

For example, the SCXML application may send the matched profiles to the IVR, which might prompt for the customer's name (with the grammar formed by taking the names from the matched profiles). More generally, the application will prompt for additional information and use other identification keys to further isolate the customer's identity. Once a given identity is assumed, the application will often use additional information (such as the customer's ZIP code) to validate the customer's identity. In this sense, UCS/ allows for the application to distinguish between assumed and validated customer identities.

No Matches Found

• In UCS, if a customer is not found on lookup, a new contact record is created. Again, this may or may not be correct.
• In UCS/CS, the application again has the opportunity to collect additional information and attempt to identify the customer using some other identification key. In the end, the application or the agent may separately decide to create a new customer/contact profile, but the decision to do this is completely application-specific.

The preceding statements about how UCS (without Context Services) identifies and creates contacts apply only to the default behavior of UCS. The "Contact Identification and Creation" chapter of the eServices 8.0 User’s Guide describes ways that you can customize this default behavior. However, what you can customize is limited to 1) the contact attributes that UCS checks and the order it checks them in, and 2) whether UCS creates a new contact in the event of no match, or if it does, a minimum set of attributes that must match. In neither case does it allow the application to expand the attributes that it checks, unlike UCS/CS.