The digital initiative launches the new customer portal. UX-award-worthy. But the customer doesn’t see all their machines. Service tickets appear a day later. Spare parts prices are generic, not discounted. After three months, usage drops below 10 percent. The portal didn’t fail because the interface was poor. It failed because the data foundation was wrong. Today’s customer expects B2C-equivalent self-service experience: view all machines, open service tickets, order spare parts, check maintenance schedules, visualize consumption data. Anyone wanting to deliver this doesn’t need better UX. They need a complete customer view, assembled from six different source systems, consolidated in a central data layer, provided via a clean API.
Why Most B2B Customer Portals Fall Short of Expectations
KAMPF was one of the first mechanical engineering companies to recognize: The portal isn’t the problem, data integration is the problem. In collaboration with Quanos (now part of Lexmark), they created a system that didn’t focus on a new frontend, but on a 360-degree customer view through consolidation of ERP, CRM, and service system data. The UX was the tip. The foundation was the data foundation.
The challenge is structural: The mechanical engineering customer expects an experience like Amazon Business. They want to log in and immediately see which machines they’ve purchased, which service cases are open, which spare parts are available, which maintenance is due. This expectation is legitimate. It doesn’t fail because of the portal technology, but because the required data sits in six different systems, and isn’t consolidated anywhere.
A Gartner study on Customer Data Platforms shows: 63 percent of B2B companies fail not at implementing the frontend system, but at integrating backend data sources. The portal can be visually perfect. If the customer doesn’t see all their machines upon login because the installed base is only maintained in the ERP but not synchronized to the portal, they won’t use the portal.
Six Data Sources a Full-Featured Portal Needs
A self-service portal for B2B customers isn’t a single system. It’s an aggregator across six different data sources. Without these six sources, the portal remains a pretty frontend without substance.
First: Installed Base (Machine View). The customer wants to know which machines they’ve purchased, which serial numbers, which configurations, which warranty periods. This data typically resides in the ERP or an asset management system. It’s the foundation for every other function in the portal. Without installed base, there’s no service case assignment, no spare parts recommendation, no maintenance planning.
Second: Service System (Tickets). The customer wants to see which service cases are open, which have been closed, which technicians are assigned, which solutions have been documented. This data sits in the field service management system or CRM. It must be synchronized to the portal in real-time. A service ticket that only appears in the portal the next day is worthless to the customer.
Third: ERP (Pricing, Inventory, Order History). The customer wants to order spare parts. For this, they need customer-specific prices, current inventory levels, delivery times. This data resides in the ERP. It must not only be retrieved but also provided at the right granularity. The customer with a framework agreement expects their individual conditions, not list prices.
Fourth: PLM (Bills of Materials). The customer wants to know which spare parts fit their machine. This information sits in the product lifecycle management system’s bills of materials. Without PLM integration, the portal becomes a generic spare parts catalog, the customer must figure out themselves what fits.
Fifth: Marketing Automation (Personalization). The customer expects personalized content: training offers for their machines, upgrade options, case studies from their industry. This data resides in the marketing automation system. It’s not a “nice-to-have,” but the difference between a pure transaction portal and a customer retention platform.
Sixth: Asset Management Sources (Master Data). Some machinery manufacturers use specialized asset management systems for maintenance schedules, operating hours, consumption data. This data is the foundation for predictive maintenance recommendations and lifecycle services. Without it, the portal remains reactive instead of proactive.
According to a McKinsey analysis on aftermarket strategy in mechanical engineering, companies with integrated service portals generate an average of 18 percent higher aftermarket revenue than companies with fragmented data sources. The reason: The customer can independently reorder, open service cases, plan maintenance, without depending on sales contact or support hotline.
DataEngine as API Layer: Why the Portal Shouldn’t Talk Directly to Six Systems
The first reaction of many companies: The portal should speak directly to the source systems. ERP API for prices, CRM API for service cases, PLM API for bills of materials. The problem: Each system has its own data structure, its own authentication, its own error handling. The portal becomes integration hell.
The alternative: A central data layer that sits between portal and source systems. In the MARINI architecture, this is the DataEngine. It consolidates the six source systems, forms a unified data model, and provides a clean API. The portal no longer talks to six different systems, but to a single endpoint.
Advantage one: Clear separation of frontend and backend. The portal team doesn’t need to understand ERP logic, know CRM data structures, or debug PLM APIs. The DataEngine encapsulates the complexity. The portal retrieves structured data, done.
Advantage two: Simpler scaling path. When a new source system is added (e.g., an IoT gateway for machine data), it’s integrated into the DataEngine. The portal itself remains unchanged. Without this separation, each new source system means an adjustment in the portal code.
Advantage three: Unified authentication. The DataEngine checks which customer user is allowed to see which data. It translates the portal session into the corresponding permissions in the source systems. The portal itself doesn’t need to worry about SAP roles, CRM security groups, or PLM access rights.
The MARINI DataEngine synchronizes data bidirectionally in real-time from SAP S/4HANA, Salesforce, Dynamics 365, and other B2B systems. It deduplicates records, creates Golden Records, and provides them via a unified API. For the portal, it’s the only point of contact, all sources are abstracted.
Role-Based Data Filters and Audit Logging: Who Can See What?
A B2B customer portal doesn’t serve “the customer,” but different roles within a customer company. The purchasing manager may view contracts. The plant manager may open service cases. The maintenance technician may order spare parts. Who can see which data isn’t a UX question. It’s a data permission question.
The DataEngine handles this filtering. Each portal login is authenticated against customer master data. The DataEngine checks which location, which cost center, which organizational unit belongs to this user. It filters the provided data accordingly. The plant manager at location A only sees machines at location A. The purchasing manager at headquarters sees all locations.
This logic must be implemented outside the portal. If the portal itself decides who sees what, a dependency arises: Every change in the customer’s role structure requires an adjustment in the portal. When the DataEngine handles this logic, it’s managed centrally, independent of the frontend.
Add audit logging. In the B2B context, data access must be traceable. Who retrieved which prices when? Who ordered which spare parts? The DataEngine logs every API call, every data retrieval, every change. This isn’t only compliance-relevant (GDPR, GoBD), but also business-critical: If a customer is suddenly poached by a competitor, sales wants to know which data was retrieved via the portal.
A PwC study on data security in B2B portals shows: 41 percent of German companies don’t have complete audit trail documentation for customer portal access. This isn’t just a compliance risk, but also a sales risk. Without logging, nobody knows whether the portal is even being used, and if so, by whom.
What MARINI Does Differently in Mechanical Engineering: DataEngine as Central API Layer
MARINI positions itself in mechanical engineering as the data layer between ERP, CRM, service system, and customer portal. The MARINI DataEngine consolidates all relevant sources and provides them via a unified API. The portal itself is exchangeable. The data foundation is the asset.
Real-time inventory queries. The DataEngine synchronizes inventory levels from SAP S/4HANA in real-time. When a customer views a spare part in the portal, they see current availability, not yesterday’s status. This is crucial for customer experience. A customer who orders and learns three days later that the part isn’t available won’t use the portal again.
Customer-specific pricing logic. The DataEngine translates customer-specific discounts, framework agreements, volume discounts from the ERP into a unified price structure for the portal. The customer doesn’t see generic list prices, but their individual conditions. This requires deep integration into ERP pricing logic, the DataEngine handles this complexity.
Service case visibility. The DataEngine synchronizes service tickets from Salesforce Field Service or Dynamics 365 Customer Service to the portal in real-time. The customer sees the current status, assigned technician, planned arrival time. When something changes, the change is immediately transferred to the portal. No nightly batch jobs, no outdated data.
Connection to installed base. The DataEngine links service cases, spare parts, maintenance schedules with the installed machine. The customer selects the machine and sees all associated information: open service cases, ordered spare parts, upcoming maintenance, available upgrades. This linkage is the heart of a successful customer portal. It requires a clean Customer 360-degree model, exactly what the MARINI DataEngine provides.
For machinery manufacturers wanting to build a spare parts self-service portal or service portal, the MARINI DataEngine is the central building block. It doesn’t replace the portal, it makes it possible. The frontend can be built by an agency, an internal development team, or a standard provider. The data foundation comes from the DataEngine.
The Portal Is the Tip, the Data Foundation Is the Iceberg Base
The KAMPF case shows: The success of a customer portal isn’t decided in the UX phase, but in data integration. Anyone with six different source systems needs a central data layer. Anyone wanting to manage role-based access needs authentication logic outside the portal. Anyone wanting to log in compliance needs audit logging at the data level.
Most B2B customer portals don’t fail at the frontend. They fail because the data foundation is wrong. The customer doesn’t see all their machines. Prices aren’t customer-specific. Service tickets are outdated. Spare parts recommendations are generic. After three months, usage drops below 10 percent.
The solution isn’t a better portal. The solution is a better data foundation. The MARINI DataEngine handles exactly this task: It consolidates ERP, CRM, service, and PLM data, forms a unified Golden Record model, filters by role, logs access, synchronizes in real-time. The portal itself becomes a pure presentation layer. The intelligence sits in the data layer.
For machinery manufacturers wanting to digitize their aftermarket strategy, this is the crucial insight: The portal is the tip. The data foundation is the iceberg base. Anyone who builds the foundation correctly will have a portal that gets used. Anyone who only polishes the tip will have a UX-award-worthy frontend, and a usage rate below 10 percent.
