Bewertung von Kundenportal-Entwicklern nach 8 Kriterien

Ein Kunde fordert per E-Mail eine Kopie der Rechnung an, erkundigt sich telefonisch nach dem Status seiner Bestellung, während ein anderer Kollege die zugehörigen Vertragsdaten aus Excel heraussucht. Der Kunde fragt sich: Warum kann ich das nicht alles an einem Ort sehen? Die Bewertung eines Kundenportal-Entwicklers ist in einer solchen Situation nicht primär eine Frage des Designs oder der Programmierung. Es geht darum, ob das Unternehmen einen neuen, nachhaltigen Betriebsweg aufbaut oder lediglich eine digitale Oberfläche vor das bestehende interne Chaos setzt.

Ein gut gestaltetes Portal kann wiederkehrende Anfragen reduzieren, die Kundeninformation verbessern und die interne Arbeit präziser machen. Ein schlecht vorbereitetes Portal hingegen erzeugt neue Ausnahmebehandlungen, parallele Daten und Supportbelastung. Daher sollte man bei der Wahl eines Entwicklers prüfen, ob der Partner versteht, wie Informationen tatsächlich zwischen Vertrieb, Kundenservice, Lager, Finanzen und dem Kunden fließen.

Warum reichen Designentwurf und Stundensatz nicht aus?

Bei Portalen ist die Oberfläche nur der Teil, den der Kunde sieht. Das Betriebsrisiko liegt typischerweise dahinter: Welches System ist der Dateninhaber, wann wird ein Bestellstatus aktualisiert, wer kann Rechnungen oder Verträge einsehen, und was passiert, wenn eine Integration vorübergehend nicht verfügbar ist.

Ein niedrigeres Entwicklungsangebot kann manchmal tatsächlich eine gute geschäftliche Entscheidung sein. Dann, wenn der Prozess einfach ist, nur wenige Systeme angebunden werden müssen und das Unternehmen seine Anforderungen genau kennt. Wenn das Portal jedoch Daten aus ERP, CRM, Webshop, Lagersystemen oder individuellen Aufzeichnungen anzeigen muss, können scheinbar günstige Anfänge später teure Anpassungen nach sich ziehen.

Der richtige Partner behauptet nicht, dass für jede Anfrage sofort eine Anwendung gebaut werden muss. Zuerst wird geprüft, ob der Kunde die gewünschte Funktion wirklich benötigt und ob der interne Prozess klar genug ist, um digitalisiert zu werden.

Die Bewertung eines Kundenportal-Entwicklers mit 8 geschäftlichen Fragen

1. Fragt der Entwickler zuerst nach dem Prozess?

Ein Warnsignal ist es, wenn das erste Gespräch ausschließlich über Menüpunkte, Farben und Anmeldebildschirme geht. Diese sind notwendige Details, aber nicht die Ausgangspunkte. Ein erfahrener Partner fragt: Welche Kundenanfragen sollen reduziert werden, welche Daten muss der Kunde eigenständig erreichen können, und welche internen Schritte löst eine über das Portal eingereichte Anfrage aus.

Wenn der Kunde beispielsweise eine Reklamation aufzeichnet, reicht es nicht, ein Formular zu erstellen. Es muss bekannt sein, wer den Fall erhält, welche Daten für die Untersuchung erforderlich sind, wie der Status verfolgt werden kann und in welchen Fällen eine menschliche Entscheidung erforderlich ist. Daraus ergibt sich, ob es sich um eine Portalfunktion, einen internen Workflow oder beides handelt.

2. Ermittelt er, woher die Daten kommen?

Der „Bestellstatus“ bedeutet oft mehrere Systeme. Laut Webshop ist die Bestellung bezahlt, laut Unternehmensverwaltungssystem in Bearbeitung, laut Lager wartet sie auf Kommissionierung und beim Kurierdienst wurde sie bereits übergeben. Der Entwickler muss nicht nur Daten abrufen, sondern gemeinsam bestimmen, was welcher Status für den Kunden bedeutet.

Fragen Sie nach, ob eine Datenquellenkarte und ein Verantwortungsmodell erstellt werden. Welches System ist das primäre Register? Wie oft werden die Daten synchronisiert? Wer untersucht Abweichungen? Diese sind keine technischen Kleinigkeiten, sondern Voraussetzungen für das Kundenvertrauen.

3. Kann er den Standard von der individuellen Anforderung unterscheiden?

Nicht jeder prozessuale Wettbewerbsvorteil erfordert eine individuelle Software. Es kommt vor, dass eine bestehende Kundenoberfläche eines Systems geeignet wäre, nur schlecht eingestellt ist oder nicht mit den erforderlichen Datenquellen verbunden ist. Manchmal rechtfertigt gerade die spezielle Preisgestaltung, der Serviceprozess oder das Partnerberechtigungssystem des Unternehmens ein eigenes Portal.

Ein guter Entwickler versucht nicht, ein einziges Werkzeug auf alle Probleme anzuwenden. Er erklärt klar, welche Elemente mit standardisierten Komponenten gelöst werden sollten und wo eine individuelle Entwicklung gerechtfertigt ist. Dies beeinflusst später die Änderbarkeit, die Kosten und das Betriebsrisiko.

4. Klärt er die Berechtigungen und geschäftlichen Ausnahmen?

Auf einem B2B-Kundenportal gibt es oft nicht nur einen Benutzer. Es kann ein Einkäufer, ein Finanzkontakt, ein Standortleiter und ein externer Partner auf derselben Kundenseite sein. Nicht alle können dieselben Preise, Rechnungen, Verträge oder Servicedaten sehen.

Bei der Bewertung des Entwicklers schauen Sie, wie er Rollen, Genehmigungsregeln und außergewöhnliche Fälle handhabt. Was passiert bei Unternehmenszusammenführungen? Wer kann neue Benutzer anfordern? Welche Kontrolle gibt es, wenn ein Kunde mehrere rechtliche Einheiten hat? Ein gut funktionierendes Portal ist nicht dadurch sicher, dass es ein Passwort hat, sondern dadurch, dass die Zugriffsregeln klar und überprüfbar sind.

5. Hat er eine Methode zur Validierung der Anforderungen?

Viele Projekte geraten ins Stocken, weil der Auftraggeber und der Entwickler denselben Begriff verwenden, aber etwas anderes darunter verstehen. „Bestellung ändern“ kann die Änderung der Menge, die Änderung der Lieferadresse, die Stornierung, die Kreditlimitprüfung oder eine Kombination davon bedeuten.

Fragen Sie, wie Annahmen zu akzeptierten Betriebsregeln werden. Verwenden sie Prozessdiagramme, konkrete Geschäftsfälle, Prototypen oder testbare Akzeptanzkriterien? Das Ziel ist nicht die Menge der Dokumentation, sondern dass Missverständnisse noch vor der Entwicklung aufgedeckt werden.

6. Plant er auch für die Übergabe, Fehlerbehandlung und den Betrieb?

Ein Portal wird nicht am Tag des Go-Live zu einem fertigen System. Benutzerfragen, Berechtigungsprobleme, neue Geschäftsanforderungen und externe Systemupdates kommen auch später. Ohne zugewiesene Verantwortlichkeiten, Überwachung, Protokollierung und Änderungsmanagement wird das Unternehmen bald wieder zu manuellen Kontrollen gezwungen.

Es lohnt sich, konkret nach dem Supportmodell zu fragen. Wer überwacht die Integrationsfehler? Wie erfährt das Unternehmen, wenn dem Kunden fehlerhafte Daten angezeigt werden? Gibt es ein Wiederherstellungsverfahren und eine Testumgebung für Änderungen? Geschäftskontinuität ist kein separater Service, sondern Teil der Entwicklungsentscheidung.

7. Kann er über Sicherheit mit geschäftlichen Konsequenzen sprechen?

Sicherheit erschöpft sich nicht darin, dass das System über eine verschlüsselte Verbindung läuft. Ein Kundenportal kann Geschäftsdaten verarbeiten: Bestellhistorien, Preise, Finanzdokumente, technische Dateien oder persönliche Daten. Ein unbefugter Zugriff ist nicht nur ein technischer Vorfall, sondern kann auch vertragliche, reputationsbezogene und sogar betriebliche Probleme verursachen.

Eine verlässliche Antwort ist, wenn der Entwickler über Zugriffsverwaltung, Protokollierung, Datenaufbewahrung, Backups und Aktualisierungsverantwortung spricht. Die Details hängen von der Branche und der Sensibilität der Daten ab, aber die Fragen können nicht bis zum Projektende aufgeschoben werden.

8. Kann er messbare Geschäftsergebnisse definieren?

Ein „moderneres Kundenerlebnis“ allein reicht nicht aus, um ein Projekt zu steuern. Es ist sinnvoll, zu Beginn festzulegen, welche Veränderungen erwartet werden: Soll die Anzahl der Anfragen nach Rechnungskopien sinken, die Zeit zur Abstimmung des Bestellstatus verkürzt, die Datenpräzision verbessert oder der Bestand offener Servicefälle transparenter werden.

Nicht jeder Vorteil ist sofort in Euro messbar. Es ist auch wertvoll, wenn der Kundenservicemitarbeiter den Vormittag nicht mit der Suche verbringt, sondern komplexe Fälle lösen kann. Die Kennzahlen helfen dennoch, echte betriebliche Verbesserungen von einfach neuen Oberflächen für alte Probleme zu unterscheiden.

Worauf sollte man beim Lesen von Referenzen und Angeboten achten?

Eine Referenz ist dann nützlich, wenn sie nicht nur Screenshots zeigt, sondern auch die gelöste Betriebssituation. Wie viele Systeme wurden verbunden? Welches Berechtigungsmodell war erforderlich? Wie wurden Datenqualitätsprobleme gehandhabt? Was hat sich in der Arbeit des Kundenservice oder der internen Verwaltung geändert?

Beim Angebot suchen Sie auch nach den Grenzen. Was genau gehört zur Entwicklung, was ist eine Integrationsvoraussetzung, wer stellt die Testdaten bereit und was gilt als spätere Änderung? Ein vages Angebot mag kurzfristig bequem erscheinen, führt aber später zu Streitigkeiten über Verantwortung und Kosten.

In der CGAT-Perspektive ist das Portal kein eigenständiges digitales Schaufenster, sondern Teil des Unternehmensbetriebs. Daher lohnt es sich, vor der Entwicklung den Weg zu verfolgen, den eine Kundenanfrage und die dazugehörigen Daten tatsächlich zurücklegen.

Der beste nächste Schritt ist oft nicht die Anforderung eines Entwicklerangebots, sondern die Auswahl von fünf bis zehn häufigen Kundenanfragen. Schauen Sie, wo sie beginnen, wie viele Personen beteiligt sind, in welchen Systemen sie erscheinen und wo heute manuell Informationen weitergegeben werden müssen. Wenn dieses Bild klar ist, wird die Bewertung des Kundenportal-Entwicklers zu einer fundierteren Entscheidung.