Skip to content

B2B Workflows

intermediate
📜Corecommerce

In B2C, a single person browses, decides, pays, and receives the product. The entire journey fits in one session and involves one decision-maker. B2B purchasing looks nothing like this. A requisitioner builds a cart, a manager approves it, finance verifies the budget, and procurement issues a purchase order that references a negotiated contract. Applying a B2C checkout to this process forces organizations to work around the system rather than with it.

Optimizely Commerce provides B2B-specific workflows that model how businesses actually buy. Instead of a single checkout funnel, Commerce supports multi-step approval chains, organizational budgets, purchase order payment, and integration with external procurement systems.

B2B commerce starts with organizations, not individual customers. Commerce models the buying company as an organization with:

  • Multiple users — Each with defined roles (buyer, approver, admin)
  • Sub-organizations — Departments or divisions with their own budgets and approval rules
  • Shared resources — Order history, saved carts, and address books that belong to the organization, not the individual

This structure means a new employee inherits their department’s pricing, budgets, and approval chains without manual configuration.

B2B buyers rarely pay with credit cards at checkout. Instead, they place orders on account and settle invoices later, often on net-30 or net-60 terms.

Commerce supports purchase order (PO) as a payment method. The buyer enters a PO number at checkout, and the order proceeds without real-time payment processing. The PO number links the Commerce order to the buyer’s internal procurement system for downstream invoicing and reconciliation.

Payment aspectB2CB2B
MethodCredit card, digital walletPurchase order, invoice
TimingPayment at checkoutPayment on terms (net-30, net-60)
AuthorizationPayment gateway approvalOrganizational approval workflow
ReconciliationAutomatic via processorManual or ERP-driven matching

Not every employee should be able to place orders without oversight. Commerce provides configurable approval workflows that route orders through one or more approvers before they become confirmed.

A typical approval workflow:

  1. Buyer creates an order and submits it for approval
  2. First-level approver (team lead) reviews line items and quantities
  3. Second-level approver (finance) verifies budget availability — triggered only when the order exceeds a threshold
  4. Order confirmed and sent to fulfillment

You configure approval thresholds per organization or sub-organization. Orders under $500 might auto-approve. Orders between $500 and $5,000 need one approval. Orders above $5,000 need two. This keeps small purchases fast while maintaining controls on larger spending.

Organizations allocate spending budgets to departments, teams, or cost centers. Commerce tracks spending against these budgets in real time.

When a buyer submits an order, the system checks whether the order total fits within the buyer’s allocated budget. If the budget would be exceeded, the order is held for review rather than rejected outright — because exceeding a budget might be acceptable with the right approval.

Budget periods can be monthly, quarterly, or annual. At the start of each period, budgets reset automatically. Budget administrators can view spending reports, adjust allocations, and see projected vs actual spending across the organization.

Large enterprises use procurement platforms like SAP Ariba, Coupa, or Oracle Procurement Cloud. These platforms expect a standardized punchout workflow:

  1. The buyer starts in their procurement platform
  2. They “punch out” to your Commerce storefront in a new session
  3. They browse and build a cart on your site
  4. They transfer the cart back to their procurement platform as a requisition
  5. The requisition goes through the buyer’s internal approval process
  6. The approved order is transmitted back to Commerce as a purchase order

Commerce supports the cXML and OCI punchout standards. The storefront renders in a simplified mode during punchout sessions — no checkout flow, no payment, just browsing and cart building. The handoff back to the procurement platform uses standardized messages that carry line items, pricing, and product identifiers.

B2B catalogs differ from B2C in several ways:

  • Contract pricing — Negotiated prices per organization that override standard pricing tiers
  • Restricted catalogs — Some products are only visible to approved organizations
  • Minimum order quantities — Variants that require a minimum purchase of 50 or 100 units
  • Quick order entry — Buyers enter SKU numbers and quantities directly, bypassing product browsing entirely

These features layer on top of the standard catalog architecture. The same product hierarchy serves both B2C and B2B channels, with visibility and pricing rules controlling what each audience sees and pays.

Many organizations sell to both consumers and businesses from the same Commerce instance. The separation of concerns in the catalog, pricing, and checkout systems makes this practical. The product data is shared. The pricing engine resolves different prices per customer group. The checkout flow adapts based on whether the buyer is an individual or an organization member.

This hybrid approach avoids maintaining two separate commerce platforms while still respecting the fundamentally different purchasing processes of each audience.