Contact Identification: Example

This page provides an example of the default process that UCS uses to identify the contact that is the source of a new incoming interaction.

1. A strategy requests identification of a contact, with only the following data provided:
   
   EmailAddress=johnanddora@doefamily.net
   FirstName=john
   LastName=doe
   
2. UCS takes EmailAddress, the highest priority attribute, and searches for EmailAddress = johnanddora@doefamily.net.
   
3. UCS finds two matching contacts, one with FirstName = john and the other with FirstName = dora.
   
4. UCS moves on to the next highest priority attribute. This would be PhoneNumber if it were specified, but it is not. So UCS takes the next-highest priority attribute, of which there are two, FirstName and LastName, both with a priority of 2.
   
5. UCS searches on EmailAddress = johnanddora@doefamily.net, and restricts the result to FirstName = john and LastName = doe
   
6. UCS finds a single contact matching these three criteria. It returns the ID of the Contact found, plus additional information if available.
   ContactId = 56464FGG519EA03
   EmailAddress = johnanddora@doefamily.net
   FirstName = john
   LastName = doe
   PhoneNumber = 555-654-6303

There are the following additional considerations:

• If the client’s request conveys no specification of what to do in the event of no match, UCS creates a new contact record.
  
• When two attributes have the same rank, as do FirstName and LastName in the default ranking, UCS tries to match both of them.
  If the interaction has values for both attributes, UCS returns only contact records that match both. But if one of equally-ranked attributes has no value, UCS returns any contact records that match the attribute that does have a value (this is equivalent to saying that an attribute with no value matches everything).

If UCS goes through all of the attributes that it has been specified to check and finds no values for any of them, it returns an error message.

If UCS goes through all of the attributes that it has been specified to check and still finds two or more matching contacts, the next step depends on the entity that requested the contact identification:

• If UCS is identifying contacts in response to a request from a media server:
  • With E-mail Server, UCS takes the first contact on the list and associates it with the interaction.
  • With Chat Server, UCS simply passes the interaction on for processing with no associated contact. It reports neither the list of contacts found nor the fact that multiple contacts were found. The agent handling the interaction can select a contact for it using the Agent Desktop.
• If UCS is identifying contacts in response to an IRD Identify Contact object, it depends on whether the object’s Return Unique checkbox is selected:
  • If Return Unique is not selected, UCS returns a list of the matching contacts.
  • If Return Unique is selected, UCS only reports that multiple contacts were found but does not return the list of matching contacts.

In either case, what happens next depends on the subsequent part of the strategy. The system may continue to process the interaction without any contact, until the interaction reaches the Agent Desktop, when the agent handling the interaction can select a contact for it.

Customizing

You can also customize this default behavior.