Bei vielen Herstellern zeigt sich dasselbe Muster: Das Portal geht live, aber die Kunden bleiben bei Telefon und E-Mail. Der Grund liegt meist nicht im Design, sondern in der Datenlage je Maschine. Wenn Anlagen fehlen, Verträge nicht stimmen oder Serviceinfos zu spät erscheinen, verliert das Portal schon beim ersten Login.
Für Sie als Serviceleiter oder Geschäftsführer ist die Sache einfach zu prüfen:
- Sind alle Maschinen dem richtigen Kundenkonto zugeordnet?
- Sind Umbauten, Softwarestände und Servicehistorien je Anlage gepflegt?
- Sind Verträge, SLAs und Preise mit der Maschine verknüpft?
- Sehen Kunden ihren Ticket-, Auftrags- und Dokumentenstatus ohne Rückfrage?
Wenn hier Lücken bestehen, entsteht kein Self-Service. Der Aufwand verlagert sich dann nur zurück in den Innendienst. Genau deshalb beginnt die Analyse bei der installierten Basis, bevor das Frontend überhaupt eine Rolle spielt.
Einordnen lässt sich das entlang des Modells Digitalisieren → Vernetzen → Entscheiden → Automatisieren: Erst wenn die Daten je Maschine sauber vorliegen, trägt ein Portal im Alltag. Auf diesem Fundament setzt später auch Service Decision Intelligence (SDI) auf – mit Quellennachweis bei Empfehlungen und Datenhoheit in der Kundeninfrastruktur.
Ein typisches Bild aus der Praxis:
| Problem im Portal | Folge im Alltag |
|---|---|
| Maschine fehlt | Kunde ruft an |
| Falscher Vertragsstand | Rückfrage an Innendienst |
| Kein Maschinenbezug bei Teilen | Falsche Bestellung oder Abbruch |
| Kein aktueller Ticketstatus | E-Mail statt Portal |
| Dokument ohne Konfigurationsbezug | Serviceeinsatz wird verzögert |
Der Kern: Ob ein Portal genutzt wird, hängt am Vertrauen in die angezeigten Maschinendaten. Das Go-live-Datum sagt darüber wenig aus. Wenn Sie wissen wollen, ob Ihre Datenbasis dafür reicht, starten Sie mit einem Installed Base Assessment und prüfen dann die Rolle der Digitalen Maschinenakte (IOTAM) als Datensatz je Maschine.
Warum viele OEM-Kundenportale nach dem Go-live kaum genutzt werden
Ein Kundenportal im Maschinen- und Anlagenbau wird nur dann genutzt, wenn es die eigene installierte Basis des Kunden sauber zeigt: Maschinen, Seriennummern, Verträge und Auftragsdaten. Fehlt diese Abbildung, bricht die Nutzung meist direkt nach dem Go-live ein.
Das Problem sitzt hinter der Oberfläche: dort, wo Kundinnen und Kunden nach dem Login prüfen, ob die angezeigten Daten zu ihrem Alltag passen. Stimmen Anlagenbestand, Vertragslage oder Servicefälle nicht, verliert der digitale Kanal sofort an Glaubwürdigkeit. Der Vorgang wandert dann zurück auf Telefon oder E-Mail, und die Serviceorganisation hat am Ende mehr statt weniger Aufwand.
Typische Anzeichen, dass ein Portal nicht angenommen wird
Das Muster ist in der Praxis klar: Ein Kunde meldet sich einmal an, findet keine verlässlichen Daten und nutzt danach wieder die alten Kanäle. Die erhoffte Entlastung im Service bleibt aus.
Besonders kritisch sind drei Signale:
- Der Kunde sieht veraltete Konditionen statt seiner verhandelten Preise.
- Er findet Ersatzteile ohne Maschinenbezug und bekommt damit keine Antwort auf die zentrale Frage, ob ein Teil zu seiner konkreten Anlage passt.
- Er erhält keinen aktuellen Status zu Tickets und Aufträgen.
In jedem dieser Fälle kippt das Vertrauen in den digitalen Kanal sofort. Das Portal wirkt dann wie ein zusätzlicher Zwischenschritt.
Typisches Szenario: Der Kunde sieht nach dem Login nicht alle Anlagen
Ein typisches Szenario: Ein mittelständischer Maschinenbauer führt ein Portal ein. Die Oberfläche ist stimmig, aber die installierte Basis liegt nur im ERP und ist den Kundenkonten nicht sauber zugeordnet. Manche Anlagen fehlen, andere sind unvollständig erfasst.
Der Kunde loggt sich ein und sieht nur einen Teil seiner Anlagen oder im schlechtesten Fall gar keine. Er kann keine Servicehistorie abrufen, weil die Zuordnung fehlt. Er findet keine passenden Ersatzteile, weil kein Bezug zur konkreten Maschine besteht. Nach wenigen Wochen sinkt die aktive Nutzung. Das Portal bleibt online, aber es wird im Alltag umgangen.
Der Hebel liegt damit vor dem Portal: bei Vollständigkeit, Struktur und Zuordnung der installierten Basis. Genau dort setzt ein Installed Base Assessment an. In Salesforce wird daraus die Grundlage, damit Portale, Serviceprozesse und Self-Service überhaupt belastbar funktionieren. Für viele Hersteller ist das der erste Schritt im Reifegradmodell Digitalisieren → Vernetzen → Entscheiden → Automatisieren.
Portal geplant oder live, aber kaum genutzt?
In 30 Minuten prüfen wir an Ihren Maschinendaten, ob Ihre installierte Basis heute schon portalfähig ist und wo die Zuordnung fehlt, die Self-Service tragfähig macht – kein Folientermin.
→ Erstgespräch vereinbaren
Die eigentliche Ursache: unvollständige Maschinendaten
Genau an diesem Punkt scheitern viele Portale – an den Daten hinter der Oberfläche. Wenn Maschinendaten fragmentiert vorliegen, nicht sauber abgeglichen sind und sich nicht für ein Portal aufbereiten lassen, verliert das Portal beim ersten Einsatz an Glaubwürdigkeit.
Warum eine reine ERP-Datenbasis für ein Portal meist nicht ausreicht
Ein ERP zeigt in vielen Fällen nur den Lieferzustand einer Maschine: Seriennummer, Kunde, Lieferdatum. Was danach passiert, fehlt oft. Umbauten, getauschte Komponenten oder neue Softwarestände werden nicht durchgängig nachgeführt. Damit entsteht ein Bild des Zustands bei Auslieferung – „As-Sold“ –, aber nicht des aktuellen Betriebszustands „As-Maintained“.
Hinzu kommt: Die Daten liegen meist verteilt in ERP, Salesforce, PLM, Field Service Management sowie IoT- und Asset-Management-Systemen. Keine dieser Quellen deckt den Maschinenstand allein vollständig ab.
Die Digitale Maschinenakte (IOTAM) führt diese Informationen zu einer belastbaren Datenbasis für das Portal zusammen. Erst damit wird die Stufe „Vernetzen“ im Modell Digitalisieren → Vernetzen → Entscheiden → Automatisieren nutzbar. Bleibt das vorherige „Digitalisieren“ lückenhaft, ist das Portal am Ende nur eine Oberfläche ohne verlässlichen Inhalt.
Welche Daten das Portal für jede Maschine braucht
Ein Kundenportal im Maschinenbau funktioniert nur dann sauber, wenn jede Anlage als eigener, vollständiger Datensatz geführt wird. Dazu gehören mindestens:
- Eindeutige Identifikation: Seriennummer, Asset-ID, Zuordnung zum Kundenkonto
- Anlagenstruktur: konkrete Variante statt generisches Modell
- Konfigurationsstatus: Umbauten und Softwarestand
- Vertrags- und Servicekontext: Verträge, SLAs, Fristen, Historie
- Dokumentation und Live-Daten: versionsgenaue Unterlagen, Betriebsstunden, Fehlercodes
Die Tabelle zeigt, wo eine reine ERP-Sicht endet und was die Digitale Maschinenakte (IOTAM) als Basis für ein Portal ergänzt:
| Merkmal | ERP-only Installed Base | Digitale Maschinenakte |
|---|---|---|
| Vollständigkeit | Nur Liefer- und Rechnungsdaten | Vollständiger Lebenszyklus inkl. Umbauten |
| Konfigurationstiefe | Lieferzustand, oft veraltet | Aktueller Betriebszustand |
| Vertragsverknüpfung | Oft separat oder unvollständig | Serviceverträge und SLAs sauber verknüpft |
| Servicehistorie | Meist nicht enthalten | Vollständiges Protokoll aller Eingriffe |
| IoT-Anbindung | Keine | Betriebsstunden und Zustandsdaten live |
| Portalfähigkeit | Niedrig – manueller Aufwand nötig | Hoch – automatisiert und synchronisiert |
Wie Datenlücken für Kunden sofort sichtbar werden
Fehlen diese Daten, merkt der Kunde das sofort beim ersten Login. Sichtbar wird das nicht erst im Reporting, sondern direkt in der Nutzung: Eine von drei Maschinen fehlt im Portal. Ein Vertrag ist nicht hinterlegt. Statt individueller Konditionen erscheinen Listenpreise.
Die Folge ist klar. Der Nutzer wechselt zurück zu E-Mail, Telefon oder Innendienst, weil er dem Portal nicht mehr vertraut. Aus Kundensicht ist das ein Bruch im Ablauf.
Auch das ist ein typisches Muster: ein Anlagenbetreiber mit mehreren Maschinen, der nur einen Teil seiner Installed Base im Portal findet. Oder ein Einkäufer, der Preise sieht, die nicht zu seinem Rahmenvertrag passen. In beiden Fällen entsteht sofort Rückfragebedarf. Der manuelle Kanal lebt wieder auf – mit Korrekturen, Abstimmungen und zusätzlichem Aufwand im Innendienst.
Darauf setzt die Digitale Maschinenakte (IOTAM) als Grundlage für den nächsten Reifegrad auf.
Die digitale Maschinenakte als Fundament des Portals
Was eine digitale Maschinenakte enthält – und warum das die Portalnutzung entscheidet
Wenn die installierte Basis im ERP für Servicefälle zu grob ist, entsteht im Portal sofort ein Problem: Kunden finden ihre Maschine nicht eindeutig, Ersatzteile passen nicht zur verbauten Konfiguration, und Dokumente stehen ohne Bezug zum konkreten Asset bereit. Für den Nutzer ist das der Punkt, an dem er das Portal wieder verlässt und zum Telefon oder zur E-Mail greift.
Die Digitale Maschinenakte (IOTAM) schließt diese Lücke. Sie bündelt alle maschinenbezogenen Daten über den gesamten Lebenszyklus hinweg in einer belastbaren Portalbasis. Jede Maschine wird als eigener Datensatz geführt – mit Seriennummer, Konfiguration, Standort, Dokumentation, Servicehistorie, Verträgen und Live-Daten. Erst dieser Zusammenhang macht Self-Service, Ersatzteile und Serviceinformationen maschinenscharf nutzbar.
Im Portal zählt nicht nur, dass Daten vorliegen, sondern wie sie miteinander verknüpft sind. Genau diese Verbindungen erwarten Kunden, wenn sie einen Servicezugang nutzen:
| Datenelement der Maschinenakte | Abhängige Portalfunktion |
|---|---|
| Seriennummer & Konfigurationsstand | Maschinenübersicht & Anlagenidentifikation |
| PLM-/ERP-Stücklisten | Maschinenspezifischer Ersatzteilshop |
| Serviceberichte & Historie | Ticketing & Statusverfolgung |
| Wartungspläne & Verträge | Wartungsplanung & Erinnerungen |
| IoT-Daten (Betriebsstunden, Sensorwerte) | Zustandsüberwachung & vorausschauende Wartung |
| Technische Dokumentation (DMS) | Dokumentenbibliothek & Self-Service-Support |
Fehlen diese Verknüpfungen, fällt das Portal im Alltag durch. Ein typisches Beispiel: Der Kunde meldet einen Bedarf, sieht aber weder den letzten Serviceeinsatz noch die zur Maschine passende Stückliste. Das Ergebnis ist Rückfrageaufwand im Innendienst statt Self-Service.
Warum das Portal zur Stufe 2 des 4-Stufen-Modells gehört
Das Portal gehört deshalb in die zweite Stufe des Modells Digitalisieren → Vernetzen → Entscheiden → Automatisieren. In Stufe 1 wird die installierte Basis sauber digital erfasst. In Stufe 2 werden diese Daten für Kunden, Service und Prozesse vernetzt, zum Beispiel im Portal.
Der Punkt ist einfach: Ein Portal kann nur so gut sein wie die Datenbasis darunter. Bleibt Stufe 1 lückenhaft, kann Stufe 2 ihre Aufgabe nicht sauber erfüllen. Dann landen Anfragen trotz Portal weiter beim Innendienst, weil die Verbindung zwischen Maschine, Historie und Dokument fehlt.
Ohne diese Basis bleibt das Portal ein zusätzlicher Kanal mit denselben Rückfragen wie zuvor.
So bauen Sie ein Portal, das Kunden wirklich nutzen
Zuerst das Installed-Base-Assessment – bevor das Portal überarbeitet wird
Sobald die Datenlücken klar benannt sind, beginnt der operative Umbau. Viele Portalprojekte starten an der falschen Stelle. Zuerst zählt die Frage: Welche Daten liegen heute vor, und wie vollständig sind sie je Maschine und Kunde?
Führen Sie dazu ERP-, Service- und Excel-Daten zusammen, prüfen Sie fehlende Maschinen-Kunden-Zuordnungen und legen Sie fest, welche Maschinen zuerst sauber abgebildet werden müssen. Damit entscheiden Sie über die spätere Datengrundlage des Portals, noch bevor ein Tool im Raum steht. Das Installed-Base-Assessment von logicline macht diese Lücken sichtbar, bevor Zeit und Budget in die Portalüberarbeitung fließen.
Aus dieser Analyse entsteht die Basis, auf der das Portal später verlässlich arbeitet.
Portal, Service und Datenmodell verbinden
Die Digitale Maschinenakte (IOTAM) bildet den zentralen Datensatz je Maschine: Seriennummer, Konfiguration, Standort, Vertragsstand und Servicehistorie. Das Portal greift auf diesen Datensatz zu, nicht direkt auf ERP, CRM oder PLM. Genau dort liegt in vielen Projekten das Problem: Kunden melden sich an und finden Anlagen nicht, sehen Unterlagen ohne Bezug zur Maschine oder erhalten einen Servicestatus zu spät.
Mit einer sauberen Datenbasis lässt sich auch das Rechtemodell klar steuern. Bei mehreren Standorten sehen Werksleiter nur ihren Standort, während zentrale Einkäufer den gesamten Maschinenpark einsehen. Das klingt banal, ist in der Praxis aber oft der Punkt, an dem Portale im Alltag bestehen oder scheitern.
Ob dafür eine Standardlösung oder eine Eigenentwicklung passt, hängt vor allem von zwei Punkten ab: Integrationsumfang und interne Kapazität. Mehr dazu finden Sie hier: Kundenportale für den Maschinenbau und Standard vs. Eigenentwicklung.
Fazit: Portalnutzung folgt dem Datenvertrauen
OEM-Portale scheitern selten am Design. Sie scheitern, wenn die installierte Basis im Portal nicht zur Lage beim Kunden passt. Dann fehlen nach dem Login Maschinen, Dokumente passen nicht zur verbauten Konfiguration oder der Servicestatus erscheint erst mit Verzögerung. Kunden nutzen ein Portal dann, wenn die angezeigten Daten im Alltag stimmen.
Die Digitale Maschinenakte (IOTAM) schafft dafür die zentrale Datenquelle, auf die Portal, Service und Innendienst gemeinsam zugreifen. In Salesforce lässt sich dieser Maschinenkontext durchgängig in Serviceprozesse einbinden, statt Informationen über mehrere Systeme zu verteilen.
Für die Einordnung der nächsten Ausbaustufe hilft das 4-Stufen-Modell Digitalisieren → Vernetzen → Entscheiden → Automatisieren. Steht das Datenfundament, folgt in Stufe 3 mit Service Decision Intelligence (SDI) der nächste Schritt: Servicedaten treiben dann belastbare Serviceentscheidungen, statt nur angezeigt zu werden.
Der nächste Schritt hängt davon ab, wo Ihre Daten heute stehen:
- Installed Base Assessment – wenn Sie zuerst prüfen wollen, ob Ihre installierte Basis portalfähig ist und wo Zuordnungen fehlen.
- Erstgespräch – wenn die Datenbasis steht und Sie den Portal- und Servicezugang für Ihre Flotte konkret durchsprechen wollen.
FAQs
Wie prüfe ich, ob unsere installierte Basis portalfähig ist?
Prüfen Sie das vorab mit einem strukturierten Installed Base Assessment. So klären Sie, wie belastbar Ihre Daten sind, wie Ihre Serviceprozesse heute arbeiten und ob die vorhandenen Informationen für ein Kundenportal überhaupt reichen, bevor Sie über Aufbau und Systeme entscheiden. Der Ausgangspunkt ist ein bekanntes Problem im Service: Kunden suchen Informationen, finden aber keine saubere Zuordnung zur konkreten Anlage. Das führt zu Rückfragen, längeren Bearbeitungszeiten und unnötigen Schleifen zwischen Service, Vertrieb und Innendienst. Typische Warnsignale sind: häufige Rückfragen zu Maschinen, Teilen oder Dokumenten; Ersatzteile nur über allgemeine Suche statt anlagenbezogen auffindbar; Dokumente nicht sauber pro Seriennummer zugeordnet; unterschiedliche Datenstände in Vertrieb, Marketing und Service. Ein Installed Base Assessment macht solche Lücken sichtbar. Häufig gilt: Das Portalprojekt startet, obwohl Stammdaten, Dokumente und Anlagenbezüge noch nicht sauber genug sind. Dann landet das Problem später beim Kunden, etwa wenn Ersatzteile nicht zur Maschine passen oder Unterlagen doppelt und in verschiedenen Versionen vorliegen. Wenn Sie diese Punkte früh prüfen, schaffen Sie eine belastbare Grundlage für die nächsten Schritte in Salesforce. Gerade in Reifegradprogrammen nach dem Muster Digitalisieren → Vernetzen → Entscheiden → Automatisieren ist das ein sinnvoller Startpunkt, weil Sie erst den Ist-Zustand klären, bevor Sie Prozesse oder Portale ausrollen.
Welche Daten je Maschine sind für ein Kundenportal unverzichtbar?
Unverzichtbar sind je Maschine: eine eindeutige Identifikation mit Seriennummer und Standort; Konfiguration, installierte Komponenten und passende Ersatzteile; maschinenspezifische Dokumentation in der richtigen Version; Servicehistorie sowie Vertrags- und Gewährleistungsstatus. Für den Self-Service braucht es zusätzlich die Zuordnung von Ersatzteilen, kundenspezifische Konditionen und Bestände in Echtzeit je Teil. Erst dann können Kunden Teile sicher selbst finden und bestellen, ohne Rückfragen an den Service auszulösen.
Wann lohnt sich eine Digitale Maschinenakte vor dem Portal-Relaunch?
Eine Digitale Maschinenakte (IOTAM) lohnt sich vor dem Portal-Relaunch, wenn Sie für Ihren Self-Service eine belastbare und sauber strukturierte Datenbasis brauchen. Fehlt diese Grundlage, sehen Kunden nach dem Login ihre Maschinen, Konfigurationen, Wartungsstände oder Dokumente oft nicht korrekt. Das führt zu Rückfragen im Service und bremst die Nutzung des Portals. Die Digitale Maschinenakte (IOTAM) schafft eine Single Source of Truth, weil sie Informationen der jeweiligen Maschine zuordnet, nicht nur dem Kundenkonto. Genau das ist für den Self-Service entscheidend: Der Nutzer sucht den Stand einer konkreten Anlage, nicht allgemeine Kundendaten. Fehlt diese Zuordnung, bleibt selbst ein neu aufgesetztes Portal im Alltag hinter den Erwartungen zurück. Häufig gilt: Erst wenn Stammdaten, Servicehistorie, Dokumente und Konfigurationen maschinenscharf verknüpft sind, kann ein Portal seinen Zweck erfüllen. Dann sehen Kunden – etwa in einem Kundenportal auf Salesforce-Basis – die Daten, die sie für Wartung, Ersatzteile oder Rückfragen tatsächlich brauchen. So sinkt das Risiko, dass die Nutzung nach dem Relaunch niedrig bleibt.
