Designing a B2B customer portal for useful self-service

A customer portal delivers value when someone can complete a task and understand its outcome. If submitting a request still requires calling a manager, checking its status and resending a document, part of the process remains manual. Adding screens can expand the interface while leaving the support workload unchanged.

In September 2026, Baymard updated its Accounts & Self-Service research. The public article highlights changes in sign-in and account security, order management and tracking, and returns. Its scope matters: this is ecommerce self-service research, not a measurement of a particular B2B portal's effectiveness. Baymard publication.

For a business product, these findings suggest questions to test with your own users. A buyer may act for several departments, handle approvals and documents, and depend on supplier staff to finish the task. Copying a retail store's structure without research is risky.

Follow one task through to completion

For a hypothetical supplier portal, take a repeat parts order request. The user needs to find a previous order, check whether its contents are still relevant, change quantities and see that the request was received. They then need to know whether approval is pending, dates are confirmed or another action is required.

Map more than customer clicks. Include the manager's queue, availability checks and the point where a confirmed answer appears. If the interface says “Done” immediately after submission while delivery is still unconfirmed, the status misleads the user. Measuring the button's usability alone will not reveal that error.

Every state needs a meaning and an owner. “Request received” differs from “Terms confirmed.” Show the customer the next step and how to ask a question. The internal system needs to identify who handles exceptions such as an unavailable item or incorrect document.

Learn what happens outside the portal

Nielsen Norman Group describes empathy mapping as a way to organise what users say, think, do and feel, based on research evidence. An empty area reveals a gap in understanding. It is a useful team tool, but guesses about customer behaviour cannot replace research. NNGroup guide.

In interviews, ask people to show their last actual request. Where did they look for the order number? Who received the forwarded confirmation? Why did they take a screenshot? What did they check against a spreadsheet? Observing these actions can uncover missing functions: copying an identifier, downloading a document, viewing clear history or checking order contents.

Separate observation from interpretation. “The user opened an email after submitting the request” can be a recorded fact. “They do not trust the portal” remains a hypothesis to investigate. This distinction prevents features being built for an invented problem.

Permissions are part of the user journey

In B2B, purchasing staff, managers and accountants may work within one customer account. Decide who creates requests, who approves terms and who sees documents. A shared login makes action history and responsibility harder to reconstruct.

Test employee replacement: transferring open requests, revoking access and retaining working history. Then test choosing the wrong organisation. If a user represents several legal entities, make the active context visible before submission. The server must enforce permissions independently; hiding a button does not provide access control.

Discuss roles together with the business process. A request to “build a customer portal” does not answer these questions, so it cannot reliably define the scope.

Assess whether self-service improved

For the first release, choose a verifiable outcome: the request is submitted, an answer arrives and the user understands the next action. Compare the share of started journeys that reach that outcome and the reasons others stop. A page view is a supporting signal.

Support enquiries also need context. Their number may fall because help is harder to reach rather than because the portal is easier to use. Compare them with incomplete actions and repeat requests. If measurements do not exist yet, start by observing the journey and avoid assigning an invented financial benefit.

Before scaling, list exceptions: a lost connection, repeated clicks, an overdue approval, an unavailable document or a user change. The portal should either finish the action or clearly explain where a person is needed. This is more useful than a broad menu concealing incomplete processes.

The customer portal first-release analysis and customer products page can help plan the product. Describe one customer task, its internal owner and the current manual handoffs. That is enough to start discussing the project scope.

Connect the customer screen to team operations

My portfolio includes a mobile application for a South African project started from scratch. Its creation is confirmed; the public account does not claim specific booking or payment functions, or current operation of the entire platform. This is a related customer product example rather than a deployed B2B portal. For a new portal, I consider customer actions alongside how the team receives information and continues handling the request.

The guide to moving from spreadsheets to a system traces one order, defines the owner of each stage and examines exceptions. Apply it to a self-service order or document upload: the customer needs a clear outcome, while the employee needs to see the next required action.

Sources

Facts checked on 7 October 2026. The supplier example and acceptance criteria are an analytical model, not an account of a completed implementation.

• Baymard: Accounts & Self-Service, 2026 update.
• NNGroup: Empathy Mapping.