Your Shopify Support Bot Keeps Forgetting the Conversation

Priya runs support for a $4M skincare brand on Shopify, a three-person team handling roughly 900 tickets a week. She rolled out an AI support bot to deflect the order-status questions that ate her mornings, and for a week it looked great in the demo.

Then she read the real transcripts.

One stuck with her. A customer gave her order number in the second message, asked a follow-up in the fourth, and in the fifth the bot cheerfully asked for the order number again. The customer typed it a third time, then asked for a human. Priya put it to us plainly on our onboarding call: “they might ask for an order number multiple times in the same chat.”

That’s not a bug you fix with a better prompt. It’s a missing layer, and almost every disappointing support bot is missing the same one.

When the bot forgets you mid-sentence

The thing that makes these failures so maddening is that the bot isn’t wrong about anything. It answers each message accurately. It just treats every message as if it’s the first one it’s ever seen.

Ask “where’s my order,” give the number, get a tracking link. Fine. Then ask “and can I change the address?” and the bot has no idea what order you mean, because as far as it’s concerned, this is a brand-new stranger asking an abstract question. The thread you can see on your screen isn’t a thread to the bot. It’s a stack of unrelated postcards.

Customers don’t experience that as a technical limitation. They experience it as being ignored, which is worse than a slow human, because at least the slow human remembered who they were.

So the bot deflects the easy first question and then collapses the moment the conversation needs any continuity. Which is most of the time, since real support is rarely one question and done.

Two kinds of memory, and the one most bots skip

There are two different things people mean by “memory,” and conflating them is where a lot of setups go wrong.

Long-term memory is the bot remembering you across visits, that you ordered the retinol serum last month and tend to ask about shipping to Canada. It’s useful, it’s a nice-to-have, and it’s not your problem right now.

Session memory is the bot remembering what happened four messages ago in this same conversation. It’s the order number you already gave, the product you already named, the fact that you’ve already said you’re in the UK. This is the layer that makes a chat feel like a conversation instead of a series of cold opens, and it’s the one most bargain bots quietly don’t have.

When a bot re-asks for something you just provided, that’s session memory failing, not intelligence failing. The model is plenty smart, it simply wasn’t handed the earlier turns when it generated its reply, so it answered the only message it could see.

Get session memory right and most of the “it forgot everything” complaints disappear. It’s not the flashy part of an AI build. It’s the load-bearing part.

Teaching the bot to resolve “that item” and “the order”

Even with the earlier turns in hand, the bot has to actually use them, and that means resolving references.

People don’t repeat full nouns. They say “can I return that,” “is the order shipped yet,” “does it come in blue.” Every one of those words, “that,” “the order,” “it,” points back to something said earlier, and a human resolves them without thinking. A bot has to be built to.

This is where a lot of cheap integrations fall down. They pass only the customer’s latest message to the model to save on tokens, stripping out the context that gives “it” a meaning. The model then guesses, and a guess in customer support reads as either a non-answer or a confidently wrong one. Both erode trust fast.

The fix is feeding enough of the recent conversation, plus any resolved entities (this customer, this order, this product), into every single turn, so “the order” is never ambiguous. It costs a few more tokens. It’s the difference between a bot that converses and one that interrogates.

Piping real Shopify state into the conversation

Memory of the chat is half of it. The other half is the bot knowing things the customer never typed.

When someone says “where’s my order,” the answer doesn’t live in the conversation, it lives in your Shopify admin: the order status, the fulfillment, the tracking number, the customer’s history. A bot with conversation memory but no connection to your store data is just a very polite parrot. It remembers the question and still can’t answer it.

A support bot that actually deflects tickets is wired into live order and customer state. It pulls the order by the number (or, better, by the logged-in customer so nobody has to recite a number at all), reads the real status, and answers from the source of truth. Shopify’s order management and the customer and order data in the Admin API are exactly what a competent integration leans on here.

This is also the cleanest way to kill the repeated-order-number problem at the root. If the customer is logged in, the bot already knows their orders and never has to ask. If they’re not, the bot asks once, stores it in session memory, and never asks again. Either way, “what’s your order number” happens zero or one times per chat, never three.

The bots that frustrate people treat your store as a black box and the customer as the database. Flip that. The customer should supply almost nothing, because your store already knows it.

Why it asks for the order number twice

It’s worth naming the exact failure, because it shows up in nearly every audit and it’s a clean tell.

The bot asks once, the customer answers, and a few turns later it asks again. Underneath, one of two things is true. Either the bot never stored the number in session memory, so it genuinely doesn’t have it, or it stored it but isn’t including it in the context for later turns, so it can’t see it when it needs it. Same symptom, slightly different plumbing.

Both are configuration problems, not model problems. And both are invisible in a quick demo, because a quick demo is one question long. You only trip the failure when the conversation runs long enough to need the earlier answer again, which is precisely when a real customer is most invested and least patient.

That’s why this specific bug does so much damage. It surfaces at the worst moment, after the customer has already put in effort, and it tells them the effort was wasted.

Testing the multi-turn paths nobody scripts

Here’s the uncomfortable part. The reason these bots ship broken is that nobody tested them the way customers actually use them.

The demo script is clean: one question, one tidy answer, a round of applause. Real conversations branch. The customer asks about the order, then changes their mind, then asks about a different product, then comes back to the first order. A bot that holds up under the demo can fall apart on turn six, and you’ll never know until a transcript like Priya’s lands in your inbox.

Before you trust a support bot, run it through genuine multi-turn scripts. Give an order number, then three messages later reference “my order” without repeating the number, and see if it keeps up. Mention a product, then ask “does it ship to Canada,” and check whether “it” resolved. Switch topics and switch back. The bot that survives that is the one that’s safe to put in front of customers.

Honestly, an afternoon of deliberately messy test conversations would catch most of what ships broken. Almost nobody does it.

A context-handling setup that holds

If you’re specifying or auditing a bot, a few things should be non-negotiable, and they’re worth writing into the brief.

Every turn gets the recent conversation history, not just the latest message, so references resolve and nothing already-said gets re-asked. Resolved entities (the active order, the customer, the product in question) are tracked across the session and passed forward. The bot is connected to live Shopify order and customer data, and prefers the logged-in customer over making people recite numbers. And there’s a clean handoff to a human the moment the bot is out of its depth, carrying the full context with it so the customer doesn’t start over a fourth time.

None of that is exotic. It’s the difference between an AI feature you demo and an AI feature your customers don’t complain about. The gap between those two is almost always this context layer, quietly missing.

What we keep telling clients

A support bot’s job isn’t to be brilliant. It’s to be coherent, to remember what was said thirty seconds ago and to know what your store already knows.

Most of the disappointment with these tools traces back to that one missing layer, not to the model being weak. The model in even a budget bot is more than capable of handling a return request. It just keeps getting handed a conversation with the memory wiped, asked to perform without the one thing it needs, and then blamed for the result.

The brands whose bots actually earn their keep didn’t buy a smarter AI. They wired in session memory, taught it to resolve references, connected it to live order data, and tested it on messy multi-turn conversations before any customer saw it. Unglamorous plumbing, every bit of it. And it’s the whole game.

Priya didn’t switch vendors. She had the integration changed so every turn carried the conversation history and the resolved order, connected it to her live Shopify order data, and made it pull orders from the logged-in customer instead of asking. The repeated-order-number complaint stopped inside a week, her deflection rate climbed, and the transcripts started reading like conversations. Same bot. It just stopped forgetting.

Questions we get every week

Why does my bot ask for the order number more than once? Because it either never saved the number to the conversation’s session memory or isn’t including it in the context on later turns. The model can only answer from what it’s handed, so if the earlier answer isn’t passed forward, it genuinely can’t see it and asks again.

Is this a problem with the AI model or the setup? Almost always the setup. The model is capable of holding a coherent conversation, but it depends on being given the prior turns and the relevant store data on every message, and a cheap integration often strips those out to save tokens.

Do I need long-term memory across visits to fix this? No. The frustrating failures are session memory problems, meaning within a single chat, and you can solve those without any cross-visit memory. Remembering people across visits is a separate, optional upgrade.

How do I stop customers from having to type their order number at all? Connect the bot to your live Shopify data and identify the logged-in customer, so it can read their orders directly. For guests, ask once and store it in session memory for the rest of the chat, so the request never repeats.

If your support bot looks great in the demo but frustrates real customers, talk to Monkey Man and we’ll audit where the context is leaking.