CommerceBolt — a Perigeon company
Talk to an expert

Service

Customer Portal

A customer portal is judged by how many phone calls it removes. Orders, invoices, returns and reordering, available without asking anyone — which is mostly an integration problem dressed as a design one.

Diagnosis first

What customers are currently phoning about

Portals fail when they are built around what is easy to expose rather than what people actually ask. These are the four that generate the volume.

  1. "Where is my order?"

    The most common contact by a distance, and the easiest to remove — provided tracking and status reach the portal from fulfilment rather than from a weekly export.

  2. "Can you resend the invoice?"

    Trivial to self-serve, routinely not implemented, and in B2B it is often the single highest-volume request finance receives.

  3. "I need to add a colleague"

    User and permission management. Without it every change becomes a ticket, which is why portals quietly stop being used.

  4. "I want to order the same as last time"

    Reordering from history is the main reason a repeat customer logs in at all. If it is buried, the portal has missed its purpose.

Scope it from the phone log

The most reliable way to specify a portal is to spend a fortnight counting what customers currently ask for and in what volume, then build that list in order.

It produces a less exciting specification than a workshop does. It also produces a portal that removes work, which is the only reason to build one. Features that look good in a demo and answer a question nobody asks are the main way these projects waste money.

Identity is the hard part

The interface is rarely what takes the time. Company hierarchies, user permissions, who can see contracted pricing, who can commit spend, and how all of that maps to records in your ERP — that is where portal projects overrun.

It is worth deciding early whether customers manage their own users. Letting them is more work up front and dramatically less work forever afterwards.

Where this sits

For businesses selling to other businesses this is usually delivered alongside B2B commerce rather than separately. It depends on integration work for orders, invoices and shipments, and sits on a storefront built under eCommerce development.

Platforms

Where we build.

Measure it in calls removed, not features shipped

The honest success metric for a portal is whether your support and finance teams are answering fewer routine questions three months after launch. That means scoping from your actual contact volumes rather than from a feature list, and it means some obviously appealing features are worth less than a working invoice download.

Talk through your contact volumes

Scope

What a build includes.

  • Order history and live status

    Status drawn from the system doing the fulfilling, including tracking, partial shipments and backorders rather than a single misleading state.

  • Invoices and statements

    Downloadable, searchable, and matching what finance issued — reconciled against the accounting system rather than regenerated hopefully.

  • Self-serve returns

    Raise a return within policy, get a label and a reference, and see progress. The policy is enforced by the system rather than argued case by case.

  • Users, roles and addresses

    Customers managing their own people and delivery locations, with permissions that reflect who is allowed to spend.

  • Reorder from history

    Previous orders, saved lists and quick entry by part number, which is what drives repeat logins more than anything else on this list.

  • Single sign-on where it is wanted

    Enterprise customers increasingly expect to use their own identity provider. Supporting it removes a procurement objection.

How it runs

From first call to live.

  1. Contact audit 1–2 weeks

    What your support and finance teams are actually asked, by volume. The portal scope should be that list in order, not a feature wish-list.

  2. Data access design 2 weeks

    Which systems hold orders, invoices, shipments and returns, and how the portal reads them safely and quickly enough to be useful.

  3. Build 8–14 weeks

    Portal, authentication and integrations. Identity and permissions usually take longer than the interface, particularly with company hierarchies.

  4. Pilot 3–4 weeks

    A set of real customers using it before anyone is told to. Their first week tells you which of your assumptions about their habits were wrong.

  5. Drive adoption Ongoing

    Measured by contact deflection rather than logins. If calls have not fallen, the portal is not finished regardless of what shipped.

Frequently asked questions

Is a customer portal different from a B2B storefront?

They overlap heavily and in most B2B projects they are one thing. The distinction is emphasis: a storefront is oriented around discovering and buying, a portal around administering what you have already bought. Businesses selling complex or contracted products sometimes need the portal and barely need the storefront.

Can customers see invoices from before the portal existed?

Usually yes, depending on how far back your finance system keeps accessible records and whether historic documents were stored in a retrievable form. We establish this during the data access phase, because "we will add history later" tends to mean never.

How do we handle customers with multiple users?

With a company account structure: an organisation, its locations, its users and their permissions. Who can see pricing, who can place an order, who must approve. Getting this right is what makes a portal usable by a procurement team rather than only by one named contact.

Do we need single sign-on?

Not initially for most, but larger enterprise customers increasingly ask, and it can become a procurement blocker. It is considerably cheaper to design the identity layer with it in mind than to retrofit it after launch.

How do we get customers to actually use it?

Make the thing they do most often the easiest thing to do, and tell them about it at the moment they would otherwise phone — on despatch emails, invoices and in your team's signatures. Adoption is usually a communication problem rather than a product one, assuming reordering and invoices work properly.

Want to talk through Customer Portal for your store?

Tell us where it hurts. We will tell you honestly whether we are the right people for it.

Talk to an expert Book 30 minutes