Launch a customer portal

Before a customer buys anything online, they usually want the things they already have: their invoices, their delivery notes, their order history, their open quotes, their contract prices. The most common service call in B2B is a search, "can you send me the invoice from March again?". A portal is often the lowest-risk first step into digital selling, because it is useful on day one and requires no change to how anyone buys.

Why this is harder than it sounds

The documents your customers want are not hard to produce. They are hard to address. An invoice PDF sits in the ERP, a document archive, or finance's folder structure, and until now the way to get "the March invoice for Meyer GmbH" has been a person who knows where to look. Making that retrievable by customer, period and document type, reliably, is the engineering in a portal project. It gets underestimated because the manual version looks so trivial.

The second problem is permissions, and it is a data-protection problem before it is a design one. At a customer with three sites and eleven buyers, who may see the invoices? Who may see other departments' orders? Who may see the credit limit? Getting this wrong is an incident, with a customer whose internal politics you do not know. The permission model has to be decided before the first document is published.

That leads to the third obstacle: you probably do not know who your customers' people are. Your master data has an organisation, a general email address, and one contact who may have left in 2021. A portal needs individuals with roles. Collecting that is a data-gathering exercise involving your Innendienst and your customers, and it runs in parallel with the technical work.

Portals fail from emptiness more often than from defects. If nothing changes between visits, there is no reason to come back. Decide before launch what makes the portal worth a second login (complete history, live order status, documents that appear the day they are issued) and give it an owner. A portal with no owner degrades into a login page nobody uses.

The levers

Model who the customer's people are, and what each may see

What good looks like: the customer is an organisation, and the people are individual contacts with named roles. Each role has an explicit answer to: which documents, which orders, which prices, which addresses.

Decide how you represent branches before you load anything. Organizations have no parent-child hierarchy, so a customer with three sites is modelled as one organisation with several addresses, as three separate organizations, or through segments. All three are workable and they behave very differently for permissions and reporting. Picking one after the data is loaded means reloading it.

What it depends on: unwinding shared logins, and cleaning customer master data far enough that one company is one organisation rather than four near-duplicates.

1. The B2B customer model
2. How procurement governance works
3. Organizations
4. Contacts and roles
5. Customer data hygiene
6. Security and data protection

Surface their documents and their whole history

What good looks like: every order the customer has placed with you, through any channel, with its current status, its delivery notes and its invoices attached, available the day the document exists.

What it depends on: a working connection to wherever documents and order status live, and a matching rule that reliably ties a document to a customer.

1. The order lifecycle
2. Integration patterns
3. Connect a system
4. Partial deliveries and backorders
5. Returns and credit notes
6. Monitor your syncs

Let the customer administer themselves

The point of a portal is that nobody has to call. That has to include the administrative calls: a new colleague needs access, someone left, the delivery address changed, a buyer was promoted and may now commit more.

The outcome: a named administrator at the customer adds and removes their own colleagues, assigns roles, sets what each may spend, and maintains their own addresses, without contacting you.

Where the boundary sits today: contacts, roles, addresses and each contact's order approval limit are real and maintainable, and the limit is enforced when an order is placed. Cost centres are not master data. A cost centre is free text the buyer types on the order line, so there is no list for the customer to curate and no budget to draw down against. An order above a contact's limit is held instead of released, and releasing it is a manual step on your side.

What it depends on: roles that mean something to the customer rather than to your internal permissions model, and, for larger customers, the option of using their own identity provider.

1. Contacts and roles
2. Approval rules
3. Cost centres and budgets
4. Users, roles and permissions
5. Single sign-on

Then let them act on what they see

Reordering from history is normally the first transactional step, and the least demanding one, because the buyer is choosing something they have already bought from you.

What good looks like: any historic order can be repeated or amended in two clicks, at the customer's current prices. Open quotes can be accepted. Returns can be requested from the delivery note instead of by email.

What it depends on: prices being correct. The moment the portal shows a price, it inherits every requirement from Move existing customers online.

1. Contract prices for a customer
2. Process an order
3. Quotes and negotiation
4. Checkout configuration
5. Forms and transactional email

A sensible order

Phase 1: read-only, and complete. Documents, full cross-channel order history, current order status, the customer's own master data. No transactions at all. This phase is the reason a portal is such a good first project: it removes a whole category of service calls, it cannot produce a wrong order, and it makes the case for everything after it. Its dependency is document retrieval and customer-data cleanliness, nothing else.

Phase 2: self-administration. Hand the customer control of their own contacts, roles, addresses and per-contact spend limits. Cost-centre lists and budget tracking stay in the customer's own purchasing system for now, and any order held above a limit is released manually by your team. Say that plainly when you introduce the phase, because it is partly a process and not purely a feature. This phase depends on Phase 1 having established the permission model in practice, and it is what converts the portal from a service tool into something the customer's purchasing organisation relies on.

Phase 3: transactions. Reorder from history, accept quotes, request returns. Because it runs on the same customer, price and stock data, this is a configuration step rather than a second project. It is also the point at which price correctness stops being negotiable. Do not bring it forward to look more ambitious.

Common mistakes

• Launching with online-only order history. The customers you built it for placed their orders by phone. Show them their whole relationship or do not show them anything.
• Keeping shared logins. One password for a purchasing department makes roles, per-contact spend limits, audit trails and reporting meaningless, and it is far harder to unwind after launch than before.
• Publishing documents before the permission model is decided. This is the one mistake on this page with legal consequences.
• An empty portal. If nothing changes between two visits, there is no second visit. Decide what the recurring reason to log in is.
• No owner after go-live. Portals do not fail loudly. They stop being maintained, and usage decays until someone proposes replacing them.
• Forcing a new password with no self-service reset, and offering no single sign-on to customers who expect it. Access friction is the most avoidable reason for a portal to go unused.

How you know it is working

• Distinct contacts per account who logged in this month. People, not logins. One person at a customer is a champion; five is adoption.
• Documents retrieved by customers, against document requests still reaching your team. These two lines should cross. Categorise a week of incoming requests first, so you have a baseline.
• Share of accounts with more than one active contact. A portal where every customer still has one shared login has not achieved its main structural benefit.
• Self-service administration actions per month: contacts added, addresses changed, roles reassigned. Every one is an email your team did not receive.
• Repeat logins. The share of contacts who logged in again within a month is the honest measure of whether there is a reason to come back.
• Time from the first login to the first self-service order, once Phase 3 is live. This is the number that shows the portal is becoming a sales channel.

Related goals

• Move existing customers online, the goal this one leads into.
• Reduce manual work, where the portal's internal payback shows up.
• Sell spare parts online, the other common low-risk entry point.

What you're building

A logged-in area of your storefront where each contact at a customer sees the orders, delivery notes and invoices their role allows, from every channel you sell through, plus their own addresses and colleagues. The ERP and your document archive stay the source; Integration Studio pulls order status and documents across and attaches them to the right organisation. Ordering comes later, on the same data.

flowchart LR
  ERP["Your ERP"]
  DOC["Document archive"]
  subgraph IS["Integration Studio"]
    WF["Workflows"]
  end
  subgraph CS["Commerce Studio"]
    C["Customers: organizations, contacts, roles"]
    O["Orders"]
    SHP["Shipments"]
    PR["Prices"]
    OL["Order lists"]
  end
  subgraph XS["Experience Studio"]
    SF["Storefront: portal"]
    MSG["Messaging"]
  end
  ERP -- "orders from all channels, status" --> WF
  DOC -- "invoices, delivery notes" --> WF
  WF --> O
  WF --> SHP
  WF -- "documents attached" --> O
  ERP -- "customer numbers, terms" --> C
  C -- "who sees what" --> SF
  O --> SF
  PR -- "current prices for reorder" --> SF
  SF -- "reorder" --> OL
  MSG -- "invitation, password reset" --> SF
  classDef planned stroke-dasharray: 5 5

What you need

• Customer master data cleaned to one organisation per company, with a decision on how sites are represented — Organizations
• Named contacts per customer with roles, collected with the Innendienst — Contacts and roles
• A written permission model: which role sees which documents, orders, prices and addresses — Security and data protection
• Order history from all channels, including phone and email orders, in the platform — Reconcile with your ERP
• A connection to wherever invoices and delivery notes live, with a rule that ties each document to a customer — Connect a system
• A storefront with a login and transactional mail for invitations and resets — Forms and transactional email
• A named owner for the portal after go-live — Notifications

Build it

1. Categorise one week of incoming document and status requests, to have a baseline — Metrics that matter
2. Decide how branches are modelled: one organisation with addresses, several organisations, or segments — Organizations
3. Clean and load organisations and addresses — Customer data hygiene
4. Define roles and write down what each may see — Contacts and roles
5. Collect named contacts per customer through the Innendienst and load them with roles — Contacts
6. Bring orders from all channels into the platform, with status — Connect a system
7. Connect the document source and attach invoices and delivery notes to orders — Field mapping
8. Set up the storefront login, invitation and password-reset mail — Forms and transactional email
9. Offer single sign-on to the customers who ask for it — Single sign-on
10. Launch read-only to a pilot group, then to all accounts — Pre-launch checks
11. Hand administration to a named person at each customer: contacts, roles, addresses, approval limits — Approval rules
12. Switch on reorder from history at the customer's current prices — Order lists and reordering
13. Watch document self-service against incoming requests monthly — Monitor your syncs

Decisions you'll need to make

Related product areas

• Commerce Studio — Organizations · Contacts · Roles · Segments · Address types · Orders · Shipments · Returns · Order lists · Prices
• Experience Studio — Sites · Pages · Forms · Messaging · Documents
• Integration Studio — Credentials · Workflows · Field mapping · Storage sync · Runs