The service manager is pleased with the new portal. Three weeks after launch, the feedback inbox has long stopped lighting up. Customers can’t find their machines. Spare parts have no prices. Orders must be manually entered into the ERP. The portal receives poor reviews, and internal morale tanks. What was intended as a revenue booster for the aftermarket turns out to be a maintenance nightmare. Not because the frontend is poor. But because five data sources don’t fit together.
Why Self-Service Spare Parts Portals Usually Fail
Spare parts account for 40 to 60 percent of service margin in many mechanical engineering sectors. According to management consultancy Horváth, margins in the spare parts business are two to ten times higher than in new equipment sales. Digitizing this area through a customer portal can significantly increase aftermarket revenue. A concrete example: Automation specialist Industrility increased its spare parts revenue by 50 percent after implementing a well-designed self-service portal.
But most portals don’t fail at the frontend. They fail at the data foundation. A spare parts portal is not an isolated website, but a complex interplay of five data sources that must fit together in real-time: Installed Base (which machine belongs to the customer), PLM bill of materials (which parts belong to the machine), pricing from the ERP (what does the part cost for this customer), real-time inventory (is the part available), and order return to the ERP.
If just one of these sources isn’t cleanly integrated, the business model collapses. The customer can’t find the right part, can’t see the price, or doesn’t get a delivery time. At that moment, they pick up the phone, and the portal becomes an expensive showcase instead of a revenue driver.
Five Data Sources That Must Fit Together
A functioning spare parts portal begins with the Installed Base. The customer must be able to identify their machines: via serial number, location, or purchase date. Without this assignment, parts search becomes a guessing game. The Installed Base is the digital machine file, it must come from the ERP or an asset management system and be linked to customer master data in the CRM.
Second component: Bill of materials. They come from the PLM system or the ERP structural bill of materials and define which parts fit which machine variant. One and the same model can require different spare parts depending on year of manufacture, configuration, or region. This variance must be reflected in the portal, machine-specific, not generic.
Third component: Customer-specific pricing logic. Discount agreements, master service agreements, framework contract prices, all are conditions stored in the ERP but apply individually to each customer. The portal must be able to reflect this logic: The customer sees their price, not the list price. This requires a bidirectional connection to the ERP that retrieves prices and conditions in real-time.
Fourth component: Real-time inventory queries. The customer wants to know if the part is available and when it will be delivered. This information resides in the WMS or the ERP warehouse module. Without real-time connection, the portal displays phantom inventory, and disappointment is inevitable.
Fifth component: The order must return to the ERP. The customer has ordered, the portal has captured the order, but it must arrive as an order in the ERP, automatically, with all conditions, with the correct assignment to the customer account. Manual post-processing is not an option.
Connecting these five data sources directly to the portal is technically possible but fragile. Every change in the source system requires adjustments in the portal. Every new target system (such as a second ERP after an acquisition) doubles the integration effort. The better way: A middleware layer that consolidates all sources and delivers a unified data foundation to the portal.
DataEngine as API Layer for the Portal
Instead of five direct connections to the portal, MARINI builds a DataEngine as a consolidating layer between source systems and frontend. The HubEngine synchronizes Installed Base, bills of material, pricing, and inventory into the DataEngine. The DataEngine structures the data, enriches it (e.g., with product images, technical data sheets, cross-selling recommendations), and provides it to the portal as an API.
The portal now only communicates with MARINI, no longer with five different source systems. This decouples frontend and backend, makes the portal flexible, and accelerates development. When a new ERP is added, it is integrated into the HubEngine, the portal remains unaffected.
The second advantage: The DataEngine can ensure data quality and consistency. Duplicates in the Installed Base are recognized and cleaned up, bill of materials inconsistencies (e.g., outdated part numbers) are resolved, prices are validated. The portal works on a golden record data foundation, the source of truth lies in the DataEngine, not scattered across five systems.
The third advantage: MARINI offers a clear separation of data management and presentation. The portal can be built by a specialized e-commerce provider that focuses on user experience and conversion optimization. MARINI handles data integration, synchronization, and quality. This is the classic division of labor: frontend specialist for the portal, data platform specialist for integration.
Customer-Specific Pricing Logic
Pricing is its own discipline. In B2B aftermarket, there are virtually no list prices, every customer has individual conditions. These can be volume discounts (15% off from 10 pieces), framework contract prices (customer X always pays price Z for part Y), or master service agreements (annual quota within which discounted conditions apply).
Mapping this complexity from the ERP into the portal is a challenge. Many portals fail here and instead display list prices, which confuses the customer who knows their conditions and expects a different price. The consequence: The customer calls, sales must manually create the quote, the portal is bypassed.
The MARINI DataEngine can map this pricing logic as mapping rules. The HubEngine retrieves the conditions from the ERP (customer discounts, framework contracts, special conditions), the DataEngine applies them to the spare parts, and delivers the individual price for each customer to the portal. The portal shows what the customer actually pays, immediately, without inquiry.
This is not just a question of user-friendliness. It’s a question of revenue realization. Portals with transparent, customer-specific prices have a significantly higher conversion rate than those showing only list prices. The customer doesn’t have to inquire, doesn’t have to negotiate, doesn’t have to wait. They see their price and order.
Real-Time Inventory Queries and Delivery Times
Spare parts orders are time-critical. A machine is down, production isn’t running, every hour costs money. The customer doesn’t just want to know if the part is available, they want to know when they’ll get it. Tomorrow morning? In three days? Not until next week because it must be ordered from the supplier?
This information resides in the ERP or WMS, but it’s volatile. Inventory changes hourly, delivery times fluctuate depending on supplier performance. A spare parts portal must be able to query this data in real-time, otherwise it displays outdated information.
The MARINI HubEngine synchronizes inventory continuously, not once daily, but by the minute. The portal queries current inventory with every product inquiry, the DataEngine delivers the information immediately. This is technically complex but critical for portal acceptance.
The second aspect: delivery times. If a part is not in stock, the portal must be able to display a realistic delivery time. This requires integration with the ERP procurement module, which knows lead times and supplier performance. Here too: transparency builds trust. The customer sees when they’ll get the part, and can decide whether to wait or switch to an alternative part.
What MARINI Does Differently in Mechanical Engineering
MARINI positions itself as a data platform between ERP, PLM, WMS, and the customer portal. The three phases of the platform, Data Integration, Data Cloud, and Agentic, cover the entire aftermarket process.
In the Data Integration Phase, the five relevant source systems are connected: ERP for pricing and orders, PLM for bills of material, asset management for the Installed Base, WMS for inventory, CRM for customer master data. The HubEngine builds a plan for each system (credentials, sync logic, mapping), synchronizes bidirectionally and in real-time.
In the Data Cloud Phase, the data is consolidated, deduplicated, and enriched. Golden records for customers, machines, and spare parts are created. The DataEngine provides the portal with a unified API through which all data can be retrieved, Installed Base, bills of material, prices, inventory, delivery times. The portal is decoupled from the backend.
In the Agentic Phase, AI agents come into play: automatic classification of new spare parts, predictive quality (which parts will be requested soon), recommendations for cross-selling (which additional parts fit the order). The MCP (Model Context Protocol) enables natural language queries: The service technician asks “Which seals do I need for the machine in hall 3?”, the system delivers the answer, with part numbers, prices, and order link.
The difference from a pure e-commerce service provider: MARINI brings the data foundation. The portal provider can focus on UX and conversion, MARINI delivers the data. This is the division of labor that works.
From Installed Base to 360-Degree Portal
A spare parts portal is the entry point, not the end state. When the data foundation is in place, Installed Base clean, bills of material synchronized, pricing customer-specific, inventory in real-time, then the portal can be expanded into a comprehensive customer portal with 360-degree data foundation.
The Installed Base becomes the digital machine file: The customer not only sees which machines they own, but also their service history, upcoming maintenance, predictive maintenance recommendations. The machine becomes the touchpoint for all services: order spare parts, book service appointments, access technical documentation, view customer health score.
The second expansion step: cross-selling based on the Installed Base. When the system knows which machines the customer owns, it can proactively recommend additional products: wear parts that are due in three months. Software upgrades that fit the machine configuration. Accessories that other customers with similar machines have purchased. This is aftermarket cross-selling based on data, not a random hit, but systematic.
The third expansion step: integration with sales. The portal is not an isolated self-service channel, but a hybrid model. Standard orders run through the portal, complex inquiries are forwarded to sales, but with full context. The sales representative sees in the CRM what the customer viewed in the portal, which machines they own, which parts they last ordered. This makes sales more efficient and the customer happier.
The fourth expansion step: predictive services. When the Installed Base is enriched with IoT data (machine running times, operating hours, error messages), the system can proactively make service recommendations. “Your machine has reached 10,000 operating hours, the next maintenance is due. Here is the appropriate service package.” This is predictive maintenance based on master data, made possible by clean data integration.
All of this begins with a functioning spare parts portal. And a functioning spare parts portal begins with five data sources that fit together. This is the prerequisite. Without this foundation, every portal remains a maintenance nightmare.
