How to preserve customer history in live chat
How to identify returning visitors, restore previous conversations and avoid creating a new request on every visit.
Kanyman editorial team · about the publisher
In brief
A returning customer expects the conversation to continue. If the widget opens an empty chat and creates a new request after the first message, the team loses context and the customer has to repeat everything.
Why conversation history disappears
Web chat often starts with an anonymous browser session. The browser receives a local identifier, the server creates a conversation and messages are attached to that pair. If the identifier is cleared or the server cannot restore it, the next visit looks like a new customer.
History also disappears when it is linked only to the current tab. A reload or a short session timeout then removes the interface reference even though the messages still exist on the server.
- the visitor identifier does not survive a return visit
- the chat session is separate from the customer identity
- a new request is created before restoration is attempted
- history loads only after a new message
What needs to be stored
The minimum model includes a stable visitor identifier, a customer profile, a conversation and its messages. The widget should request the available conversation before the visitor types anything.
Use a signed product-side identifier for authenticated customers and an unpredictable browser token for anonymous visitors. Never expose a sequential internal conversation ID as the access key.
- visitor_id for the browser or signed user
- contact_id for the shared customer profile
- conversation_id for one dialogue
- messages and service events in chronological order
A correct return visit
The widget first restores its token and asks the server for an available conversation. If the conversation is still active, history appears immediately. If it is closed, the product can show it in read-only mode and explicitly offer to start a new request.
The server must verify the customer-to-conversation relationship again when every message is sent. This protects conversations that were moved, deleted or made unavailable to the current project.
How Kanyman handles continuity
Kanyman treats web chat as a project channel rather than a single page session. A conversation belongs to the customer context, so the agent can continue it, use accumulated history and hand it to a specialist with the context intact.
The result is fewer duplicates and repeated questions for the team, and a support experience that genuinely remembers the customer.
A practical verification checklist
Test the first visit, a page reload, a return after several days, sign-in and sign-out, a closed request and a handoff to a specialist. History should appear before the customer sends another message.
Also verify access boundaries: a token from one project must never open a conversation from another project, and an invalid token must fail safely without exposing metadata.
- restore before creating
- verify identity on the server
- keep projects isolated
- make closed conversations explicit