B2B customer portals: data, access and initial scope

A B2B customer portal is a private space where a business customer views information or starts requests relating to its relationship with your company. Choose a recurring task: tracking a service request, downloading an authorized document or supplying missing information. Describe what the person needs to complete without asking your team to retrieve each piece of data.

A CRM organizes internal work; the portal exposes only the journey and information relevant to that customer. It does not need to replicate the CRM, display internal notes or open every module. Receiving and reviewing compliance files from companies supplying your business is a different decision, covered in the supplier document portal guide.

Before commissioning screens, record the repeated question, its source system and who can answer it today. If the answer still depends on an internal conversation or an undefined rule, a portal alone cannot turn it into reliable information.

Native features may cover an initial scope. HubSpot documents a support portal for managing tickets and states that only tickets appear, not conversations without an associated ticket. Its current documentation distinguishes this experience from the legacy version. Do not assume it is an invoice portal or a view of the entire operation.

Zoho CRM documents portals granting access to modules and related records according to permissions. This is another starting point to evaluate, not proof that external ERP data is already connected. These are vendor-described capabilities checked on November 4, 2026, not products tested by Duotach or a license recommendation.

Ask each option to complete the same task and exceptions. An existing feature may need configuration; information in another system may need integration; a rule neither covers may justify development. Separate these scopes before commissioning a whole application to solve an access issue or a form.

Create a record for each piece of customer-facing information: source system, owner, account relationship, update frequency and behavior when the source is unavailable. Do not promise real-time information from a daily feed. Displaying an update timestamp helps interpretation but does not make an outdated copy fit for a decision.

Also define how internal states become customer-facing states. A request received by the portal is not an order accepted by operations; acceptance is not completed work. The interface should identify which event occurred and the next step. Preserve a reference support can trace to the internal record without exposing private notes.

This proposed scope matrix is for adaptation with operations and IT. It does not describe an installed product or establish that an integration exists.

Define who invites users, which business relationship authorizes access, what each profile may view or request and who revokes it. Two people at one company may need different scopes. Agree whether someone sees only their requests, all account requests or selected departments. A matching email domain does not by itself define that relationship.

The OWASP authorization guide distinguishes identity from authorization and recommends least privilege, denial by default and permission checks on every request. It also covers file access and server-side enforcement instead of relying on the screen. Checked on November 4, 2026; citing it does not certify portal security.

Turn agreed permissions into viewing, downloading and modification tests. Include someone from another account and a user whose access has been removed. In an authorized test environment, hiding a button is not enough: verify direct resource access too. Do not use actual customer data in a public demonstration.

Consider two fictional accounts, North and South. North has service request SR-47 and its delivery document; South has SR-82. A North user may view SR-47 and request a correction but cannot confirm completion. Operations owns that final decision. These invented records and rules illustrate a test, not a client case or a Duotach result.

First the user views SR-47 and sees the source-confirmed state and update time. They request a correction: the portal records that request and reference but preserves the work status until operations resolves it. Complete the journey by checking the internal decision and visible update; sending a form does not demonstrate resolution.

Next test the same journey without a source connection. Agree whether the portal may display a clearly identified previous copy, record the request as pending or stop the operation. It must not present an invented state as confirmed. Finally verify that North cannot view or download South information even when its reference is known.

Before development, agree the expected result and evidence for each situation. The following table continues the fictional example; it is not an executed product test. Use it on the release candidate with records authorized for testing.

Include onboarding and account recovery as well as the main task. An available portal can still send all work back to email if customers cannot sign in, understand the status or find help. Record these difficulties with authorized participants rather than assuming a screen obvious to its developers is obvious to its users.

Ask for the included task, accounts and profiles, source systems, permitted actions and exclusions. Separate configuration, integration, development and data preparation. An available API does not establish permission to read the needed documents or perform the required action.

Assign owners for invitations, incorrect information, synchronization failures and user support. Infrastructure, storage, licenses and maintenance need their own terms. User counts alone cannot compare a manually updated portal with one connected to operational systems.

Complete the scope with code, account and documentation handover and ongoing maintenance. The portal should not depend on a provider employee manually updating each document indefinitely unless that work is explicitly contracted.

Before enabling the first process, record the task volume, current channel and definition of correct completion. Then observe completed tasks, access failures, outdated information and work returning to staff. Compare equivalent periods and the same request type; more sign-ins do not demonstrate less administrative work.

For a download, verify delivery of the right document to the authorized account. For a correction, verify operations resolved it and the customer could learn the outcome. Keep opening a page, receiving a request and resolving it separate. This guide promises no percentage reduction in inquiries, savings or sales increase.

Duotach builds custom software for businesses. Ask about an integrated portal by describing the customer task and where the information lives. System assessment, specific testing and implementation belong in the agreed paid scope; this is not a free audit or a promise of immediate availability.