Many manufacturers follow the same pattern: The portal goes live, but customers continue to use the phone and email. The reason usually lies not in the design, but in the data available for each machine. If equipment is missing, contracts are incorrect, or service information is posted too late, the portal loses users right from their first login.
For you, as the head of service or CEO, this is easy to check:
- Are all machines assigned to the correct customer account?
- Are modifications, software versions, and service histories maintained for each system?
- Are contracts, SLAs, and prices linked to the machine?
- Can customers view the status of their tickets, orders, and documents without having to ask?
If there are gaps here, self-service won’t work. The workload will simply shift back to inside sales. That’s exactly why the analysis starts with the installed base before the front end even comes into play.
This can be categorized according to the model: Digitize → Connect → Decide → Automate. Only when the data for each machine is clean and accurate can a portal be useful in day-to-day operations. Service Decision Intelligence (SDI) later builds on this foundation—with source citation for recommendations and data sovereignty within the customer’s infrastructure.
A typical scenario from real-world practice:
| Problem on the Portal | Impact on Daily Life |
|---|---|
| Machine Missing | Customer calls |
| Incorrect Contract Status | Inquiry to the inside sales staff |
| No machine reference for parts | Incorrect order or cancellation |
| No current ticket status | Email instead of the portal |
| Document Not Related to Configuration | Service call is delayed |
The bottom line: Whether a portal is used depends on trust in the machine data it displays. The go-live date doesn’t tell us much about that. If you want to know whether your database is sufficient for this, start with an Installed Base Assessment and then evaluate the role of the Digital Machine File (IOTAM) as a data set for each machine.
Why Many OEM customer portals are rarely used after going live
A customer portal in the machinery and plant engineering industry will only be used if it clearly displays the customer’s own installed base: machines, serial numbers, contracts, and order data. If this information is missing, usage usually drops off immediately after go-live.
The problem lies beneath the surface: it’s there, after customers log in, that they check whether the information displayed matches their day-to-day reality. If the asset portfolio, contract status, or service cases are incorrect, the digital channel immediately loses credibility. The process then gets transferred back to the phone or email, and the service organization ends up with more work instead of less.
Typical signs that a portal is not being accepted
The pattern is clear in practice: A customer logs in once, can’t find any reliable data, and then goes back to using the old channels. The hoped-for reduction in service workload fails to materialize.
Three indicators are particularly critical:
- The customer sees outdated terms and conditions instead of the prices they negotiated.
- He finds spare parts without any reference to specific machines, so he can’t determine whether a part is compatible with his particular system.
- He does not receive updates on the status of tickets and orders.
In any of these cases, trust in the digital channel plummets immediately. The portal then comes across as an unnecessary extra step.
Typical scenario: After logging in, the customer does not see all attachments
A typical scenario: A medium-sized machinery and equipment manufacturer launches a portal. The user interface is well-designed, but the installed base is only tracked in the ERP system and is not properly mapped to customer accounts. Some systems are missing, while others are incompletely recorded.
The customer logs in and sees only some of their equipment—or, in the worst-case scenario, none at all. They can’t access service history because the equipment isn’t assigned to an account. They can’t find the right spare parts because there’s no link to the specific machine. After a few weeks, active use declines. The portal remains online, but users bypass it in their day-to-day work.
The key, therefore, lies in the portal: in the completeness, structure, and mapping of the installed base. This is exactly where an Installed Base Assessment comes in. In Salesforce, this forms the foundation that enables portals, service processes, and self-service to function reliably. For many manufacturers, this is the first step in the maturity model: Digitize → Connect → Decide → Automate.
Is your portal planned or already live, but barely used?
In 30 minutes, we’ll use your machine data to check whether your installed base is already portal-ready and where the missing integration points are that would make self-service viable—no slide presentations.
→ Schedule an introductory call
The real cause: incomplete machine data
This is exactly where many portals fall short—with the data behind the interface. If machine data is fragmented, not properly reconciled, and cannot be prepared for use in a portal, the portal loses credibility from the very first use.
Why a pure ERP database is usually not sufficient for a portal
In many cases, an ERP system only shows a machine’s delivery status: serial number, customer, and delivery date. What happens afterward is often missing. Modifications, replaced components, or new software versions are not consistently tracked. This results in a picture of the machine’s condition at the time of delivery—“As-Sold”—but not of its current operational condition—“As-Maintained.”
In addition, the data is usually scattered across ERP, Salesforce, PLM, Field Service, and IoT and asset management systems. None of these sources alone provides a complete picture of the machine status.
The Digital Machine File (IOTAM) consolidates this information into a robust database for the portal. Only then can the “Connect” stage in the Digitize → Connect → Decide → Automate model be utilized. If the preceding “Digitize” step remains incomplete, the portal will ultimately be nothing more than a user interface without reliable content.
What data the portal needs for each machine
A customer portal in the machinery and equipment industry can only function properly if each piece of equipment is maintained as its own complete data record. This includes, at a minimum:
- Unique Identification: Serial Number, Asset ID, Assignment to Customer Account
- System Structure: A Specific Variant Rather Than a Generic Model
- Configuration Status: Modifications and Software Version
- Contract and Service Context: Contracts, SLAs, Deadlines, History
- Documentation and Live Data: version-specific documentation, operating hours, fault codes
The table shows where a pure ERP perspective ends and what the Digital Machine File (IOTAM) adds as the basis for a portal:
| Characteristic | ERP-Only Installed Base | Digital Machine File |
|---|---|---|
| Completeness | Shipping and billing information only | Full life cycle, including renovations |
| Level of Configuration | Factory settings, often outdated | Current operating status |
| Contract Link | Often separate or incomplete | Service contracts and SLAs clearly linked |
| Service History | Usually not included | Complete log of all service visits |
| IoT Connectivity | None | Real-time operating hours and status data |
| Portal Capability | Low – manual effort required | High – automated and synchronized |
How Data Gaps Become Immediately Apparent to Customers
If this data is missing, the customer notices it immediately upon their first login. This isn’t something that only becomes apparent in the reports; it’s evident right away during use: One out of three machines is missing from the portal. A contract hasn’t been entered. List prices appear instead of customized terms.
The result is clear. The user reverts to email, phone, or inside sales because they no longer trust the portal. From the customer’s perspective, this is a disruption in the process.
This, too, is a typical scenario: a plant operator with multiple machines who can only find part of their installed base on the portal. Or a buyer who sees prices that don’t match their framework agreement. In both cases, this immediately triggers the need for follow-up inquiries. The manual channel comes back into play—with corrections, coordination, and additional workload for inside sales.
The Digital Machine File (IOTAM) builds on this as the foundation for the next level of maturity.
The Digital Machine File as the Foundation of the Portal
What a Digital Machine File contains—and why that decides portal usage
If the installed base in the ERP system is too general for service cases, a problem immediately arises in the portal: Customers cannot uniquely identify their machine, spare parts do not match the installed configuration, and documents are available without any reference to the specific asset. For the user, this is the point at which they leave the portal and turn to the phone or email.
The Digital Machine File (IOTAM) closes this gap. It consolidates all machine-related data across the entire lifecycle into a robust portal-based system. Each machine is managed as its own data record—including serial number, configuration, location, documentation, service history, contracts, and real-time data. It is this context that makes self-service, spare parts, and service information available on a machine-specific basis.
In the portal, it’s not just about having data available—it’s about how that data is linked together. These are precisely the connections customers expect when they use a service portal:
| Data Element in the Machine File | Dependent portal function |
|---|---|
| Serial Number & Configuration Status | Machine Overview & Equipment Identification |
| PLM/ERP Bills of Materials | Machine-Specific Spare Parts Store |
| Service Reports & History | Ticketing & Status Tracking |
| Maintenance Schedules & Contracts | Maintenance Scheduling & Reminders |
| IoT data (operating hours, sensor readings) | Condition Monitoring & Predictive Maintenance |
| Technical Documentation (DMS) | Document Library & Self-Service Support |
Without these links, the portal falls short in day-to-day use. A typical example: A customer reports a need but cannot see either the most recent service call or the bill of materials for the machine. The result is that the inside sales staff has to spend time answering inquiries instead of customers being able to help themselves.
Why the portal is part of Level 2 of the 4-step model
The portal therefore belongs in the second stage of the model: Digitize → Connect → Decide → Automate. In Stage 1, the installed base is accurately digitized. In Stage 2, this data is connected for customers, service, and processes—for example, within the portal.
The point is simple: A portal can only be as good as the database it’s built on. If Level 1 remains incomplete, Level 2 cannot perform its task properly. Then, despite the portal, inquiries still end up with the inside sales staff because the link between the machine, the history, and the document is missing.
Without this foundation, the portal remains just another channel that generates the same follow-up questions as before.
How to Build a Portal That Customers Will Actually Use
First, the Installed Base Assessment—before the portal is redesigned
Once the data gaps have been clearly identified, the operational restructuring begins. Many portal projects start off on the wrong foot. The first question to ask is: What data is currently available, and how complete is it for each machine and customer?
To do this, consolidate ERP, service, and Excel data, check for missing machine-to-customer mappings, and determine which machines need to be accurately mapped first. This allows you to decide on the portal’s future data foundation even before a tool is selected. logicline’s Installed Base Assessment identifies these gaps before time and budget are invested in the portal overhaul.
This analysis provides the foundation on which the portal will later operate reliably.
Integrating the Portal, Service, and Data Model
The Digital Machine File (IOTAM) serves as the central data record for each machine: serial number, configuration, location, contract status, and service history. The portal accesses this dataset, not ERP, CRM, or PLM systems directly. This is precisely where the problem lies in many projects: Customers log in and cannot find equipment, see documents unrelated to the machine, or receive service status updates too late.
With a clean database, the access rights model can also be clearly managed. When there are multiple locations, plant managers see only their own location, while central procurement staff can view the entire machine fleet. That may sound trivial, but in practice, it’s often the factor that determines whether portals succeed or fail in day-to-day operations.
Whether a standard solution or a custom-developed solution is the right choice depends primarily on two factors: the scope of integration and internal capacity. You can find more information here: Customer Portals for the machinery and equipment industry and Standard vs. Custom Development.
Conclusion: Portal usage depends on trust in data
OEM portals rarely fail because of their design. They fail when the installed base shown in the portal does not match the customer’s actual situation. As a result, after logging in, machines may be missing, documents may not match the actual configuration, or the service status may not appear until later. Customers use a portal when the data displayed accurately reflects their day-to-day operations.
The Digital Machine File (IOTAM) serves as the central data source that the portal, service, and inside sales teams can all access. In Salesforce, this machine context can be seamlessly integrated into service processes, rather than having information scattered across multiple systems.
The 4-step model— Digitize → Connect → Decide → Automate—helps in determining the next phase of expansion. Once the data foundation is in place, the next step in Stage 3— Service Decision Intelligence (SDI) —follows: Service data then drives reliable service decisions, rather than simply being displayed.
The next step depends on where your data stands today:
- Installed Base Assessment – if you first want to check whether your installed base is portal-compatible and where mappings are missing.
- introductory call – once the data is in place and you’d like to discuss the specifics of portal and service access for your fleet.
FAQs
How can I check whether our installed base is portal-compatible?
Check this in advance with a structured Installed Base Assessment. This will help you determine how reliable your data is, how your service processes currently operate, and whether the available information is even sufficient for a customer portal before you decide on the structure and systems. The starting point is a common problem in service: Customers search for information but cannot find a clear link to a specific piece of equipment. This leads to follow-up inquiries, longer processing times, and unnecessary back-and-forth between service, sales, and inside sales staff. Typical warning signs include: frequent inquiries about machines, parts, or documents; spare parts that can only be found via a general search rather than by specific equipment; documents not properly assigned by serial number; and discrepancies in data across sales, marketing, and service. An Installed Base Assessment reveals such gaps. Often, the portal project is launched even though master data, documents, and equipment associations are not yet sufficiently organized. The problem then surfaces later for the customer—for example, when spare parts do not fit the machine or when documents exist in duplicate or in different versions. By addressing these issues early on, you create a solid foundation for the next steps in Salesforce. This is a particularly sensible starting point in maturity programs following the model of Digitize → Connect → Decide → Automate, because you first clarify the current state before rolling out processes or portals.
What data for each machine is essential for a customer portal?
The following information is essential for each machine: unique identification via serial number and location; configuration, installed components, and compatible spare parts; machine-specific documentation in the correct version; service history; and contract and warranty status. For self-service, it is also necessary to have real-time assignment of spare parts, customer-specific terms, and inventory levels for each part. Only then can customers reliably find and order parts on their own without having to contact the service department.
When Is It Worth Creating a Digital Machine File Before the Portal Relaunch?
A Digital Machine File (IOTAM) is worthwhile before the portal relaunch if you need a robust and well-structured database for your self-service. Without this foundation, customers often see incorrect information about their machines, configurations, maintenance statuses, or documents after logging in. This leads to follow-up inquiries to the service department and slows down portal usage. The Digital Machine File (IOTAM) creates a single source of truth because it links information to the specific machine, not just the customer account. This is precisely what’s crucial for self-service: Users are looking for the status of a specific piece of equipment, not general customer data. Without this association, even a newly launched portal will fall short of expectations in day-to-day use. Often, a portal can only fulfill its purpose once master data, service history, documents, and configurations are linked to specific machines. Then customers—for example, in a Salesforce-based customer portal —see the data they actually need for maintenance, spare parts, or inquiries. This reduces the risk that usage will remain low after the relaunch.
