A B2B experience built around your business rules

B2B covers very different realities. An independent reseller who orders twice a year doesn't operate like an international network with several locations, buyers, and approval chains.

We map the roles and the moments where a business rule needs to show up:

• How are a company and its locations created?
• Who can invite or remove a buyer?
• Which catalog and pricing does each location see?
• Are there minimums, multiples, or quantity rules?
• How are payments, due dates, and offline-prepared orders handled?
• Who can view, reorder, or track an order?
• Which data needs to flow back into the ERP or OMS?

This reading keeps us from rebuilding an old portal's workarounds inside Shopify.

Shopify B2B on Shopify Plus structures the relationship around companies, their locations, and their authorized buyers. The configuration needs to reflect your actual organization.

A group may buy for several locations. A buyer may have access to a single site, while a regional manager views several accounts. Addresses, payment terms, and catalogs can vary. Invitations and role changes need a clearly identified owner.

We define the rules with the sales and operations teams, then adapt the account experience. Custom development stays focused on what native configuration doesn't cover.

A B2B catalog isn't just a blanket discount.

A company may have a product selection, negotiated prices, quantity rules, and specific availability. Some ranges may be reserved for a network. Others need to appear with packaging different from DTC.

We document the source of each rule. If the ERP owns the contract price, Shopify needs to receive consistent, traceable data. If Shopify carries the catalog, teams need to know who edits it and how it's QA'd.

The catalog page and product page are designed for professional buying: visible SKU, clear packaging, efficient quantity entry, technical information, and quick access to products already known. The design serves the buyer's job.

Some customers order directly. Others go through a sales rep, a quote, a draft order, or internal approval. The project needs to specify which journeys belong in Shopify and which stay in another system.

We handle the dependencies around payment, terms, order statuses, cancellations, and returns. Information shown in the customer account needs to come from a reliable source. A vague "order in progress" message isn't enough if the sales team sees a different status in the ERP.

Sales support keeps its place. Shopify can cut down re-entry and make certain operations visible to buyers, but it doesn't automatically replace a company's own credit, negotiation, or approval processes.

Bringing B2B and DTC together can simplify the design system, the catalog, and maintenance. It can also create too many conditions in the theme if the models diverge sharply.

We assess:

• The level of shared catalog.
• Differences in price, content, and navigation.
• Account and checkout journeys.
• The markets and entities involved.
• Integrations and operational responsibilities.
• How fast the B2B and DTC teams each need to move.

One store isn't a doctrine. It's an architectural option. When separation is preferable, we explain it along with its consequences for data, deployments, and QA.

The portal can't show reliable business rules if the systems don't share the same identifiers.

We map companies, locations, buyers, products, catalogs, prices, and orders. Every object has a system of record. Transformations, errors, and recovery are defined before development starts.

The PIM can feed attributes and technical documents. The ERP can carry accounts, prices, and terms. The OMS can return availability and status. Shopify orchestrates the buying experience and passes orders along according to the chosen architecture.

1. Qualifying the business model

We work with e-commerce, sales, operations, and IT. We list customer types, pricing rules, orders, exceptions, and manual tasks.

2. Comparing native and custom

We check the Shopify B2B capabilities available for the plan and the project's context. Gaps are sorted into configuration, theme adaptation, an app, or integration.

3. Prototyping the sensitive journeys

Account, location selection, catalog, quantity, ordering, and tracking are mocked up before development. Edge cases surface earlier this way.

4. Building the flows

The data needed is connected to its source systems. Errors, duplicates, and delays are part of the design from the start.

5. QA-testing with real profiles

QA covers several companies, locations, buyers, catalogs, prices, and rights. The sales team takes part in QA when its own processes are involved.

Depending on scope, the project can include:

• A map of personas, accounts, and B2B journeys.
• A matrix comparing native capabilities, configuration, and custom development.
• The data model for company, location, buyer, and catalog.
• B2B templates built for recurring or high-volume purchasing.
• Integrations with ERP, PIM, OMS, or other chosen systems.
• Business QA, documentation, and training within the contracted scope.

We don't claim a portal alone solves wholesale organization. We build the Shopify side around validated rules and named owners.

Enlaps, a French startup making autonomous, connected timelapse cameras, sells its technical products with a B2B catalog and a multi-market experience on Shopify.

Les Secrets de Loly evolved its Shopify Plus store to serve both its retail customers and its resellers: a custom B2B catalog, customer account, and checkout, a tailored affiliate program, and international extension stores.