Should a customer support chatbot remember customers between chats?

Should a support bot remember a customer from one chat to the next? Yes, but only a short list of facts tied to the customer's orders and open requests. Everything else it should ask again, because stale memory produces confident wrong answers.

The topic is live again. On October 6, 2026, an AI support company announced a $17 million Series A, as reported by Pulse 2. For a small shop the point is simple: the more your bot knows about a person, the more ways it can go wrong. The about page explains what this site covers.

What is actually useful to remember?

Facts that change what the correct answer is. An illustration, not a real customer:

A customer writes, "Where is my order?" A bot with no memory asks for the order number. A bot with order history sees one open order, shipped two days ago, and answers with the carrier status straight away. That saves a round trip and the customer feels recognised.

The same goes for an unresolved earlier request. If yesterday's chat ended with "we'll check the refund and get back to you", today's bot should know that the case is open. Otherwise the customer has to repeat the whole story to a bot that should already know it.

Useful to keep:

• open and recent orders with their status
• the plan the customer is on, and the next billing date
• the state of any request still waiting on you
• a note that the customer already talked to a person, and about what

What is better left out?

Anything the customer did not give you for support. Browsing habits, reviews, and loyalty details may sit in the same system, but a refund question does not need them. Pulling them into a reply ("I see you liked the blue jacket") feels odd in a support chat, however clever it is technically.

Old opinions are another trap. A customer who was angry last month is not necessarily angry today. If the bot opens with a softer, cautious tone because of an old complaint, it reads as being watched.

Memory needs a plain rule, not a feature. Decide what the bot may mention in a reply, and keep that list short.

When should the bot ask again?

When the fact can change or the cost of a mistake is high. Delivery address, email, and which of two similar orders the customer means: ask, even if the system has an answer. "I see your address ends in Maple Street, is that still right?" is two seconds for the customer and prevents a parcel going to a former flat.

Ask again too when the record looks thin or contradictory. Two open orders and a vague question mean the bot should list both and let the customer choose, not pick one.

When is it better to call a person?

When the memory looks wrong, or when the stakes are higher than a status question. The customer says "that's not what I ordered", or the history shows three contacts about the same issue: hand the chat over with a short summary, so nobody starts from zero.

The same goes for a refund dispute, a complaint about a past mistake, or a customer who asks to speak to someone. A bot that keeps answering from stored history at that point only makes the customer more annoyed. Let the bot say plainly that it is passing the chat on, and let the person see what the bot knew, including anything it got wrong.

Three things to check before you switch memory on

1. Read through every field the bot can see about a customer and cross out the ones no support answer needs. If a field would not change a reply, the bot should not see it.
2. Take a returning customer whose order changed status since the last chat and watch which version the bot reports. It should use the current status, not the one from the old conversation.
3. Ask the bot about something it has no record of. If it cannot say "I don't have that on record" and offer a person, leave memory off for now.