Almost nothing is more deflating for a customer than explaining the same problem twice. They spent fifteen minutes with you last Tuesday, they come back on Friday, and the conversation opens with a cheerful greeting from someone who has clearly never heard of them.
This is not usually carelessness. It is that a returning visitor genuinely looks like a new one. Chat sessions are identified by a session id that is created fresh each time someone opens the widget, so from the console’s point of view Friday’s visitor and Tuesday’s visitor are two different people who happen to have the same problem. The history card is the piece that closes that gap, and it is worth understanding precisely how far it closes it.
The recap that used to die with the tab
The wrap-up card already produces a good summary at the end of a chat — duration, message counts, mood, open questions, a readable markdown recap. The problem was never generating it. The problem was that it lived exactly as long as the browser tab did. You could copy it to the clipboard or append it to the visitor’s notepad, and then it was gone.
The notepad was the closest thing to a fix, and it does survive, but it is a free-form blob of text. Once it has three or four sessions in it, nobody is scrolling that to answer have we spoken to this person before, and what about?
The history card turns that into a structured list. Instead of one growing wall of text, you get a row per prior conversation, newest first, each of which expands into the full recap from that session.
What a history row holds
Each saved conversation keeps rather more than a summary line:
- When it happened, how long it ran, and how many messages each side sent
- Your average response time during that chat
- The mood reading the console had on the visitor when it was saved
- How many questions were still open, and how many had been answered
- Any follow-up reminders still pending at the time
- Which agent handled it
- City and country, and the page the visitor started from
- A one-line headline, capped at two hundred characters
- The full markdown recap, capped at six thousand characters
If the wrap-up card was not running when the chat was saved, the history card composes a basic recap of its own from the same underlying numbers, so the row is never empty. It is thinner than a real wrap-up recap, but it still tells you the shape of the conversation.
The mood label is worth reading with a little care. It is a snapshot of where the visitor was when the row was written, not an average across the conversation. A chat that started badly and ended well can be saved as Pleased, and one that soured in the last two minutes is saved on that note.
The email address is the memory
This is the part that determines whether any of the above is ever useful, and it comes down to one rule: recognition works on the email address.
When a visitor has given an email — through the pre-chat form, or at any point the console captured it — their history is filed under that address, lowercased. Come back three weeks later under a completely new session, give the same address, and the card matches you to the earlier conversations immediately.
When there is no email, the history is filed under the session id instead. That row is still written, and it is still perfectly readable during the session it belongs to. But the session id is a new value every single time the widget opens, so on the visitor’s next visit there is nothing to match against. Those rows are, in practice, write-only.
The practical consequence is that whether you ask for an email is not just a lead-capture decision. It is the decision about whether your team gets any memory of this person at all. If continuity across visits matters for your product — and for anything with accounts, orders or subscriptions it usually does — that field is doing double duty.
For a first-time visitor the card stays hidden entirely. It only appears when there is genuinely something to show, which is what makes it readable: if the pill is there, there is history.
When a chat gets recorded
There is a Save chat to history button in the card, but you will rarely need it, because the card takes several other opportunities to record on its own.
It records when you use any of the wrap-up gestures — copying the recap, saving it to notes, or setting the follow-up reminder. The reasoning is that all three mean you consider the conversation finished, which is exactly the right moment to preserve it. It also records when the session closes for real, and it makes a final pass when the browser tab unloads, so an agent who closes the console without ceremony does not lose the day.
Automatic recording has a floor: the visitor must have sent at least two messages. A window that opened, said hi, and got nothing else is not worth keeping, and without that floor the ledger fills up with them. The manual button ignores the floor, so if a one-message chat did matter, you can still keep it.
Recording is idempotent within a session. All those triggers can fire on the same conversation and you get one row that gets updated, not five rows that all say the same thing.
What it forgets and when
The ledger prunes itself on load, on three separate rules, and none of them announce themselves:
- Anything saved more than two hundred and forty days ago is dropped.
- Each visitor keeps their forty most recent conversations.
- Across all visitors the store holds fifteen hundred conversations, and when it is over that it drops the oldest first regardless of who they belong to.
That last rule is the one that interacts badly with anonymous visitors. Rows filed under a session id can never be matched again, but they still occupy space in the fifteen-hundred budget, which means a high volume of anonymous chats will gradually evict the email-keyed rows that actually work. If you handle a lot of anonymous traffic and you care about returning-visitor recognition, that is another argument for capturing the email.
There is one more behaviour worth knowing: if the stored data is ever unreadable, the card discards the whole thing and starts clean rather than trying to repair it or failing loudly. That is the safe choice for a console you need to keep working, but it does mean history can vanish without a message.
This memory lives in one browser
Everything above is stored locally, in the browser you are using. Nothing is sent to a server and nothing is shared between agents.
Read that back and the real limit becomes clear. Returning visitor means returning to this browser profile, not returning to your team. If Tuesday’s chat was handled by a colleague, you will see no history on Friday. If you handled Tuesday on the office desktop and Friday from a laptop, you will see no history either. Clear your browser data and it is gone.
For a solo operator or a small team where one person covers most of the shift, that is a genuinely useful memory and it costs nothing. For a larger rota it is better understood as a personal convenience than as team continuity. If you need history that follows the customer rather than the browser, the durable record is the stored transcript, which is searchable, retained on your account, and available to whoever picks up the next conversation.
The two work well together in practice: the history card is the instant recall that saves you the first thirty seconds of a chat, and transcripts are the record you go to when the answer matters.
How MyLiveChat fits
The history card runs in the agent console with no setup. It appears as a small pill on the right rail when a visitor with saved history opens a chat, and clicking a row shows you the full recap from that conversation.
The single change with the biggest effect on how much it helps you is upstream of the card entirely: ask for an email in the pre-chat form. That one field is what turns a stream of unconnected sessions into a person with a history.
And where the answer needs to be authoritative rather than convenient — what was actually promised, what was actually said — go to the transcript. The card is there to stop you opening cold, not to be the system of record.
That recap is about earlier conversations. For the context a visitor states inside the chat you are in right now, the facts a visitor tells you about themselves covers the card that pins it, and why it deliberately empties when a chat is transferred.