Kundenportale in der Praxis: Was sich an der Zusammenarbeit wirklich ändert

Der Großteil der Individualsoftware, die ich für Kunden baue, ist unspektakulär. Das über sehr unterschiedliche Unternehmen hinweg zuverlässig Nützlichste hat sich als das Langweiligste herausgestellt: den Kunden einen Login zu geben.

Keine Plattform. Einen Login und vier Bildschirme dahinter.

Das habe ich darüber gelernt, was sich dabei wirklich ändert — einschließlich der Teile, die mich überrascht haben, und der Teile, die ich falsch gemacht habe.

Was sich ändert, ist nicht die Arbeitsmenge

Früher habe ich diese Projekte über gesparte Zeit verkauft. Dieser Rahmen ist falsch, und Kunden, die deshalb kaufen, sind häufig enttäuscht.

Die Anfragen, die ein Portal aufsaugt, sind einzeln winzig. „Wo ist meine Bestellung." „Könnt ihr die Rechnung noch mal schicken." „Was hatten wir zum Liefertermin vereinbart." Jede kostet neunzig Sekunden. Wenn man sie zählt und multipliziert, kommt eine Zahl heraus, die neben den Baukosten wenig beeindruckend aussieht.

Was sich tatsächlich ändert, ist wann die Arbeit passiert.

Vorher: zwölf Unterbrechungen über den Tag verteilt, jede mitten in etwas anderem, jede mit Wiedereinstiegskosten auf beiden Seiten. Nachher: Dieselbe Information holt sich der Kunde sonntags um 22:40 — und niemandem wird der Dienstagvormittag zerlegt.

Das ist ein echter Produktivitätsgewinn, und er taucht in keiner Tabelle mit gesparten Minuten auf. Er zeigt sich darin, dass die Person, die vorher den ganzen Tag reaktiv war, sich wieder einen Vormittag einteilen kann.

Der Effekt zweiter Ordnung, den niemand vorhersieht

Den hier habe ich nicht kommen sehen: Das Portal verändert, was das Team des Kunden selbst weiß.

Um einem Kunden einen korrekten Status zu zeigen, muss jemand definieren, welche Status es überhaupt gibt. Das klingt trivial. Ist es nicht. In den meisten kleinen Unternehmen wird „wo ist diese Bestellung" von einem Menschen beantwortet, der die Antwort aus Erinnerung, drei Systemen und einem Bauchgefühl rekonstruiert. Es gibt keinen kanonischen Status, weil ihn nie jemand aufschreiben musste.

Der Portalbau erzwingt diese Definition. Und sobald die Status existieren und gepflegt werden, hat das Unternehmen fast nebenbei die operative Transparenz, von der es seit Jahren gesprochen hat. Mehr als ein Kunde hat aus der eigenen internen Sicht auf die Statusdaten mehr Nutzen gezogen als aus dem kundenseitigen Teil.

Wer so etwas erwägt: Das ist heute mein Hauptargument. Nicht „deine Kunden bedienen sich selbst", sondern „du weißt endlich, wo alles steht".

Die vier Bildschirme

Jedes Portal, das ich gebaut habe und das funktioniert hat, enthält diese — und die, die sich schwertaten, enthielten mehr:

1. Status. Wo die Sache steht, in einer Sprache, die Kunden verstehen. Nicht „WIP" — was passiert ist, wann, und was als Nächstes kommt.
2. Dokumente. Rechnungen, Verträge, Lieferscheine, Berichte. Reines Abrufen, null Ermessen — und es erledigt still eine ganze Kategorie von E-Mails.
3. Historie. Was früher bestellt, vereinbart oder geliefert wurde. Wird seltener genutzt als der Rest, beseitigt aber die schlimmste Aufgabe — jemanden, der sich für eine Antwort durch ein Jahr E-Mails gräbt.
4. Eine Aktion. Nachbestellen, freigeben, Datei hochladen. Genau eine, ausgewählt, weil es das ist, was der Kunde am häufigsten als Nächstes tun will.

Alles darüber hinaus ist in Version eins eine Wette, die du nicht bewerten kannst, weil dir die Nutzungsdaten fehlen. Liefere vier Bildschirme, beobachte einen Monat, ergänze dann, wonach die Leute tatsächlich greifen.

Drei Dinge, die ich falsch gemacht habe

Passwörter. Mein erstes Portal hatte einen normalen Login mit E-Mail, Passwort und Reset-Flow. Die Nutzung war miserabel. B2B-Kunden loggen sich höchstens alle paar Wochen ein, das Passwort sitzt also weder im Muskelgedächtnis noch im Browser — was heißt, dass jeder einzelne Besuch mit einer Reset-Mail beginnt. Magic Links haben das mehr verbessert als jede andere Änderung. Wer sich selten einloggt, soll sich nichts merken müssen.

Status, die ehrlich, aber nutzlos waren. Ich habe einmal die Portalstatus direkt auf die internen Produktionszustände abgebildet, weil das die korrekte Variante war. Kunden sahen „Stufe 3" und riefen an, um zu fragen, was Stufe 3 bedeutet. Korrekt und nutzlos. Der kundenseitige Status braucht ein eigenes Vokabular, geschrieben für jemanden, der nicht dort arbeitet — und er muss sagen, was als Nächstes passiert, denn das ist die eigentliche Frage hinter „wo ist meine Bestellung".

Die Annahme, Ankündigung sei Adoption. Wir haben eines per E-Mail gestartet. Zwei Wochen später hatte sich fast niemand eingeloggt, und der Schluss im Raum war, die Kunden wollten es nicht. Sie wollten es — sie hatten vergessen, dass es existiert. Geholfen hat etwas Prosaisches: Der Link kam in jede transaktionale E-Mail und jede Signatur, und zwei Monate lang beantwortete das Team Routinefragen mit „ich habe es gerade im Portal aktualisiert, hier ist der Link". Adoption ist eine Gewohnheit, die man antrainiert, kein Feature, das man ausliefert.

Wann ich davon abrate

Drei Situationen, in denen ich Nein gesagt habe — oder hätte sagen sollen:

• Die Daten existieren noch nicht. Wenn der Bestellstatus in jemandes Kopf lebt, kann das Portal ihn nicht zeigen. Das ist zuerst ein Systemprojekt; etwas anderes zu behaupten liefert ein Portal mit veralteten Informationen, das in einem Monat das Vertrauen zerstört.
• Kunden kaufen einmal im Jahr. Portale zahlen sich über Wiederholung aus. Ein Einmal-im-Jahr-Kunde schreibt dir ohnehin eine E-Mail, weil das für ihn wirklich einfacher ist — und er hat recht.
• Niemand verantwortet die Aktualität. Der Fehlerfall nach achtzehn Monaten ist nicht, dass das Portal kaputtgeht. Es ist, dass es still veraltet, Kunden auf falscher Grundlage handeln und es schlechter wird als gar nichts.

Was ich einem Unternehmer sagen würde

Mach zuerst die Zählübung. Notiere eine Woche lang jede eingehende Frage, die du hättest beantworten können, indem du auf einen Bildschirm zeigst. Sind es unter zehn pro Woche, baue kein Portal — schreib bessere E-Mail-Vorlagen und mach weiter. Sind es dreißig, hast du einen Business Case, und er ist stärker, als die Minuten nahelegen, weil du nicht Zeit, sondern Zersplitterung entfernst.

Und begrenze den Umfang auf vier Bildschirme. Jedes Portal, das ich scheitern sah, meines eingeschlossen, ist daran gescheitert, dass es früh ehrgeizig war statt früh nützlich.