What a customer portal does for business customers
A customer portal is a protected area where your customers look up for themselves what they currently ask you about. For business customers this usually comes down to five things: the status of their orders, the related documents such as quotes, order confirmations and delivery notes, open and paid invoices, the status of complaints or service requests, and a way to ask a question without hunting for an email address.
The benefit works both ways. Your customers get an answer when they have the question, including evenings and weekends. Your team no longer answers the same status enquiries on the phone every day, only the cases that genuinely need a conversation. A self-service portal does not shift work to the customer; it removes work that only existed because information was not visible.
Typical triggers for a portal project in a mid-sized company:
- Several employees spend time every day giving information that has long been available in the ERP.
- Documents are sent individually by email and requested again later because the customer cannot find them.
- Customers with many orders want an overview that your sales team currently compiles by hand in a spreadsheet.
- Invoices and credit notes should be traceable without the accounting team explaining bank statements.
Buy customer portal software or build a customer portal?
Both routes have their place. The question is not which is better in general, but which fits your process.
When standard customer portal software is enough
Many ERP and industry systems ship with their own customer portal or offer one as an add-on module. That is the right route if three conditions are met: all your data lives in that one system, your process matches what the vendor has designed for, and you can live with the terminology, screens and permissions the module provides. The advantage is obvious: the integration is already solved, rollout takes weeks rather than months, and the vendor maintains the portal together with the main system.
The limits appear as soon as the standard no longer fits. A portal module usually shows only the data of its own system. If order data sits in the ERP, documents in a document management system and invoices in the accounting software, the customer’s view stays incomplete. Approval workflows that deviate from the standard, such as order approval by several people on the customer side, often cannot be modelled either.
When you should build a customer portal
Building a custom customer portal makes sense when the portal has to bring several systems together, when it must reflect your own terminology and workflows, or when it is part of what you offer your customers and should differ from what competitors using the same industry system show. If customers are expected to supply data themselves, such as call-offs, orders or evidence that feeds directly into your process, a custom build is usually the more direct route as well.
A custom build takes longer to reach first operation and requires a clear decision about who will maintain and extend the portal later. In return, the result belongs to you, source code included, and it grows with your process rather than with a vendor’s product roadmap. What that means in practice is described on the page about custom software development (in German).
Integration decides: ERP, inventory management and accounting
The most important feature of a customer portal is not its user interface but its connection to the systems where the data originates. A portal into which employees type order statuses by hand is out of date within weeks, and customers stop opening it.
In practice three sources need to be connected:
- ERP or inventory management for orders, line items, delivery dates and status. This is the core of what customers want to see.
- Document storage for quotes, order confirmations, delivery notes, inspection reports and drawings. Documents should stay where they are today and only be linked by the portal.
- Accounting for invoices, credit notes and payment status. Systems such as Lexware, sevDesk or Odoo provide interfaces for this.
How to plan such a connection, which routes exist and why integration projects fail is explained in the guide on ERP integration. For the portal, one rule of thumb applies: the portal reads, the source systems lead. If customers may change something in the portal, such as a delivery address or a call-off, the portal writes that change back to the source system rather than merely displaying it.
Login and permissions per customer
A B2B customer portal has one characteristic that consumer portals lack: behind each customer there are several people with different tasks. Purchasing sees orders and prices, accounting sees invoices, the warehouse manager sees delivery dates. The permission model therefore needs two levels: which data belongs to which customer, and which role a person has within that customer.
Two login approaches have proven themselves:
- Sign-in with existing accounts. If your customers work with Microsoft 365 or Google Workspace, they can sign in with their company account. When a person leaves the customer, their access ends with the company account.
- Dedicated accounts by invitation. One contact per customer invites further people and assigns roles. This relieves you of user administration and keeps responsibility where it belongs.
In both cases every access should be logged, so that it can later be traced who retrieved which document and when.
Data protection and hosting in Germany
A customer portal processes personal data of your customers’ contacts and usually confidential business data as well. Three points should be settled before launch: where the portal is hosted, who has access to it and how long data remains in the portal.
Hosting in a German data centre or on your own infrastructure is a precondition for many mid-sized customers before they use a portal at all. If an external operator is involved, a data processing agreement under the GDPR is required. It is also sensible to define a rule under which completed transactions disappear from the portal after a set period, even if they are retained in the source system. Which retention periods apply to your records is a question for your tax or legal adviser; this guide does not replace that advice.
How a portal project runs in stages
A customer portal should not be built in one go. A staged approach has proven effective, with each stage usable on its own:
- Stage 1: reading. Order status and the most important documents, connected to the ERP. Login, roles and access logging are in place from the start. This stage already answers most of today’s enquiries.
- Stage 2: invoices and payments. Invoices, credit notes and payment status from accounting, plus notifications when new documents arrive.
- Stage 3: interaction. Questions about an order directly in the portal, approvals, call-offs or orders that are written back to the source system.
- Stage 4: extensions. Reports for key accounts, connections to their own systems, multiple languages.
Before stage 1 comes the process review: which questions do customers actually ask today, who answers them, and where do the answers live? From this follows what belongs in the first stage and what can wait. The technology decision for the user interface is also made at this point; the guide React or Angular provides an overview.
What determines the cost of a customer portal
The cost of a customer portal depends less on the number of screens than on four factors:
- Number and condition of the interfaces. A system with a documented API is connected in days; one with only database access or file export takes considerably more effort and ongoing maintenance.
- Depth of permissions. One login per customer is simple; roles per person, approval workflows and corporate groups with subsidiaries increase the effort noticeably.
- Write functions. Displaying is cheaper than changing. Every function that writes data back to the source system needs validation, error handling and coordination with the respective vendor.
- Operation and further development. Hosting, monitoring, updates and adjustments when a source system changes are recurring items and belong in the plan from the outset.
A reliable figure is only available after the process review, ideally as a quote with a clearly defined scope per stage.
Common mistakes with customer portals
- Portal without data integration. Data is copied into the portal by hand, goes stale and destroys the customers’ trust in what they see.
- Mandatory login without benefit. Customers have to sign in to see information they previously received by email, but find nothing beyond that. The portal is not opened again after the first visit.
- No notifications. A portal does not replace email; it complements it. Customers need a notice when a new document, a new status or an invoice is available, with a direct link to the transaction.
- Permissions added later. Whoever builds roles and client separation only in stage 3 rebuilds stages 1 and 2.
- Everything at once. A portal that goes live after a year has delivered no benefit until then and is measured against requirements that have changed in the meantime.
How RLOX builds customer portals
RLOX builds customer portals as custom software for mid-sized companies in Munich and the surrounding region: connected to the ERP, accounting and document storage already in use, with roles per customer, sign-in via existing company accounts and hosting in Germany. Delivery happens in usable stages, starting with reading order status and documents. The framework of the collaboration is described on the page about custom software development (in German).
