B2B Workflows
Why B2B cannot run on B2C checkout
Section titled “Why B2B cannot run on B2C checkout”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.
Organizational structure
Section titled “Organizational structure”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.
Purchase order payment
Section titled “Purchase order payment”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 aspect | B2C | B2B |
|---|---|---|
| Method | Credit card, digital wallet | Purchase order, invoice |
| Timing | Payment at checkout | Payment on terms (net-30, net-60) |
| Authorization | Payment gateway approval | Organizational approval workflow |
| Reconciliation | Automatic via processor | Manual or ERP-driven matching |
Approval workflows
Section titled “Approval workflows”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:
- Buyer creates an order and submits it for approval
- First-level approver (team lead) reviews line items and quantities
- Second-level approver (finance) verifies budget availability — triggered only when the order exceeds a threshold
- 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.
Budget management
Section titled “Budget management”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.
Punchout catalogs
Section titled “Punchout catalogs”Large enterprises use procurement platforms like SAP Ariba, Coupa, or Oracle Procurement Cloud. These platforms expect a standardized punchout workflow:
- The buyer starts in their procurement platform
- They “punch out” to your Commerce storefront in a new session
- They browse and build a cart on your site
- They transfer the cart back to their procurement platform as a requisition
- The requisition goes through the buyer’s internal approval process
- 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-specific catalog features
Section titled “B2B-specific catalog features”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.
Combining B2B and B2C
Section titled “Combining B2B and B2C”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.
1. A B2B customer's order of $3,500 is stuck in a 'pending approval' state. The organization has approval thresholds at $500 and $5,000. What is happening?
Orders between $500 and $5,000 require first-level approval. The order is waiting for the team lead or designated approver to review it.
Orders between $500 and $5,000 require first-level approval. The order is waiting for the team lead or designated approver to review it.
Review this topic →2. An enterprise buyer completes a punchout session on your storefront. What happens to their cart?
In a punchout workflow, the cart transfers back to the buyer's procurement platform via cXML or OCI. The buyer's internal approval process handles the rest.
In a punchout workflow, the cart transfers back to the buyer's procurement platform via cXML or OCI. The buyer's internal approval process handles the rest.
Review this topic →3. How does Commerce handle a buyer whose order would exceed their department's quarterly budget?
Budget overruns hold the order for review because exceeding a budget may be acceptable with proper approval. The system does not auto-reject.
Budget overruns hold the order for review because exceeding a budget may be acceptable with proper approval. The system does not auto-reject.
Review this topic →