B2B Ecommerce Portals: Build Ordering, Pricing and Approval Workflows That Fit

The purchasing manager passes an order list in Excel to the supplier. Sales reviews the account price, makes corrections to two item codes, queries the delivery address, and sends the order for approval. The customer then calls to ask whether the supplier received the order. None of these activities are out of the ordinary, yet together they produce delays and plenty of chances for misinformation to find its way onto the order.

A B2B ecommerce site could help to streamline this process. Businesses could easily access the correct catalog, enter the right terms for their account, place an order, and track the order status. The hard part is not adding a login screen to an existing online store. The challenge is converting the supplier's account management and processes into an order system that actually works.

This guide outlines the thought process that goes into building an ecommerce portal for B2B businesses. The topics covered include the business account, negotiations, quotation, permissions, inventory management, integration, and launch. The use cases described do not come from any Digitonix customer experience; they are possible use cases and examples. You should rely on your experience with orders to make these decisions.

Order mapping is key to creating a catalog

Trace an order from its inception all the way through delivery and settlement. Identify who creates it, who signs off on it, who verifies terms and who sorts out changes. Determine what documents are created in the process, and copied across systems. Figure out where an order gets held up and why. The portal has to solve that problem, not re-create it online.

Analyze multiple types of accounts. The same type of approval process and shipping rules may not be applied for a reseller account and a customer with multiple branches. Describe the standard workflow and the exceptions that arise often enough for you to consider them. Specify those exceptions that are usually agreed upon and can stay within sales at this initial point. This will save you from automating the very first release with all the exceptions that the company ever tolerated before.

Define organizations, locations and users

There might be multiple people working for an organization and multiple delivery locations. Determine which entities represent the company, which entities represent the location and which entities represent individuals. Changing jobs should not mean deleting a company's purchase history. Neither should opening a new delivery location give it access to the privileges of a different branch or department.

Use stable identifiers for the portal and related systems. People can change their names and email addresses, and two places can use the same point of contact. Define how accounts are created, validated, merged, and retired. Provide the account managers a mechanism for correcting the relationships. This gets you an easier model to explain during pricing, permissions, and integration after more customers and systems rely on it.

Create roles that reflect buying activity

Potential roles could be the person preparing orders, the person approving orders, and the administrator of company users. The actual roles should be defined based on the customer's process. Not everybody logged in needs access to all the account records or to adjust deliveries. Focus on what permission is needed for individual operations rather than a simple menu visibility test.

Enforce authorization on the application services that read or modify the record. Button hiding is an excellent feature from the user perspective, but it is not the boundary that keeps other company’s price list safe. Evaluate modifications to roles and the companies’ memberships, including invites and previous company members. Provide clear explanations in cases where an action cannot be performed so that buyers can find out whom to approach - their admin or supplier.

Establish the origin of the account pricing

Understand the origin of negotiated prices and how these prices get into the portal. It could be an ERP, a commerce system, or a managed price list. Define the rules concerning quantities, products, currencies, and validity. If people working for the company cannot tell the precedence of a particular rule, then the developers will try to guess, and this guess will affect actual orders.

Display the applicable account terms clearly and verify them again when the order is submitted. What cost was valid yesterday might be invalid now due to changes in the contract or changes in quantity. Make such changes without silently overriding an approved total cost. Explain why it is necessary and stick to the required approval process. It is important for your customer to have consistent information from the product page, quotation, confirmation, and actual operation.

Keep catalogues appropriate for the account

There can be customers who purchase only certain products or even have certain configuration for their account. You have to decide whether your portal will operate with shared catalogues, restricted catalogues, or even both. Visibility of the products must correspond to the business rules that were specified. Do not rely on the frontend filtering mechanism when building an account-specific catalogue.

Product codes, pack sizes, units, and compatibilities must be managed carefully. Business buyers tend to know a code or reorder a prior item, hence facilitate those approaches along with conventional browsing. Clarify minimums and order incrementation prior to submission. A product appearing to be sold by the unit but shipped in cartons is one that can result in significant confusion due to differing interpretations of quantity on the part of the buyer and warehouse staff.

Provide a real-world approach to repeat ordering

Start with previous orders, saved selections, or templates if such an approach fits the task. Rather than simply duplicating the previous order, reconfirm product availability, conditions, and shipment logistics. Provide information regarding products that have been updated or removed since last ordering. The repeat function must facilitate the process, yet also help the buyer see where new decision-making is needed for a complete order.

In the case of spreadsheets or quick entry forms, show the buyer a preview with row-level feedback. Look out for codes not known, invalid quantities and confusing units. You cannot accept just half a file while keeping the outcome unclear. Allow the buyer to rectify any mistakes and know what will be sent. Use customer spreadsheets that represent reality, and not an example made up for the demo.

Version control for quotes

A quote could have many versions due to negotiation of some terms, expiration date, substitution and delivery terms. Capture all this information and keep track of the version you are viewing. If the salesperson makes changes on the line and the customer makes changes to the quantity, determine if there is a need for another approval process. The quote number might not be sufficient to know the accepted version.

State clearly that the quotation will convert into an order. Confirm the relevant conditions in terms of your established policy, such as whether the quotation is still valid and the management of inventory. Let the customer know the difference before completing the sale. Do not suggest that a previously accepted quotation automatically holds stock unless this is what the company does.

Approval processes based on the decision

Approval criteria should be defined in collaboration with the purchasing teams responsible. This could relate to the order amount, location, department, type of goods purchased, or any other business criterion. Present the entire offer to the approver along with the changes. Define clearly what the approve, reject, and change requests mean. Do not create a process where the purchaser has to contact support because nobody knows which approval step has the order at the moment.

Approvals must be tied to the version of document under review. Any future modification of address, quantity, or total may require additional approvals. Document the history of approvals and let the buyer know of their current status. Make sure to have a plan in case of the absence of the approver or his or her leaving the company. Portal must allow for authorized reassignment of approvers, not promote account sharing by staff members.

Order status that operations can support

Select customer-facing statuses that map to operations processes. "Submitted", "accepted", "awaiting approval", "dispatched" and "completed" will all have meanings. "Accepted" status cannot be shown because of request submitted by a browser. Clarify whether the supplier has accepted and verified the order and provide a reference to help support trace the order status in the underlying systems.

Keep the status message clear when there is a split in orders among several shipments. A single green 'complete' label can hide a missing item. Include relevant products and next steps wherever appropriate. Define the display format for cancellation, substitution, and partial delivery. Review the wording with operations so the customer view describes states that the warehouse, sales team, and integration can actually confirm.

Inventory tracking with transparency

Find out where the inventory comes from and how old the available data is in the portal. Available stock, forecasted stock, and confirmed reservation are not the same thing. Make sure the customer knows which of those he is seeing in the portal. In case of integration delay, outline what happens on submission and how the supplier handles an order that exceeds actual availability.

Make provisions for integration problems without creating fictitious certainty. For example, the portal could stop ordering, let users make a quote request, or offer a qualified indication of availability, depending on the business. Make a provision for exceptions that can be reconciled by the operations team. It is also a product question; customers should know whether they are placing an order or making a request for approval.

Build your integrations with ownership and recovery

Draw a field ownership map for your company, addresses, products, prices, orders, and status. Determine what systems may change a field, and how to resolve any problems when that happens. Don't assume that any system can overwrite any other just because it has an API. The software development services of Digitonix may also help in this regard.

Employ long-lasting operational logs, explicit identification, and a retry mechanism that avoids duplicating the transaction from the business standpoint. Order creation may be successful within the ERP system, while confirmation may be dropped. It must be possible to explain to the support staff how to examine this status and restore it. Reconciliation must be done by comparing expectations with actual records in the source system, otherwise quiet delivery failures will go unnoticed for weeks.

Describe delivery and payment terms clearly

There may be different account terms. Explain what terms apply to the order being processed now and not the general terms of retail checkout page. Describe the delivery address, delivery method, and the payment expectations before order submission. If there is no actual order creation on the portal side but just a request for sales review, say so.

Ensure that the business reviews the commercial wording and gets proper advice regarding contractual considerations. Developers require concrete guidelines for the interface and records once such decisions have been made. Do not make a commitment to a credit facility unless it has been approved for the account. Make changes to the commercial terms traceable and ensure that the update process for the portal does not overwrite the terms on the accepted order.

Select the platform post assessment of the workflow

The commerce platform might have B2B capability relevant to your use case but this will depend upon their current plan and implementations. The Shopify B2B development guide highlights the platform concepts that should be reviewed. Assess the current eligibility and limitations of your planned deployment. The capabilities of Digitonix on the Shopify platform should be assessed against this criterion. See Shopify's B2B development documentation for related information.

Custom solutions could be considered where the account structure or integration demands behavior that is not available in the selected platform. Next.js, Node.js, and PostgreSQL could be some possible options to discuss. Consider comparing maintainability, operational cost, and flexibility. The custom solution will still require proper management of catalogue ownership, permissions, and the operation support process.

Test exceptions identified by sales and support

Consider demonstrating a price change during the approval process, an unavailability of the repeated order item, duplicate submission, and an account user losing their permissions. Consider adding an ERP timeout after a possible order acceptance. Observe what happens from the customer's point of view and what can be investigated by support staff. These examples will say much more about reliability than a test run where every integration works properly.

Evaluate usability with representative buyers. See if they comprehend units, find recurring products, check for changes, and know what to do next. Make sure keyboard accessibility and error recovery are there. UI/UX design services will assist with the above tasks, whereas cloud and DevOps services may prove useful when deploying and monitoring the system using the selected architecture.

Move accounts and orders with a review

Before moving the data, find duplicate accounts, missing relationships, inactive addresses, and ambiguity about who owns prices. Do not assume that successful completion of import implies no errors in the business data. Produce a representative preview for account managers to review. Record the unresolvable cases and determine whether they prevent the launch of the system or stay part of a controlled manual process.

Arrange invitation and assistance for your current clients. State clearly what is going to change with the new portal and what will happen with the previous ordering system during transition. Plan to have a pilot user group to try the new system and find the potential issues before moving forward with implementation. Prepare yourself for any possible issues regarding import or configuration of your information. The process of transition is considered to be over when your customers and employees get used to use it in their work, not when you are able to access the new log-in page.

Measure adoption and operations together

Record useful actions like completing an order form, completing repeat orders, delays in approvals and contacts made for support because the user was confused about how to use the portal. Measure the portal against its predecessor, considering the differences in the customers and the seasons of the year. Lots of registrations does not matter if customers are still sending orders via email spreadsheet because the portal can't meet their needs.

Consider what is left in sales and operations to do. Some manual actions may be required, especially for unique agreements or configurations. Consider whether the portal reduces redundant activities that could have been eliminated or simply passes them to another group. Base your prioritization for future releases on that analysis. New features should respond to specific demands and ownership, not an inventory of B2B capabilities.

How Digitonix can assist planning a B2B portal

Show some examples of your orders, account types, pricing models, approvals and integrations. You can discuss this matter with Digitonix during the discovery process, ecommerce buildout, integration and implementation. Ask for a proposal which includes the description of the process, acceptance criteria, data collection, maintenance issues and other details. Such an approach will allow you to evaluate your options easily and objectively. See ecommerce development for more information.

Examine what Digitonix has to offer and request a consultation for your specific order case. Request a demonstration of handling an error and recovery of the transaction as well as a regular purchase process. A reliable B2B portal consists of useful customer journeys complemented by logs and operational processes that are understandable for sales, finance, and fulfillment teams after going live. See technology capabilities and contact the team for related information.

Frequently asked questions

Does B2B portal mean just a login-enabled ecommerce website?

Not always. Company relations, prices for accounts, locations, approval processes, repeat orders, and operations can be different from usual order processing procedures. First of all, you need to define those differences. In some cases, there will be enough standard platform functionality available, while in other situations, customization will be required. It all depends on the actual process and platform eligibility rather than the availability of a login form only.

Do customers have different prices for one product?

This could very well be a legitimate business requirement, but it must have a clear source and owner. Determine what type of arrangement will apply to the account in question and validate it when submitting the request. Ensure the confidentiality of restricted pricing on the services which will provide the data back. Document any changes which have occurred between preparation and validation and adhere to the pre-negotiated approval process.

What if an order submission times out?

There is a possibility that the order failed, or that the order was actually successful, but without a confirmation response being sent back to the portal. The system requires an operation history and a process for validating the source system before resubmission of a critical transaction. Document the unknown condition truthfully and provide the support function with a helpful reference point.

Which customers should participate in the initial pilot?

Select a suitable group of clients which is representative of your intended first workflow and include suitable variation in account and order requirements among them. Do not include only such clients whose needs are too simple to cater to. Explain the workflow and give proof of successful accomplishment, misunderstandings, and exceptions in the process. Extend it after your team knows the issues involved and can handle the account and process well.

How would you decide the winners of this project?

Give representative orders along with pricing criteria, constraints in the interface and failure criteria to all bidding firms. Figure out who will be responsible for preparing the data, acceptance testing, operations and modifications in future. Compare recurring costs and platform constraints with the development requirements. The winning proposal should explain how things go wrong with the workflow, not how they appear in the demo.