Kundenportal oder Buchungssystem: Welches Problem soll eigentlich verschwinden?

„Wir bräuchten so ein Kundenportal – oder erst mal ein Buchungssystem.” Beides wird gern als dieselbe Anschaffung behandelt, und beides klingt nach demselben Ziel: weniger Telefon, weniger E-Mail, mehr Selbstbedienung.

Tatsächlich lösen die beiden unterschiedliche Probleme. Wer sie verwechselt, baut die falsche Lösung sauber und wundert sich, dass die Anrufe bleiben.

Ein Buchungssystem beendet Terminabstimmung, ein Portal beendet Statusanfragen

Ein Buchungssystem wirkt vor dem Termin. Es ersetzt das Hin und Her, das entsteht, bevor überhaupt etwas stattfindet: „Wann passt es Ihnen?”, „Da bin ich leider unterwegs”, „Und Donnerstag?”. Der Kunde sieht verfügbare Zeiten, wählt eine, bekommt eine Bestätigung, und der Termin steht im richtigen Kalender. Die Zielgruppe sind auch Menschen, die noch keine Kunden sind.

Ein Kundenportal wirkt nach dem Auftrag. Es richtet sich an Menschen, die bereits Kunde sind, und beantwortet Fragen, die sonst per Anruf kommen: Wie weit ist mein Auftrag? Wo finde ich die Rechnung von März? Wohin schicke ich die fehlenden Unterlagen? Was habe ich letztes Jahr bestellt?

Daraus folgt eine einfache Prüfung. Zählen Sie zwei Wochen lang mit, welche Anrufe und E-Mails tatsächlich eingehen:

• Überwiegen Fragen nach Terminen, brauchen Sie ein Buchungssystem.
• Überwiegen Fragen nach Status, Unterlagen und Historie, brauchen Sie ein Portal.
• Überwiegen Fragen, die es ohne einen unklaren internen Ablauf gar nicht gäbe, brauchen Sie zuerst weder das eine noch das andere.

Der dritte Fall wird beim Vergleich von Produkten leicht übersehen. Wenn Ihre Mitarbeiter den Auftragsstatus selbst nur mit Rückfrage ermitteln können, kann ein Portal ihn dem Kunden auch nicht anzeigen. Ein Portal macht Informationen zugänglich; es erzeugt sie nicht.

Nebeneinandergestellt sieht der Unterschied so aus:

Wer beides gleichzeitig will, sollte die Tabelle von unten nach oben lesen: Die Pflichten der rechten Spalte entstehen mit der Anmeldung, nicht mit dem Funktionsumfang.

Für viele Betriebe ist ein fertiges Buchungsprodukt genau richtig

Wenn Ihre Terminlogik sich in wenigen Sätzen beschreiben lässt, ist ein Standardprodukt fast immer die wirtschaftlichere Wahl – und Sie brauchen für diesen Schritt keinen Dienstleister, der etwas entwickelt.

Typische Merkmale, bei denen ein fertiges Produkt genügt:

• eine überschaubare Zahl von Leistungen mit festen Dauern
• eine oder wenige Personen beziehungsweise Ressourcen, die gebucht werden
• Öffnungszeiten und Pausen als einzige Einschränkung
• ein Standort
• Bestätigung und Erinnerung per E-Mail reichen aus
• die Anbindung an den vorhandenen Kalender ist im Produkt enthalten

Dass dabei ein monatlicher Betrag anfällt, ist kein Argument dagegen. Der Vergleichsmaßstab ist nicht „kostenlos”, sondern die Arbeitszeit, die heute in die Terminabstimmung fließt.

Ein Standardprodukt stößt an seine Grenzen, wenn die Regeln komplexer werden als die Oberfläche des Produkts:

• Kombinierte Ressourcen. Ein Termin braucht gleichzeitig eine bestimmte Qualifikation, einen bestimmten Raum und ein bestimmtes Gerät.
• Fahrzeiten und Gebiete. Zwischen zwei Vor-Ort-Terminen muss ein Puffer liegen, der von der Entfernung abhängt.
• Vorlauf- und Nachlaufzeiten je Leistung. Vorbereitung, Reinigung, Rüstzeit.
• Vorabprüfung. Bestimmte Termine dürfen erst nach einer inhaltlichen Prüfung bestätigt werden, nicht automatisch.
• Übergabe in nachgelagerte Systeme. Die Buchung soll nicht nur im Kalender landen, sondern einen Vorgang in der Auftragsbearbeitung oder im CRM auslösen.
• Umbuchung und Stornierung nach eigenen Regeln, die dieselbe Prüfung durchlaufen müssen wie die ursprüngliche Buchung.

Erst an dieser Stelle wird eine eigene Buchungslogik zum Thema – und auch dann selten als komplette Neuentwicklung. Oft genügt es, das Standardprodukt zu behalten und nur die Übergabe in die internen Abläufe zu ergänzen. Wie wir Buchungs- und Anfrageprozesse mit den nachgelagerten Systemen verbinden, beschreibt die Seite zu Websites, Buchungsprozessen und Portalen.

Ein Portal rechnet sich, wenn dieselbe Frage jede Woche neu gestellt wird

Ein Kundenportal ist teurer als ein Buchungswerkzeug – in der Einführung und im Betrieb. Es lohnt sich, wenn mehrere der folgenden Punkte zutreffen:

• Sie haben wiederkehrende Kunden, keine Einmalkäufer. Wer einmal etwas bestellt und nie wieder auftaucht, legt kein Konto an.
• Es werden regelmäßig Unterlagen in beide Richtungen ausgetauscht. Nachweise, Pläne, Freigaben, Prüfberichte, Rechnungen. Der Dokumentenaustausch per E-Mail ist der teuerste Teil, weil er nie auffindbar ist, wenn man ihn braucht.
• Statusfragen kosten messbar Zeit. Nicht gefühlt, sondern gezählt.
• Kunden brauchen ihre eigene Historie. Frühere Aufträge, Konfigurationen, Verträge, Wartungstermine.
• Es gibt mehrere Ansprechpartner auf Kundenseite, die unterschiedliche Dinge sehen dürfen.

Genauso wichtig sind die Gegenanzeigen:

• Ein Portal ohne Inhalt bleibt leer. Wenn im Portal nichts steht, was nicht auch in einer E-Mail stünde, meldet sich niemand an. Die Nutzung entsteht nur, wenn es dort etwas gibt, das es woanders nicht gibt.
• Ein Portal ersetzt keinen Prozess. Wenn der Status intern nicht gepflegt wird, zeigt das Portal veraltete Informationen an – und erzeugt genau die Anrufe, die es abschaffen sollte.
• Ein Portal ist dauerhaft zu betreiben. Anmeldung, Rechte, Aktualisierungen, Ausfälle und Rückfragen von Nutzern gehören ab dem ersten Tag dazu.
• Wenige Kunden mit hoher Betreuung profitieren oft nicht. Wenn Sie zwölf Großkunden persönlich betreuen, ist ein geteilter Ordner mit klarer Struktur womöglich die bessere Antwort.

Wenn ein Portal fachlich begründet ist, ist der Umfang die nächste Entscheidung – und in aller Regel deutlich kleiner als der erste Wunschzettel. Wie sich Rollen, Rechte, Datenhaltung und Anbindung an vorhandene Systeme planen lassen, beschreibt die Seite zu individueller Softwareentwicklung.

Hinter der Anmeldung gelten andere Pflichten

Solange Ihre Website nur Informationen zeigt und ein Kontaktformular anbietet, ist die datenschutzrechtliche Lage vergleichsweise überschaubar. Sobald personenbezogene Daten hinter einer Anmeldung dauerhaft vorgehalten werden, kommen Pflichten hinzu, die vor dem Projektstart bekannt sein sollten – nicht danach.

Zugriffskontrolle ist mehr als ein Passwortfeld. Der IT-Grundschutz des BSI verlangt im Baustein APP.3.1, dass sich Clients gegenüber einer Webanwendung authentisieren müssen, wenn sie auf geschützte Ressourcen zugreifen, und dass geeignete Grenzwerte für fehlgeschlagene Anmeldeversuche festgelegt werden. Zugangsdaten müssen serverseitig mit sicheren kryptografischen Verfahren geschützt werden; der Baustein nennt dafür ausdrücklich Salted-Hash-Verfahren. Für Upload-Funktionen – also für jeden Dokumentenaustausch – fordert derselbe Baustein, erlaubte Dateigröße, Dateitypen und Speicherorte festzulegen und einzuschränken.

Der entscheidende Punkt wird dabei häufig übersehen: Die Anmeldung klärt nur, wer jemand ist. Sie klärt nicht, was diese Person sehen darf. Jeder einzelne Abruf eines Dokuments oder eines Vorgangs muss serverseitig gegen die Berechtigung des angemeldeten Nutzers geprüft werden. Wer nur die Anmeldung prüft und danach der Objektnummer aus der Adresszeile vertraut, hat ein Portal gebaut, in dem jeder Kunde die Unterlagen jedes anderen Kunden abrufen kann.

Berechtigungen brauchen einen Lebenszyklus. Der Baustein ORP.4 des IT-Grundschutzes verlangt unter anderem, dass geregelt wird, wie Benutzerkennungen eingerichtet und gelöscht werden, dass jede Kennung eindeutig einer Person zugeordnet werden kann, dass Berechtigungen nur nach tatsächlichem Bedarf vergeben und bei personellen Veränderungen wieder entzogen werden, und dass die vergebenen Kennungen und Rechteprofile dokumentiert und regelmäßig überprüft werden. Übertragen auf ein Kundenportal heißt das: Was passiert mit dem Zugang, wenn der Ansprechpartner beim Kunden wechselt oder das Vertragsverhältnis endet?

Ein Löschkonzept ist keine Kür. Der Grundsatz der Speicherbegrenzung nach Art. 5 Abs. 1 lit. e DSGVO bedeutet, dass personenbezogene Daten nur so lange in identifizierbarer Form gespeichert werden dürfen, wie es für den Zweck erforderlich ist. Das Standard-Datenschutzmodell der deutschen Datenschutzaufsichtsbehörden nennt als Maßnahme dazu ausdrücklich die „Festlegung und Umsetzung eines Löschkonzepts”. Hinzu kommt das Recht auf Löschung nach Art. 17 Abs. 1 DSGVO. Praktisch sind das Fragen, die in der Datenmodellierung entschieden werden müssen und nicht im Nachhinein: Wie lange bleiben Dokumente im Portal? Was passiert mit dem Konto nach Vertragsende? Und wie werden Daten aus Sicherungskopien behandelt?

Das Verzeichnis von Verarbeitungstätigkeiten betrifft auch kleine Unternehmen. Die vielzitierte Ausnahme für Stellen unter 250 Beschäftigten ist enger, als ihre Kurzfassung vermuten lässt. Die Datenschutzkonferenz – das Gremium der deutschen Datenschutzaufsichtsbehörden – formuliert es so: Unternehmen und Einrichtungen mit weniger als 250 Mitarbeitern müssen kein Verzeichnis führen, „es sei denn, der Verantwortliche bzw. Auftragsverarbeiter führt Verarbeitungen personenbezogener Daten durch”, die ein Risiko für die Rechte und Freiheiten der betroffenen Personen bergen, „die nicht nur gelegentlich erfolgen (z.B. die regelmäßige Verarbeitung von Kunden- oder Beschäftigtendaten)” oder die besondere Datenkategorien betreffen. Ein Kundenportal ist der Sache nach eine regelmäßige Verarbeitung von Kundendaten. Die Aufsichtsbehörden halten in demselben Papier fest, dass „vielfach das Erstellen eines Verzeichnisses von Verarbeitungstätigkeiten geboten sein” wird.

Dienstleister und Auftragsverarbeitung. Hosting, Versand von Benachrichtigungen, Dokumentenspeicher, Buchungsprodukt: Wo Dritte personenbezogene Daten in Ihrem Auftrag verarbeiten, sind entsprechende Verträge und die Prüfung der Dienstleister Teil der Aufgabe, nicht eine Formalie am Schluss.

Nicht jeder Cookie braucht ein Banner – aber die Unterscheidung muss stimmen. Nach § 25 Abs. 1 TDDDG ist das Speichern von Informationen auf dem Endgerät oder der Zugriff darauf grundsätzlich einwilligungsbedürftig. Absatz 2 nimmt davon aus, was „unbedingt erforderlich ist, damit der Anbieter eines digitalen Dienstes einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann”. Der Cookie, der eine Anmeldung während der Sitzung aufrechterhält, fällt typischerweise unter diese Ausnahme. Reichweitenmessung und Komfortfunktionen tun das nicht.

Eine Abgrenzung gehört dazu: TakFlow setzt technische und organisatorische Maßnahmen um und dokumentiert sie. Die datenschutzrechtliche Bewertung Ihres konkreten Portals – Rechtsgrundlagen, Fristen, Verträge, gegebenenfalls eine Datenschutz-Folgenabschätzung – gehört zu Ihrer Datenschutz- und Rechtsberatung. Eine Zusicherung der DSGVO-Konformität ist keine Leistung, die ein Entwicklungsdienstleister seriös geben kann.

Ein realistischer Weg: Formular, Buchungswerkzeug, Portal

Die drei Stufen bauen aufeinander auf. Jede hat ein Kriterium, das erfüllt sein muss, bevor die nächste sinnvoll wird.

Stufe 1 – Das Formular, das tatsächlich übergibt

Ein Anfrage- oder Terminformular, das die Angaben strukturiert erfasst, Pflichtfelder prüft und den Vorgang nicht als formlose E-Mail im Postfach ablegt, sondern strukturiert weitergibt. Das ist die günstigste Stufe und beseitigt bereits die häufigste Ursache für Rückfragen: unvollständige Erstangaben.

Weiter zur nächsten Stufe, wenn die Anfragen vollständig ankommen und der verbleibende Aufwand vor allem in der Terminfindung steckt.

Stufe 2 – Das Buchungswerkzeug

Ein Standardprodukt, an den vorhandenen Kalender angebunden, mit Bestätigung und Erinnerung. Messen Sie danach zwei Dinge: Wie viele Termine werden tatsächlich selbst gebucht, und welche Fälle fallen aus dem Raster?

Weiter zur nächsten Stufe, wenn die Terminfrage weitgehend erledigt ist und der verbleibende Aufwand aus Status-, Unterlagen- und Historienfragen besteht.

Stufe 3 – Das Portal in kleinstmöglichem Zuschnitt

Nicht alle Funktionen für alle Kundengruppen, sondern eine Kundengruppe und die zwei Dinge, die dort am häufigsten gefragt werden – meist Status und Dokumente. Dazu von Anfang an: Rollen, Rechteprüfung je Vorgang, Protokollierung, Löschfristen.

Beurteilen Sie den Erfolg an der Nutzung, nicht am Funktionsumfang. Wenn die eingeladenen Kunden das Portal nach zwei Monaten nicht verwenden, ist die Antwort selten „es fehlen Funktionen”. Meist fehlt ein Grund, sich anzumelden.

Diese Reihenfolge ist eine Empfehlung, keine Regel. Wenn der Dokumentenaustausch das eigentliche Problem ist und Termine gar keine Rolle spielen, ist Stufe 2 überflüssig.

Was auf jeder Stufe gleich bleibt: Die Daten müssen bei Ihnen bleiben

Unabhängig davon, welche Stufe Sie erreichen, gelten dieselben Fragen an jedes eingesetzte Produkt:

• Können Sie Kunden, Termine und Dokumente vollständig exportieren – einschließlich der Anhänge?
• Ist das Exportformat dokumentiert, oder erhalten Sie eine Datei, die nur das Produkt selbst wieder lesen kann?
• Wo werden die Daten gespeichert, und wer hat als Dienstleister Zugriff?
• Was passiert mit den Daten nach einer Kündigung, und wie lange bleiben sie abrufbar?
• Bleibt die verbindliche Kundenakte in Ihrem führenden System, oder entsteht im Buchungsprodukt schleichend eine zweite, konkurrierende Kundendatenbank?

Der letzte Punkt ist der, der später am meisten Arbeit macht. Ein Buchungsprodukt legt für jeden Buchenden einen Datensatz an. Wenn diese Datensätze nirgends mit Ihrer bestehenden Kundenverwaltung zusammengeführt werden, haben Sie nach zwei Jahren zwei Kundenbestände mit unterschiedlichen Adressen – und ein Portal, das auf dem falschen aufsetzt.

Die richtige Antwort ist manchmal, nichts entwickeln zu lassen

Ein Buchungssystem und ein Kundenportal sind keine Ausbaustufen desselben Produkts. Sie beantworten unterschiedliche Fragen, sie richten sich an unterschiedliche Personen, und sie haben unterschiedliche Betriebskosten.

Für viele Betriebe ist die wirtschaftlich beste Entscheidung ein fertiges Buchungsprodukt, ein gut gebautes Formular und die saubere Übergabe der Daten in die internen Abläufe. Ein Portal lohnt sich dort, wo dieselben Menschen regelmäßig wiederkommen, Unterlagen austauschen und Auskunft über laufende Vorgänge brauchen. Wo das nicht der Fall ist, entsteht ein geschützter Bereich, den niemand betritt – mit allen Pflichten, die eine Anmeldung mit sich bringt, und ohne den Nutzen, der sie rechtfertigen würde.

Handlungsaufruf

Wissen Sie, welche Fragen Ihre Kunden am häufigsten stellen? TakFlow ordnet die tatsächlich eingehenden Anfragen den passenden Stufen zu und benennt, was ein Standardprodukt abdeckt und was nicht. Das Ergebnis darf auch lauten, dass für Ihren Fall ein fertiges Buchungswerkzeug genügt.

Kundenprozess besprechen

Weiterführend: Websites, Buchungsprozesse und Kundenportale · Website-Relaunch oder gezielte Reparatur · Standardsoftware, Open Source oder individuelles Tool

Quellenhinweise

• BSI: IT-Grundschutz-Bausteine, Edition 2023 – Bausteine APP.3.1 Webanwendungen und Webservices sowie ORP.4 Identitäts- und Berechtigungsmanagement
• Datenschutzkonferenz: Kurzpapier Nr. 1 „Verzeichnis von Verarbeitungstätigkeiten – Art. 30 DS-GVO”, Stand 17.12.2018 – Ausnahme für Stellen unter 250 Beschäftigten und ihre Grenzen
• Datenschutzkonferenz: Das Standard-Datenschutzmodell (SDM), Version 3.1, beschlossen am 14. Mai 2024 – Speicherbegrenzung, Löschkonzept, Löschbarkeit von Daten
• § 25 TDDDG (Telekommunikation-Digitale-Dienste-Datenschutz-Gesetz) – Einwilligung und Ausnahme für unbedingt erforderliche Informationen auf dem Endgerät
• Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), EUR-Lex – Art. 5 Abs. 1 lit. e, Art. 17 Abs. 1, Art. 28, Art. 30