DEV Community

Elogic Commerce
Elogic Commerce

Posted on

B2B Ecommerce AI: the Architecture Mattered More Than the Chatbot

By Paul Okhrem · paul-okhrem.com


Everyone wanted to ship the chatbot first.

That's the pattern I kept seeing across B2B ecommerce projects over the past two years. A company decides it needs AI. Someone on the leadership team demos ChatGPT. A product manager writes a brief. Three months later, there's a chatbot on the product page that answers questions about shipping times and return policies.

And then — nothing. No measurable impact on conversion. No reduction in support tickets. No uplift in average order value. Just a widget that lives in the corner of the screen and gets used by maybe 4% of visitors.

The chatbot wasn't the problem. The architecture was.


What "architecture" actually means here

When I talk about AI architecture in B2B ecommerce, I'm not talking about model selection or infrastructure. I'm talking about how AI connects to the operational reality of the business — the product catalog, the pricing logic, the account-level rules, the procurement workflows.

Most B2B ecommerce platforms are not designed with AI in mind. They were built to display products, manage carts, and process orders. The data structures that power them — ERP integrations, PIM systems, customer-specific pricing tables — are not easily queryable by a language model.

So when you drop an AI layer on top without rethinking how data flows, you get an AI that either:

  • Answers generic questions because it can't access the right data
  • Hallucinates specifics because the specifics aren't grounded anywhere
  • Gets abandoned by users who needed precision and got approximations

The chatbot becomes a liability rather than an asset.


The projects that worked looked different

In the implementations that actually moved metrics, the AI layer was designed around a different question. Not "what can AI do?" but "where does friction currently destroy value in this buying journey?"

For one industrial distributor, the answer was quote generation. Their sales team was spending 40-60% of their time manually building quotes for repeat customers — pulling from price lists, applying account-specific discounts, cross-referencing availability. The AI didn't replace the salesperson. It gave them a draft quote in under two minutes, pre-populated with the right pricing logic, flagged with substitutions where items were out of stock.

That required building a proper retrieval layer against their pricing engine. It required defining clear rules for when the AI should escalate vs. complete. It required structured output that could flow directly into their quoting system. The chatbot interface was almost an afterthought — the architecture was the work.


The three architectural decisions that matter most

1. Where does ground truth live, and how does the AI access it?

B2B catalogs are not static. Pricing is account-specific. Availability changes by the hour. Any AI that's answering product or pricing questions needs a real-time retrieval layer — not a document dump from three months ago. This means designing the data pipeline before designing the interface.

2. What does a "good" response actually look like?

Generic AI outputs are often useless in B2B contexts. A purchasing manager asking about lead times for a specific SKU doesn't want a paragraph — they want a number, a date, and a flag if something is unusual. Defining the output structure upfront is part of the architecture, not an afterthought.

3. Where is human judgment still required?

The best implementations I've seen are explicit about this. They don't try to automate everything. They identify the decisions that require account knowledge, relationship context, or exception handling — and they route those to humans efficiently, with AI providing the prep work.


Why this matters more as AI capabilities improve

There's a tempting assumption that better models will solve the architecture problem. They won't — at least not the structural part.

A more capable model doesn't know your customer's contract pricing. It doesn't know that Account X gets a 15% discount on certain SKUs but not others. It doesn't know that the procurement contact at this company changed six months ago and the new person has different approval thresholds.

That knowledge lives in your systems. The architecture is how you bring it into the model's context reliably and safely.

The companies that are investing in that layer now are the ones that will actually compound the value of AI improvements over time. The ones shipping chatbots without it will keep asking why AI isn't working for them.


One practical starting point

If you're evaluating where to start with AI in B2B ecommerce, I'd suggest mapping the five most friction-heavy moments in your buying journey — the places where customers either abandon, call support, or wait for a human response.

Then ask: what data would an AI need to resolve this friction? Where does that data live? Is it accessible in a structured, reliable way?

The answers will tell you more about your AI readiness than any model evaluation will.


Paul Okhrem works at the intersection of AI strategy and B2B commerce. More at paul-okhrem.com

Top comments (0)