Matching contacts to customers

Every conversation starts with a question the customer never hears: who is this? The agent answers it by matching the contact details and references the customer uses against the customer record and your own systems. A correct match lets the agent carry on from the last conversation, and a careful one keeps one customer's account details away from another person. This page explains how contacts are matched, how identity is confirmed before anything sensitive is shared, and what happens when the answer is not clear.

How a contact is linked to a customer

The agent matches on verified identifiers: details that belong to one customer and that your systems already hold. There are four.

When a call, message or email arrives, the agent checks the identifiers it carries, such as the phone number or email address, against the record. If they match one customer, the conversation is linked to that customer's record, and the agent sees their history before it replies. When the customer gives a booking or policy reference during the conversation, the agent checks that too. That is how a customer writing from a new number or a new email address is linked to the right record.

The customer record works alongside your CRM. Your CRM stays the system of record (the source your organisation treats as authoritative) for customer and account data. The Telonic record is the system of record for conversation history. When the agent needs a customer's details, it reads them from your systems during the conversation, so a change made there is reflected in the next conversation.

Confirming identity before account details are shared

A match tells the agent who the customer is likely to be. Before it shares or changes anything specific to their account, it confirms their identity using the checks you set for your deployment.

Checks are set per deployment, and you can require a stronger check for more sensitive requests.

A question about a project's completion stage needs no check. A question about the next instalment might need a knowledge check. A change of contact details might need a one-time passcode. The same rules apply on every channel.

When a check is not passed, the agent carries on with anything that does not need account details, and offers the customer a person on your team. Account details are not shared on the strength of a match alone.

When a match is uncertain

The agent suggests the match to a person on your team, who confirms or rejects it. This covers the contacts that do not match cleanly: an email from a new address signed with a customer's name, or a name and a reference that belong to one customer arriving from a number linked to another.

Suggested matches appear in the Records view of the console (the Telonic web application your team uses). Until a suggestion is confirmed, the agent treats the customer as unconfirmed. It can answer general questions and run the identity checks you have set. If the customer passes those checks during the conversation, the checks confirm the link.

Merging records

Two records sometimes turn out to be the same person, such as a buyer who first enquired by email and later bought with a different phone number. Authorised administrators on your team can merge the two records, so the history comes together in one place, in date order.

Who counts as an authorised administrator is set by role, in the same way as other access to the record. Every merge is logged with who made it, which records were merged, and when. See Audit trail and decision records.

Shared phone numbers

When a number is linked to more than one customer, the agent asks who it is speaking to. Families share numbers, a company phone may be used by several employees, and an executive's office manager may call on their behalf. The agent uses a second identifier, such as a booking or policy reference, to find the right record, then runs the identity checks you have set before sharing account details.

Requests from someone acting for another customer, such as a family member or a broker, follow your rules on who is authorised to act, as recorded in your systems. Where your systems hold no such authority, the agent hands the request to your team.

When the agent cannot find a match

The agent helps the customer anyway. It answers general questions from your approved documents, takes the details of what they need, and starts a new contact in the customer record.

If the customer says they are an existing customer, the agent asks for a booking or policy reference to find them. If it still cannot find them, it offers a person on your team. Any likely match is suggested to your team to confirm afterwards, so the history ends up in one record.

The technical detail

In practice

Yousef bought a two-bedroom apartment from Sahel Crest Properties, a Dubai developer. His record holds his mobile number, his email address and his unit reference. The developer requires a one-time passcode for payment questions.

1. One evening, Yousef messages on WhatsApp from his office phone, a number that is not on any record. He asks when his next instalment is due.
2. The agent finds no match for the number, so it asks for his unit reference. He gives B-0907, which matches his record.
3. Because this is a payment question, the agent sends a one-time passcode by SMS to the mobile number on his record. Yousef types it in.
4. The check passes. The agent links the conversation to his record, and gives him the amount and due date of his next instalment from the developer's payment system.
5. Two days later, an email from an unfamiliar address, signed "Y. Haddad", asks about snagging (the defects a buyer reports at handover). The agent suggests a match to Yousef's record, and the customer care team confirms it in the Records view.

What your team controls

• Which identity checks apply, and to which kinds of request.
• Who can confirm suggested matches, and who can merge records.
• Your rules on who may act on another customer's behalf.
• Which of your systems the agent reads identifiers from.

Related

• The customer record: overviewCustomer record
• Issues and threadingCustomer record
• Web and app: signed-in customersChannels
• Access control and single sign-onSecurity and data protection
• Audit trail and decision recordsGovernance and control

Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.