Wie wir mit KI eine eigene Kundenportal-Software gebaut haben
Wer Kundenaufträge betreut, kennt die Abstimmung zwischen Bestellung und Umsetzung: Unterlagen verschicken, Rückfragen beantworten, Änderungen besprechen und auf eine Freigabe warten. Bei wenigen Aufträgen funktioniert das per E-Mail und Telefon. Laufen immer mehr Projekte parallel, wird das Nachhalten zur eigenen Aufgabe. Welche Rückmeldung fehlt noch? Auf welche Fassung bezieht sich die Antwort? Und kann das Team jetzt weiterarbeiten?
Ein eigenes Kundenportal könnte diese Abstimmung deutlich einfacher machen. Bisher stand dafür meist eine größere Entscheidung an: passende Software suchen, Funktionen und Tarife vergleichen oder eine individuelle Entwicklung beauftragen. Wir wollten ausprobieren, wie weit wir heute mit KI kommen. Wie schnell lässt sich ein Portal bauen, das einen solchen Ablauf tatsächlich abbildet?
Dafür haben wir mit vector zero Build einen Kundenportal-Prototyp entwickelt. Als Beispiel dient ein technischer Betrieb, der mit seinem Kunden die Ausführung eines Bauteils abstimmt. Wir haben den Weg von der vorgeschlagenen Auswahl über Rückfragen bis zur Bestätigung umgesetzt. Hier zeigen wir, was dabei entstanden ist, was wir während der Entwicklung ändern mussten und wie daraus eine Anwendung für den täglichen Einsatz werden könnte.
Was wir gebaut haben
Aus diesem Ablauf haben wir im Codex-Chat eine kleine Webanwendung gebaut. Die KI schrieb den Code für die Ansichten und die Aktionen dazwischen. Dadurch konnten wir die Abstimmung im Browser ausprobieren und anschließend ihre fachlichen Regeln überarbeiten.
Bei mehreren Aufträgen muss der Kunde zunächst erkennen können, wo er noch gebraucht wird. Deshalb zeigt unsere Übersicht neben dem Status auch den nächsten Schritt: eine Unterlage ergänzen, eine Rückfrage beantworten oder einen Vorschlag prüfen. Bei bereits bestätigten Aufträgen ist dagegen kein Handlungsbedarf ausgewiesen. Im Prototyp haben wir einen dieser Aufträge vollständig ausgearbeitet.
Den Vorschlag dort besprechen, wo er zu sehen ist
In unserem Beispiel soll der Kunde die Auswahl eines Gehäuses bestätigen. Dazu braucht er den konkreten Vorschlag: Welches Gehäuse ist vorgesehen, welche Oberfläche soll es haben und wird es zusätzlich bearbeitet? Wir haben diese Angaben in einem Prüfblatt zusammengeführt. Die Rückfrage des Betriebs steht direkt bei der Auswahl, damit der Kunde beim Antworten dieselben Informationen vor sich hat.
Den technischen Inhalt mussten wir während der Entwicklung korrigieren: Im ersten Entwurf passten Darstellung und Änderungsbeschreibung noch nicht zusammen. Wir haben das Beispiel deshalb auf die Auswahl eines konkreten Gehäuses umgestellt und die Maßübersicht aus der Herstellerzeichnung von Hammond abgeleitet. Sie beschreibt das ausgewählte Gehäuse; eine eigene Fertigungszeichnung haben wir damit nicht erstellt. So lässt sich eindeutig benennen, worüber Betrieb und Kunde gerade sprechen.
Mit dem Prüfblatt war klar, was der Kunde beurteilen soll. Für seine Entscheidung mussten wir außerdem festlegen, wie das Portal mit Änderungen umgeht. Eine Zustimmung zum bisherigen Vorschlag darf nicht automatisch für eine andere Auswahl gelten. Deshalb haben wir Antworten und Bestätigungen an den jeweiligen Auswahlstand gebunden.
Wenn der Betrieb einen geänderten Vorschlag vorlegt, ist wieder eine Kundenbestätigung erforderlich. Die frühere Entscheidung bleibt beim alten Stand sichtbar, einschließlich Person und Zeitpunkt. Diesen Wechsel kann man im Prototyp simulieren. Wir haben die Zuordnung mit KI im selben Codex-Chat angepasst und anschließend im Browser geprüft.
Auch die Bedeutung der Bestätigung haben wir eingegrenzt: Der Kunde erklärt sich mit der dargestellten Auswahl einverstanden. Die interne technische Prüfung und die Fertigungsfreigabe bleiben eigene Schritte. Der Hinweis steht unmittelbar bei der Entscheidung, damit der Betrieb eine Kundenzusage nicht mit dem Abschluss seiner eigenen Prüfung verwechselt.
Vom Prototyp zur eigenen Anwendung
Die Kundenseite dieses Abstimmungsprozesses ist damit abgebildet. Für den Betrieb wäre als Nächstes der Blick über alle ausstehenden Entscheidungen interessant: Welche Rückmeldungen fehlen und bei welchen Aufträgen wird es zeitlich eng? Eine interne Arbeitsliste könnte offene Kundenentscheidungen bündeln und nach einer vereinbarten Frist hervorheben. Sie wäre eine Erweiterung des vorhandenen Ablaufs; gebaut haben wir sie noch nicht.
Für den täglichen Einsatz müssten außerdem dauerhafte Speicherung und echte Zugriffsrechte hinzukommen. Der nächste Entwicklungsschritt wäre also, den Prototyp zu einer ersten nutzbaren Version für den konkreten Betrieb auszubauen und mit dessen Team zu erproben.
An diesem Punkt setzt vector zero Build an. Wenn Sie ein eigenes Kundenportal entwickeln lassen möchten, bauen wir die erste Version, richten die Entwicklungsumgebung ein und übergeben Code, Zugänge und Dokumentation. In der Schulung lernt Ihr Team am eigenen Projekt, mit KI Funktionen zu ergänzen, Änderungen zu prüfen und zu veröffentlichen. Eine zusätzliche Arbeitsliste wie in unserem Beispiel kann so Teil der eigenen Weiterentwicklung werden. Bei Bedarf unterstützen wir dabei.
Eigene Software statt SaaS. Make statt Buy.