An online shop's support inbox is really two inboxes wearing the same chat bubble. One is the shopper who has not bought yet and is deciding whether to. The other is the customer who already paid and now needs something to go right. They arrive through the same widget, and the cheapest mistake you can make is answering both with the same agent behavior.
I build AI support agents for e-commerce, and separating these two has done more for results than any model upgrade. Here is how we think about the split and how it shows up in the code.
A pre-sale question is a conversion event in disguise. "Does this fit a 12-month-old?", "Will it ship before Friday?", "Can I return it if the color is off?" The shopper is holding their card. A fast, correct, confident answer removes the last reason not to buy. A slow or hedged answer loses the sale, and you never even see it in a ticket count.
A post-sale question is a retention event. "Where is my order?", "I need to send this back." The money is already collected. Now the only variable is whether this person comes back or tells a few friends not to. The cost of a wrong answer is different on each side: pre-sale a bad answer costs one conversion, post-sale a bad answer costs a customer and their word of mouth.
Same widget, opposite failure modes. That alone justifies routing.
The naive split is "widget on a product page means pre-sale, widget in the account area means post-sale". It breaks immediately, because people ask "where is my order" from a product page and "do you restock this" from their account.
So we route on intent, detected from the message, with the page as a weak prior. The first job of the agent is to classify the turn into a small, fixed set of intents, and pre-sale versus post-sale falls out of that classification. It is the same closed intent set I use for everything else: a known list, an explicit "unclear" branch, and no free-form guessing about what the customer "probably" meant.
Once the branch is known, it changes what the agent can do, not only what it says.
The post-sale branch gets tools that read order state: order lookup, tracking, return and refund eligibility. Those tools touch personal data and the real order system, so they require an identified customer and they are scoped to that customer's own orders. The pre-sale branch usually needs none of that. It needs the catalog, stock, shipping and returns policy, and it has no business reaching into the order database at all.
Giving the pre-sale branch fewer tools is a feature. A shopper asking about sizing should not be able to trigger an order lookup, and an agent that does not have the tool will not do it by accident. The permission boundary follows the intent.
Pre-sale, the agent should be willing to be helpful and a little forward within the truth: confirm the fact, then add the relevant detail the shopper did not ask for yet ("yes, it ships before Friday, and returns are free for 30 days"). The escalation threshold is high, because pulling a human into a sizing question is overkill.
Post-sale, the agent should be calmer and quicker to hand off. Someone whose parcel is late does not want a cheerful product pitch, they want a status and a next step. The escalation threshold is lower: a frustrated customer, or a request the tools cannot satisfy, goes to a human fast, with the transcript attached so the customer never has to repeat themselves.
You can try to encode all of this in a single system prompt and hope the model juggles goal, tone, tools and escalation on its own. It mostly works, until the day a pre-sale conversation quietly triggers an order tool, or a late-delivery complaint gets an upbeat upsell. Those are exactly the embarrassing failures that separate a scripted chatbot from an agent that acts.
Splitting the two intents makes them structurally hard to reach instead of prompt-dependent. The pre-sale branch cannot read orders because it does not hold the tool. The post-sale branch escalates early because its threshold is set that way. The behavior lives in the routing and the tool permissions, where you can test it, and not only in a paragraph of instructions you are trusting the model to honor.
For a shop, the payoff is simple: the same chat bubble stops treating a hesitating buyer and an anxious customer as the same person. It answers the first to win the sale and the second to keep it. If you are weighing tools for this, it is worth seeing how the French AI support agents compare on exactly this kind of routing. I'm Amine, founder of Bynevo Labs. We build sovereign AI support agents for French e-commerce, answering customer questions before the sale and after it, hosted in France on an open-source stack. Happy to talk architecture in the comments.