Ein neues Modul in einem bestehenden Portal
Bei einem Insurance-Tech-Dienstleister habe ich in einem dreiköpfigen Team an einem produktiven Maklerportal gearbeitet. Die Plattform unterstützte den Ablauf von der Vertragsunterschrift bis zur Antragsübermittlung an die Versicherungsgesellschaften. Über 20 Monate gehörten Architektur und Senior-Entwicklung zu meiner Verantwortung.
In diesem Umfeld entstand ein Support-Chat, von der Konzeption bis zum Produktivbetrieb in zwei Monaten. Zur Portal-Erweiterung gehörten ein eigenständiges Node.js-API-Backend neben der bestehenden TYPO3-Plattform und ein Frontend mit Vue.js. Responsive Darstellung war von Anfang an eine Anforderung. Parallel wurde die Plattform weiterentwickelt, unter anderem um zusätzliche Versicherer-Schnittstellen.
Die zwei Monate beschreiben diesen konkreten Projektverlauf. Für ein anderes Portal hängt der Aufwand davon ab, welche Funktionen benötigt werden und welche Grundlagen bereits vorhanden sind. Meine wichtigste Schlussfolgerung für ähnliche Vorhaben: Den ersten nutzbaren Ablauf und seine Grenzen früh festlegen.
Den Ablauf vor der Funktionsliste beschreiben
„Wir brauchen einen Chat“ reicht als Arbeitsauftrag kaum aus. Dahinter können sehr unterschiedliche Erwartungen stehen: eine kurze Rückfrage an den Support, eine dauerhaft nachvollziehbare Unterhaltung oder ein vollständiges System zur Bearbeitung von Servicefällen.
Für ein vergleichbares Vorhaben würde ich zuerst einen Ablauf beschreiben: Ein angemeldeter Nutzer stellt eine Frage, eine zuständige Person übernimmt sie, beide können die Unterhaltung fortsetzen und erkennen, wann sie abgeschlossen ist.
An diesem Ablauf lässt sich der erste Umfang prüfen. Benötigt man dafür bereits Dateianhänge, eine automatische Verteilung auf mehrere Teams oder die Anbindung an ein Ticketsystem? Das kann notwendig sein. Es sollte aber jeweils aus dem konkreten Arbeitsablauf folgen.
Diese Fragen sind Planungsempfehlungen für ein neues Projekt. Welche Zusatzfunktionen sinnvoll sind, entscheiden Nutzer und Support gemeinsam anhand ihrer tatsächlichen Aufgaben.
Die Grenzen zur vorhandenen Plattform klären
Ein eigener Backend-Baustein schafft zusätzliche Gestaltungsmöglichkeiten. Gleichzeitig braucht er klare Übergänge zur bestehenden Anwendung.
Vor der Umsetzung würde ich insbesondere klären, wie der Chat einen angemeldeten Nutzer erkennt, wer auf welche Unterhaltung zugreifen darf und wo der verbindliche Gesprächsverlauf liegt. Ebenso wichtig ist die Zuständigkeit für Änderungen: Wenn das Portal seine Benutzerverwaltung anpasst, wer prüft die Auswirkungen auf den Chat?
Hier lohnt sich eine kurze gemeinsame Beschreibung der Schnittstellen. Sie sollte erklären, welche Informationen übergeben werden, welche Seite sie verantwortet und wie Fehler sichtbar werden. Ein zusätzliches Backend erleichtert die Arbeit nur dann, wenn diese Verantwortlichkeiten verständlich bleiben.
Die Wahl von Node.js und Vue.js gehört zu diesem Projekt. Für eine .NET-Plattform würde ich die vorhandenen Kenntnisse und Betriebsabläufe ebenso berücksichtigen. Das Projektbeispiel ist kein Grund, einen bestimmten Stack in jede Umgebung zu übertragen.
Den Umfang begrenzen und den Kern vollständig liefern
Ein kleiner erster Funktionsumfang muss den gewählten Ablauf zuverlässig abdecken. Dafür würde ich die Abnahme an konkreten Situationen festmachen:
- Eine berechtigte Person kann eine Unterhaltung öffnen; eine unberechtigte erhält keinen Zugriff.
- Nach einem Neuladen ist der erwartete Gesprächsstand wieder verfügbar.
- Beim Senden ist erkennbar, ob eine Nachricht angenommen wurde oder ein erneuter Versuch nötig ist.
- Auf einem schmalen Bildschirm bleiben Eingabe, Verlauf und Status bedienbar.
- Außerhalb der verfügbaren Supportzeiten ist klar, welche Reaktion Nutzer erwarten können.
Diese Prüfpunkte beschreiben, was ich heute mit einem Team vereinbaren würde. Sie sind keine vollständige technische Spezifikation. Sie machen aber sichtbar, welche Entscheidungen hinter einer scheinbar einfachen Oberfläche stehen.
Gerade bei einem Chat beeinflusst eine unklare Rückmeldung unmittelbar das Verhalten: Wer nicht erkennt, ob die Nachricht angekommen ist, sendet sie möglicherweise erneut oder wechselt zum Telefon. Verständliche Zustände gehören deshalb zum Kern der Funktion.
Den Supportbetrieb mitplanen
Mit der technischen Bereitstellung beginnt die Nutzung durch das Supportteam. Vor dem Start würde ich festlegen, wer neue Gespräche beobachtet, wie eine Übergabe funktioniert und wer bei einer Störung entscheidet.
Auch der Umgang mit Gesprächsinhalten gehört in die Planung: Welche Informationen sollen Nutzer übermitteln, wer benötigt Zugriff und wie lange werden Inhalte gebraucht? Daraus entstehen Anforderungen an die Umsetzung und den Betrieb.
Für den Rollout würde ich außerdem beschreiben, wie sich die neue Funktion bei Problemen deaktivieren lässt und welcher Kontaktweg dann verfügbar bleibt. Das bestehende Portal muss seine übrigen Aufgaben weiterhin erfüllen können.
Solche Entscheidungen benötigen Zeit im Projektplan. Sie nach der Entwicklung zu treffen, verschiebt Arbeit lediglich in die Einführung.
Was sich aus dem Projekt übertragen lässt
Das Ergebnis war ein produktionsreifer Support-Chat als Erweiterung einer laufenden Plattform. Daraus lässt sich keine feste Dauer für andere Projekte ableiten. Übertragbar ist die Frage, wie ein neues Modul einen konkreten Bedarf erfüllt und sich dabei in vorhandene Abläufe einfügt.
Für deinen nächsten Erweiterungswunsch würde ich mit einer Seite beginnen: Wer nutzt die Funktion, welcher Ablauf muss vollständig funktionieren, welche Schnittstellen berührt sie und woran erkennt das Team die Betriebsbereitschaft?
Wenn diese Punkte klar sind, lässt sich der Aufwand wesentlich konkreter besprechen als anhand einer langen Wunschliste.
Ich unterstütze Unternehmen dabei, neue Funktionen in bestehende Web- und .NET-Plattformen einzuordnen und umzusetzen. In einem kostenlosen Erstgespräch können wir klären, welcher erste Umfang für dein Vorhaben sinnvoll ist.