Design B2B Ordering Platform

Medium45 min
1 / 30
understanding6 min read

Problem Statement: B2B Ordering Platform

Problem Statement: B2B Ordering Platform — B2B ordering interview depth

Problem Statement: B2B Ordering Platform

A B2B ordering platform connects buyer organizations — procurement teams, not individual consumers — with suppliers through negotiated catalogs, contract pricing, and governed purchase flows. The defining difference from B2C is that an order is not a checkout; it is a governed workflow. Before a warehouse ever picks a line item, a single order may require multi-level approval, net payment terms, a tax-exempt certificate, and ERP synchronization. Amazon Business, Alibaba's wholesale flows, and Grainger's punchout integrations all converge on the same engineering truth: you are building a workflow-centric commerce kernel where price, entitlement, and policy matter as much as inventory.

The system serves four personas and must satisfy all of them at once. The buyer purchaser builds carts from contracted SKUs and may try to exceed a personal spend limit. The approver / budget owner releases or rejects requisitions against policy. Supplier ops confirms availability, ships against PO numbers, and posts the ASN and invoice. The platform admin configures the org hierarchy, payment instruments, and integration credentials.

A representative order traces the whole system. A purchaser searches an org-scoped catalog — not the global retail catalog — and the cart validates contract price, minimum order quantity, ship-to, and budget encumbrance. The requisition enters an approval chain (manager, then finance for capex). The approved purchase order is idempotently submitted to the OMS/WMS, and the ERP returns an acknowledgement. Partial shipments and invoices then reconcile against the PO's line items.

The interviewer is testing whether you treat this as governed B2C or as a genuinely different system. The tell is whether you separate the mutable requisition from the immutable purchase order: once approved, the PO snapshot — its prices, terms, and approvals — must never change, because ERP reconciliation and six-months-later disputes depend on point-in-time truth. The failure that defines the design: a contract price changes after a requisition is approved but before the PO ships; if the PO is not an immutable snapshot, finance and the supplier now disagree on what was actually agreed.

Key Highlights

  • B2B ordering is a governed workflow, not a checkout — approval, net terms, tax-exempt certs, and ERP sync precede fulfillment
  • Four personas to satisfy at once: purchaser, approver/budget owner, supplier ops, platform admin
  • Org-scoped catalog + contract price + MOQ + budget encumbrance, then an approval chain, then idempotent PO submission
  • Separate the mutable requisition from the immutable PO snapshot — ERP and disputes depend on point-in-time truth
Staff+ signal
Link Problem Statement: B2B Ordering Platform to measurable procurement SLAs and audit trails, not generic microservices.
Avoid
Treating B2B as B2C plus invoices—misses approval DAG and contract entitlements.

Section Rescue Kit

Buzzwords to use:

Purchase Order SnapshotEntitlement Index

Safe statements:

  • "For Problem Statement: B2B Ordering Platform, I'll anchor on org_id tenancy and contract snapshots before discussing caches."
  • "If time is short, I'll draw requisition → approval → PO → ERP ACK and quantify PO RPS."
Design B2B Ordering Platform - System Design | WinJob | WinJob