Bewertung eines Kundenportal-Entwicklers anhand von 8 Kriterien

Ein Kunde bittet per E-Mail um eine Kopie der Rechnung, 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 Kundenportalentwicklers ist in einer solchen Situation nicht in erster Linie eine Frage des Designs oder der Programmierung. Es geht darum zu entscheiden, ob das Unternehmen einen neuen, nachhaltigen Betriebskanal aufbaut oder nur eine digitale Oberfläche vor das bestehende interne Chaos setzt.

Ein gut gestaltetes Portal kann wiederholte Anfragen reduzieren, die Kundeninformation verbessern und die interne Arbeit präziser machen. Ein schlecht vorbereitetes Portal hingegen erzeugt neue Ausnahmebehandlungen, parallele Daten und Supportbelastung. Bei der Auswahl eines Entwicklers sollte daher geprüft werden, ob der Partner versteht, wie Informationen tatsächlich zwischen Vertrieb, Kundenservice, Lager, Finanzen und dem Kunden fließen.

Warum reichen das Design und der 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, 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 entwickelt werden muss. Zuerst wird geprüft, ob der Kunde die betreffende Funktion wirklich benötigt und ob der interne Prozess klar genug ist, um digitalisiert zu werden.

Bewertung eines Kundenportalentwicklers mit 8 geschäftlichen Fragen

1. Fragt der Entwickler zuerst nach dem Prozess?

Ein Warnsignal ist, 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 müssen für den Kunden eigenständig zugänglich sein und welche internen Schritte werden durch eine im Portal eingereichte Anfrage ausgelöst?

Wenn ein Kunde beispielsweise eine Reklamation aufzeichnet, reicht es nicht aus, 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. Klärt er, woher die Daten kommen?

Der „Bestellstatus“ bedeutet oft mehrere Systeme. Laut Webshop ist die Bestellung bezahlt, laut Unternehmenssystem 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, ob eine Datenquellenkarte und ein Verantwortungsmodell erstellt werden. Welches System ist die primäre Aufzeichnung? Wie oft werden die Daten synchronisiert? Wer untersucht die Abweichung? Dies sind keine technischen Kleinigkeiten, sondern Voraussetzungen für das Kundenvertrauen.

3. Kann er den Standard vom individuellen Bedarf unterscheiden?

Nicht jeder prozessuale Wettbewerbsvorteil erfordert eine individuelle Software. Manchmal wäre die Kundenoberfläche eines bestehenden Systems ausreichend, ist aber schlecht eingestellt oder nicht mit den erforderlichen Datenquellen verbunden. In anderen Fällen rechtfertigen gerade die spezielle Preisgestaltung, der Serviceprozess oder das Partnerberechtigungssystem des Unternehmens ein eigenes Portal.

Ein guter Entwickler versucht nicht, jedes Problem mit einem einzigen Werkzeug zu lösen. 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 einzigen Benutzer. Es kann einen Einkäufer, einen Finanzkontakt, einen Standortleiter und einen externen Partner auf derselben Kundenseite geben. Nicht alle können dieselben Preise, Rechnungen, Verträge oder Servicedaten sehen.

Bei der Bewertung des Entwicklers sollte man sehen, wie er Rollen, Genehmigungsregeln und außergewöhnliche Fälle handhabt. Was passiert bei Unternehmenszusammenführungen? Wer kann einen neuen 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 verzögern sich, weil Auftraggeber und Entwickler denselben Begriff verwenden, aber etwas anderes darunter verstehen. „Bestellung ändern“ kann die Änderung der Menge, die Änderung der Lieferadresse, Stornierung, Kreditlimitprüfung oder eine Kombination davon bedeuten.

Fragen Sie, wie aus Annahmen akzeptierte Betriebsregeln werden. Verwenden sie Flussdiagramme, 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 für Übergabe, Fehlerbehebung und Betrieb?

Ein Portal wird nicht am Go-Live-Tag zu einem fertigen System. Benutzerfragen, Berechtigungsprobleme, neue Geschäftsanforderungen und externe Systemaktualisierungen treten auch später auf. Wenn keine Verantwortung, Überwachung, Protokollierung und Änderungsmanagement vorhanden sind, wird das Unternehmen bald wieder zu manuellen Überprüfungen 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 ein vertragliches, reputationsbezogenes und sogar betriebliches Problem sein.

Eine zuverlässige 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“ reicht allein nicht aus, um das Projekt zu steuern. Es lohnt sich, zu Beginn festzuhalten, welche Veränderungen erwartet werden: Soll die Anzahl der Anfragen nach Rechnungskopien sinken, die Zeit für die Abstimmung des Bestellstatus verkürzt werden, 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 Suchen verbringt, sondern komplexe Fälle lösen kann. Die Kennzahlen helfen dennoch, echte Betriebsverbesserungen von der bloßen Bereitstellung einer neuen Oberfläche für alte Probleme zu unterscheiden.

Worauf sollte man bei der Lektüre 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 verändert?

Bei Angeboten sollte man auch die Grenzen suchen. 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-Philosophie ist das Portal kein eigenständiges digitales Schaufenster, sondern Teil des Unternehmensbetriebs. Daher sollte vor der Entwicklung der Weg verfolgt werden, 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 betroffen sind, in welchen Systemen sie erscheinen und wo heute manuell Informationen weitergegeben werden müssen. Wenn dieses Bild klar ist, wird auch die Bewertung des Kundenportalentwicklers zu einer fundierteren Entscheidung.