B2B E-Commerce Is Not Just a Webshop

Most B2B e-commerce projects start with a sentence that sounds simple. *We need a webshop so our B2B customers can order online.* Add products, add prices, connect a payment gateway, build a checkout, launch.

Six months in, the project is a different shape. Customers have negotiated prices that don't match the public catalogue. Some orders need internal approval before they can be placed. Some products can't be sold without a quote. Stock is split across three warehouses, and the ERP knows it but the webshop doesn't. Different customers need different catalogues. The sales rep wants to stay in the loop on accounts above a certain size. The CFO wants invoices and credit limits visible to the right buyer roles, but not the wrong ones. The PIM hasn't been implemented yet, so half the technical attributes are missing. And nobody's quite sure whose data wins when ERP and the webshop disagree.

None of that was in the original brief. All of it is normal B2B.

This is the disconnect at the heart of most struggling B2B e-commerce projects: companies plan a B2C-style webshop and then meet a B2B-style business behind it. The visible storefront — products, search, cart, checkout — is maybe ten percent of what makes the platform work. The other ninety percent is data, pricing rules, account logic, integration, sales workflow and internal process. A B2B webshop isn't a sales channel sitting next to the business. It's a digital layer sitting on top of how the business actually sells.

Getting that distinction right before development starts is what separates B2B e-commerce projects that pay back from the ones that get rebuilt eighteen months later.

Why B2B doesn't behave like B2C

Most of the B2B e-commerce playbook is built on the assumption that what works for B2C will mostly work for B2B with a few extra fields. It won't. The mechanics of buying are different in almost every layer.

B2C is built around individuals making fast, often emotional, often discovery-driven decisions. Public catalogues, single-user accounts, simple pricing, card payments, standard delivery, a checkout designed to remove every second of friction. The job of the platform is to convert browsing into buying as quickly as possible.

B2B looks similar from the outside and works almost nothing like it underneath. Buyers are companies, not people — multiple users on one account, often with different roles and permissions. Pricing is rarely public; it's negotiated, contract-bound, customer-specific, and often invisible to anyone but the buyer logged in. Catalogues differ between customers. Orders may need internal approval before they're placed. Payment is typically on invoice with credit terms, not a card swipe. Delivery splits across multiple warehouses and may include partial shipments. Some products can be ordered with a click; others need a quote, a configurator, or a sales conversation before a price even exists. And the customer relationship is a long-term one — purchases repeat, accounts grow, and a single bad pricing error can compromise trust that took years to build.

The convenience layer can look the same. The business logic behind it can't. B2B buyers want B2C-grade ease of use, but applied to a buying process that's structurally more complex. A platform that delivers the convenience without the underlying logic produces fluent friction — fast checkouts on top of wrong prices, smooth UX over data the customer doesn't trust.

What B2B buyers actually need

A useful starting point for any B2B e-commerce project is to stop talking about features and start describing how customers actually buy. The features fall out of that conversation. The features chosen without it tend to fall out of the budget.

Most B2B buyers don't browse the way B2C customers do. They know what they need. They're reordering, replenishing, building project lists, sourcing spare parts, or executing on a contract that already specifies the products. The most useful experience for them is rarely beautiful product discovery — it's placing a correct order quickly with confidence. That means features the B2C playbook treats as edge cases and B2B treats as primary: reorder from history, upload an order list as a CSV, search by SKU, save product templates, repeat previous baskets, see only the products their contract entitles them to, find the spare part for the machine they bought four years ago.

Account structure follows from this. A single B2B account often has multiple users with different jobs — a purchaser who places orders, a manager who approves them, a finance contact who reviews invoices, a warehouse contact who tracks deliveries, sometimes a sales rep on the supplier side who watches the account. Each needs different permissions. Some can browse and add to cart but not submit. Some can submit only up to a value threshold. Some can see invoices but not place orders. Some can manage the address book and the user list. Building this on top of a single-user B2C account model is one of the most common reasons B2B platforms get rebuilt later.

Approval workflows sit on top of that — orders above a certain value going to a manager before placement, certain product categories requiring sign-off from a specialist, contract products bypassing approval but custom configurations triggering it.

And not every product belongs in a checkout flow at all. B2B catalogues frequently mix items that can be ordered directly with items that need a quote, configurator or sales conversation first — custom dimensions, project-specific pricing, volume negotiation, technical validation, margin control. A platform that forces every product through the same buying flow either pushes complex products into a checkout that can't handle them, or pushes simple products into a quote workflow that just slows them down. The right model usually has both: direct buying for the products that fit it, request-a-quote or configurator flows for the products that don't.

What sits behind the storefront

Once the customer-facing logic is mapped, the project meets its real complexity: the systems, data and rules that make the storefront actually work. Three layers are where projects most often succeed or quietly break.

Product data is usually the first bottleneck, and it's almost always underestimated. B2B customers need confidence before they order — especially at higher order values, for technical products, or in regulated categories. Confidence comes from product information that's complete, consistent, comparable and trustworthy: full technical attributes, accurate descriptions, working filters, current images, accessible manuals and certificates, translations that match local terminology, related products and accessories that match how the catalogue is actually structured. If any of that is missing, B2B buyers don't self-serve. They call the sales rep — which is the exact behavior the project was meant to reduce. Or they leave for a competitor whose product page they can actually trust. This is where most B2B platforms benefit from a real PIM behind them: ERP holds the operational data (SKU, price, stock), but PIM is what manages the enriched, channel-ready product information that customers see.

Customer-specific pricing is the second hidden minefield. In B2B, pricing rarely lives in one place and is rarely simple. It depends on customer group, contract, volume tier, region, currency, discount level, payment terms, sales agreement, and sometimes margin rules and rep approval. Where the price is calculated — ERP, CPQ, CRM, the webshop itself, a dedicated pricing engine — has to be a deliberate decision, not a default. So does the question of what's visible: do customers see only their negotiated price, or also a list price for context? Are discounts shown explicitly? What happens when a price isn't available for a particular product-customer combination? The platform's behavior in those edge cases is where trust gets won or lost. Wrong pricing in B2B isn't a UX issue. It's a credibility issue, and credibility is harder to repair than functionality.

Integration is the third. A B2B platform isn't a self-contained system; it's a layer that has to talk reliably to several others. ERP for stock, pricing, orders, invoices, customer data. PIM for enriched product information. DAM for approved assets. CRM for customer relationships and account history. CPQ for complex quoting. Often WMS for warehouse-level stock, logistics systems for delivery tracking, payment providers, marketing automation, analytics. We've built integrations with the ERPs that most Slovenian B2B businesses actually run on — MS Dynamics, Vasco, Metakocka, Čebelca — and the lesson is consistent across all of them: the technical connection is the easy part. The hard part is the business logic. Which system is the source of truth for which field? How often does data sync? What happens when ERP is unavailable while a customer is trying to place an order? Where do orders get validated before they hit ERP? How are failed syncs detected and corrected? Those questions aren't IT details. They determine whether the platform is reliable enough for a customer to base their procurement on.

If those three layers — product data, pricing, integration — are unclear, no amount of frontend polish saves the project. If they're handled well, the customer-facing experience has somewhere stable to stand on.

What this means for sales teams

A common assumption inside B2B companies is that e-commerce is coming for the sales team's job. It almost never is, and selling the project that way internally is one of the surest ways to lose adoption.

The actual goal of B2B e-commerce isn't to remove sales from the relationship. It's to remove repetitive sales administration from the sales role — the routine reorders, the lookups of last quarter's order history, the manual quotations for products that could have been priced automatically, the calls about delivery status that exist because the customer can't see it themselves. None of that is what good sales reps want to spend their week on. None of it is what builds long-term accounts. Moving it to self-service frees sales to spend time on the work that actually grows revenue: account development, complex deals, technical consultation, customer relationships.

A well-designed B2B platform is an asset to the sales team, not a competitor. It gives reps account-level visibility — order history, account activity, product interest signals, abandoned carts, quote requests, frequently ordered items, customer-specific catalogues. It surfaces signals reps couldn't see otherwise. It makes the routine work disappear so the strategic work has room.

Selling the project this way internally — to sales leadership, before the project starts — is what determines whether sales champions the platform or quietly resists it. Adoption inside the company is at least as important as adoption outside it.

What gets B2B e-commerce projects in trouble

Across roughly 2,500 B2B transactions a day flowing through platforms we've built, the failure patterns are remarkably consistent — and almost all of them happen before development starts.

The biggest one is treating B2B like B2C — designing a checkout for individual buyers, then bolting B2B logic on top once the limitations show up. By then the data model, the account structure and the integration patterns are already built around the wrong assumptions, and retrofitting is more expensive than starting again.

Right after that is starting development before product data is ready. A platform launched on top of incomplete, inconsistent product data produces an experience customers don't trust, and trust lost on a B2B catalogue is hard to win back. PIM readiness — even at a basic level — usually has to be a parallel workstream, not a phase-two problem.

Underestimating pricing complexity is the third. Project teams discover during implementation that pricing logic involves more variables than the platform was designed to handle, and the resulting workarounds — manual price overrides, hardcoded customer groups, ERP exports running on schedules that don't match what the customer expects — undermine the whole self-service value.

Ignoring the sales team is the fourth. If sales isn't involved in shaping how the platform supports them, adoption suffers in both directions: sales doesn't promote it to existing accounts, and the platform doesn't reflect the buying patterns sales already knows work.

Building too much in phase one is the fifth. B2B e-commerce platforms have a lot of natural surface area — accounts, roles, pricing, quoting, repeat ordering, integrations, reporting — and the temptation is to launch with all of it. The better pattern is to launch with a sharply defined phase one (often: a known set of customers, a focused product range, the core ordering and account features) and build outward from there based on real usage.

And the sixth — the one that catches even experienced teams — is treating integration as "just a connection." The technical pipes are usually solvable. The business logic the integrations encode is what determines whether the platform is reliable, and that needs to be designed alongside the connections, not after.

The pattern across all six: the project's success was decided before development began. Mapping customers, data, pricing, systems, sales process and ownership before writing code is what saves the budget that gets spent later when those questions show up uninvited.

The webshop is the visible part. The business logic is where the value lives.

A B2B webshop isn't a digital sales channel sitting next to the business. It's a digital layer sitting on top of how the business actually sells, prices, fulfills, supports and relates to its customers. Every part of that — customer accounts and roles, repeat ordering and quoting flows, product data and pricing logic, ERP and PIM and CRM integration, sales team workflow, internal ownership — has to be reflected in the platform if the platform is going to be reliable enough for customers to base their procurement on.

That's why the strongest B2B e-commerce projects don't begin with platform selection or design. They begin with a much less glamorous conversation: how customers actually buy, where the data lives, where the pricing comes from, how the systems connect, what the sales team needs from the result, and what ready for launch actually means for a business this complex.

Get that conversation right, and the rest of the project is mostly execution. Skip it, and the platform will eventually need to have it anyway — usually after launch, in front of customers, at considerable cost.

The webshop is the visible part. The business logic behind it is where the value lives.

Planning a B2B e-commerce project?

Before choosing a platform or starting development, it's usually worth mapping how your customers actually buy, how your product data is structured, where pricing lives, which systems need to connect, and how your sales team should be involved.

A focused discovery phase tends to turn what looked like a webshop project into a reliable digital sales and self-service system — and surfaces the questions that are much cheaper to answer now than during implementation.