Kundenportale · Sechs Anti-Patterns
Sechs Muster, an denen Kundenportale zuverlässig scheitern, und was stattdessen trägt.
Kundenportale gehören zu den am häufigsten falsch dimensionierten Produkten in der Unternehmenssoftware. Sie werden zu groß geplant, zu spät gestartet, zu selten benutzt. Die folgenden sechs Muster sehen wir immer wieder. Sie sind vermeidbar, wenn man sie kennt.
Das Portal als vollständige Zweitanwendung.
Ein Portal, das alles können soll, wird nie fertig. Der erste sichtbare Nutzen liegt oft im Bruchteil des geplanten Funktionsumfangs. Wer das nicht akzeptiert, produziert ein Portal, das zwei Jahre in der Entwicklung bleibt und danach als „nicht fertig" wahrgenommen wird.
Besser: Ein Portal löst die drei häufigsten Vorgänge, und zwar besser als die aktuelle E-Mail. Alles andere wird später bei Bedarf ergänzt.
Fünf Rollen ab Tag eins.
Ein häufiger Wunsch: „Wir brauchen einen Kunden-Admin, einen Kunden-Nutzer, einen Kunden-Beobachter, einen internen Bearbeiter und einen internen Freigeber, alle mit unterschiedlichen Rechten." Der Aufwand für die Rechte-Modellierung übersteigt den Aufwand für den eigentlichen Inhalt.
Besser: eine Rolle pro Seite, klar. Weitere Rollen werden hinzugefügt, sobald ein realer Bedarf existiert, nicht auf Vorrat.
Formulare als Ersatz für Prozesse.
Ein digitales Formular macht einen unklaren Prozess nicht besser. Es macht ihn nur formal digital. Wenn nicht klar ist, wer ein Formular ausfüllt, was danach passiert und wer den Vorgang freigibt, ersetzt das Formular die E-Mail nur durch eine langsamere Variante.
Besser: Der Prozess wird zuerst geklärt. Erst danach entsteht das passende Formular. Ein Formular ist ein Endpunkt eines Prozesses, nicht sein Anfang.
Das Portal als Insel.
Ein Portal, das nicht mit dem internen System spricht, erzeugt eine zweite Datenpflege. Kundenanfragen werden im Portal erfasst und intern nochmal ins CRM übertragen. Nach sechs Wochen benutzt niemand mehr das Portal, weil die E-Mail schneller ist.
Besser: Das Portal ist ab dem ersten Release mit dem internen System gekoppelt. Wenn eine solche Kopplung technisch nicht möglich ist, ist der Start des Portals verfrüht.
Design-getriebene Nutzenverschiebung.
Wer ein Portal am Design entlang plant, priorisiert Startseite, Bilder, Farben, Login-Optik und Dashboards. Wichtig ist der operative Nutzen, meistens in unspektakulären Listen und Detailseiten. Ein Portal muss nicht schön wirken, es muss den Vorgang schneller machen.
Besser: Der Nutzen definiert das Design, nicht umgekehrt. Ein Portal darf ruhig unaufgeregt aussehen, wenn es den täglichen Ablauf spürbar verbessert.
Kein Bezug zum internen Prozess.
Ein Portal, dessen internes Gegenstück nicht existiert, wird zu einer Fassade. Der Kunde sieht Statusmeldungen, aber intern liegt der Vorgang weiter in E-Mails und Excel. Das fällt spätestens bei der ersten Reklamation auf.
Besser: Portal und internes System werden gemeinsam gedacht. Der Kunde sieht einen Ausschnitt dessen, was intern ohnehin sauber läuft, nicht eine simulierte Fassade.
Zum Thema.
- Wie klein darf ein Portal starten?
- So klein wie möglich. Drei Vorgänge, eine Rolle, klare Kopplung an das interne System. Das ist genug, wenn diese drei Vorgänge häufig und wichtig sind. Der Rest kann inkrementell entstehen.
- Wann ist ein Portal die falsche Antwort?
- Wenn die Kundenkommunikation heute überwiegend telefonisch läuft und dabei stabil funktioniert. Ein Portal löst geschriebene Prozesse. Was mündlich stabil ist, kann mündlich bleiben.
- Wie messen wir, ob ein Portal wirtschaftlich ist?
- An der Reduktion wiederkehrender Vorgänge. Wie viele E-Mails wurden ersetzt? Wie viele Statusanfragen bleiben aus? Wie viele Freigaben laufen digital ohne Rückfrage durch? Wenn diese Zahlen nicht sichtbar sinken, trägt das Portal nicht.
Fynn-Luca Schulz (Head of Product & Strategy) und Julian Stosse (Head of Engineering) verantworten die Arbeit an Taskey und an den individuellen Systemen, die Schulz & Stosse entwickelt und betreibt.