Thousands of customer tickets every month. Most about orders, returns, replacements. The same questions, the same policies, the same responses – written under pressure to respond quickly while following different rules for different customer types.

Vive Health sells medical equipment across the US – wheelchairs, braces, therapy supplies. Thousands of orders flow through Amazon daily. Another stream comes from their direct B2B platform, where healthcare providers and retailers buy in volume. Both channels generate support tickets. Both need fast, accurate responses. And both have different policies.

The support team was doing their best. But inconsistency crept in. Typos frustrated business clients who expected polished communication. Policy exceptions got made when they shouldn't have been. Response quality varied by who happened to pick up the ticket.

Vive had tried building with ChatGPT. Custom GPTs with policies pasted into prompts. It worked most of the time – good enough to show promise, not good enough to trust.

They came to us looking to close that gap.

The Problem: Policy Compliance at Scale

Before the AI support agent, Vive faced five interconnected challenges.

Inconsistent response quality. With a team spread across different skill levels, responses varied widely. Some were polished and precise. Others had errors that made business clients question the company's professionalism.

Policy exceptions gone wrong. The AI kept making exceptions it shouldn't. Return windows stated incorrectly. Carrier information that didn't match reality. Edge cases handled with confident-sounding but incorrect answers.

Two different policy sets. B2B customers and consumers operate under different rules. Return windows differ. Pricing structures differ. The level of service expected differs. One system needed to navigate both correctly.

Integration complexity. Vive runs on Odoo with an XML-RPC interface. Connecting AI to their helpdesk meant building through an integration layer that required careful engineering.

No visibility into failures. When the AI got something wrong, there was no easy way to understand why. No logs. No categorization. No feedback loop to drive improvement.

The result: a team that couldn't fully trust automation and an AI that couldn't be trusted to run unsupervised.

Why E-Commerce Support Is Different

Most AI customer support demos show simple FAQ responses. Real e-commerce support is harder.

Order data lives in multiple systems. A customer references an order number, but it might be a Sales Order, Purchase Order, Invoice, or Amazon order ID. The AI needs to recognize formats, extract identifiers from messy ticket text, and query the right system to find the actual order.

Policies have nuance. A return window sounds simple until you factor in: when does the window start? What about items shipped late? What if the product arrived damaged versus unwanted? Each scenario requires different handling, and customers don't volunteer which scenario applies.

Customers provide incomplete information. They say "my order" without any identifier. They include SKUs with extra characters. They describe products by color when the system tracks by model number. The AI needs to handle this gracefully – ask for clarification when needed, not hallucinate when data is ambiguous.

Stakes are real. A wrong answer about a return can cost a sale. A promise the company can't keep damages trust. Business clients with volume accounts require higher accuracy than one-off consumers. Each mistake has downstream consequences.

These constraints shaped every technical decision.

Building the Support Agent

We started with the hardest problem: could we actually integrate with Odoo?

The integration proof of concept came first. Odoo's XML-RPC interface requires careful handling. Before committing to a full build, we built a minimal system – basic LLM integration, basic Odoo connection, ability to fetch and push order and ticket information. A short demo video confirmed it worked. Only then did we scope the full project.

Policy rules got embedded in the prompt. We worked with Vive's team to document every policy scenario. Return windows by customer type. Carrier restrictions. Replacement eligibility criteria. Escalation triggers. The knowledge base wasn't scraped from a website – it was structured from how experienced support staff actually handled tickets.

Identifier extraction required careful engineering. Tickets contain order numbers in various formats, often buried in email threads. We built extraction logic that handles SO/PO/INV prefixes, cleans formatting inconsistencies, and validates identifiers against Odoo before using them.

Automated tests covered regression cases. Product replacements, refunds, upgrades, mixed scenarios – we built test suites that catch breaks before they reach production. When we modify prompts or add features, we verify nothing broke across hundreds of test cases.

Background monitoring preceded any customer-facing deployment. The agent ran silently on real tickets for weeks, generating responses that were never sent. We analyzed where it succeeded and where it failed. Only after this phase did we move to internal suggestions.

Internal notes became the first production step. Before auto-responding to any customer, the agent generated suggestions inside Odoo Helpdesk. Support staff could review, copy, and edit before sending. Another safety layer before full automation.

The Architecture

The technical approach prioritized reliability and observability over speed-to-market.

Turn-based processing, not real-time. Ticket response doesn't require sub-second latency. We chose a deliberate approach: receive ticket, gather context from Odoo, process through LLM with full policy context, validate response, deliver as internal note. Each step is logged and traceable.

Multi-step reasoning reduces errors. Rather than single-pass generation, the system thinks before responding. Extended thinking capabilities catch policy conflicts, identify missing information, and flag low-confidence scenarios for human review.

Retry logic handles LLM overload. Early analysis revealed tickets with no response due to API failures. We added retry mechanisms with exponential backoff. Transient failures no longer mean missed tickets.

Structured logging enables debugging. Every request captures: ticket content, extracted identifiers, Odoo queries, LLM reasoning, generated response, and any errors. When something fails, we can trace exactly what happened.

Rating-based feedback loop. Support staff rate every AI suggestion. These ratings feed back into improvement priorities. We know which issue types need work, which policies cause confusion, and which scenarios the AI handles well.

Results and Ongoing Improvement

The agent now handles the full volume of B2B support tickets, with consumer support as the next phase.

Quality score improved significantly from baseline. After implementing retry logic, fixing carrier information errors, and refining policy handling, the quality ratings climbed substantially. Remaining issues are systematically categorized and addressed.

Response consistency increased. Business clients now receive polished, policy-compliant responses regardless of which agent picks up the ticket. The tone and accuracy are standardized.

Critical failure categories are known and tracked. We identified specific patterns: order number recognition, SKU formatting issues, policy edge cases. Each category has a targeted improvement path.

Support staff time shifted. Instead of drafting responses from scratch, staff review and refine AI suggestions. Faster turnaround, less cognitive load, fewer errors.

The system continues improving. Each week brings new edge cases, new refinements to prompts, new policy clarifications fed back into the knowledge base.

How We Worked Together

Building AI for e-commerce support requires more than prompting skills. It requires understanding the business.

Process mapping came before technology. We studied how Vive's support team actually handled tickets. Which policies applied when. Which identifiers they looked for. What information they pulled from Odoo. The AI system mirrors their decision-making, not a theoretical ideal.

Iterative build with constant validation. POC first, then integration, then core agent, then automated tests, then background monitoring, then internal suggestions. Each phase validated before moving to the next. No big-bang deployments.

Honest about AI limitations. We were direct about what the AI could and couldn't do. Full automation without human review wasn't realistic for the first phase. Policy exceptions would require ongoing refinement. Edge cases would surface that we hadn't anticipated.

Observability as a feature. From day one, we built visibility into system behavior. The rating feedback loop, the structured logging, the failure categorization – these aren't afterthoughts. They're how the system gets better over time.

Where It Stands

The AI support agent is live, processing B2B tickets daily. The consumer support channel is next. Beyond that, Vive is exploring voice support and chat – the same decision-making logic extended to new channels.

What started as a ChatGPT experiment that wasn't reliable enough has become a production system with clear metrics, systematic improvement, and the reliability that e-commerce support demands.

The gap between demo and production? It's the integration work, the policy edge cases, the observability infrastructure, and the patient iteration that turns promising technology into trusted automation.