Your website chatbot asks simple qualifying questions and moves conversations toward a demo. Conversion rates climb. Then you install the same bot in your support inbox, where customers arrive angry about a late delivery or a broken feature. Conversion rates crater. Support tickets multiply. Escalations explode. You fire the vendor. They blame the training data. You blame the LLM. Neither of you is wrong—but you're both looking at the wrong problem. The issue isn't the bot. It's the context architecture. Website bots and support bots operate in opposite information environments, and a tool optimized for one will systematically fail the other. The context gap: information flow in two directions A website chatbot inherits a thin, pre-qualified context: a visitor landed on your pricing page, clicked 'Chat with us', and has 90 seconds of patience. The bot's job is mechanical: confirm job title, budget range, timeline, and route to a sales rep. The stakes are low. The visitor expects a bot. Friction is acceptable because the alternative was a form. A support chatbot inherits the opposite: a customer arrives with order history, ticket escalations, refund requests, and emotional charge. They don't want a bot—they want their problem solved. The bot now owns context responsibility. It must know whether this customer has already been promised a refund by email three days ago. It must understand that 'my invoice is wrong' could mean 'I was overcharged by your billing system' or 'I don't understand the tax calculation'—each demanding a different resolution path. Without that depth, the support bot commits cardinal sins: it suggests a self-service knowledge article for a problem the customer can't solve alone; it asks for information the customer already provided; it routes to a tier that can't help because the previous interaction never synced. Routing architecture: why escalation paths matter more than AI quality Website chatbots route to a homogeneous endpoint: a sales rep pool. Qualification criteria are simple: budget threshold, timeline, vertical. A routing error delays a demo. No customer is harmed. Support bots route to fragmented endpoints: billing specialists, technical support, fulfillment, refund operations. A routing error means a billing complaint lands with a technician, wasting 20 minutes of both parties' time. The customer's frustration deepens. The ticket reopens. When Intercom or Drift embeds the same routing logic into both channels, the website version succeeds because sales teams are forgiving of imperfect qualification—they prospect anyway. Support teams are not. A customer expecting resolution will not tolerate a misrouted bot. The website bot's job is to qualify. The support bot's job is to diagnose and resolve. Qualification tolerates error. Resolution does not. Why embedded chat widgets solve the wrong problem Intercom, Drift, and many native CRM chat widgets optimize for a single metric: widget deployment speed. They ship one chatbot engine, one interface, one escalation model. Configuration options exist, but they're thin. The assumption is that AI quality will carry both use cases. It doesn't. Here's why: Website context is forward-looking. The bot qualifies unknown prospects. It collects intent signals. It answers 'what does your product cost' or 'how long is implementation'. The bot doesn't need deep history; it needs to move the visitor toward a decision fast. Support context is backward-looking. The bot explains what went wrong, why the customer was charged, or when their order will arrive. It needs history: order records, prior support interactions, billing data, shipping status. Without it, every answer sounds like a guess. Website routing is outcome-agnostic. Sales reps will take any qualified lead. Routing errors don't fail the business—they just create longer sales cycles. Support routing is outcome-critical. A billing question routed to technical support doesn't fail gracefully; it fails expensively, in front of the customer. Intercom and Drift excel at website conversion because their routing is simple and their LLM context requirements are low. They fail in support because they inherit no operational context. They don't know that this customer was promised a refund; they can't see why the invoice total is wrong; they can't access the fulfillment status without a manual lookup. What actually converts in support: context depth over chat speed Support bots convert when they resolve on first contact. They resolve on first contact when they have access to operational context: order history, prior interactions, billing records, fulfillment data, and return policies specific to that customer's region or plan tier. This context must live in the bot's instruction set before the conversation starts. It can't be retrieved mid-conversation; latency tanks the experience. It can't be learned from the chat history alone; the customer's first message ('My invoice is wrong') is too ambiguous wit