I build B2B ecommerce workflows around how business customers buy. That means account access, product rules, repeat orders, quotes, and the systems that hold prices and stock. Plan those first. Then choose a storefront or platform.

Manufacturers and distributors need a website that hands off cleanly to their sales and operations teams. This guide explains the decisions to scope. Where products need it, my configurator work covers the visual specification step.

Discuss your trade buying processDownload a project brief

Why B2B ecommerce needs a different model

A consumer picks a product and pays at checkout. A business purchase can involve a buyer, an approver and a finance contact. They all work under one company account. What each person can see or do may depend on their branch, contract, credit status or role.

The goal is not always to remove every human contact. A good system moves routine work to self-service. It keeps sales or support involved where expert judgement adds value.

Possible measures include:

  • the share of eligible orders placed online;
  • time taken to create and approve an order;
  • how often prices or stock availability are disputed;
  • order-entry errors and manual fixes;
  • use of saved lists and repeat ordering;
  • how long quotes take to get a reply and be accepted;
  • support requests about routine account questions;
  • how often data syncs correctly with finance, stock and fulfilment systems.

These are measurement options. They are not promised outcomes. You need a starting baseline and reliable tracking before a project can claim any improvement.

Accounts, companies and roles

Start by modelling the customer’s company. A company may have several delivery locations, billing arrangements and users. Each person needs an identity, a role and clear permissions.

For example:

Role Typical permissions
Buyer Build baskets, request quotes, submit permitted orders
Approver Review or reject orders above agreed rules
Account administrator Invite users and manage delivery details
Finance contact Access invoices, credit information or payment records
Sales representative Assist the account without exposing unrelated customers

The model should define who can invite users, change addresses, see negotiated prices, place orders and approve spend. It should also cover staff who leave, locked accounts and disputed access.

Shopify’s B2B company model separates three things. They are the parent company, its company locations and the individual customers who buy for them. Other platforms use other names. The core design problem is the same.

Company account roles and approval checkpoints guiding a purchase request into a shared business order
B2B ecommerce needs explicit account roles and approval paths so the portal reflects how a buying organisation actually works.

Products, pricing and quantity rules

B2B customers may see different products. They may have contract prices, currencies, tax treatment, minimum quantities or volume discounts. These rules need one source of truth and a clear order of priority.

Do not start with the screen that shows a price. First, answer these questions:

  • Is the base price held in the ecommerce platform, the ERP or a pricing system?
  • Can a contract price override a customer-group price?
  • What happens when two catalogues apply to one customer?
  • Do discounts stack, or does only one apply?
  • Does a quantity break count units, packs, cases or total order value?
  • When does a new price take effect?
  • What should the customer see if no valid price exists?

Shopify’s current B2B catalogue guidance shows how product availability, company assignments, quantity rules and volume pricing can link together. Treat those features as evidence for that platform only. They are not a universal design.

Test complex rules with a decision table. Include normal orders, boundary quantities, overlapping assignments, expired agreements and products with missing data.

Quotes, approvals and payment terms

Some orders are ready for checkout. Others need a negotiated quote, internal approval or a purchase order.

A quote workflow should define:

  1. who can request a quote;
  2. which product and configuration details are captured;
  3. how freight, tax and validity are handled;
  4. who may edit or approve the commercial terms;
  5. how an accepted quote becomes an order;
  6. what happens if stock or price changes;
  7. where the audit record is kept.

Approval rules need the same precision. Thresholds may vary by user, department, location or category. The interface should tell the buyer why approval is needed. It should give the approver enough context to decide. The approver should not have to rebuild the basket somewhere else.

Payment terms raise questions about credit and reconciliation. The storefront should not invent credit status. It should show official data and handle missing data safely. It should record how each order was authorised.

The B2B checkout guide and scenario matrix covers account review, internal purchase approval and orders on terms. Each has its own confirmation states and exception owners.

Integrations and data ownership

B2B commerce often depends on several systems:

  • an ERP for customers, prices, stock or orders;
  • a PIM for product information;
  • a CRM for accounts and sales activity;
  • a warehouse or fulfilment platform;
  • finance, tax or credit services;
  • procurement networks or electronic data interchange (EDI);
  • identity providers for single sign-on.

Map the integrations before you estimate the work. For each important field, name the system of record. Then name the update direction, timing, validation rule and operational owner.

Plan for failure too. A dependable integration needs logs, safe retries, duplicate protection, alerts and a manual recovery route. One clean test order does not prove the system can handle timeouts, conflicting updates or partial data.

Repeat ordering and account self-service

Repeat buying is one of the clearest B2B opportunities. Buyers may want to reorder a past basket. They may upload a product list, use saved order templates or enter stock codes and quantities directly.

A good build checks current prices, stock and permissions when it rebuilds the order. It does not copy old values blindly. Show clear messages for exceptions. Examples are a discontinued item, a changed pack size, an expired contract or not enough permission.

Account self-service may also cover delivery addresses, user admin, invoices, returns, quotes and order tracking. Choose tasks based on support requests and customer interviews. A long account menu does not help if the most common job is still hard.

Structured product data and customer-specific pricing passing through an integration core into a repeat-order workflow
Reliable repeat ordering depends on one consistent view of product data, commercial rules and the customer account.

A reusable delivery framework

  1. Map the buying company

    Interview buyers, approvers, sales staff, customer service, finance and operations. Write down company structures, roles, exceptions and work done by email, spreadsheets or phone calls.

  2. Set the rules before the features

    Create decision tables for catalogue access, pricing, quantities, quotes, approval and payment. For each rule, record its source and the person allowed to change it.

  3. Agree on data and integration contracts

    Agree on field definitions, identifiers, update timing, error behaviour and who owns what between systems. Use real customer and product records. Include the hard cases.

  4. Prototype the riskiest journey

    Test one realistic account from sign-in to an accepted order. Include several roles, customer pricing, an approval and an integration response. This finds gaps faster than designing every account page.

  5. Build and test by scenario

    Write acceptance tests in business language. Describe who the user is, which account they act for, what conditions apply and what result should follow. Cover permissions and failure states, not only the normal path.

  6. Roll out in controlled stages

    A pilot group can reveal problems with training, data and operations. Before the wider rollout, decide how feedback is recorded, who supports users and what must be true before you expand.

Practical example: a repeat-ordering portal

Imagine a supplier whose customers email spreadsheets of stock codes and quantities. Staff retype each order into the ERP. Then they contact the buyer about old items or wrong pack sizes.

A portal could let permitted buyers upload the list. It would match codes to current products and show prices for each account. It would flag exceptions before submission. Orders above an account limit would go to an approver. Accepted orders would pass to the ERP with a shared reference.

The dependency map would cover customer identity, catalogue access, price source, stock status, pack rules, approval limits and ERP confirmation. To judge the result, compare the old and pilot processes. Use error records, processing time and support demand. Without verified observations, do not claim any uplift.

Trade-offs and common mistakes

  • Too much customisation: Rebuilding every old exception can make the new system harder to support than the old one.
  • Weak identity design: Treating each user as a separate customer breaks company-level control.
  • Unclear price ownership: Conflicting systems cause disputes and unreliable baskets.
  • Testing only the perfect path: Real accounts have expired agreements, missing data and unusual permissions.
  • Ignoring sales teams: Self-service fails if it removes useful help or hides account context.
  • No recovery process: Integration errors turn into hidden orders or duplicate work.
  • Choosing a platform too early: A feature list cannot replace tested business rules.
  • No adoption plan: Customers need the right accounts, accurate data, training and support.

Action checklist

  • List the companies, locations and user roles the system must cover.
  • Write down the product, pricing, quote, approval and payment rules.
  • Name the source of truth for each critical data field.
  • Map integrations, failure states and the owner of each.
  • Pick one high-value journey to prototype.
  • Record baseline measures before you start building.
  • Test permissions, limits and recovery scenarios.
  • Plan pilot access, support, feedback and the wider rollout.

For help turning these decisions into a clear scope, review selected work or contact Niall. How I handle your details is set out in my privacy policy.

Compare B2B platforms and full costs

The right B2B platform supports your customers’ buying rules reliably. It also lets your team maintain those rules. Before you compare software, write down three real orders. Use a new customer’s first purchase, a repeat buyer restocking, and an exception that now needs a phone call. Those journeys show needs that a generic demo hides.

  • Hosted commerce with B2B features: The provider runs the infrastructure, and the buying features are established. Which required features are in the proposed plan? Which need apps or custom work? Shopify documents company-based setup, so confirm current plan eligibility.
  • WordPress and WooCommerce with extensions: Suits content-led businesses with a defined trade workflow. Who keeps the pricing, account and payment extensions working together?
  • Specialist B2B platform: Suits complex account structures or sector-specific operations. Can your real catalogue and approval process be demonstrated before you commit?
  • Custom application: Suits a distinctive quoting, configuration or ordering process. Who owns integration contracts, failure handling and long-term support?

Turn requirements into acceptance tests. Replace a requirement like “supports trade pricing” with a test case. For example, an approved customer at branch A sees its agreed price. A public visitor sees only permitted information. The system acts sensibly when the customer switches branch, goes over a credit limit or orders a restricted product. For repeat orders, test a discontinued item, a changed pack size and a quantity above available stock. For configurable products, decide whether the output is a payable item or a quote for review.

Write down which system is the authority for product identifiers, stock, customer terms, prices and order status. Then ask what happens when an external system is down. Can customers still browse? Are prices current enough? Are orders held safely, or rejected clearly?

Treat trends such as self-service portals, assisted quoting and AI-supported discovery as things to test against a real task. They are not requirements in themselves.

Compare the full cost. Include setup, data cleanup, subscriptions, integrations, support, training and the manual re-entry that remains after launch. Score what is shown to work separately from roadmap promises. Then run a proof of concept on the riskiest journey. If your shortlist is Shopify and WooCommerce, the platform comparison adds a requirements list and a cost worksheet.

Choose a platform by testing the trade journey

A B2B ecommerce portal must prove account pricing, order permissions, repeat purchasing and the handoff to operations. Use the B2B platform comparison framework to turn those needs into acceptance tests before you choose software.

If products need visual specification, the configurator data guide explains how identifiers, options and rules connect to the receiving system.

To make a trade catalogue easier to find, see B2B ecommerce SEO. It covers part numbers, datasheets, gated pricing and qualified enquiries.

Related reading: Magento and Adobe Commerce configurators.

Frequently asked questions

What is a B2B ecommerce portal?

It is a logged-in buying space for business customers. It can show account-specific products, prices, users, approvals, quotes, orders and documents.

Can B2B and consumer customers use the same store?

Some platforms support a mixed model. Whether it suits you depends on your catalogue, pricing, checkout, content and operations. Compare it with separate storefronts using your own scenarios.

Does B2B ecommerce replace a sales team?

It should remove avoidable admin and make routine buying easier. Salespeople stay involved in advice, negotiation and complex deals where their judgement matters.

Which integration should you design first?

Start with the systems that own customer access, products, prices, stock and orders. Their limits shape the buying journey. They also carry the greatest operational risk.

How do we choose a platform?

Test each shortlisted platform against your roles, rules, data volumes, integrations, support needs and total running effort. A guided demo using your own scenarios is more useful than a generic feature tour.

For large trade catalogues, the product finder and filter design guide covers filters, counts and no-match recovery.