Most manufacturers don't fail at eCommerce because they picked the wrong platform. They fail because they try to force manufacturing workflows into retail eCommerce patterns. A manufacturer's eCommerce requirements are fundamentally different from a retailer's. You need configure-price-quote logic that handles thousands of attribute combinations. You need dealer portals where pricing changes by region, volume, and relationship tier. You need catalogs where a single product family spans 500 SKUs generated dynamically from engineering specifications. Retail platforms weren't designed for this. Here's how manufacturers actually solve these problems instead of working around them.
Barrier 1: Configure-Price-Quote Complexity
The CPQ problem is the single biggest customization barrier manufacturers face in eCommerce. Your products aren't "add to cart" simple. A customer configuring an industrial pump needs to select material (stainless steel, carbon steel, alloy), size (2" to 24"), pressure rating (150# to 2500#), connection type (flanged, threaded, welded), actuator (manual, pneumatic, electric), and coating (epoxy, rubber-lined, none). Each combination affects price, lead time, and availability.
Traditional eCommerce platforms handle this by creating every possible variant as a separate SKU. For a product with 6 configurable attributes and 5 options each, that's 15,625 SKUs for a single product. Multiply by 200 product families, and your catalog has 3 million SKUs. No platform manages that well. Shopify caps at 100 variants per product. BigCommerce caps at 600. Even platforms without hard limits choke on catalog indexing and search performance at that scale.
The solution: dynamic configuration engines on top of your commerce platform.
Instead of pre-generating every SKU combination, you build a configuration engine that calculates valid combinations, pricing, and availability in real-time. The customer selects attributes through a guided workflow. The engine validates each selection against business rules (you can't pair a 24" pump with a threaded connection, for example), calculates the price based on material costs and margin rules, checks lead time against your production schedule, and generates a quote.
On Adobe Commerce, this architecture uses the configurable product type as the base, with a custom module that handles the configuration logic and pricing calculation. The key is keeping the configuration engine separate from the catalog. Your product catalog contains product families (not individual SKUs), and the configuration engine generates the specific SKU when the customer completes their selection.
At Bemeir, we've built CPQ systems for manufacturers where the configuration engine makes real-time calls to the client's ERP for pricing and availability. The eCommerce platform handles the storefront experience, the configuration UI, and the cart/checkout flow. The ERP handles the pricing math and inventory validation. This separation means the eCommerce platform doesn't need to store millions of price points. It asks the ERP "what does this specific configuration cost?" and gets an answer in under 200 milliseconds.
The architecture matters here. If you build CPQ as a monolithic feature inside your eCommerce platform, every pricing rule change requires a deployment. If you build it as a service that your eCommerce platform calls, pricing rule changes happen in your ERP (where your operations team already manages them) and the eCommerce platform reflects them immediately.
Barrier 2: Dealer and Distributor Pricing
Manufacturers rarely sell at a single price. You have:
- List price (MSRP, which nobody actually pays)
- Dealer price (varies by dealer tier: Platinum, Gold, Silver)
- Distributor price (volume-based, negotiated annually)
- Contract price (specific to a customer, locked for 12 months)
- Project price (one-time quote for a specific job, valid for 30 days)
- Promotional price (seasonal, limited-time offers by region)
A single SKU might have 15 different active prices depending on who's buying, what contract they're on, how much they're ordering, and where they're shipping. Traditional eCommerce platforms handle customer group pricing (show different prices to different logged-in customer groups), but the depth of manufacturer pricing goes far beyond that.
The solution: a pricing engine that sits between your ERP and your commerce platform.
Adobe Commerce's B2B module handles the most common manufacturer pricing scenarios natively. Shared catalogs let you define which products each dealer sees and at what price. Customer groups support tiered pricing. Negotiable quotes handle project-specific pricing. For many manufacturers, this native functionality covers 80% of requirements.
The remaining 20% is where it gets complicated. Contract pricing with annual escalation clauses, volume rebate calculations that retroactively adjust pricing when quantity thresholds are met, and real-time currency conversion for international dealers all require custom development.
Bemeir's approach for complex pricing is to build a pricing middleware layer. Your ERP (SAP, Oracle, Epicor) already has the pricing logic. Rather than recreating that logic in your eCommerce platform, you expose it via API. When a dealer views a product, the Magento storefront calls the pricing API with the customer ID, product SKU, quantity, and ship-to location. The ERP returns the correct price. This sounds simple, but the implementation requires careful caching strategy (you can't make an ERP call on every page load) and fallback logic (what happens when the ERP is slow or down).
The manufacturers who get pricing right are the ones who accept that the eCommerce platform is a presentation layer for pricing, not the pricing engine. Your ERP knows the right price. Let it do its job.
Barrier 3: Complex Catalog Architecture
A manufacturer's catalog isn't a flat list of products. It's a hierarchy:
- Product lines (Industrial Pumps, Residential Pumps, Marine Pumps)
- Product families within each line (Centrifugal, Positive Displacement, Submersible)
- Base models within each family (Model 100, Model 200, Model 300)
- Configurations within each model (hundreds of attribute combinations)
- Accessories and spare parts mapped to each configuration
Representing this hierarchy in an eCommerce platform requires a data model that supports deep nesting, cross-references (spare part X fits Models 100, 200, and 300 in configurations A through F), and dynamic filtering (show me all pumps rated for 500 PSI in stainless steel available from the Houston warehouse).
Most eCommerce platforms handle two levels of hierarchy well (categories and products) and struggle beyond that. When you need five levels of hierarchy with cross-references, you're building custom navigation and filtering logic.
The solution: treat your catalog as a managed dataset, not a platform feature.
The approach that works for complex manufacturer catalogs is PIM-first architecture. Your Product Information Management system (Akeneo, Salsify, inRiver) becomes the source of truth for product data. It manages the full hierarchy, cross-references, technical specifications, and documentation. Your eCommerce platform receives a flattened, optimized view of this data for storefront presentation.
On Adobe Commerce, this means using the Adobe Commerce import framework to sync product data from your PIM on a scheduled basis. The PIM handles the complexity; Magento handles the commerce. Layered navigation and Elasticsearch handle the filtering. Custom product types handle the cross-references (spare parts mapped to parent products).
We implemented this architecture for a client at Bemeir where the manufacturer had 18,000 product families generating roughly 2 million possible configurations. The PIM managed the master data. Adobe Commerce received a curated catalog of 18,000 configurable products with their attributes. The CPQ engine (discussed above) handled the configuration-to-SKU generation at order time. The result: a catalog that loads in under 2 seconds, supports complex filtering, and accurately represents the manufacturer's full product range.
Barrier 4: Approval Workflows and Purchasing Controls
In manufacturing eCommerce, the person browsing isn't always the person who can buy. Procurement teams have hierarchies:
- Engineer selects the product and configuration
- Procurement specialist reviews the quote and negotiates
- Purchasing manager approves orders above a threshold
- Finance reviews and issues a purchase order
- The PO gets transmitted to the manufacturer's order management system
eCommerce platforms built for retail assume one person handles the entire buy flow. Manufacturing purchasing involves 3-5 people, approvals, PO numbers, payment terms (Net 30, Net 60), and credit checks.
The solution: extend the platform's B2B capabilities with workflow automation.
Adobe Commerce B2B module provides the foundation: company accounts with role hierarchies, purchase order workflows, and approval rules. You configure rules like "orders over $25,000 require VP approval" or "orders from new accounts require credit check." The platform routes orders through the approval chain before they reach fulfillment.
Where Bemeir extends this is in the integration with external approval systems. Many manufacturers already have procurement approval workflows in SAP or Ariba. Rather than recreating those workflows in the eCommerce platform, we integrate with them. The eCommerce platform collects the order, transmits it to the approval system, and updates the order status when approval is granted or denied.
The Architectural Pattern That Works
Across all four barriers, the pattern is consistent: the eCommerce platform is the experience layer, not the system of record. Your ERP handles pricing. Your PIM handles product data. Your approval system handles procurement workflows. Your eCommerce platform handles the storefront, the user experience, and the commerce transaction.
Manufacturers who try to make their eCommerce platform do everything end up with a slow, bloated, expensive system that does nothing well. Manufacturers who treat the eCommerce platform as an orchestration layer that coordinates specialized systems end up with a fast, flexible, maintainable system that actually serves their customers.
According to Forrester's research on B2B digital commerce, manufacturers that adopt this composable approach see 35% faster time-to-market for new digital capabilities and 40% lower total cost of ownership compared to monolithic implementations.
The implementation is harder and takes longer. A manufacturer eCommerce project with ERP integration, PIM integration, and CPQ development typically runs 12-18 months on Adobe Commerce. But the result is a system that actually works for manufacturing instead of a retail platform with manufacturing bolted on.
That's the difference between manufacturers who succeed at eCommerce and manufacturers who spend three years fighting their platform. The ones who succeed accept that manufacturing eCommerce is an integration challenge, not a platform feature challenge, and they architect accordingly.
