The record most teams have never seen
Your contacts screen is not the only place a person exists. Every ticket that arrives with an email address or a phone number is linked to a separate per-person record, created quietly at the moment the ticket is created.
It is a small record and it does not have a screen of its own, which is why most teams never think about it. It surfaces as the customer panel beside a ticket, and as the person-level view available to integrations. It is also what makes the question have we heard from this person before answerable across channels, so it is worth understanding what it does and does not promise.
Email first, phone second, anonymous never
Matching is attempted on the email address first, because it is the more stable of the two, and falls back to the phone number when there is no email. Whichever matched, you get back the same record you had before.
If a ticket arrives with neither an email address nor a phone number, no record is created at all. There is deliberately no attempt to invent a key from a name or a session, because a record nobody can match again is worse than no record: it cannot be found, it cannot be merged, and it still takes up space in every list.
The practical implication runs backwards into your forms. Whether a person accumulates a history depends entirely on whether you captured one of those two fields, which is a good reason to ask for an email address on the paths where a follow-up is likely, and a good reason not to bury it behind five optional fields.
It fills in blanks and never overwrites
When a returning person's record is found, newly supplied details are merged in with a strict rule: a value is written only where the existing field is empty. A phone number arrives and the record had none, so it is stored. A different phone number arrives and the record already had one, and nothing changes.
This is protective rather than lazy. It means a mistyped address on one form submission cannot silently replace the correct value that has been on the record for a year. It also means the record is not self-correcting: if a wrong value is what got there first, later correct values will not displace it, and fixing it is a deliberate act rather than something that happens on its own.
Display names behave the same way. The first name supplied is the name you will keep seeing, which explains the record that stubbornly shows a placeholder somebody typed into a form months ago.
The count is interactions, not distinct conversations
Each record carries a count that is incremented every time an interaction is attributed to it, along with a first-seen and a last-seen timestamp. Read that count as a measure of how often this person comes back, which is what it is good for.
Do not read it as a reconciled total of conversations you could go and list. It is a running counter maintained at write time rather than a query over your tickets, so it answers a different question from a filtered ticket list, and the two are not obliged to agree exactly. For sorting your most-engaged people, it is precisely the right number. For an audit, count the tickets.
Two people behind one address
Because the record is keyed on the address, a shared mailbox is one person as far as this is concerned. Everything sent from an operations or accounts address collapses into a single record with a large count, whoever actually typed the message.
That is the correct trade for a support system, since the alternative is inventing distinctions that nobody can verify. But it does mean the person-level view for business customers is often an account-level view wearing a person's name. If you rely on it for segmentation, treat the shared addresses as accounts and say so in whatever you build on top.
The mirror image also holds. One human with a work address and a personal address is two records, and nothing merges them automatically. The system deduplicates on the key it was given, not on the person behind it.
Messaging handles hang off the same record
Conversations that arrive from a messaging channel carry a channel identifier rather than an email address, and those identifiers can be bound to a record so that the same person is recognised whichever way they arrive.
The binding is stored per channel and is idempotent, so re-binding the same handle refreshes when it was last seen and does nothing else. The human-readable handle is kept alongside it, which is what allows an agent to see a recognisable name in the header rather than an opaque identifier.
Worth being clear about the limit: a handle is bound to a record when something makes that connection, most commonly the person supplying an email address at some point in the conversation. Until that happens, the messaging identity and the email identity are two separate records that happen to be the same human being.
The contacts screen and this record are different objects with different rules, and conflating them causes real confusion when the numbers do not line up.
Contacts are a list you curate: you can import them, tag them in bulk, hide the ones you consider spam, and delete them permanently. Nothing about that list is deduplicated for you. These records are the opposite: nothing is imported, nothing is manually created, deduplication on the key is the entire point, and they only come into being when a real interaction happens.
Use contacts as the working list your team searches and organises, and treat the linked record as the thread that connects a person's conversations across time and channels. Expecting either one to behave like the other is the source of most of the surprise here.
How MyLiveChat fits
This record is what makes conversations from different channels line up behind one person, and three habits get the most out of it. Ask for an email address wherever a follow-up is plausible, because that field is the difference between a history and a series of unconnected conversations. Correct a wrong value at the source when you spot it, since nothing later will overwrite it. And when a business customer writes from a shared mailbox, expect one record rather than several.
Everything here is best-effort by design: if the linking step fails, the ticket is still created and still works, it simply has no person attached. That is the right priority, and it means the absence of a linked record on an old ticket is not evidence of a fault.
For the list your team actually curates, keeping your contact list clean and deduplicated covers the rules on that side. For how conversations become tickets in the first place, turning your support inbox into tickets is the path most of these records are created by, and verifying customer identity in live chat covers the separate and more important question of whether the person is who the record says they are.