Customer portal

Technically, it sits as a separate application in front of the existing systems, usually in front of the ERP, and accesses their data via interfaces.

What problem a customer portal solves

In many mid-sized companies, customer service is essentially a look-up activity. The most common requests are: where is my order? Send me the invoice from March again. What was my discount? What was the item number of the spare part from last year? Each of these requests costs inside sales a few minutes, and almost every one could be answered by the customer if they had access to their own data.

The lever therefore lies not in communication but in access. In practice, a portal that covers the ten most frequent questions replaces a large part of the email volume. This is why, in B2B constellations with recurring orders and individual terms, a customer portal is almost always the project with the shortest payback period.

The calculation a portal has to support

A reliable estimate needs three values: the number of service requests per month, the average processing time and the proportion that can actually be replaced by self-service. A business with 800 service requests a month, five minutes per request and a replaceable share of 60 per cent saves around 40 working hours a month. On top of this come effects that are harder to measure but real: fewer queries because of wrong item numbers, fewer reminders because invoices can be found, and a measurable share of repeat orders placed at night and at weekends.

The counter-calculation is important. A portal creates permanent effort: hosting, updates, support for log-ins, content maintenance. Anyone who only sets the savings against the project costs and forgets about operation makes the project look better than it is. The honest view is a calculation over five years, i.e. over the total cost of ownership.

Range of features: the ten things that replace 80 per cent

• Log-in with roles. Buyers, accounting and technicians need different views of the same customer account.
• Order overview with open and completed transactions, searchable and filterable.
• Delivery status including the carrier's tracking link.
• Invoice archive with download, ideally in the format of the statutory e-invoice in addition to the PDF.
• Master data for self-maintenance: delivery addresses, contacts, payment details.
• Terms and price lists specific to the customer, including tiered prices.
• Reordering from the history, the most heavily used button in B2B.
• Returns and complaints as a guided form instead of a free-text email.
• Documents such as data sheets, certificates and drawings, linked to the customer account.
• Service requests with status, so the customer does not have to ask whether the request has arrived.

Everything beyond this is stage two. The most common project mistake is not a first release that is too narrow but one that is too broad: quote configuration, chat, dashboards and customer reviews in the first release extend the timeline and push the benefit back.

Architecture: portal in front of the system, not portal inside the system

Technically, a customer portal is a stand-alone web application that accesses the leading systems via interfaces. The data stays where it belongs: orders in the ERP, documents in document management, item data in product data management. As far as possible, the portal holds no truth of its own but reads and writes via an API.

The three decisions that determine the costs

1. Interface to the ERP. If the ERP comes with a documented REST or GraphQL interface, the portal is a manageable project. If the interface first has to be built, for example via middleware or a nightly data synchronisation, the effort can easily double. This question belongs at the start, not in the implementation phase.
2. Identity and access. Your own user management or an existing identity provider? For B2B portals with corporate customers, a provider with a role and multi-tenant concept is worthwhile, because changes of buyer and permissions otherwise end up in support. Single sign-on is a real selling point with larger customers.
3. Real time or synchronisation. Reading stock and prices from the ERP in real time is clean but puts a load on the system. Synchronisation every minute is usually sufficient and considerably more robust. This decision should be made consciously and documented, not left to the chance of implementation.

Data protection and security

A customer portal processes personal data and can be reached from outside. Three non-negotiable obligations follow from this: a permission concept that ensures that a user sees only data from their own customer account; logging of access and changes; and a data processing agreement with every service provider that has access, including the hosting provider. The most common serious mistake in practice is the insecure direct object reference: an invoice URL with an incrementing number that is delivered without a check exposes the invoice archive of all customers within minutes. A portal should therefore undergo a test before go-live that attempts exactly this kind of access.

An example from practice

A technical distributor with around 1,200 B2B customers had an inside sales team that spent two thirds of its time giving status updates and resending invoices. In the first stage, the portal was limited to five functions: order overview, delivery status, invoice download, reordering and master data maintenance. The existing ERP was connected via a REST interface, with prices and stock synchronised every five minutes. The timeline was ten weeks to go-live with a pilot group of 40 customers, followed by a week of fine-tuning and then the roll-out.

Two observations from such projects are transferable. First: reordering from the history is almost always the most heavily used function and is regularly underestimated in the requirements discussion. Second: usage does not increase by itself. Without an active introduction (an email to customers, a note on every invoice and an inside sales team that refers to the portal when requests come in), the uptake remains low and the emails keep coming.

Economic classification and funding

A lean B2B customer portal based on an existing ERP interface typically takes eight to sixteen weeks to implement. Experience shows that the effort is distributed unevenly: just under a third goes into connecting the leading systems, another third into permissions and identity, and only the rest into the interface that the customer ultimately sees. Anyone who bases the cost estimate on the interface systematically underestimates the project.

For financing such projects in Germany, the instrument is less the classic grant than the promotional loan. The KfW ERP digitalisation loan finances up to 100 per cent of eligible costs, with terms of five to ten years and up to two repayment-free start-up years. In the higher funding tiers, a non-repayable grant is added. Applications are made via your house bank, and before the project begins. There are also state programmes whose conditions change frequently; the current situation should be checked before every application.

Operation: what comes after go-live

A portal is not a project with an end date but a product. After go-live, four ongoing tasks arise. First, support for log-ins: changes of buyer, forgotten passwords, new locations of a customer. Second, content maintenance, in particular of documents and data sheets, which quickly become outdated. Third, security updates for the framework and dependencies, which are not optional for an application that can be reached from outside. Fourth, further development based on usage.

For the fourth point, it is worth measuring from the outset which functions are actually used, anonymously and in compliance with consent requirements. Practice regularly shows that a laboriously built function is hardly used, while a minor function has become the main entry point. This information is the basis for stage two and replaces the discussion about what customers might want with observation of what they do.

A final point on expectations: a customer portal reduces requests; it does not eliminate them. Complex cases, negotiations and complaints still land with people, and that is right. The gain lies in the routine falling away and the time becoming free for precisely these cases.

Distinction: portal, shop, extranet

An online shop serves to sell to potentially unknown buyers; a customer portal serves the self-service of existing customers with individual terms. In practice, the boundary blurs because modern shop systems come with B2B functions such as customer prices, budgets and approval workflows and can therefore also cover a portal. This is often the more economical variant if a shop is being operated anyway. An extranet is the older term for a protected partner area, usually document-heavy and without transactions. Anyone running an extranet today and thinking about a portal should first check whether the existing area can be extended.

When a customer portal is not worthwhile

Three constellations speak against the project, at least as a first undertaking. First, a small number of customers with very individual transactions: with thirty key accounts who are looked after personally anyway, a portal does not replace any work but creates an additional interface that nobody uses. Second, a business without recurring transactions: anyone selling one-off projects has no order history from which a customer could draw anything. Third, a data situation that does not allow an outside view: if prices and terms are not in the system but in people's heads and Excel files, the clean-up is the real project, and the portal comes afterwards.

In these cases, another project often brings more, such as automated quote generation or replacing paper filing with document management. The order decides success, not the technology.

Why portal projects fail

Three patterns repeat themselves. The first is too large a scope: a portal that is supposed to do everything goes into operation after eighteen months and solves problems that now look different. The second is an unresolved process: anyone who has not cleaned up the order process beforehand rebuilds the lack of clarity in software and makes it more expensive. The third is a lack of data quality: a portal exposes master data that lived internally for years as a note in a free-text field. That is unpleasant but healthy, and it should be scheduled before go-live, not afterwards.

The countermeasure is the same in all three cases: define a narrow range of features, observe and measure the underlying process beforehand, and start with a pilot group before all customers are invited.