Zum Hauptinhalt springen
    SystemSelect · Beratung für Software-Auswahl

    30 Min · kostenlos

    Beratung anfragen

    Anfragen →

    CRM-Auswahl mit Kundenportal beim technischen Gebäudeservice

    Projektmuster für eine CRM-Auswahl unter der Prämisse eines Kundenportals – Kontext und Kennzahlen sind illustrativ modelliert.

    Evidenzstatus · Stand 2026-08-12

    Projektmuster · kein Kundennachweis

    Dieses Projektmuster verdichtet typische Anforderungen, Entscheidungen und Risiken aus der Beratungspraxis. Es beschreibt kein einzelnes Kundenmandat. Unternehmen, Verlauf und Kennzahlen sind illustrativ modelliert und dürfen nicht als gemessene Kundenergebnisse gelesen werden.

    Interner Nachweis

    Redaktionelles Szenario; im Repository liegt kein freigegebener Kundennachweis vor.

    Datenschutz & Freigabe

    Keine Kundendaten oder Original-Screenshots verwendet. Kundenfreigabe ist für dieses Projektmuster nicht anwendbar.

    Auf einen Blick

    Branche
    Technischer Gebäudeservice
    Unternehmensgröße
    120 Mitarbeitende
    Gewähltes System
    Dynamics 365 + Power Pages
    Projektdauer
    9 Monate

    Ausgangslage

    Das Unternehmen wartet Gebäudetechnik für rund 800 Bestandskunden – überwiegend Hausverwaltungen und Gewerbebetriebe. Die Kundenbetreuung war telefonisch geprägt und über Access, Outlook und Notizzettel verteilt. Der Auslöser für das Projekt war eine klare Erwartung der Kunden: Sie wollten Störungen selbst melden, Termine einsehen und Nachweise abrufen können – ohne anzurufen. Das CRM sollte deshalb von Anfang an mit einem Kundenportal gedacht werden.

    Störungsannahme
    800 Wartungskunden meldeten Störungen telefonisch – zwei Innendienst-Kräfte nahmen Tickets per Zuruf und Notizzettel auf
    Kundenkommunikation
    Terminzusagen, Rückfragen und Statusupdates liefen über Einzel-E-Mails – kein zentraler Verlauf, keine Nachvollziehbarkeit
    Dokumente
    Prüfprotokolle und Wartungsnachweise wurden auf Anfrage einzeln herausgesucht und per Mail verschickt – oft mit Tagen Verzug
    Vertragsübersicht
    Servicevertrags-Daten lagen in einer Access-Datenbank – Laufzeiten und Leistungsumfang für Kunden nicht selbst einsehbar
    Vertrieb
    Keine strukturierte Pipeline für Neuverträge und Upselling bestehender Wartungskunden – Chancen blieben im Kopf einzelner Techniker

    Warum das Kundenportal die Systementscheidung bestimmte

    Bei vielen CRM-Projekten ist ein Kundenportal ein „Nice-to-have“, das später ergänzt wird. Hier war es umgekehrt: Das Portal war die eigentliche Prämisse – das CRM war das Fundament, das dieses Portal tragen musste. Diese Reihenfolge hat die gesamte Auswahllogik verändert.

    • Kunden (überwiegend Hausverwaltungen und Gewerbebetriebe) forderten zunehmend Self-Service: Störung melden, Termin einsehen, Nachweise selbst abrufen – rund um die Uhr, ohne Telefonat.
    • Ein reines Innendienst-CRM hätte die eigentliche Kernanforderung nicht gelöst. Das Portal war kein Zusatzwunsch, sondern der Auslöser des gesamten Projekts.
    • Damit wurde die Portalfähigkeit zum entscheidenden Auswahlkriterium: CRM und kundenseitige Oberfläche mussten auf einer Datenbasis laufen – ein separat gebautes Portal neben dem CRM hätte doppelte Datenpflege und Medienbrüche bedeutet.

    Unsere Rolle im Projekt

    SystemSelect hat die Systemauswahl moderiert und dabei früh sichergestellt, dass die Portalanforderung nicht als Nebensache behandelt wurde, sondern als hart gewichtetes Auswahlkriterium in die Scorecard einfloss. Wir haben die Anbieter gezielt gezwungen, das Portal im Demo-Szenario mit echten Vertrags- und Nachweisdaten zu zeigen – nicht nur auf Folien zu behaupten.

    Die größte Gefahr in solchen Projekten ist eine Insellösung: ein CRM für innen, ein separat gebautes Portal für außen – mit doppelter Datenpflege. Wir haben darauf bestanden, dass Portal und CRM auf einer Datenbasis laufen, und die wirtschaftliche Bewertung der Portal-Lizenzen je externem Nutzer bei 800 Kunden in den Vordergrund gestellt.

    Vorgehen: 5 Phasen in 9 Monaten

    01Anforderungsanalyse (Woche 1–5)

    • Workshops mit Innendienst, Serviceleitung, Vertrieb und Geschäftsführung – plus Interviews mit 6 Bestandskunden zum gewünschten Portal-Funktionsumfang
    • 140 priorisierte Anforderungen, davon 18 Must-haves – 6 davon direkt am Kundenportal (Störungsmeldung, Terminanzeige, Dokumentenabruf, Vertragsübersicht)
    • Zentrale Prämisse festgehalten: CRM und Kundenportal auf einer Datenbasis – keine Insellösung neben dem CRM
    • Rahmenbedingung: bestehende Microsoft-365-Umgebung und geplante Field-Service-Einsatzplanung sollten anschlussfähig bleiben

    02Marktanalyse & Longlist (Woche 6–9)

    • 5 Systeme evaluiert: Microsoft Dynamics 365 Customer Service + Power Pages, Salesforce Service Cloud + Experience Cloud, HubSpot Service Hub (Customer Portal), Zoho CRM + Zoho Creator, SugarCRM
    • Portal-Deep-Dive als eigener Bewertungsblock: Konfigurierbarkeit, Rechte-/Rollenmodell für Kundenkontakte, Dokumenten-Freigabe, Aufwand für Individualisierung
    • Ausschluss HubSpot: Customer Portal zum Bewertungszeitpunkt zu wenig anpassbar für Vertrags- und Nachweisabruf – nur eingeschränkt geeignet
    • Shortlist: Microsoft Dynamics 365 + Power Pages, Salesforce Service Cloud + Experience Cloud

    03Demo & Bewertung (Woche 10–14)

    • Scripted Demo mit echtem Szenario: Kunde meldet Aufzugsstörung im Portal → Ticket → Technikereinsatz → Nachweis im Portal
    • Bewertung durch 5 Personen (Serviceleitung, Innendienst, Vertrieb, IT, GF) mit gewichteter Scorecard – Portalfähigkeit dreifach gewichtet
    • Entscheidung: Microsoft Dynamics 365 Customer Service + Power Pages – nahtlose Microsoft-365- und Field-Service-Integration bei deutlich geringeren Portal-Lizenzkosten je externem Nutzer
    • Salesforce funktional gleichwertig, aber Experience-Cloud-Lizenzen je Portalnutzer bei 800 Kunden nicht wirtschaftlich darstellbar

    04Implementierung, Portal & Datenmigration (Woche 15–30)

    • Migration: 800 Wartungskunden, 1.900 Kontakte und 2.400 aktive Serviceverträge aus Access nach Dynamics 365
    • Field Service aufgesetzt: Einsatzplanung, Technikerdisposition und mobile Auftragsrückmeldung
    • Power-Pages-Kundenportal gebaut: Störungsmeldung mit Objektbezug, Terminanzeige, Vertragsübersicht und Download von Prüfprotokollen – gespiegelt aus denselben Dynamics-Datensätzen
    • Rechte-/Rollenmodell: jeder Kundenkontakt sieht ausschließlich die eigenen Objekte, Verträge und Nachweise

    05Rollout, Change Management & Kunden-Onboarding (Woche 28–38)

    • Interne Schulung: Innendienst und Serviceleitung auf CRM und Ticketprozess, Techniker auf mobile Field-Service-App
    • Kunden-Onboarding in Wellen: 800 Kunden gestaffelt eingeladen, mit Kurzanleitung und persönlicher Aktivierung der 50 wichtigsten Objektkunden
    • 4-wöchige Begleitung nach Go-Live: wöchentliche Feedbackrunde, Nachschärfung der Portal-Texte und Ticket-Formulare
    • Portal-Adoption als Steuerungsgröße: monatliches Dashboard zu Portalnutzung, Ticketkanälen und Bearbeitungszeiten

    Modellierte Ergebnisse nach 6 Monaten Betrieb

    68 %
    Portal-Adoption
    der Wartungskunden nutzen das Portal aktiv nach 6 Monaten
    -45 %
    Telefonische Störmeldungen
    Störungen laufen jetzt überwiegend strukturiert über das Portal ein
    -30 %
    Bearbeitungszeit je Störung
    durch strukturierte Erfassung mit Objektbezug statt Notizzettel
    100 %
    Vertrags- & Nachweis-Transparenz
    Kunden rufen Verträge und Prüfprotokolle selbst im Portal ab

    Qualitative Ergebnisse

    • +Kunden melden Störungen mit Objektbezug direkt im Portal – der Innendienst tippt keine Tickets mehr aus Telefonnotizen ab
    • +Prüfprotokolle und Wartungsnachweise stehen im Portal auf Abruf bereit – die frühere Sucherei und der Mailversand entfallen
    • +Serviceleitung disponiert Techniker über Field Service statt über Excel und Zuruf – mit mobiler Rückmeldung vom Einsatzort
    • +Vertrieb arbeitet erstmals mit strukturierter Pipeline für Neuverträge und Upselling bestehender Wartungskunden
    • +Neues Reporting: Ticketkanäle, Bearbeitungszeiten je Objekt und Portalnutzung je Kundensegment