A B2B customer portal has no universal price. An early estimate is useful only when its assumptions, included work and exclusions are clear.

The useful question is “what needs to be included in this portal’s budget?”. Two portals that look almost identical in a mockup — a login, a catalogue, a cart — can require different implementation work depending on accounts, prices, approvals and integrations. Screen count alone does not describe that work.

This guide separates implementation from ongoing costs, explains the scope decisions behind an estimate and gives you a way to compare proposals without assuming a universal amount.

At a glance

  • Cost follows commercial rules, permissions and integrations — not page count.
  • Separate one-time implementation from recurring and usage-based charges.
  • Define one complete first-release journey before adding secondary features.
  • Phasing can defer work; it does not guarantee a lower total cost.

Why a portal resists a flat price

A portal estimate must include the rules behind the interface: who a user represents, which products and prices they are allowed to see, which orders need approval, and which existing system owns each piece of data.

Two portals with “the same catalogue and login” can still have different scope:

  • A single buyer per company, or several locations with branch-level permissions.
  • One public price list, or contract, segment and quantity-based pricing.
  • Direct ordering, or a review and approval flow.
  • A standalone catalogue, or one connected to an ERP, CRM and PIM.

Because of that, a serious proposal itemises scope and ownership rather than pricing a feature list. The rest of this guide follows the same sequence a project does.

1. Discovery and commercial rules

Start by writing down the commercial rules. Discovery has its own cost, but can expose assumptions and reduce the risk of rework before implementation. It cannot guarantee that requirements will remain unchanged.

The first discovery questions concern the business process:

Who can request access? Who approves a company?
Can one company have several users and locations?
What determines product visibility and price?
Do orders need approval or quoting?
What payment terms apply?
Which system owns products, prices, stock and orders?

These are the same questions that define the architecture of a B2B customer portal. Record unresolved points as assumptions or separate discovery tasks rather than hiding them in a fixed estimate.

2. Accounts, roles and permissions

An organisation model — company, locations, users, roles — is not a login screen. It is a data model with consequences. Permissions should describe actions (view prices, place orders, approve orders, manage users, view documents), and the model has to reflect the real relationship between a company and the people who buy on its behalf.

Budget for the account structures and approval chains that actually need to work. One buyer per company and a hierarchy of parent companies, branches and location-specific conditions have different modelling and testing requirements. Changing the structure later may affect stored data and permissions, so identify those dependencies early.

3. Catalogue and pricing

Catalogue and pricing estimates should cover rule definition, imports, calculations and verification — not only displaying a price. Prices need to remain consistent between the catalogue, the cart and the invoice.

Currency, market, volume tiers, contract terms, customer-specific adjustments and rounding rules each add modelling work. Where pricing is complex, define which system owns the price, described in B2B pricing architecture. Spreadsheet-managed rules may also need import validation or manual reconciliation unless those steps are automated.

4. Ordering and approval flows

Not every portal needs a standard checkout. Common flows include direct ordering, approval (a buyer creates, a manager approves), commercial review and quoting. Each additional flow is additional product surface, additional states and additional testing. Deciding which flows are genuinely used in the first release keeps the build focused.

5. Integrations

Integration estimates depend on the systems involved and the quality of their data and APIs. Customers, products, prices, stock, orders and invoices may already live in an ERP, a CRM or a PIM.

The estimate should include more than “connecting two APIs”: data ownership, a synchronisation pattern per dataset, retries, idempotency, reconciliation and observability. Each connection needs a defined mapping and access requirements. Use the ERP, CRM and ecommerce integration guide to identify work that might otherwise be omitted from a proposal.

6. Documents

Invoices, delivery notes, technical sheets, certificates and price lists can make a portal useful even before advanced commerce exists. Include permission checks, private storage, controlled downloads and any document generation or migration in their estimate.

7. Quality, security and accessibility

Authorisation must be enforced at the data layer, not by hiding buttons in the interface. Scoped access, server-side checks, accessible and responsive interfaces, and testing are part of the cost of a portal, not optional extras added at the end. A system that only appears correct, without a real authorisation boundary, is not a cheaper system — it is a liability.

8. Launch and ongoing ownership

Data migration, catalogue reconciliation, launch checks and handover belong in the implementation estimate. After launch, define who owns updates, integration monitoring, access administration and incident handling. Do not assume those responsibilities are included in a build fee.

Separate setup from recurring costs

Ask for a budget that distinguishes these categories:

Cost category What to include What to verify
One-time implementation Discovery, design, development, imports, integration setup, testing and handover Deliverables, acceptance criteria, assumptions and exclusions
Recurring platform and infrastructure Commerce plan, hosting, database, private storage, backups and monitoring where required Billing interval, account owner, included capacity and renewal terms
Usage-based services Email delivery, storage growth, bandwidth or integration-service usage where applicable Billing units, expected volumes, limits and overage charges
Ongoing support and changes Updates, incident response, reconciliation and later releases Included work, response arrangements and separately quoted changes

Compare proposals over the same operating period and expected usage. Keep setup charges separate from recurring commitments; include required vendor plans and taxes on the same basis. Record who pays each provider and who controls the accounts, credentials and data.

Some costs may sit outside the supplier’s proposal: ERP access or licences, data cleanup, product photography, internal staff time and approval delays. Mark each as included, excluded, client-owned or unresolved. A blank line is not a zero-cost assumption.

What makes a portal more expensive

  • Many overlapping price rules and unclear precedence.
  • Deep account hierarchies and multi-step approval chains.
  • Several external systems with different owners.
  • Custom documents, exports and reporting.
  • Wide device and accessibility requirements without a base design system.
  • Undefined rules that require further discovery or changes to the agreed scope.

What usually does not need to be in the first release

A useful first release solves one complete journey end to end:

Company applies → company is verified → user logs in → correct catalogue and price appear → order is placed

Dashboards, advanced analytics, document libraries, CRM integration and messaging can follow if they are not dependencies of that journey. For each deferred feature, record what remains manual and who handles it. A staged release may reduce the initial commitment, but can add later integration or handover work; compare both the first release and the planned total scope.

How to compare proposals

When offers differ, compare more than the total:

  • Does the proposal itemise scope, or only list features?
  • Does it state which system owns each entity?
  • Does it say what is explicitly excluded?
  • Is discovery priced separately, or hidden inside the build?
  • Does it describe how the work is verified?
  • Are recurring fees, usage assumptions and post-launch responsibilities explicit?

A lower headline price may reflect narrower scope, different assumptions or excluded running costs. Compare those differences before deciding that the offers describe the same system. Missing integration ownership or authorisation is a scope and risk question, not proof of a particular future cost.