Introducing a B2B portal can start with a small group of partners while everyone else continues to order by email. During that transition, choose one place where sales confirms orders, assign someone to review possible duplicates and agree how emails attach to an existing request. Check the full handoff to fulfilment before inviting more buyers.
A buyer might submit an order through the portal and then email it “just in case”. Sales needs to establish whether that message is a copy, an amendment or a separate purchase. Plan that process as part of the first version of your B2B portal.
Which partners should join the pilot?
Choose a group small enough for your team to follow each order through individually. Include different purchasing routines: a buyer who repeats a familiar list and one with several branches or an approval step. Select participants around your actual customers and the first task you want the portal to support.
Record each partner's branch, users, price list and permitted actions. Agree who helps them when they get stuck. The person who usually orders should try the task on their own device. A demonstration led by a salesperson can hide the points where a buyer needs help.
Before the pilot, use a clearly labelled test company and sample data, with sales and the warehouse aware of the exercise. The official Shopify B2B testing guide, for example, calls for a test company, a catalogue and an authorised customer, followed by checks of prices and terms. The exact procedure depends on your platform and configuration.
Where should the final order record live?
Choose one system or controlled register from which the warehouse receives work. It might be your existing ERP or another agreed application. If the integration is not ready, sales can temporarily enter accepted requests by hand and retain a link to the original. Assign that work to someone and keep a visible list of requests awaiting entry.
The portal and shared inbox remain intake channels. Give each confirmed order one internal reference. Retain the buyer's reference, where provided, and the source of the request. When matching a buyer's number, account for the company, branch and numbering rules. Different customers can use the same number.
Distinguish receipt of a request, acceptance by sales and stock reservation. A receipt should explain whether prices, availability or delivery dates still need checking. Agree which system reserves stock and when it does so as part of connecting ordering with inventory and business software.
How should sales handle the same request by email and portal?
Include a request reference in the receipt and ask the buyer to use it for amendments. The person reviewing email looks for that reference first. If it is missing, they compare the customer, branch, items, quantities and requested delivery. Similarity calls for a check with the buyer: a customer may deliberately order the same goods twice.
The following example is fictional and illustrates a proposed procedure. It reports no client test results or features of a particular project. The internal reference N-1042 and buyer references are sample values only.
Scroll the table sideways to see all columns.
| What arrives | What sales checks | What is recorded |
|---|---|---|
| Portal request with buyer reference PO-27 | Company A, Central branch, items and terms. | One request under internal reference N-1042, awaiting a sales decision. |
| Email saying “Also sending PO-27 here, as submitted in the portal” | The link to N-1042 and confirmation that no additional purchase is intended. | The message attached to the existing request, with no new warehouse instruction. |
| An email changing the quantity | Whether stock is reserved or fulfilment has started, and who can approve the change. | An amendment to the same request, retaining the previous value and the reply to the buyer. |
| The same buyer requests identical items for a separate delivery | Confirmation that the buyer intends another order. | A new internal reference and separate processing once the new purchase is confirmed. |
A portal can be designed to recognise a retry of the same technical request by its identifier and return the existing result. That behaviour needs to be specified and tested. A separate email may carry no such identifier, so detecting the buyer's duplicate intent needs another rule or a person reviewing it. Your API integration plan should also cover repeated transfers into the business system.
What if prices or approvals are still pending?
Record which price list applies to the branch and what happens to a request submitted before a price change. The buyer should be able to identify the version they approved and who confirms the final terms. If details change, retain the connection between the original request and the agreed amendment.
The buyer's own purchasing approval may be a separate step. Adobe Commerce documentation describes flows where a user submits a purchase request and an order follows after the required approvals and further steps. Roles and payment methods affect that flow. In your portal, give each state a clear name and identify the person responsible for the next action.
What should you check before inviting the next group?
Write the scenarios and expected outcomes before testing. Record what was actually run, the environment and who confirmed receipt. The following list proposes checks; it is not evidence that your solution has already passed them.
- A buyer submits a request from their phone, receives a reference and can find where to send an amendment.
- Sales attaches an email to the existing request, and the warehouse receives one approved instruction for that purchase.
- A connection failure and retry of the same action create no additional record, while a genuine new order remains possible.
- Quantity changes and cancellation requests reach the person handling fulfilment, with an agreed process for reserved or prepared goods.
- A customer cannot access another company's orders or documents, including through a direct link.
- A failed transfer into business software leaves the request visible for review, with a controlled way to resume processing.
Pause expansion if receipts are unclear, access permissions fail or order records have unexplained differences. If you temporarily return to email, preserve open references and reconcile the records before reopening portal ordering. Switching channels should not restart instructions already accepted for fulfilment.
How do you know whether the pilot helped?
Before launch, review a sample of comparable email orders. Record the time sales actively spends processing them, the requests for missing information and manual re-entry. Keep time waiting for the buyer or an approval separate from staff handling time.
During the pilot, track the same measures, the help partners need and discrepancies between the portal and final order record. State the number and types of orders reviewed. A repeat purchase and a complex first request involve different work, so compare those groups separately.
Base the decision to invite more partners on completed tasks and unresolved problems. Portal visits and account counts can indicate use; assessing order handling needs evidence from actual orders.
What should you prepare for a portal rollout plan?
Bring an anonymised email order, the steps sales currently performs and a description of the system where processing ends. Add the rules for pricing, approval and changes to accepted orders. If you are still choosing the type of solution, read our comparison of a B2B portal and online store.
For a B2B portal estimate, send an outline of one process and the first group of partners. We can use that to work through the first release, responsibilities during parallel ordering and checks before expansion.