Show live inventory data or buffered data: which do you choose?
This is the first fork in the road. You want to tell your customer how many units are available, but your back-office system works in batches, or stock levels fluctuate due to reservations that have not yet been confirmed. If you show live data that turns out to be incorrect, your customer will lose confidence in the portal faster than they gained it. Buffered data, updated every few hours, is in many cases more honest and more stable. The right choice depends on your lead times and the type of customer: a customer who orders large volumes every day has different needs than someone who reorders once a week. What you always want to avoid is showing a stock figure the customer acts on, only for your internal team to have to call back because reality looked different. That creates more friction than having no portal at all.
Connecting order history and reorder flow to the back-office system
The second bottleneck lies in the integration with your back office. Displaying order history is not technically difficult, but building a reorder flow that actually works requires the portal to have write access to your ERP or order management system. This is where things go wrong if your back-office system lacks a proper API, or if order lines contain product configurations that cannot simply be copied one-to-one. Think of customer-specific pricing agreements, minimum order quantities, or substitutes that were added by your internal team. A reorder button that ignores that context gives the customer a sense of control that does not reflect reality. The solution is not to make the portal more complex, but to be honest about which orders are suited to self-service reordering and which ones need a check from the internal team. Build that boundary in, and communicate it explicitly in the interface.
What belongs in the portal and what still runs through the internal team?
This is the most underestimated question when building a customer portal for wholesale. The temptation is to put everything in it: status information, non-standard orders, complaints, invoice queries, delivery changes. But a portal is not a replacement for a capable internal team. It is an extension for situations where self-service is faster and clearer than a phone call. If you try to handle a complaint or an urgent booking through the portal without human involvement, you risk leaving the customer clicking around when what they actually want is to speak to someone quickly. What works: status updates, invoice history, document downloads, standard reorders. What does not work as a fully automated process: custom requests, non-standard delivery instructions, complaints with financial consequences. Define that boundary before you start building, not after helpdesk tickets start piling up.
When does a customer portal create more friction instead of less?
A portal adds friction when the underlying data is unreliable, when the back-office integration is half-finished, or when your customer base is a mix of large accounts with complex agreements and small customers with straightforward needs. These groups require a different interface and different permissions. A portal that shows the same screen to both works well for neither. Large accounts want their dedicated contact, their own price list, their own order formats. Small customers simply want to find an invoice quickly. If you do not choose between these, you build something nobody fully uses and that your internal team still has to support. Sometimes the most honest advice is: start with one customer group, prove the concept, then expand.
How do you integrate a customer portal with your existing ERP or order system?
The integration strategy determines more than 80% of the lead time and the end result. If your back-office system has a modern REST API, you can build a portal that shows live or near-live data relatively quickly. If the system only supports database exports or batch connections, an intermediate layer is needed to normalise and expose data. That intermediate layer adds maintenance costs and is a potential point of failure. It is worth making no compromises here: a portal that goes down every three days due to a failed synchronisation is worse than no portal at all. If your back-office system is the bottleneck, this is also the moment to assess whether the system itself is due for replacement, rather than building a layer around an outdated core.