Einen No-Code-KI-Agenten aufbauen: Wissensdatenbank, Multi-Turn, Aktionen

Warum die meisten „KI-Agenten“ beim Beantworten von Fragen stecken bleiben

Mittlerweile behauptet jeder Anbieter, einen KI-Agenten zu verkaufen. Schaut man hinter das Marketing, tun die meisten davon eines: eine Antwort aus einem Dokument abrufen und in ein Chatfenster einfügen. Das ist eine Wissensdatenbank mit einer Konversations-Oberfläche, kein Agent. Ein echter Agent muss sich merken, was vor drei Nachrichten gesagt wurde, entscheiden, wann er genug Informationen hat, um zu handeln, tatsächlich etwas in einem führenden System bewirken und wissen, wann er aufhören und einen Menschen hinzuziehen muss.

Für CX-, Support- und RevOps-Verantwortliche, die diese Kategorie bewerten, ist diese Unterscheidung geschäftlich relevant. Ein Bot, der nur Wissen abruft, wehrt Tickets ab, die ohnehin schon einfach waren. Ein Agent, der ein mehrstufiges Gespräch führen und eine Aktion ausführen kann — eine Rückerstattung veranlassen, eine RMA anlegen, eine Reklamation eskalieren — wehrt die Tickets ab, deren manuelle Bearbeitung tatsächlich Geld kostet. Dieser Beitrag zeigt, was nötig ist, um einen solchen Agenten ohne Entwicklungsressourcen aufzubauen, unter Verwendung der Bausteine, die die meisten Teams bereits haben oder schnell aufsetzen können.

Die drei Ebenen, die ein echter Agent braucht

Ebene 1: Fundierung in der Wissensdatenbank

Ein Agent, der aus einem statischen Dokumentenbestand antwortet, ist nur so gut wie die Struktur dieses Bestands. Die praktische Anforderung ist eine Wissensdatenbank, die abfragbar und versioniert ist und je nach Seite zugangsbeschränkt oder öffentlich sein kann — denn ein Artikel zur Rückgaberichtlinie sollte für anonyme Besucher sichtbar sein, ein bestimmter Bestellstatus dagegen nicht.

Genau das bietet eine Support-Portal-Vorlage von Haus aus: einen öffentlich zugänglichen Wissensdatenbank-Bereich neben Seiten, die eine Anmeldung erfordern, wie z. B. die Ticketverfolgung, auf derselben Domain. Die Seitenstruktur unterstützt dynamische Seiten — ein mit Doppelpunkt versehener Slug wie articles/:articleId rendert den passenden Wissensdatenbank-Eintrag aus einer Datenliste, was bedeutet, dass Ihre KB-Inhalte in einer strukturierten Datenentität liegen statt in verstreuten PDFs. Genau diese Struktur braucht ein Agent, um zuverlässig darauf zuzugreifen.

Ebene 2: Multi-Turn-Kontext, der nicht zurückgesetzt wird

Die meisten Bot-Baukästen behandeln jede Nachricht als neue Anfrage. Das funktioniert bei „Wie sind Ihre Öffnungszeiten“, scheitert aber in dem Moment, in dem ein Kunde sagt: „Eigentlich meine ich Artikel 2, nicht Artikel 1.“ Ein brauchbarer Agent braucht einen persistenten Thread, der Kontext über mehrere Züge hinweg akkumuliert und mit dem betreffenden Datensatz verknüpft bleibt.

Die Threads-Funktion von SurveyAnalytica ist genau dafür gebaut. Ein Thread vom Typ „Konversation“ ist von Natur aus kundenseitig — dasselbe Konstrukt, das für RMA-Dialoge oder Befragten-Nachfassaktionen genutzt wird — und bleibt mit den Entitäten verknüpft, mit denen er zu tun hat: der Antwort, dem Kontakt, der Bestellung, dem Workflow, der ihn bearbeitet. Ein einzelner Thread kann gleichzeitig mit einer Antwort, der Kampagne, die sie ausgelöst hat, dem zugehörigen Kontakt und dem Workflow, der die Anfrage bearbeitet, verknüpft sein — mit bidirektionaler Navigation dazwischen. Das bedeutet: Kehrt ein Kunde zwei Tage später zu einem Gespräch zurück, fängt der Agent nicht bei null an; er knüpft (im wahrsten Sinne) an einen Thread an, der bereits weiß, wer er ist und worüber gesprochen wurde.

Ebene 3: Ausführung von Aktionen, nicht nur Vorschläge

Hier hören die meisten „KI-Agenten“-Produkte still und leise auf. Sie entwerfen eine Antwort, schlagen einen nächsten Schritt vor oder markieren ein Ticket — aber der Mensch muss es trotzdem noch in einem anderen System umsetzen. Ein No-Code-Agent, der es wert ist, kommerziell eingesetzt zu werden, muss echte Aktionen auslösen können: einen Datensatz anlegen, einen Versand veranlassen, in Slack posten, in ein Buchhaltungssystem schreiben.

Ereignisse im Thread-Lebenszyklus — Thread erstellt, Nachricht gepostet, Thread gelöst, archiviert oder geschlossen — sind native Workflow-Auslöser. Ein gelöster Support-Thread kann automatisch den Versand eines Versandetiketts auslösen. Aktionen, die innerhalb eines Threads erzeugt werden, übernehmen die verknüpften Entitäten des Threads und erscheinen im Action Center mit Fälligkeitsdatum und Verantwortlichem — sodass nichts, was der Agent erzeugt, in einem Chatprotokoll verschwindet, sondern zu einer nachverfolgbaren Aufgabe mit einem Verantwortlichen wird. Für Finanz- und Betriebsteams, die bereits Tally Prime einsetzen, unterstützt der Konnektor Echtzeit- oder gebündelte Auslöser pro Belegtyp, sodass eine vom Agenten initiierte Rückgabe direkt in eine Gutschrift einfließen kann, ohne dass jemand sie erneut erfassen muss.

Die vierte Ebene: Übergabe an den Menschen

Ein Agent, der nie eskaliert, ist nicht selbstsicher — er ist rücksichtslos. Das ehrliche Designziel ist nicht vollständige Automatisierung; es geht darum, die Teile zu automatisieren, die kein Urteilsvermögen erfordern, und den Rest an eine Person mit vollständigem Kontext weiterzuleiten, nicht an ein kaltes Ticket. Ein kundenseitiger Thread, der 24 Stunden unbeantwortet bleibt, kann automatisch eine Slack-Benachrichtigung auslösen, und externe Teilnehmer (ein Kunde, ein externer Installateur) können in einen einzelnen Thread eingeladen werden, ohne Zugriff auf andere Workspace-Daten zu erhalten — der Zugriff ist auf diesen Thread beschränkt und läuft an einem von Ihnen festgelegten Pflichtdatum ab. Das ist der Mechanismus, der es einem Menschen ermöglicht, in ein laufendes Agentengespräch einzusteigen, ohne alles neu erklären zu müssen und ohne dafür einen breiteren Systemzugriff öffnen zu müssen.

Durchgerechnetes Beispiel: ein Retouren-Agent für eine E-Commerce-Marke

So greifen die vier Ebenen bei einem Einzelhändler im mittleren Marktsegment ineinander, der RMAs über ein Self-Service-Portal abwickelt:

• Einstiegspunkt: Ein Kunde besucht das gebrandete Support-Portal unter returns.yourbrand.com und öffnet die öffentliche Wissensdatenbank-Seite zur Rückgaberichtlinie. Wird seine Frage dort beantwortet, endet die Interaktion — kein Thread nötig, kein Agenten-Aufwand.
• Eskalation zur Konversation: Muss tatsächlich eine Rückgabe gestartet werden, öffnet der Agent einen Konversations-Thread und fragt nach Bestellnummer, Artikel und Grund — ein mehrstufiger Austausch, kein Formular-Dump. Da der Kunde angemeldet ist, ist der Thread bereits mit seinem Kontaktdatensatz verknüpft.
• Strukturierte Detailerfassung: Bei einer Bestellung mit mehreren Artikeln übergibt der Agent an einen wiederholbaren Abschnitt im RMA-Formular — eine Instanz pro zurückgesendetem Artikel, jeweils fortlaufend benannt („Retouren · Artikel 1“, „Retouren · Artikel 2“) —, sodass ein Kunde, der drei Produkte in einer Bestellung zurücksendet, das Gespräch nicht dreimal getrennt führen muss.
• Ausführung der Aktion: Erreicht der Thread den Status „gelöst“ (Rückgabe genehmigt, Berechtigung bestätigt), wird automatisch ein Workflow-Trigger ausgelöst: Ein Versandetikett wird erstellt und per E-Mail versandt, und der RMA-Datensatz aktualisiert das Bestellsystem per Webhook.
• Übergabe an den Menschen: Bleibt der Thread 24 Stunden unbeantwortet — etwa weil der Agent die Rückgabeberechtigung im Hinblick auf einen Grenzfall der Richtlinie nicht bestätigen konnte —, zieht eine Slack-Benachrichtigung einen Support-Mitarbeiter hinzu, der demselben Thread mit bereits sichtbarem vollständigem Kontext beitritt, statt bei einem leeren Ticket zu beginnen.

Jedes Freitextfeld, das der Kunde unterwegs ausgefüllt hat — „das Ladegerät hat nach zwei Wochen aufgehört zu funktionieren“, „falsche Farbe geliefert“ — durchläuft eine Sentiment- und Entitätsextraktion unabhängig pro wiederholbarer Instanz, sodass ein Bündel von drei Beschwerden in einer Einreichung drei eigenständige Signalpunkte statt einer verwaschenen Durchschnittsaussage erzeugt. Das sind Daten, auf deren Grundlage Ihre Qualitäts- und Produktteams später handeln können — als Nebenprodukt einer Support-Interaktion erzeugt, nicht als separate Umfrage.

Was „No-Code“ tatsächlich von Ihnen verlangt

No-Code bedeutet nicht kein Setup. Bevor ein solcher Agent zuverlässig funktioniert, müssen einige Dinge vorhanden sein, und es lohnt sich, das offen anzusprechen, statt etwas anderes vorzugeben:

• Strukturierte Wissensdatenbank-Inhalte. Der Agent ruft ab, was Sie ihm zuführen. Eine Wissensdatenbank aus losen PDFs und verstreuten Wiki-Seiten wird unabhängig davon, wie gut das zugrunde liegende Modell ist, inkonsistente Antworten liefern. KB-Inhalte in eine strukturierte Datenlisten-Entität zu migrieren, ist hier die eigentliche Arbeit — und es lohnt sich, das einmal richtig zu tun.
• Klare Eskalationsschwellen. Legen Sie im Vorfeld fest, was „ungelöst“ bedeutet — 24 Stunden, drei unbeantwortete Züge, ein bestimmter Kunden-Stimmungswert —, bevor Sie die Automatisierung aktivieren, nicht erst, nachdem sich ein Kunde über eine Bot-Schleife beschwert hat.
• Identitätskontinuität. Wenn Ihr Agent Bestellhistorie oder Kaufkontext braucht, um gut zu antworten, erfordert das die Verknüpfung anonymer Browsing-Sitzungen mit bekannten Kontakten beim Login — jene Art von Identitätsauflösung, die der identify-Aufruf des Clickstream-Trackings übernimmt und dabei das Verhaltenssignal mit derselben Kontakt-ID verknüpft, die der Agent bereits in seinem Konversations-Thread verwendet.
• Governance für externen Zugriff. Wenn Kunden oder Lieferanten an Threads teilnehmen, sind verpflichtende Ablaufdaten für externe Einladungen keine optionalen Extras — sie verhindern, dass sich der Zuständigkeitsbereich eines Support-Agenten unbemerkt zu einer Datenexposition ausweitet.

Wie SurveyAnalytica hilft

SurveyAnalytica verkauft kein einzelnes „KI-Agenten“-Widget, das an ein Chatfenster angeflanscht wird — es liefert Ihnen die Komponenten, die ein echter Agent braucht, bereits miteinander verdrahtet: eine strukturierte, gebrandete Wissensdatenbank über die Support-Portal-Vorlage, persistente Multi-Turn-Konversations-Threads, die mit dem Kundendatensatz und jeder verwandten Entität verknüpft bleiben, sowie eine Workflow-Engine, die Thread-Ereignisse in echte Aktionen umwandelt — Versandetiketten, Slack-Benachrichtigungen, ERP-Aktualisierungen — statt sie als bloße Vorschläge in einem Chatprotokoll zu belassen.

Da diese Bausteine dasselbe Datenmodell wie Ihre Umfragen, Portale und Konnektoren nutzen, ist ein Agentengespräch kein isoliertes Silo. Das aus einer Rückgabebeschwerde eines Kunden extrahierte Sentiment fließt in dieselbe Analyseschicht ein wie Ihre NPS-Umfragen; die dadurch ausgelöste Aktion erscheint im selben Action Center wie Ihre Freigabe-Workflows. Das ist der Unterschied zwischen dem Einsatz eines Chatbots und dem Aufbau einer operativen Fähigkeit, die Sie tatsächlich steuern, prüfen und im Laufe der Zeit verbessern können.

Wenn Sie das mit einer Plattform wie Qualtrics oder einem eigenständigen Chatbot-Anbieter vergleichen, lautet die praktische Frage nicht „Hat es KI?“ — sondern ob Wissensdatenbank, Konversationsebene und Aktionsebene dasselbe System sind oder drei separate Systeme, die Sie selbst zusammenflicken müssen.

Fazit

Ein No-Code-KI-Agent, der sich kommerziell einzusetzen lohnt, definiert sich nicht dadurch, wie flüssig seine Antworten klingen. Er definiert sich dadurch, ob er ein Gespräch über mehrere Züge hinweg führen kann, ohne den Kontext zu verlieren, seine Antworten in Inhalten verankert, die Sie tatsächlich kontrollieren, eine echte Aktion in einem echten System ausführt, wenn er genug Informationen hat, und sauber zur Seite tritt, wenn nicht. Bauen Sie diese vier Dinge in der richtigen Reihenfolge auf — Wissensdatenbank, Multi-Turn, Aktionsausführung, Übergabe an den Menschen —, und Sie erhalten einen Agenten, der die Arbeitslast tatsächlich reduziert. Lassen Sie einen davon aus, und Sie haben eine FAQ-Seite mit besserem Marketing gebaut.