Die Frage ist einfach. Die Antwort beschäftigt drei Personen.
Stellen wir uns einen Lieferanten vor, dessen Geschäftskunden mehrere Niederlassungen haben. Der Einkauf fragt nach dem Auftragstermin, die Buchhaltung nach einem Dokument und eine Niederlassung meldet eine neue Lieferadresse. Alle Nachrichten erreichen denselben Betreuer, obwohl jede einen anderen Teil desselben Vorgangs betrifft.
Der Betreuer kann antworten, muss aber zuerst im System suchen und die Ausführung fragen. Der Kunde wartet nicht wegen einer schwierigen Situation, sondern weil die Information auf der anderen Seite des Telefons liegt. Das Portal soll diese Abhängigkeit auflösen und nicht die Arbeit des ganzen Teams auf den Kunden verlagern.
Was hält die Arbeit auf?
Ausgangspunkt
Daten sind vorhanden, aber unverständlich
Der interne Status „Stufe 4“ erklärt dem Kunden nicht, was mit seinem Auftrag geschieht. Rohe ERP-Daten anzuzeigen ergibt noch keine gute Betreuung.
Das Dokument erreicht die falsche Person
In einer Organisation arbeiten Einkauf, Buchhaltung und Niederlassungen. Ein gemeinsames Konto erschwert Zugriffskontrolle und die Zuordnung einer bestätigten Änderung.
Eine Nachricht ohne Zusammenhang
„Bitte die Lieferung korrigieren“ nennt weder Auftrag noch Änderungsumfang. Das Team beginnt mit Fragen, deren Antworten das Portal bereits kennen könnte.
Das Design beginnt mit den häufigsten Kundenfragen
Wir gestalten die erste Version rund um wenige Aufgaben: Auftrag prüfen, Dokument herunterladen, einen Hinweis senden und die Kontaktperson finden. Jede Ansicht erklärt, was bekannt ist, was fehlt und ob der Kunde etwas tun muss.
Die Daten stammen aus einer vereinbarten Quelle; beim Status zeigen wir den Aktualisierungszeitpunkt. Ist die Integration zeitweise nicht erreichbar, informiert das Portal offen darüber. Es macht eine alte Information nicht zur Zusage eines aktuellen Termins.
So könnte der neue Ablauf aussehen
Die richtigen Personen einladen
Ein Konto gehört einer konkreten Person und Organisation. Wir klären, wer Kollegen einladen darf und welche Aufträge, Niederlassungen und Dokumente jede Rolle sehen kann.
Die Situation in der Sprache des Kunden zeigen
Die Auftragsliste zeigt eine erkennbare Nummer, Phase, Termin und nächste Aktion. Details erklären geplante und bestätigte Termine und zeigen die Änderungshistorie.
Dokumente mit dem Vorgang verbinden
Dokumente besitzen Typ, Datum und Version. Der Kunde lädt die richtige Datei direkt beim Auftrag herunter, statt ein allgemeines Verzeichnis zu durchsuchen oder erneut den Betreuer zu fragen.
Fragen mit vollständigem Kontext weiterleiten
Eine Meldung enthält Auftrag und Thema. Die interne Warteschlange zeigt die Zuständigkeit, während der Kunde Eingangsbestätigung und weitere Antworten in einem Gesprächsverlauf sieht.
Zugriff besteht aus Geschäftsregeln, nicht nur einer Anmeldung
Zwei Nutzer desselben Portals dürfen nicht automatisch dieselben Daten sehen. Wir gestalten Grenzen zwischen Organisationen, Niederlassungen und Rollen und prüfen Berechtigungen auch auf dem Server. Neue Nutzer einzuladen und ausgeschiedenen Mitarbeitenden den Zugang zu entziehen sind vollständige Prozessschritte und keine Aufgaben außerhalb des Systems.
- Der Einkauf kann die Aufträge seiner Organisation einsehen.
- Die Buchhaltung kann Abrechnungsdokumente erhalten, ohne Lieferungen ändern zu dürfen.
- Der Kundenadministrator verwaltet Nutzer ausschließlich im vereinbarten Umfang.
Selbstbedienung darf nicht in einer Sackgasse enden
Manchmal benötigt der Kunde ein dringendes Gespräch, manchmal fehlt ein Dokument, weil der Vorgang noch nicht synchronisiert wurde. Deshalb erklärt eine leere Ansicht mögliche Ursachen und den nächsten Schritt. Benachrichtigungen betreffen wesentliche Änderungen statt jeder technischen Aktion. Am Smartphone bleiben wichtige Aufgaben ohne seitliches Scrollen breiter Tabellen zugänglich.
Beginnen wir mit einem funktionierenden Teil.
Der Einstieg kann ein Portal mit Lesezugriff für eine ausgewählte Kundengruppe sein: Aufträge, Status und Dokumente sowie ein Meldeformular. So prüfen wir Datenqualität und Verständlichkeit, bevor Auftragsänderungen, individuelle Preislisten oder eigenständige Bestellungen ermöglicht werden. Der Pilot benötigt eine unternehmensseitige Betreuung und eine vereinbarte Nutzergruppe.
Woran erkennen wir eine Verbesserung?
Dies ist ein Messplan, keine Ergebniszusage. Den Vergleichsmaßstab legen wir vor der Einführung fest.
Wiederkehrende Fragen an die Betreuung
Wir vergleichen Kontaktarten vor und nach dem Portalstart, insbesondere Statusfragen und erneute Dokumentanforderungen, und berücksichtigen die Zahl aktiver Aufträge.
Eine Aufgabe selbstständig erledigen
In Tests beobachten wir, ob Kunden ein bestimmtes Dokument finden und den Termin prüfen können. Die Zahl angelegter Konten sagt nichts über den Nutzwert aus.
Aktualität der Informationen
Wir kontrollieren Synchronisierungsverzögerungen und Abweichungen vom Quellsystem. Das ist wichtiger als ein attraktives Dashboard mit Daten, denen Nutzer nicht vertrauen können.
Fragen, die sich lohnen
Muss ein B2B-Portal ein Onlineshop sein?
Nein. Es kann bestehende Aufträge betreuen und Dokumente austauschen. Warenkorb, Zahlungen und Produktkatalog ergänzen wir, wenn sie zur Zusammenarbeit passen, nicht weil sie in B2B-Systemen üblich sind.
Müssen Kunden eine Anwendung installieren?
Das Portal kann im Browser auf Computer und Smartphone laufen. Wir prüfen konkrete mobile Aufgaben wie Lieferstatus oder Dokumentdownload. Benachrichtigungen und ein möglicher App-Modus richten sich nach den tatsächlichen Nutzerbedürfnissen.
