B2B sales start with who orders and on what terms

A company account may include several people with different permissions. A sales representative ordering on a customer's behalf should use that customer's terms, and the activity history must distinguish the person placing the order from the buyer.

These relationships are the starting point for designing accounts, catalogue access and price lists. Shared catalogues with company-specific products and prices are a feature of the B2B extension for paid Adobe Commerce or extensions for Magento Open Source. The appropriate process can be built using selected extensions and custom modules.

For each type of data, we define its source, update method and when it must be checked again. Equally important is deciding what happens during a communication outage. The platform may show the last known value with an appropriate notice, suspend purchasing or accept an order subject to confirmation.

No single option suits every company. The choice depends on price volatility, availability and sales rules. We also implement error handling, responses and retries. Buyers know whether terms need confirmation, and the team has a defined way to handle exceptions.

Regular buyers often know the SKUs and prepare a list of items and quantities. In these processes, we use quick ordering by product code, XLS imports and orders created by sales representatives. For repeat purchases, customers can use order history or standing order lists.

Units matter here: the number of cartons must be distinguished from the number of individual items, and a bulk pack from a single product. Customers can enter orders in the format they work with, and the data move to further processing without retyping the list.

We implement modern Quick Order features that recognise customers' order documents in different formats and map fields automatically. This makes ordering easier without requiring manual editing of XLS or CSV files.

With several warehouses, it is necessary to decide whether buyers see total availability or stock at their assigned location. Mixed orders, lead times and possible split deliveries require separate decisions.

We agree these rules with the logistics team and reflect them in the integration and store messages. Customers receive information consistent with how orders are fulfilled, and the service team can verify orders using the same rules.

In a marketplace, a catalogue product may appear in several sellers' offers. Each seller manages its own assortment, prices and sales locations. These elements must be separated in the data and permissions before designing the buyer interface.

We have experience with this model. The project scope includes both the partner panel and the customer's selection of an offer, including through a map. Sellers can manage their own offer on a shared platform, while buyers see who they can buy from and where.

We take over existing stores and integrations, including when development is slow and errors return after successive fixes. Our assessment covers code, data, configuration and the flow of orders to the back office.

Initial work is prioritised by its impact on sales and operations. It may involve repairing an integration, adding a missing ordering method or a broader rebuild. The company receives a plan explaining the purpose of each change and helping assess further investment.