Standard or custom B2B platform

Choosing a B2B platform often starts with a simple request: let customers place orders online. Then the conditions your sales team handles every day emerge: one customer buys from a specific price list, another requests a quote and a third needs deliveries to several locations.

Many of these rules already exist, although they are spread across your management system, emails and people's experience. The ecommerce project needs to make them explicit so buying online does not force customers to call and resolve what the website cannot handle.

You do not need to develop everything from scratch. You need to check what a platform covers, what requires configuration and what needs genuine adaptation.

The B2B platform starts with your customers

A portal can serve repeat orders, catalogue browsing, quote requests or relationships with new customers. These goals do not require exactly the same journey, even when they share products.

If your customers already order by phone, observe what information they need before confirming. It might be availability, a compatible product reference or the application of their terms. Bringing that context into the digital channel often matters more than adding features nobody will use.

The channel also needs to fit the sales team's work. Decide what customers can do themselves and when a person steps in. A quote request can be the right endpoint for certain transactions. Not everything needs to end with immediate payment.

B2B ecommerce works better when this decision is settled before design begins. You can then assess whether the portal makes work easier for both sides or adds another inbox someone must handle manually.

Pricing deserves its own test

“Customer-specific pricing” can mean several things. A price list assigned to an account is different from a combination of discounts, quantities, product-family agreements and negotiated offers. Document the rules you actually use before signing a contract.

Then test a representative order and an exception. The aim is to check that the displayed price, quote and final order follow the same logic. If the calculation depends on another system, you also need to decide what happens when that system is unavailable.

Do not pass a discrepancy the project should resolve internally on to the buyer. If the website displays one price and the team corrects it later, the channel may be less convenient than the previous process.

Some rules can be simplified through a commercial decision. Others are part of the agreement with the customer and must be preserved. The business should make that distinction with information about the consequences, rather than discovering an unexpected limitation at the end of development.

Catalogue, availability and orders

A useful catalogue needs information that helps people choose: references, attributes, documentation and images where relevant. The first task may be to organise those data and decide who maintains them, even before changing platforms.

Availability needs its own policy. Showing exact stock, an approximate indication or a timeframe for an enquiry involves different commitments. Define what your systems and available update frequency can support.

For orders, check the entire journey: creation, receipt, confirmation and later access. Changes and cancellations also need explicit handling, even if the sales team manages them initially.

Ecommerce lets you answer enquiries and receive requests outside the team's working hours. That availability is useful, but it does not mean promising an immediate response or automatic delivery. The portal's wording should reflect what operations can fulfil.

What an existing platform can offer

An existing solution is a good foundation when it covers the main journey and adaptations are limited. You can focus effort on data, implementation and the buying experience instead of rebuilding common features.

Ask for each requirement to be classified clearly: available, configurable, covered by an extension or requiring development. This distinction shows where risk is concentrated and who will maintain each part afterwards.

You should also check the limits of the proposed plan or architecture. A feature shown in a demonstration may depend on a different subscription or an integration that is not included in the offer.

The test should use your rules and sample data. A generic catalogue helps you assess navigation, but it does not demonstrate that the platform can handle a pricing exception or an order with the administrative journey you need.

SaaS, open source and custom development

With a SaaS service, the provider handles part of the technical operation. You still need to review the contract, data exports, integrations, limits and price changes. Operational convenience should be assessed alongside those conditions.

An open-source solution provides access to the code under its licence, but someone must handle hosting, updates and support. It does not inherently mean losing control of your data, nor does it guarantee that every change will be simple.

Custom development lets you work around the business's specific rules, with responsibility for maintaining what you build. It can start from an ecommerce foundation: the Django Oscar documentation presents it as an extensible framework for building ecommerce solutions.

These options are not always mutually exclusive. An ecommerce development project can combine an existing foundation with custom modules and integrations. What matters is that the proposal explains the combination rather than hiding specific work behind a generic label.

ERP integration requires a defined exchange

Before discussing a connector, identify which data need to travel: products, customers, prices, stock or orders. For each one, decide where it is maintained and in which direction it is updated.

Then review how incidents are detected. If an order does not reach the management system, someone must be able to find it, understand why and recover it. If a transmission is repeated, the solution should prevent it from appearing as a second transaction.

Integration also needs agreement on frequency and responsibility. Periodic updates may be enough for a particular catalogue. Another process may need a different response. Do not promise immediate synchronisation without checking what both systems allow.

A platform's ability to integrate with an ERP does not establish that a specific connector exists. Ask for the system's name and version, the operations covered and a demonstration of the journey included in the project. This information is worth more than a long list of logos.

What Nou Grup shows

For Nou Grup, Mecexis developed B2B platforms for members of an electrical supplies distribution group. The case describes a combination of individual and shared catalogues, built on Django Oscar.

The example is useful because the commercial need includes autonomy for each member and a shared catalogue component. That balance affects the system and content administration. It cannot be resolved simply by changing a store's appearance.

The case also describes the ability to adapt to the members' existing ERP systems, but does not identify a specific integration brand, version and flow. It should therefore not be used as proof that every connector is available or that another implementation will have the same scope.

The first launch should complete a journey

A reasonable initial scope lets a group of customers complete a useful task: check their terms, prepare a request or submit an order the team can process. This provides more information than opening many features at once without completing any connection.

Agree how you will evaluate that first phase. Alongside visits, observe whether customers complete the journey, where they need help and how much manual work receiving orders creates. Do not confuse website activity with valid orders or savings in sales work.

Include maintenance, training and corrections in the cost comparison. If the proposal requires someone to review every order outside the system, that work is part of the cost even when it does not appear in the platform fee.

The best choice will let you support your commercial terms clearly. When customers can transact and the team understands what has happened, the channel starts to become part of the business instead of another screen to attend to.