How to choose a B2B ordering system: considerations and costs

How to choose a B2B ordering system: considerations, permissions, and costs

A good ordering system can replace a process built on phone calls, messages, and spreadsheets with an organized, more convenient buying experience. But in a business setting, an impressive catalog and an order button are not enough: customers may buy at different prices, operate through several branches, and need approvals. At the same time, the sales team needs to keep managing personal relationships.

So how do you choose a B2B ordering system that will still fit your business after the demo? This guide will help sales, operations, and digital managers examine the processes, integrations, permissions, and total cost before signing.

1. Start with your sales model, not the feature list

Before approaching vendors, map your current ordering process: who orders, who approves, who handles exceptions, and what data is needed to complete the sale. Also define what you want to improve: is the goal to enable self-service repeat orders, reduce manual data entry, or make the catalog accessible to more customers?

In a wholesale ordering system, it is important to check support for customer-specific or group price lists, quantity tiers, promotions, minimum order amounts, and payment terms. Also check sales units and packaging: a product sold in single units to one customer may be sold by the carton to another.

Ask the vendor to demonstrate the rules on representative data and to state in writing what already exists in the product, what requires configuration, and what requires development. That way you can tell the difference between an available capability and a future promise.

2. Test the catalog and the ordering experience

A business ordering system should let customers find products and order them quickly. Check search by name and SKU, filtering, the display of variants, images, and relevant commercial information. If customers tend to repeat orders, ask to see how customers repeat a previous order or build a standing product list.

Some businesses need to show products only to certain customer groups or to hide prices until login. Also check what happens when a customer requests a quantity that is not available, when a product is sold only by the pack, or when the price changes before the order is confirmed.

Try the process on a phone and on a computer, in Hebrew and in right-to-left (RTL) layout. Alongside usability, examine which accessibility requirements apply to the service and how the vendor helps you meet them.

3. Define what passes between the system and the ERP

An ERP connection is not just about sending an order at the end of checkout. For each type of data, you need to define the source of truth, the direction of transfer, and the update frequency. For example, the ERP may manage price lists and inventory, while the ordering system collects the cart and shows the customer the processing status.

• Customers and users: Where is the customer record created, and how are users and branches associated with it?

• Products and prices: What is the source of SKUs, sales units, price lists, and promotions?

• Inventory: How often is it updated, and is availability shown overall or by warehouse?

• Orders and statuses: When is the order sent to the ERP, and how do the order number, changes, and status come back?

Also document how conflicting data is handled. For example, if a price is updated in the ERP while the customer is building a cart, it must be clear which price applies and when the customer sees the change.

4. Examine the connection method and error handling

An integration may be based on an API, file transfer, or EDI. The choice depends on the capabilities of the systems and on the business process, not just on the name of the technology. Ask for documentation, make sure the connection is compatible with your ERP version, and check usage limits, update frequency, and monitoring options.

Also ask what happens when a transfer fails: Is an alert raised? Who checks it? Can it be retried without creating a duplicate order? How is data that failed to sync recovered? Ask to see a demonstration of such a failure, not just of a successful transfer.

Finally, make sure you know who is responsible for maintaining the integration after an upgrade to either system, what support includes, and what may involve an additional charge.

5. Build a permissions matrix by role and company

When reviewing integrations and permissions in a B2B system, it is important to check the separation between customers, branches, and roles. A customer should not see another company's price lists or orders, and even within the same company, not every user may be allowed to perform the same actions.

Prepare a simple matrix of user groups and the actions each one is allowed to perform:

• Order preparer: Views the relevant products and prices and prepares a cart.

• Approver: Reviews the cart and submits the order on behalf of the company or branch.

• Customer admin: Manages users and permissions within the authority defined for them.

• Sales rep: Accesses the customers they are responsible for and performs the actions agreed with the business.

Check whether additional restrictions can be defined, such as approval above a certain amount, and how users joining and leaving are managed. Requirements vary between businesses, so it is important to actually test the scenarios that are relevant to you.

6. Make sure permissions are enforced behind the scenes too

Hiding a button or a screen is not enough to prevent unauthorized access. Ask the vendor to explain how permissions are checked on the server side and in the APIs, including when a user tries to directly access an order, a price list, or an action that does not belong to them.

The OWASP API Security Top 10 for 2023 includes risks related to object-level and function-level access authorization. You can use it as a basis for a conversation with your security team and the vendor. Also ask for information about security testing, activity logging, and how access by the vendor's employees is managed.

7. Calculate the total cost, not just the subscription

The cost of a B2B ordering system depends on your business requirements, the complexity of the integrations, and the pricing model. Comparing subscription fees alone can be misleading. Ask each vendor for a detailed proposal based on the same usage assumptions, and examine the total cost of ownership over a uniform period, for example three years.

The list of costs to check includes:

• Specification, setup, and initial implementation.

• Development or configuration of integrations, and migration of customer and product data.

• Customizations, design, and development work not included in the product.

• Subscription, maintenance, support, and training.

• Possible charges by number of users, orders, or volume of activity.

• Upgrades, future changes, and data export at the end of the contract.

Add up the one-time and ongoing costs over three years and add expected usage costs for the same volume of activity. Ask the vendor to state what is not included, how the price changes as activity grows, and what the indexation and renewal terms are. Without detailed proposals and shared assumptions, there is no single price that fits every business.

8. Check security, privacy, and payments

Find out who is responsible for backups, how often they run, and how the ability to restore is tested. Define responsibility for access management, activity logging, and reporting and handling security incidents. Ask where the data is stored and which subcontractors are involved in the service.

Check with the relevant professionals which law applies to the data and the service, including Israeli privacy protection law and the GDPR where relevant. Whether the requirements apply depends on the circumstances of the business and is not determined solely by the use of the system.

If you accept payments in the system, find out whether PCI DSS applies and how responsibility is divided between the business, the system vendor, and the payment processor. An external payment page may reduce the scope of handling card data, but it does not necessarily remove all security obligations.

9. Compare service levels and exit terms

Check the service level agreement (SLA): support hours, how faults are reported, guaranteed response times, and how outages that stop orders are handled. Clarify who coordinates the response when the system vendor, the ERP vendor, and the payment processor are all involved.

It is just as important to check the end of the contract: What data can be exported, in what format, within what time frame, and at what cost? Ask how you receive the order history, users, and catalog data, and what happens to backups and data after the service ends. Clear terms agreed in advance reduce dependency and make a future migration easier.

10. Run a pilot with customers and sales staff

A successful demo is no substitute for real use. Choose a group of customers and sales reps that represents different types of activity, and define the pilot's duration, scenarios, and success metrics in advance. Use representative data and test unusual situations as well:

• A customer with a special price or a quantity tier.

• A product that is out of stock or sold in different pack sizes.

• An order that requires manager approval before it is submitted.

• A change to an order after it was submitted, and a failed sync to the ERP.

• A user's attempt to access data belonging to another company or branch.

Measure, for example, the order completion rate, price accuracy, and the amount of manual work needed to handle orders. Also collect feedback on navigation, mobile use, and the clarity of messages. Define target values that suit your business in advance, so the decision is not based only on how participants feel.

Checklist before choosing a vendor

Before signing, make sure you have a requirements document, a demonstration of the key scenarios, a permissions matrix, and a written definition of every integration. Add to them a detailed three-year price quote, a service agreement and exit terms, and pilot results measured against the success metrics you defined.

The right system is not necessarily the one with the longest list of capabilities. Choose a vendor that proves it fits your sales processes, explains the limits of its product, and commits in writing to responsibilities, costs, and service levels.

Frequently asked questions about choosing a B2B ordering system

What should you check in the integration between a B2B ordering system and the ERP?

You need to define which data flows in each direction, who is responsible for each data item, and how often it is updated. It is also worth checking compatibility with your ERP version, error handling, and responsibility for maintaining the integration after upgrades.

Which permissions should you check in a B2B ordering system?

It is worth checking permissions by role, company, or branch, including separation between preparing an order and approving it. Make sure permissions are also enforced on the server side and in the APIs, not just by hiding screens.

How much does a B2B ordering system cost?

The cost depends on your business requirements and the vendor's pricing structure. Beyond the subscription, there may be costs for implementation, integrations, customizations, and support. It is best to compare the total cost over a uniform period, based on shared usage assumptions.