Ein neuer Kunde öffnet deine Anwendung, folgt der Anleitung und bleibt bei „Datenquelle verbinden“ hängen. Die Anleitung erklärt die Schritte. Sie kann ihm nicht sagen, ob die Verbindung geklappt hat, ob der Import noch läuft oder ob er gerade im falschen Workspace arbeitet.
Das ist eine sinnvolle Aufgabe für einen SaaS-Onboarding-Chatbot. Er verbindet eine gepflegte Erklärung mit einem kleinen, freigegebenen Ausschnitt des tatsächlichen Einrichtungsstands und hilft beim nächsten Schritt.
Ich würde mit einem Ablauf beginnen, dessen Fortschritt sich prüfen lässt: eine Datenquelle verbinden und den ersten Import abschließen. Eine konkrete Blockade lässt sich leichter verbessern als die gesamte Anwendung auf einmal.
Ein Ziel wählen, das eure Anwendung überprüfen kann
„Der Kunde ist fertig mit dem Onboarding“ ist oft zu ungenau. „Der Workspace hat eine verbundene Datenquelle und einen erfolgreich verarbeiteten Import“ ist wesentlich greifbarer.
Schreib die Zustände auf, die zu diesem Ziel führen. Noch keine Quelle verbunden. Verbindung wartet auf Prüfung. Import eingereiht. Import läuft. Import abgeschlossen. Import mit einer für Kunden verständlichen Fehlerkategorie gescheitert. Zu jedem Zustand gehört ein erlaubter nächster Schritt.
Diese Zustände werden von der Anwendung bestimmt. Der Assistent liest sie und erklärt den passenden Schritt. Ein freundliches Gespräch, ein gelesener Hilfeartikel oder „Ich glaube, es hat geklappt“ darf einen Import nicht auf erfolgreich setzen.
Was eine Onboarding-Fallstudie tatsächlich belegt
In der veröffentlichten trumpet-Kundenstory von Intercom werden Produkttouren, Nachrichtenfolgen, Hilfeartikel und Anwendungsdaten für das Onboarding kombiniert. Der Case zeigt, wie Fortschrittsinformationen die Hilfestellung relevanter machen. Fin wird dort als zukünftige Erkundung beschrieben. Die Ergebnisse lassen sich deshalb keinem bereits eingesetzten KI-Chatbot zuschreiben. Es ist ein externes Beispiel, kein Projekt mit meinem Plugin.
Für einen KI-Assistenten ist der übertragbare Ausgangspunkt derselbe: Erst den aktuellen Schritt verstehen, dann den nächsten empfehlen. Dafür muss man nicht gleich einen vollständigen Onboarding-Stack nachbauen.
Ein kleiner Blick auf den Einrichtungsstand reicht oft
Der Assistent benötigt meistens deutlich weniger Informationen als euer Support im Adminbereich sehen kann. Für den ersten Import könnte diese Sicht genügen:
| Information | Wofür sie gebraucht wird | Grenze |
|---|---|---|
| Name des aktuellen Workspaces | Der Kunde erkennt, welche Einrichtung gemeint ist | Nur ein Workspace, auf den er zugreifen darf |
| Verbindungsstatus | Die Bereitschaft der Datenquelle erklären | Keine API-Schlüssel oder Zugangstoken |
| Importstatus und Zeitpunkt des Updates | Warten, Verarbeitung und Abschluss unterscheiden | Nur erlaubte Importe im aktuellen Workspace |
| Für Kunden geeignete Fehlerkategorie | Die richtige Hilfe auswählen | Keine rohen Stacktraces oder vertraulichen Logs |
| Verfügbare nächste Aktionen | Einen gültigen nächsten Schritt anbieten | Von Berechtigungen und Geschäftsregeln bestimmt |
Angemeldeten Benutzer und Workspace ermittelt ihr über vertrauenswürdigen Anwendungskontext. Eine Nachricht beschreibt, was der Kunde sieht; sie erzeugt keinen Zugriff auf einen anderen Mandanten. Fehlt der erforderliche Kontext, muss die Abfrage stoppen.
Die Erklärungen bleiben in gepflegter Einrichtungsdokumentation. Ändert sich der Importparser, aktualisiert auch die betreffenden Hilfetexte und prüft die betroffenen Gespräche. Der Assistent sollte keine Spaltenzuordnung empfehlen, die eure Anwendung gar nicht unterstützt.
Ein gescheiterter CSV-Import als Beispiel
Das folgende Gespräch beschreibt ein Beispielszenario, keinen gemessenen Kundenerfolg:
Kunde: Ich habe die Quelle verbunden, aber es sind noch keine Kontakte da.
Assistent: Die Verbindung ist bereit. Der letzte Import wurde gestoppt, weil eine E-Mail-Spalte fehlt. Hat diese Spalte in deiner Datei einen anderen Namen?
Hier kommen zwei Quellen zusammen: Die Anwendung meldet den Importfehler. Eure Dokumentation erklärt erlaubte Spaltennamen und die unterstützte Zuordnung.
Kann das Produkt „E-Mail-Adresse“ dem E-Mail-Feld zuordnen, erklärt der Assistent diese Option. Unterstützt es keine solche Zuordnung, muss die Datei anhand des dokumentierten Formats angepasst werden. Der Rat hängt am tatsächlichen Produktverhalten.
Läuft der Import dagegen noch, sollte die Antwort diesen Stand erklären und zum Fortschritt führen. Ein erneuter Upload könnte unnötig einen zweiten Auftrag erzeugen.
Nach dem Abschluss wird das Ergebnis gelesen, bevor der nächste Meilenstein empfohlen wird. Entscheidend ist, ob der Kunde etwas Nutzbares in seiner Anwendung hat. Eine beruhigende Unterhaltung allein reicht dafür nicht.
Erklären und Ausführen müssen im Gespräch erkennbar sein
Zu erklären, wie ein Import erneut gestartet wird, hat andere Folgen als ihn auszulösen. Bei einem Assistenten mit Aktionen zeigst du den geplanten Auftrag und lässt ihn vor der Ausführung bestätigen.
Die Anwendung prüft, ob der Kunde die Aktion ausführen darf, ob der Auftrag zu seinem Workspace gehört und ob der aktuelle Zustand sie erlaubt. Eine zuvor gelesene Fehlermeldung berechtigt nicht zu einem Neustart, wenn der Import inzwischen erfolgreich war.
Auch das Einreihen eines Hintergrundauftrags und sein erfolgreicher Abschluss sind verschiedene Ereignisse. Wurde der Auftrag angenommen, meldet der Assistent zunächst, dass er eingereiht wurde. Erfolg kann er erst nach dem tatsächlichen Ergebnis melden. Bei einem Timeout oder unklaren Absendeergebnis wird der Stand geprüft, bevor ein zweiter Versuch entsteht.
Für den ersten Umfang genügen möglicherweise lesende Statusabfragen und konkrete Anleitungen. Aktionen kommen dazu, wenn ihr den normalen Anwendungspfad und seine Fehlerfälle sauber kennt.
Mit dem bisherigen Einrichtungskontext an den Support übergeben
Manche Probleme brauchen einen Menschen. Eine nicht unterstützte Quelle, wiederholte Parserfehler oder ein Zugriffsproblem können einen Supportmitarbeiter oder Implementierungspartner benötigen.
Die Übergabe sollte das angestrebte Ziel, die erlaubte Workspace-Referenz, den beobachteten Stand, die sichere Fehlerkategorie und bereits versuchte Schritte enthalten. Kontaktdaten fragt ihr nur ab, wenn sie für die weitere Bearbeitung gebraucht werden.
Zugangsdaten gehören nicht in den Chat. Muss ein Schlüssel ersetzt werden, führt den Kunden in die dafür vorgesehenen sicheren Verbindungseinstellungen. Der Assistent braucht den Schlüssel selbst nicht zu sehen.
Für den Kunden ist der Vorteil einfach: Er muss seine bisherige Einrichtung nicht noch einmal vollständig erklären.
So würde ich das in einem Laravel-SaaS anbinden
Ich würde Filament Agentic Chatbot mit einem Onboarding-Agent, freigegebenen Einrichtungsanleitungen als Knowledge Sources und einer eng begrenzten Data Resource für Verbindungs- und Importdatensätze konfigurieren. Liegt der Status in einem anderen Dienst, kann ein eingerichteter API Connector die erlaubte Abfrage übernehmen.
Die Anwendung liefert vertrauenswürdigen Kunden- und Mandantenkontext. Sie bleibt für Berechtigungen und Einrichtungszustände zuständig. Das Plugin stellt die Assistentenoberfläche und freigegebene Tools bereit; euer Produkt definiert weiterhin, wann etwas bereit ist.
Ein optionales Playbook hilft bei einem abgegrenzten Ablauf mit Bestätigung, Warten oder strukturierter Übergabe. Einfache Statuserklärungen können direkt über die freigegebenen Abfragen des Agent laufen. Oberfläche und kontobezogene Anbindung werden für eure Host-Anwendung eingerichtet.
Damit werden nicht automatisch beliebige Bildschirmansichten erkannt, Buttons hervorgehoben oder Produkttouren gebaut. Solche Oberflächenfunktionen sind eigene Bestandteile. Ein fokussierter Assistent kann bereits helfen, indem er die konkrete Blockade verständlich erklärt.
Die Zustände testen, an denen Kunden wirklich hängen bleiben
Beginne mit fehlender Verbindung, ausstehender Prüfung, laufendem Import und einem Fehler mit dokumentierter Lösung. Ergänze Fehler, für die eure Hilfe keine Erklärung enthält. Hier muss der Assistent Unsicherheit weitergeben, statt eine Reparatur zu erfinden.
Teste einen Benutzer, der zwischen zwei Nachrichten den Workspace wechselt. Lass einen Auftrag fertig werden, während der Kunde den Vorschlag zum Neustart liest. Prüfe einen ausgefallenen Statusdienst und die doppelte Bestätigung einer Aktion. Diese Fälle zeigen, ob der Rat zum aktuellen und erlaubten Zustand passt.
Eine Person aus Customer Success sollte den vorgeschlagenen nächsten Schritt mitbewerten. Technische Richtigkeit ist ein Teil der Hilfe. Verständlich muss die Anweisung auch für jemanden sein, der eure Anwendung zum ersten Mal sieht.
Den ersten erfolgreichen Arbeitsschritt messen
Miss die Zeit vom Beginn des gewählten Ablaufs bis zum überprüften Ziel, den Anteil erfolgreicher Einrichtungen, wiederholte Setupfragen und Übergaben mit ausreichendem Kontext. Trenne nach Datenquelle und Fehlerkategorie.
Die Gespräche zeigen auch, wo Dokumentation oder Produktoberfläche unklar sind. Wenn jeder Kunde nach derselben Spaltenzuordnung fragt, ist vielleicht die Verbesserung dieser Ansicht der sinnvollste nächste Schritt.
Nicht jede Änderung der Aktivierungsquote stammt vom Assistenten. Produktänderungen, andere Kundengruppen und neue Akquisekanäle beeinflussen die Zahlen ebenfalls. Vergleiche ähnliche Gruppen oder nutze einen kontrollierten Rollout, wo das praktikabel ist.
Die laufende Qualitätsprüfung behandelt mein Guide zum Betrieb eines Laravel AI Support Bot ausführlicher. Für das Onboarding würde ich zuerst einen überprüfbaren Meilenstein und die wenigen Situationen wählen, die Kunden daran hindern, ihn zu erreichen.
Fragen vor der Umsetzung
Ist ein Onboarding-Chatbot dasselbe wie eine Produkttour?
Nein. Eine Tour führt durch eine geplante Folge von Oberflächenschritten. Ein Chatbot reagiert auf die Frage des Kunden und kann mit der passenden Anbindung den tatsächlichen Einrichtungsstand erklären. Beides kann sich ergänzen.
Darf der Assistent das Onboarding als abgeschlossen markieren?
Die Anwendung entscheidet anhand eines überprüften Meilensteins. Der Assistent kann dieses Ergebnis mitteilen. Ein beendetes Gespräch ist kein Beleg für eine erfolgreiche Einrichtung.
Sollte das Onboarding direkt mit Schreibaktionen beginnen?
Lesende Statusabfragen und genaue Anleitungen ergeben bereits einen brauchbaren Pilot. Freigegebene Aktionen kommen hinzu, wenn Berechtigungen, Bestätigung und Wiederherstellung definiert und geprüft sind.