Customer Self-Service Portal Integrated With ERP: The Complete Guide

Every inbound call asking “where is my order?” costs you money. Not just the cost of the call — the cost of the interruption, the context switch, the diverted attention that could have been on closing a deal or solving a genuine problem. Your sales team should be selling, not relaying information your ERP already holds.

We have spent the past several years building interface layers for UK manufacturers and distributors running ERP systems like Dynamics 365 Business Central, Sage 200, OrderWise, Kerridge K8, and SAP Business One. In every single deployment, the customer self-service portal delivers the fastest measurable return on investment of any feature we build. This article explains why, and exactly what you need to know to make an informed decision.

The real cost of being a switchboard

Let us quantify a problem you probably already sense intuitively. A typical sales administrator at a UK manufacturing or distribution SME fields between 20 and 40 inbound calls per day. Our data suggests roughly half of those calls fall into one of the following categories:

• Order status. “Has my order shipped yet?” “What is the tracking number?” “When will it arrive?”
• Invoice queries. “Can you email me the invoice for order 4521?” “Why is the amount different from the quotation?”
• Account balance. “What is my current balance?” “Have you received my payment?” “What is my credit limit?”
• Stock availability. “Do you have 500 metres of that cable in stock?” “When is your next delivery due?”
• Proof of delivery. “The customer says they never received it. Can you prove it was delivered?”
• Document requests. “Can you re-send the quotation?” “I need a copy of the delivery note.”

Each of these queries requires a staff member to: log into the ERP (assume 20 seconds), navigate to the correct screen (30 seconds to two minutes, depending on the ERP and the user’s familiarity), retrieve the information (15 seconds), and relay it back (one to two minutes if the answer is straightforward, longer if the customer has follow-up questions). Total cycle time: three to six minutes per query.

At 20 such queries per day, that is one to two hours of productive time. At 40 queries, it is two to four hours. For a sales team of five people, that is ten to twenty hours per day — effectively one full-time equivalent spent entirely on information retrieval that the customer could have performed themselves.

And that is just the measurable cost. The unmeasurable cost is harder to spot: customers who do not call at all and instead order from a competitor because your sales team was unavailable; the frustration of being put on hold; the small dissatisfaction that erodes long-term loyalty.

What a customer self-service portal actually is

A customer self-service portal is a branded web application, separate from your ERP, that connects to it via API to give your customers secure, 24/7 access to the data that matters to them. Think of it as a read-optimised, tightly scoped interface that surfaces exactly the information a customer needs, without the complexity of the ERP itself.

Key characteristics of a well-built portal:

• Account-scoped. A customer logs in and sees only their own data. Orders, invoices, statements, stock pricing — all filtered to their account. They never see another customer’s information.
• Branded. The portal carries your company’s branding, not your ERP vendor’s. It is an extension of your customer experience, not a white-labelled third-party tool.
• Read + write appropriate. Most portals are read-heavy (order tracking, invoice viewing) with selective write capabilities (placing repeat orders, submitting support tickets). You decide what the customer can do.
• Real-time or near-real-time. Data comes live from your ERP. When your warehouse despatches an order, the customer sees the status update within seconds. No batch synchronisation, no overnight updates.
• API-connected, not screen-scraped. The portal reads and writes through your ERP’s REST or OData API. It does not log in as a user and scrape HTML. This matters for reliability, security, and maintainability.

Core features your portal should offer

The feature set of a customer self-service portal should be driven by one question: what do your customers call or email about most often? The features below are organised by business value, not technical complexity. Start with the highest-value features and add more over time.

Order tracking with carrier integration

Customers log in, see a dashboard of their open orders, and click through to view status, despatch date, carrier, and tracking number. With carrier API integration (DPD, UPS, FedEx, DHL, Royal Mail), the portal can surface the live tracking link and estimated delivery window directly. This alone typically eliminates 40–60% of inbound order status calls.

Invoice history and PDF download

Customers browse posted invoices by date range, download PDF copies, and view payment due dates. No more “can you email me the invoice?” calls. The PDF is generated once from your ERP and stored; the portal simply serves it back on demand.

Account statement and credit balance

A real-time view of the customer’s account: outstanding balance, credit limit, available credit, overdue items, payment history. For finance teams chasing payments, this feature alone can shift the dynamic from “chasing the customer for information” to “the customer already knows what they owe.”

Stock availability with personalised pricing

Customers check stock levels for items they typically buy, at prices specific to their account. This is the feature that drives the most portal adoption over time — once a customer realises they can check stock and pricing without calling, they rarely go back.

Proof of delivery retrieval

A named signature and delivery photo (if your carrier provides it) attached to each order. Resolving “the customer says it never arrived” disputes becomes a five-second check rather than a 20-minute investigation.

Reorder from history

With one click, the customer copies a previous order into a new one, adjusts quantities, and submits it. No re-entering the same twenty line items they order every month. This is a genuine value-add that reduces order entry errors as well as call volume.

Architecture: how a portal connects to your ERP

The architecture is straightforward, but the details matter. Here is the high-level data flow:

                         ┌──────────────────┐
                         │   CUSTOMER       │
                         │   (Web Browser)  │
                         └────────┬─────────┘
                                  │ HTTPS (TLS 1.3)
                                  ▼
                         ┌──────────────────┐
                         │  CUSTOMER PORTAL │
                         │  (Your Domain)   │
                         │  Branded UI      │
                         │  OAuth 2.0 Auth  │
                         └────────┬─────────┘
                                  │ API calls (REST / OData)
                                  ▼
                         ┌──────────────────┐
                         │  API ADAPTER     │
                         │  (Translation +  │
                         │   Auth + Rate    │
                         │   Limiting)      │
                         └────────┬─────────┘
                                  │ Authenticated API
                                  ▼
                         ┌──────────────────┐
                         │  YOUR ERP        │
                         │  (BC / Sage 200 /│
                         │  OrderWise /     │
                         │  Kerridge /      │
                         │  SAP B1)         │
                         └──────────────────┘

The API adapter is critical. It sits between the portal and the ERP and handles:

• Authentication translation. The customer authenticates to the portal (typically via email + password or SSO). The portal authenticates to the ERP via OAuth 2.0 client credentials or API token. The two never share the same credential store.
• Data scoping. Every API call from the portal is scoped to the authenticated customer’s account. If customer A is logged in, they cannot see customer B’s data — even if the API adapter receives a malicious or malformed request.
• Caching. Frequently accessed data (stock levels, pricing, customer information) is cached at the adapter layer to reduce load on the ERP and improve response times.
• Rate limiting and throttling. The adapter prevents any single customer from overwhelming the ERP with API calls.

ERP-by-ERP API coverage for customer portal use cases

Not all ERP APIs are created equal. Here is what you can expect from the most common systems in UK manufacturing and distribution:

Microsoft Dynamics 365 Business Central

Business Central exposes a comprehensive OData v4 REST API. Every entity you need for a customer portal is available: Sales Orders, Posted Sales Invoices, Customers, Items (stock), Item Ledger Entries, and more. Authentication is via OAuth 2.0 with Entra ID. The API is well-documented and the coverage is strong enough that a portal can be read-only or read-write with full transactional integrity. Real-world data: the Business Central API handles several thousand requests per minute without degradation in our production deployments.

Sage 200

Sage 200’s API coverage has improved substantially in recent versions. The REST API covers Sales Orders, Invoices, Stock Items, Customers, and SOP (Sales Order Processing) documents. The API uses OAuth 2.0 with Sage ID. There are some gaps — live carrier tracking integration, for example, requires a separate API call to the carrier rather than being available as a Sage 200 field. The Sage 200 API is generally slightly slower than Business Central’s, with typical page load times around 200–400ms for list queries, but still perfectly adequate for a customer portal.

OrderWise

OrderWise provides a SOAP-based API with a REST wrapper. The API covers Core Sales Orders, Stock, Customers, and Invoices. The SOAP protocol makes development slightly more involved than a pure REST API, but the data coverage is solid. OrderWise does not natively expose carrier tracking data through its API, so portal tracking features typically require a separate integration with the carrier directly. Authentication uses API keys rather than OAuth 2.0, which is workable but less flexible for multi-tenant scenarios.

Kerridge K8 (now Epicor K8)

Kerridge K8 provides a REST API with coverage of Sales Orders, Inventory, Customers, and Invoicing. The API is functional but the documentation can be sparse, and the authentication model (typically basic auth or certificate-based) is older than OAuth 2.0. In practice, a portal for Kerridge K8 will need a more robust API adapter layer to handle authentication and data transformation. The underlying data model is strong for distribution use cases, which makes it a solid fit for customer portal features like stock availability and reordering.

SAP Business One

SAP Business One provides a REST API (the Service Layer) that covers Sales Orders, Invoices, Business Partners (customers), Items, and Warehouses. The API is comprehensive and well-documented. Authentication uses a session-based model (login to get a session ID, then pass it on subsequent calls). This works but requires the adapter to manage session lifecycle carefully. The Service Layer can be hosted on-premise or in the cloud, depending on your SAP B1 deployment model. For customer portal use cases, SAP B1’s API is among the stronger options available.

ISV add-on vs Power Pages vs custom build: an honest comparison

You have three broad routes to a customer portal. Each has trade-offs. Here they are, without the sales pitch:

ISV add-ons are cheap to start and fast to deploy, but you trade away control and you are locked into a single ERP vendor’s roadmap. Power Pages (Microsoft’s low-code portal builder) works well if you are already in the Microsoft ecosystem, but it is limited to Business Central and carries per-user Power Platform licensing costs that scale with adoption — making it expensive as your customer base grows. A custom build costs more upfront but gives you total control over features, branding, data residency, and future-proofing. For most UK manufacturing and distribution SMEs with 50–500 active customer accounts, a custom build offers the best long-term value.

Data security: the non-negotiable

A customer portal sits at the boundary of your organisation. It is exposed to the internet, accessed by customers from any device, and it talks to your ERP — your system of record. Security is not a feature; it is a prerequisite. Here is what a properly built portal handles:

• Account-scoped data isolation. Every API call from the portal includes the authenticated customer’s account identifier. The API adapter enforces the scope server-side, not client-side. Even if a customer deliberately modifies a request, they cannot access another customer’s data.
• OAuth 2.0 authentication. Customers authenticate to the portal using standard OAuth 2.0 flows. The portal never receives the customer’s ERP credentials. The portal authenticates to the ERP using separate service-to-service credentials with the narrowest possible permissions — typically read-only access to specific entity sets for the specific customer.
• No ERP credentials exposed. The customer does not need an ERP login, cannot see your ERP interface, and cannot interact with your ERP directly. The portal is the only surface area exposed to the internet; your ERP remains behind your network security.
• UK/EU hosting. All data is stored and processed within the UK or EU, with full UK GDPR compliance. You choose the hosting region based on your data residency requirements.
• HTTPS everywhere. TLS 1.3 enforced. HSTS headers set. No plaintext traffic at any point in the request chain.
• Session management. Tokens expire after a configurable period. Idle sessions are terminated. Failed login attempts trigger rate limiting and account lockout.

Customer adoption: making the portal stick

Building the portal is the easy part. Getting customers to actually use it is where most implementations succeed or fail. Here is what we have learned about driving adoption:

Onboarding. Do not send a link and hope for the best. Assign a named person from your team to each customer for the first two weeks. Walk them through logging in, finding their orders, downloading an invoice. Make the first experience positive enough that they want to come back.

Incentivise usage. Consider offering a small discount for orders placed through the portal, or a faster fulfilment SLA for portal orders. Even a small incentive drives initial trial, and trial is the precursor to habit.

Remove friction gradually. When a customer calls for order status, the response should be: “I can look that up for you — and next time, you can check it yourself in the portal in about ten seconds. Let me send you the link while we are on the phone.” The goal is consistent, gentle redirection, not an abrupt “use the portal or nothing.”

Training needs are minimal. A well-designed portal requires no formal training. If your portal needs a user manual, you have designed it wrong. A single-page PDF quickstart guide and a 5-minute walkthrough call is sufficient for virtually every customer.

Real-world impact: what the numbers say

These figures are drawn from our own deployment data across manufacturing and distribution clients in the UK. Your results will vary, but these are realistic targets for a well-executed portal implementation:

• 40–60% reduction in order-status-related inbound calls. The highest-impact metric. Customers who use the portal stop calling for order tracking within the first two weeks.
• 30–50% reduction in invoice-request-related emails. Once customers discover the invoice PDF download feature, email requests for “please send the invoice again” drop sharply.
• 15–25% increase in order accuracy. When customers enter their own orders or reorder from history, the transcription errors introduced by phone-based or email-based ordering disappear.
• 25–40% reduction in accounts receivable queries. Customers check their own balance and payment due dates, reducing calls to your finance team.
• 8–12 point increase in customer satisfaction (CSAT) scores. Customers consistently rate portal access as a significant improvement in their experience with your company. The ability to get information instantly, without waiting on hold, is highly valued.

One client — a Middlesbrough-based industrial supplies distributor running Kerridge K8 — measured a 73% reduction in inbound phone calls within three months of launching their portal. Their inside sales team of four went from spending 3 hours per day each on information retrieval to under 30 minutes. That team is now actively selling, not answering stock check questions.

Frequently asked questions

How long does it take to build a customer self-service portal?

A minimum viable portal with the core features described above typically takes 8–14 weeks from kick-off to go-live. The timeline depends on your ERP’s API quality, the number of features in scope, and how many carriers or third-party systems need integrating.

Can we connect the portal to multiple ERPs?

Yes, if you operate more than one ERP (for example, Business Central for your UK entity and Sage 200 for your Irish entity), a custom-built portal can connect to both simultaneously. The API adapter layer routes requests to the correct ERP based on the customer’s account. This is something ISV add-ons and Power Pages cannot do.

Does the portal replace our ERP?

No. The portal is an interface layer on top of your ERP. Your ERP remains the system of record for all transactions. The portal reads from it and writes to it, but never replaces it. This is deliberate — it means you can replace or upgrade your ERP in future without rebuilding the portal from scratch, as long as the new ERP exposes comparable APIs.

How does pricing scale?

A custom-built portal’s ongoing cost is primarily hosting, which scales with usage. If you have 50 active customer accounts, you will pay significantly less than if you have 500. ISV add-ons typically charge per customer account, which means your cost grows linearly with adoption. Power Pages charges per portal user (your customer) on a per-app/per-user Power Platform licence. A custom build’s hosting cost grows far more slowly than either, making it cheaper at scale.

Can customers place new orders through the portal?

Yes. The portal can offer order creation with varying levels of control: the customer can submit an order that goes directly into your ERP as a sales order, or it can enter as a quotation for your team to review and confirm. The exact workflow depends on your business rules and the level of trust you have in each customer’s ordering accuracy.

What happens if our ERP API changes?

ERP API changes are inevitable. The key is the API adapter layer: it abstracts the portal from the ERP’s specific API version. If your ERP vendor deprecates an endpoint or changes its response format, you update the adapter, not the portal. This centralisation reduces maintenance effort significantly.

Do we need a separate portal for each customer?

No. A single portal instance serves all your customers, with each customer seeing only their own data after authentication. This is standard multi-tenancy at the account level. You have one codebase, one hosting setup, one maintenance schedule.

What about customers who refuse to use a portal?

A small minority will always prefer the phone. That is fine. The portal is not a replacement for personal relationships; it is a supplement that reduces low-value interactions so your team has more time for high-value ones. Monitor portal usage at the account level and focus your onboarding efforts on the customers who generate the most call volume. Even 60% adoption among your highest-volume accounts will deliver measurable benefits.

---