Building B2B Ordering Portals with Customer-Specific Pricing: A Case Study

The B2B ordering portal is one of the highest-value eCommerce capabilities a distributor or manufacturer can build. Done well, it shifts repeat-order volume from inside sales and phone channels to self-service, reduces order-processing cost, eliminates pricing errors, and gives customers a faster way to reorder. Done badly, it produces a customer-facing version of the company's pricing chaos, exposes mistakes to customers who used to be insulated from them by inside sales, and creates support volume that exceeds the labor it was supposed to save.

The difference between the two outcomes is mostly architectural. The teams that get B2B portals right invest in the foundational data work that customer-specific pricing demands. The teams that get B2B portals wrong try to bolt the portal onto pricing chaos that the inside sales team had been quietly managing for years.

The Composite Case Study: A Specialty Distributor's Portal

Consider a composite drawn from typical B2B distributor engagements. A specialty industrial distributor with 8,000 active customer accounts, 35,000 SKUs, $180M in annual revenue, and an order desk taking roughly 1,500 orders per day — 60% by phone and email, 30% by EDI from large customers, and 10% through an early-generation web portal that customers complained about.

The strategic objective was clear: migrate 50% of phone and email volume to self-service within 24 months. The operational reality was complicated: customer-specific pricing was managed in the ERP through a combination of price lists, customer-specific override tables, contract pricing for major accounts, and "tribal knowledge" pricing that inside sales agents applied case-by-case for known customers.

The early-generation portal had failed because it could not reproduce the pricing the inside sales team produced. Customers who logged in saw prices that did not match what the sales rep had quoted, and after one or two confusing experiences they stopped using the portal and went back to phone orders. The portal made the company's pricing look broken.

The rebuild required addressing pricing as a foundational data problem, not just a UI problem.

The Phase 1 Work: Cleaning Up the Pricing Data

The first phase of the rebuild took roughly four months and produced no customer-visible change. The work was unglamorous but necessary.

The team audited the existing pricing structures: 12 different price lists, 1,200 customer-specific override tables, contract pricing for the top 80 accounts, and an estimated 15-20% of orders priced "off-system" by sales reps using rules they applied from memory. The audit produced a clear map of how prices were actually being set, which exposed the gap between the documented pricing strategy and the operational reality.

The team then consolidated: the 12 price lists collapsed to 5 tier-based price lists, the 1,200 override tables were rationalized into customer-group pricing (which scaled cleanly in the ERP) plus a smaller set of true customer-specific override prices for accounts that genuinely required them. The contract pricing for major accounts moved into a structured contract pricing table with explicit terms, expiration dates, and approval workflows.

The "off-system" pricing was the hardest problem. The team interviewed sales reps to surface the rules they were applying, validated those rules against historical order data, and codified the legitimate rules into either customer-group pricing or a structured discretionary discount approval workflow. The portion of off-system pricing that turned out to be arbitrary or undisciplined was eliminated, with sales reps required to use the approval workflow for anything outside the codified rules.

By the end of phase one, the ERP held a complete, structured representation of how prices were actually set. The same logic could now be applied consistently whether the order came through the portal, the sales rep, or EDI.

The Phase 2 Work: Building the Portal

With the pricing data structured, the portal build became feasible. The portal was built on Adobe Commerce with Hyvä storefront, with the following architecture:

The catalog was sourced from the ERP, with product data, inventory levels, and authoritative pricing flowing into Adobe Commerce on a schedule. The customer master was syncing from the ERP, with company hierarchies and user roles structured in Adobe Commerce's B2B capabilities.

Customer-specific pricing was resolved at cart computation. When a customer added a product to cart, the platform looked up the customer's pricing using the same logic the ERP applied: customer group, customer-specific overrides if any, contract pricing if applicable, and active promotional pricing. The lookup was cached for the customer's session but refreshed on each cart change to ensure accuracy.

The portal included features that addressed the specific friction points of B2B reordering: quick reorder from order history, scheduled recurring orders, saved order templates for frequent reorder patterns, customer-specific catalogs (showing only the products that customer was approved to purchase), order approval workflows for accounts where approval was required, and quotation tooling for non-standard requests that needed sales-rep review.

The portal also included visibility into account-level data: open invoices, payment history, available credit, contract terms, and order status across all channels (not just orders placed in the portal). This visibility was new for most customers, and it became one of the most-used capabilities.

The Phase 3 Work: The Migration

Migrating customers to the portal required deliberate effort. The team did not assume customers would migrate organically. The migration plan included:

Sales rep training and incentive alignment. The sales reps had to be reskilled from order takers to relationship managers and given incentives that rewarded portal adoption rather than penalizing them for "losing" the order volume. Without this work, sales reps would have undermined the migration to protect their customer relationships.

Customer onboarding sequencing. The team identified 50 customers in the top 200 who were most likely to adopt the portal early (digital-savvy buyers, frequent reorderers, customers who had asked for self-service capabilities). Each of these customers got a dedicated onboarding session. Their early success became the proof points for broader rollout.

Phased rollout to the broader customer base. After the early-adopter cohort stabilized, the team rolled out access progressively, with concierge support during transition periods and clear communication about what customers should expect.

Migration of EDI customers required separate work. EDI customers had been transacting through different channels, and the question for each was whether the portal complemented or replaced the EDI integration. For most, the portal complemented EDI: large recurring orders continued through EDI, while one-off and emergency orders moved to the portal.

The Outcomes

By month 24, the portal was producing 42% of total order volume by transaction count (slightly below the 50% target) but 51% by dollar volume. Customer satisfaction scores for portal users were measurably higher than for phone-order customers, primarily because of the order visibility and self-service capabilities the portal provided.

The order-processing cost reduction was significant: roughly $1.4M annualized in inside-sales labor that could be redeployed to relationship-building work rather than order-taking. The pricing error rate dropped to nearly zero on portal orders, eliminating the credit memos and customer goodwill costs that pricing errors had been producing.

The sales reps' role shifted as planned. Many initially resisted; over the 24 months of rollout, most adapted to the new role and several reported that the work was more satisfying. The compensation structure was revised to reward account growth rather than order volume, which aligned the reps with the portal strategy.

The Lessons Worth Generalizing

The case study illustrates several patterns that recur across B2B portal builds.

Pricing is data work, not UI work. The portal cannot fix pricing chaos. Pricing has to be structured upstream of the portal, in the ERP, before the portal can present it consistently. Teams that try to skip this work always end up doing it eventually, usually after a failed portal launch.

Off-system pricing has to be addressed. Every B2B distributor has some amount of off-system pricing where sales reps apply rules from memory. The portal cannot accommodate this informality without producing inconsistency. The off-system pricing has to be either codified (if the rules are legitimate) or eliminated (if they are not).

Customer migration is a sales operation, not an IT project. Portals do not migrate themselves. The sales operations team has to actively support migration, including incentive realignment, customer onboarding, and ongoing support during the transition. Underinvesting here produces portals that work technically but fail commercially.

B2B portals are continuous products, not one-time builds. The portal that ships on launch day is the starting point. Customer feedback, usage patterns, and operational learning produce a continuous backlog of improvements that need ongoing investment.

The Platform Considerations

For B2B portal builds of this complexity, Adobe Commerce with B2B capabilities is usually the right platform choice for mid-market to enterprise distributors. The native company hierarchies, role-based permissions, customer-specific pricing, and quote management features provide the foundation without forcing extensive custom development.

Shopify Plus B2B has matured significantly and is increasingly viable for B2B portals, particularly for distributors with simpler pricing structures and strong customer-experience requirements. BigCommerce B2B Edition and Shopware are credible alternatives in specific contexts.

The platform decision matters less than the architectural discipline behind the build. According to research from Forrester on B2B eCommerce maturity, the strongest predictor of B2B portal success is not the platform selected but the depth of upstream pricing and customer-data work that precedes the portal build.

For distributors considering B2B portal investments: respect the upstream work. The portal is the visible product; the pricing structure, customer data hygiene, and operational alignment are the foundations that determine whether the portal becomes a strategic asset or a public-facing reminder of the company's internal complexity. Get the foundation right, and the portal pays back its investment many times over. Get it wrong, and the portal becomes a cautionary tale.