The VP of Operations had approved the ecommerce project. The platform was selected. The agency had built B2B sites before. Six months later, the project was stalled on a single feature: the product configurator.
The manufacturer sold industrial pumps. Customers didn’t buy SKUs. They specified flow rates, pressure requirements, materials, and certifications. The combination determined the part number, the price, and the lead time. This wasn’t a product variant. It was an engineering calculation that lived in their ERP’s configurator module.
The agency had built the storefront beautifully. But they’d treated the configurator as a commerce feature. Something to build in the platform. When they finally understood the requirement, they realized the platform couldn’t replicate decades of engineering logic. The configurator had to stay in the ERP. The ecommerce site had to call it in real-time. That integration alone cost more than the original project budget.
This is the pattern we see repeatedly in manufacturer ecommerce. The projects that fail don’t fail on the storefront. They fail on the assumption that manufacturing B2B works like distribution B2B. It doesn’t.
Key Takeaways
| What Works for Distributors | What Manufacturers Actually Need |
|---|---|
| Product catalog with variants | Configured products with engineering rules |
| Customer-specific price lists | Pricing that requires calculation (BOM + labor + margin) |
| Inventory availability | Lead time calculation based on capacity and components |
| Standard checkout flow | Quote-to-order workflow with engineering approval |
| Real-time inventory sync | ATP (Available to Promise) from production scheduling |
The trap question to ask any agency: “Have you built ecommerce where the product doesn’t exist until the customer configures it, and pricing requires an ERP calculation?” If they describe variant dropdowns or simple rules engines, they haven’t done manufacturer ecommerce. They’ve done distribution ecommerce with extra steps.
Why Manufacturer Ecommerce Is Different
Distributors sell products that exist. Manufacturers often sell products that don’t exist yet.
This distinction drives everything. The product is configured to order. The price is calculated, not looked up. The availability is a production scheduling question, not an inventory question. The order might require engineering review before it can be accepted.
Standard B2B ecommerce platforms assume products exist in a catalog. You can add variants. You can set customer-specific prices. You can sync inventory. But the fundamental model is: product exists, customer buys product.
Manufacturer ecommerce often inverts this. Customer specifies requirements. System determines if requirements are feasible. System calculates price. System estimates lead time. Customer places order. Order may still require review.
| Ecommerce Model | Product State | Pricing Model | Availability Model |
|---|---|---|---|
| B2C Retail | Exists, in warehouse | Fixed price | Inventory count |
| B2B Distribution | Exists, in warehouse or drop-ship | Customer-specific price lists | Inventory across locations |
| B2B Manufacturing (MTS) | Exists, made to stock | Price list or calculated | Inventory + production schedule |
| B2B Manufacturing (MTO/ETO) | Doesn’t exist until ordered | Calculated from configuration | Capacity + component availability |
MTS (Make to Stock) manufacturers can use standard B2B ecommerce patterns. MTO (Make to Order) and ETO (Engineer to Order) manufacturers need something different.
The Four Challenges That Break Standard Platforms
These are the specific requirements that cause manufacturer ecommerce projects to fail or go over budget.
Challenge 1: Product Configuration
The most common failure point.
What manufacturers need: A configurator that enforces engineering rules. Valid combinations only. Incompatible options disabled. Required certifications enforced. The output is a buildable product with a BOM (Bill of Materials).
What platforms offer: Variant selection. Dropdowns for size, color, material. Maybe a rules engine for simple dependencies. This works for “pick your options” products. It doesn’t work for “calculate whether this combination is physically possible” products.
The integration reality: Most manufacturers already have configuration logic. It’s in their ERP (SAP Variant Configuration, Oracle Configurator, Infor CPQ) or a dedicated CPQ system. This logic represents years of engineering knowledge. Rebuilding it in an ecommerce platform is expensive, error-prone, and creates a maintenance nightmare (two systems to update when rules change).
| Approach | When It Works | When It Fails |
|---|---|---|
| Platform-native configurator | Simple options, no engineering rules | Complex dependencies, BOM generation |
| Custom-built configurator | Moderate complexity, stable rules | Complex rules, frequent changes |
| ERP/CPQ integration | Complex engineering rules, existing system | No existing configurator to integrate |
What this really means: If your configuration logic lives in your ERP or CPQ, don’t rebuild it. Integrate it. The ecommerce platform should present the interface and capture selections. The ERP should validate configurations and calculate BOMs.
Challenge 2: Pricing Calculation
Manufacturers often can’t pre-calculate prices for every possible configuration.
What manufacturers need: Pricing that reflects actual cost. Material costs (which fluctuate). Labor time (which varies by configuration). Overhead allocation. Margin rules. For complex products, the price literally cannot be known until the product is configured.
What platforms offer: Price lists. Customer-specific price lists. Tiered pricing. Volume discounts. These are lookup operations. The price exists somewhere, and the platform finds it.
The integration reality: For calculated pricing, the ecommerce platform must call an external system. This is typically the ERP’s pricing engine or a CPQ tool. The call must happen after configuration, before the customer can add to cart.
| Pricing Pattern | Platform Capability | Integration Required |
|---|---|---|
| Fixed price per SKU | Native | None |
| Customer-specific price list | Native | Price list sync |
| Tiered/volume pricing | Native | None |
| Cost-plus margin | Limited | ERP integration |
| Configured product pricing | Not native | CPQ/ERP real-time integration |
The latency problem: If pricing requires an ERP call, that call must be fast. A 5-second delay while SAP calculates a price kills conversion. The architecture must either cache aggressively, use async patterns, or ensure the ERP pricing call is optimized.
Challenge 3: Availability and Lead Time
Inventory count doesn’t answer “when can I get this?”
What manufacturers need: ATP (Available to Promise). Not how many exist in inventory, but when can this specific configuration be delivered. This calculation considers current inventory, production schedule, component availability, and capacity constraints.
What platforms offer: Inventory quantity by location. Maybe available vs. reserved. This answers “do you have it?” not “when can you make it?”
The critical distinction: Inventory vs. Capacity
| Concept | What It Measures | Data Source | Relevant For |
|---|---|---|---|
| Inventory | What’s on the shelf | WMS/ERP inventory module | MTS (Make to Stock) |
| Capacity | What can be made | Production scheduling/MES | MTO/ETO (Make/Engineer to Order) |
| ATP | When can we promise delivery | Inventory + Capacity + Component availability | All manufacturing |
For MTO/ETO manufacturers, inventory is almost irrelevant. The product doesn’t exist. The question is: given current production load, component availability, and shop floor capacity, when can we start and finish this specific configuration?
The customer experience angle: Showing “12-week lead time” based on actual production schedules is better for customer trust than showing “Out of Stock” because the finished goods warehouse is empty. The warehouse is supposed to be empty. You make to order.
A distributor showing “Out of Stock” means they failed to anticipate demand. A manufacturer showing “Out of Stock” for a configured product means the ecommerce platform doesn’t understand the business model. The correct message is lead time, not availability.
The integration reality: ATP requires integration with production scheduling. For MTO/ETO, the “inventory” concept doesn’t apply. The question is capacity and component availability.
| Availability Question | Data Source | Integration Complexity |
|---|---|---|
| Do you have it in stock? | Inventory system | Low |
| How many across all warehouses? | Inventory + WMS | Medium |
| When can you ship it? | Production schedule + inventory | High |
| When can you make this specific configuration? | Production scheduling + MRP + component inventory | Very high |
For complex ATP, consider whether real-time is necessary. Many manufacturers show “Request Quote for Lead Time” on configured products and provide ATP during the quote process rather than forcing real-time integration.
Challenge 4: Quote-to-Order Workflow
Not every manufacturer order can be accepted automatically.
What manufacturers need: Orders that require review before acceptance. Engineering validation for complex configurations. Credit review for large orders. Management approval for non-standard terms.
What platforms offer: Cart to checkout to order confirmation. Maybe a “request quote” button that sends an email. The assumption is that orders are accepted when placed.
The real workflow requires bidirectional data flow:
1. Customer configures product on web
2. Customer requests quote (data flows TO ERP)
3. ERP validates configuration, engineering reviews if needed
4. ERP calculates final price and lead time
5. Quote pushed BACK to web for customer visibility
6. Customer reviews, requests changes (cycle repeats if needed)
7. Customer accepts quote on web
8. Accepted quote converts to order, flows TO ERP
9. Order confirmation pushed BACK to webThis bidirectional flow is where standard agencies fail. They build a “request quote” form that sends an email. The quote gets created in the ERP. Then someone manually emails the customer a PDF. The customer responds by email. The order gets manually entered.
That’s not ecommerce. That’s a contact form with extra steps.
Real manufacturer ecommerce maintains quote state in both systems. The customer can view quote status, see revisions, accept, or request changes, all within the platform. This requires integration architecture that most agencies have never built.
| Workflow Element | Standard B2B Platform | Manufacturer Requirement |
|---|---|---|
| Quote request | Email or simple form | Structured data to ERP |
| Quote status | Not tracked | Visible to customer in portal |
| Quote revisions | Manual, via email | Version-controlled, in platform |
| Quote acceptance | N/A (direct order) | Digital signature, converts to order |
| Order visibility | Post-purchase | Quote through fulfillment |
At this point, you should understand why manufacturer ecommerce projects go sideways. The remaining question is how to approach them correctly.
The Sales Rep Portal: Your Hidden ROI
Manufacturer ecommerce isn’t just for customers. It’s a tool for your sales team.
Most manufacturers have a hybrid sales model. Some customers order directly. Others work with territory reps. The reps often configure complex orders on behalf of customers, sometimes while sitting in the customer’s facility.
The traditional approach: Reps use a separate system (or spreadsheets, or phone calls to inside sales) to configure and quote. The ecommerce site is customer-only.
The better approach: Reps use the same ecommerce platform, with elevated permissions. They can:
- Configure products on behalf of customers
- See customer-specific pricing (the customer’s negotiated rates, not list)
- Create quotes that the customer can review and accept online
- Place orders on behalf of customers who prefer phone/email
- Track order and quote status for their accounts
| Capability | Customer Portal | Sales Rep Portal |
|---|---|---|
| Product configuration | Self-service | On behalf of customer |
| Pricing visibility | Own prices only | Customer’s prices |
| Quote creation | Request quote | Create and send quote |
| Order placement | Own orders | Orders for assigned accounts |
| Order history | Own history | History for assigned accounts |
| Account management | Own account | Assigned accounts |
Why this matters for ROI: The sales rep portal often delivers faster ROI than the customer-facing portal. Reps adopt it because it makes their job easier. Complex configurations that used to require back-and-forth with engineering can be validated in real-time. Quotes that took days now take minutes.
One manufacturer client saw 40% of their ecommerce orders placed by sales reps on behalf of customers within the first year. The customers preferred calling their rep. The rep used the portal to configure and quote. Everyone got what they wanted, and the manufacturer got structured data and faster order processing.
The Architecture That Works
Manufacturer ecommerce succeeds when the platform is positioned correctly: as a customer interface, not a business logic engine.
Principle 1: ERP as Source of Truth
The ecommerce platform should not contain engineering rules, pricing logic, or production scheduling. These live in the ERP (or CPQ or MES). The platform presents interfaces, captures inputs, and displays outputs.
| Function | Where Logic Lives | Platform Role |
|---|---|---|
| Product configuration | ERP/CPQ | Present UI, send selections, display valid options |
| Pricing | ERP/CPQ | Request price, display result |
| Availability/ATP | ERP/MRP | Request lead time, display result |
| Order validation | ERP | Submit order, handle acceptance or rejection |
Principle 2: Async Where Possible, Sync Where Necessary
Not every operation needs real-time ERP integration. Some do.
| Operation | Sync vs. Async | Why |
|---|---|---|
| Browse catalog | Async (cached) | Performance |
| Configure product | Sync (real-time validation) | User experience |
| Get price | Sync (after configuration) | Accuracy |
| Get lead time | Depends on complexity | Consider “request quote” for complex |
| Place order | Async (queued) | Reliability |
Principle 3: Design for the Quote Path
Even if some products can be ordered directly, design the platform for quote workflows. It’s easier to simplify the path for simple products than to add complexity for configured products.
Selecting the Right Platform
Not every B2B platform handles manufacturer complexity well.
| Platform | Configuration Support | ERP Integration Depth | Quote Workflow |
|---|---|---|---|
| Adobe Commerce (Magento) | Custom development required | Flexible, complex | Requires customization |
| Shopware | Custom development or extension | Clean API, event-driven | B2B Suite includes |
| SAP Commerce | Native integration with SAP | Deep SAP integration | Native |
| Salesforce B2B | Integrates with Salesforce CPQ | CRM-centric | Via CPQ |
| Oro Commerce | Built for complex B2B | Flexible | Native workflow engine |
For manufacturers with heavy ERP dependency (SAP, Oracle, Infor), evaluate platforms based on integration depth with your specific ERP, not generic feature lists.
The Decision
Manufacturer ecommerce fails when teams treat it like distribution ecommerce. The fundamental model is different. Configured products, calculated pricing, capacity-based availability, and quote workflows don’t fit standard B2B platform assumptions.
The projects that succeed accept this reality. They position the ecommerce platform as a customer interface, not a replacement for ERP business logic. They integrate deeply with existing systems rather than rebuilding logic. They design for quote workflows even when direct ordering is possible.
If your products are configured, your pricing is calculated, or your availability depends on production capacity, you’re not doing standard B2B ecommerce. You’re doing manufacturer ecommerce. The approach, the platform selection, and the integration architecture must reflect that difference.
Building ecommerce for a manufacturing operation? The first question isn’t which platform. It’s where your configuration, pricing, and availability logic lives today. We help manufacturers map that architecture before platform selection, so you don’t discover integration complexity six months into the project. That’s usually a 30-minute conversation.
B2B Manufacturing Ecommerce: Strategic FAQ
Distributors sell products that already exist in a warehouse. Manufacturers often sell products that don’t exist yet. This requires a platform capable of handling complex product configuration, engineering-driven pricing, and ‘Available to Promise’ (ATP) lead times based on production capacity rather than just inventory counts.
In most cases, no. Your engineering and configuration logic already lives in your ERP or a dedicated CPQ system. Rebuilding this logic in an ecommerce platform creates a maintenance nightmare. The best practice is to integrate your existing ERP configurator, using the ecommerce site as a user-friendly interface to capture customer requirements.
ATP is a calculation that tells a customer when a product can be delivered based on production scheduling, raw material availability, and labor capacity. Unlike simple inventory counts, ATP provides an accurate lead time for ‘Make to Order’ products, which is essential for maintaining B2B customer trust.
For products where the price depends on specific configurations, the ecommerce platform must call your ERP pricing engine in real-time. To prevent performance issues, we use a hybrid approach: caching standard components while fetching final, complex calculations via a high-speed API call only after the configuration is finalized.
The best platform is one that can defer business logic to your ERP. Shopware and OroCommerce are excellent for their native B2B workflows and clean APIs. For SAP-heavy environments, SAP Commerce Cloud offers the deepest integration, while Salesforce B2B works best if you are already heavily invested in Salesforce CPQ.
Building ecommerce for a manufacturing operation? Don’t force your engineering logic into a commerce template. Let’s spend 20 minutes mapping how your configuration, pricing, and availability logic can be surfaced without compromising your ERP as the source of truth.