An order number arrives in message four. You need it in message nineteen, to paste into an internal tool. So you scroll back, hunt for it, select it carefully enough not to catch the trailing full stop, copy, scroll forward, and hope you did not lose your place in the other two chats you are holding.
That round trip costs a few seconds and a whole train of thought, and it happens several times an hour. The detected-items panel exists to remove it. As visitor messages arrive it scans them, pulls out anything that looks like a hard data point, and stacks them as chips on the right rail. One click copies the value.
It is a derived index, not a store. Nothing is written anywhere, nothing is sent to us, and the transcript remains the source of truth. Understanding where the index is thinner than the transcript is the whole of using it well.
The eight things it looks for
There are eight categories, each with its own icon: email addresses, phone numbers, links, order references, tracking numbers, money amounts, dates, and unlabelled codes. The collapsed pill shows a count and the icon of the highest-priority category present, so a chat with an email in it reads as an email chat at a glance.
They are extracted in a deliberate order, and each match blanks out the text it claimed so a later, broader pattern cannot re-read the same characters. Emails go first, because a link pattern would otherwise swallow an address inside a mailto:. Links follow. Then the labelled references — anything introduced by a word like order, invoice, reference or tracking — because a labelled match is more trustworthy than a bare string. Then money, then dates, then phone numbers, and last of all the unlabelled codes, which only get whatever nothing else claimed.
Each pattern has its own guard. A phone number needs between seven and sixteen digits, so call me on 12-3 is ignored. An unlabelled code needs at least six characters and must contain both a letter and a digit, which is why ISO27001 becomes a chip and 2026 does not.
Repeats collapse. A visitor who types their email, then retypes it with different capitalisation to correct you, produces one chip rather than three — addresses, links, phone numbers and reference codes are all matched case- and format-insensitively for the purpose of deciding whether something is new, while the chip itself keeps whatever the visitor actually typed.
Only the visitor, and only live
Two boundaries decide what the panel can ever contain, and both surprise people the first time.
It reads visitor messages only. Anything you type is skipped on purpose, on the reasoning that you already have what you just wrote. A consequence worth knowing: if you read an order number back to confirm it and the visitor replies yes that is right, the confirmed number is in your message, not theirs, so nothing new appears.
It reads live messages only. Messages replayed as history are skipped, which means the panel is built from what has arrived since it started watching. Reload the console mid-conversation and the panel comes back empty; it does not re-scan the transcript to rebuild itself. The values are all still in the chat, but the index is gone and will only refill from what the visitor says next.
So treat it as a convenience layer over the live conversation, not as a record of it. If a value genuinely matters — a refund reference, an account number you agreed to act on — it belongs somewhere durable, in your ticket or in the visitor note, not left sitting in a panel that a browser refresh will clear.
Why you read the number back before you act on it
The labelled patterns are deliberately loose, because a strict one misses real order numbers written in the dozen formats real people use. Loose patterns overreach, and this one overreaches in a specific way worth seeing once.
The trigger words are matched wherever they appear, including inside a longer word. So a visitor writing please check my preferences 998877 can produce an order chip whose value is erences — the tail of preferences, read as a reference label followed by an identifier. It is an odd-looking chip and you would probably notice, but the general shape of the failure is the point: an ordinary sentence can produce a confident-looking reference.
It fails in the other direction too. An order number that the visitor mentions with no label, in a format the fallback does not recognise — all digits, or under six characters — produces no chip at all. Absence from the panel is not evidence that the visitor did not give you a number.
Which gives the working rule. The panel is for saving keystrokes on a value you have already seen in the conversation, not for discovering values you have not read. Before you act on a lifted reference — before you look up an order, issue a refund, or trigger anything a wrong identifier would make a mess of — read it back to the visitor in your own next message. That takes one line, it catches both the panel’s mistakes and the visitor’s typos, and customers read it as competence rather than doubt.
What clearing does, and what it does not
The Clear button at the foot of the card empties the list for that conversation, and it also forgets what it has already seen. Those are two separate things and the second one is why the button behaves the way people expect: after a clear, a value the visitor sends again will come back as a fresh chip. Without that reset it would be permanently suppressed as a duplicate.
The list itself holds the most recent twenty-four items. Beyond that the oldest drop off the bottom — but their duplicate memory is deliberately kept, so a value that scrolled off cannot reappear simply because it was mentioned again. In a very long chat, that means the panel is a window on the recent part of the conversation rather than a complete index of it.
Clicking a chip copies it and flashes a confirmation. That confirmation reports that the copy was requested, not that the browser accepted it, so on the rare occasion a paste comes out empty the fix is to click the console window and try again rather than to go hunting in the transcript.
When the panel disappears
The card is only visible when the active chat has something in it. No detections means no pill, which is why it feels like it appears from nowhere the first time a visitor sends an email address. That is also why a chat that seems to have lost its panel usually has not: switching tabs re-renders it for whichever conversation you are now looking at, and each conversation keeps its own list and its own open-or-collapsed choice.
Two events wipe a conversation’s list. Transferring the chat to another agent clears it, on the reasoning that the conversation is no longer yours. And closing the tab clears it within a second, because the panel keeps state only for chats that are still open.
None of that state ever leaves the browser, so it is also per-machine: a colleague looking at the same conversation builds their own index from what arrives after they join, and yours is not handed over with the chat.
How MyLiveChat fits
The detected-items panel is part of the agent console, with nothing to enable and nothing to configure. It watches the active conversation, and the first time something matches, the pill appears above the compose box and opens itself so you can see what it found.
It pairs naturally with the kind of conversation where identifiers fly around: order status, returns, warranty claims, anything where the first thirty seconds are spent establishing which record you are both talking about. The order tracking guide covers the conversation shape itself.
One boundary is worth stating plainly. This panel makes it easy to copy whatever a visitor typed, which includes things they should not have typed. A public chat widget is not an authenticated channel, so if a visitor pastes a full card number or a password, the correct response is to tell them not to and to have it removed from the transcript — not to copy it somewhere more convenient. The sensitive data guide covers what to do when it happens.
Structured data is only half of what a visitor gives you. The qualitative half — their role, their plan, the version they are running — is caught by a separate card, covered in the facts a visitor tells you about themselves.