A B2B customer portal should not start with a dashboard. It should start with a business process.

Many portal projects begin by asking what the homepage should look like. The more useful question is:

What does a customer repeatedly need from the business that currently requires manual work?

That might be finding the right product, checking a price, placing or repeating an order, downloading a document, checking status, updating users or contacting an account manager. A portal becomes valuable when those actions become easier.

At a glance

  • A portal is defined by context: identity, organisation, permissions and commercial rules.
  • The highest-value features are usually private catalog, correct pricing and reordering.
  • Registration and approval are part of the business process, not a formality.
  • Build one complete journey before adding dashboards and analytics.

Portal versus website

A normal website is primarily public. A portal is contextual. After authentication, the system knows something about the user and adapts what they see. That context is the real product.

PUBLIC WEBSITE
same information for everyone

B2B PORTAL
identity → organisation → permissions → commercial context → personalised interface

The ten parts of a B2B customer portal

1. Company accounts

The portal needs an organisation model: company, user, role and status. For more complex organisations, it needs a hierarchy that reflects the real relationship:

Company
└── Locations
    └── Users
        └── Roles

Forcing all buyers into individual consumer accounts is an architectural mistake that is expensive to undo later.

2. Registration and verification

Not every business should receive access immediately. A common workflow is request, company details, internal review, approval, commercial conditions, activation. This is especially relevant when prices, terms or products are confidential, which connects the portal to an internal approval workflow from day one.

3. Roles and permissions

Permissions should describe actions, not job titles. Model capabilities such as view prices, place orders, approve orders, manage users and view documents. A purchasing manager may need a different experience from a branch buyer, even within the same company.

4. Private catalog and pricing

For many businesses this is the central value proposition: the customer logs in and sees the products they can buy, the price they actually pay and the quantities they are allowed to order.

The difficult part is not displaying the price but determining it correctly. A pricing engine may consider customer, company, location, group, product, quantity, contract, currency and market. The model needs a canonical source — the platform, the ERP or another commercial system. This is covered in depth in B2B pricing architecture.

5. Product discovery

Professional buyers often shop differently from consumers. A consumer browses visually; a professional buyer arrives with a SKU, reference, dimensions, material, compatibility list, model or brand. The portal therefore benefits from strong search, filtering, SKU lookup, structured attributes, product tables and fast quantity entry.

6. Ordering workflows

Not every portal needs a standard ecommerce checkout. Common flows include direct order, approval (buyer creates, manager approves), commercial review (sales confirms price and availability) and quote (customer configures, then negotiates). Trying to force all four into one generic checkout usually creates friction.

7. Reordering

Repeated purchasing is one of the clearest opportunities in B2B. Offer order history, one-click reorder, saved lists, frequent products and purchase templates. A buyer placing the same 25 SKUs every month should not have to rediscover them.

8. Documents

Invoices, delivery notes, technical sheets, certificates, price lists and contracts can make a portal useful even before advanced commerce exists. But document access needs the same permission model as the rest of the portal — never assume every user within a company should see every document.

Post-purchase visibility is a useful place to start: in Baymard’s 2026 research on ecommerce accounts and self-service, 51% of participants selected order tracking as the most important self-service feature. That is consumer ecommerce research, not a B2B benchmark, but it supports testing order status before adding low-frequency dashboard widgets (Baymard Institute, 9 September 2026).

9. Integrations

A portal sits between the customer and several existing systems:

CUSTOMER
↓
PORTAL
↓
API / INTEGRATION
├── ERP
├── CRM
├── PIM
├── ACCOUNTING
└── LOGISTICS

Do not approach integration as “sync everything.” For each entity — customer, product, price, stock, order, invoice — decide which system owns it. The full method is in ERP, CRM and ecommerce integration.

10. A useful dashboard

Only now does the dashboard make sense. It should surface recent orders, pending actions, reorder shortcuts, account status, documents and support — not ten charts. A good portal dashboard shortens the distance between login and the next useful action.

Architecture

A simple portal might use a frontend, authentication, an application database and business APIs. A commerce-oriented portal might place a custom frontend over Shopify or another commerce engine, connected to an ERP or CRM. Another common shape is a portal over a managed backend such as Supabase with integrations into internal systems.

The stack depends on where the commercial truth already lives. When Shopify is the commerce layer, map its company and location model to the portal’s permission model before adding a separate account hierarchy; the Shopify B2B guide covers the platform’s native boundaries.

What to build first

The portal MVP should solve one complete journey:

Company applies → company is verified → user logs in → correct catalog and price appear → customer places order

That has a measurable operational effect. By contrast, a dashboard with notifications, analytics, documents, CRM, chat and AI but no working core order flow is a large product with little value.

Discovery questions

Before implementation, answer: who can request access, who approves the company, whether a company can have several users and branches, what determines product visibility and price, whether orders need approval, whether buyers can repeat orders, which documents customers can access, and which system owns products, prices, stock and orders.

Those answers define the architecture. The UI comes afterwards.

Continue reading

FRN.Q builds private commerce and portals under B2B Systems and Product Systems. The usual first step is a working session on the contact page.