No-Code Chatbot-Builder: Flows, Nodes und Webhooks

Die meisten Chatbot-Plattformen zwingen Sie zu einer von zwei schlechten Optionen. Entweder Sie schieben Kästchen über eine Arbeitsfläche und erhalten am Ende einen aufgehübschten Entscheidungsbaum, der nicht mit Ihren Systemen sprechen kann, oder Sie öffnen einen Code-Editor, lernen den nächsten YAML-Dialekt und verbringen eine Woche damit, etwas zusammenzustöpseln, das niemand im Team mehr bearbeiten kann. Der Flow-Builder von Svyazio ist visuell, hat aber für jede ernsthafte Anforderung eine Hintertür: validierte Eingaben, verzweigende Bedingungen, echte HTTP-Webhooks mit Response-Mapping, Variablen, die durch die gesamte Sitzung fließen, und die Übergabe an einen echten Menschen, sobald der Bot an seine Grenzen stößt.

Derselbe Flow läuft auf jedem von Svyazio unterstützten Kanal — dem Website-Widget, Telegram-Bots, VK-Communities und MAX. Inline-Tastaturen werden auf jeder Plattform nativ dargestellt. Auf Kanälen ohne Tastaturunterstützung weichen Buttons auf nummerierte Textoptionen aus, sodass der Besucher weiterhin mit "1" oder "2" antworten kann. Sie bauen den Flow einmal; die Engine kümmert sich darum, wie sie die Sprache jedes Kanals spricht.

Warum ein visueller Builder Code und Entscheidungsbäume schlägt

Das Argument für einen visuellen Flow-Builder lautet nicht nur "auch Nicht-Entwickler können ihn bearbeiten". Die wahren Vorteile sind subtiler:

Flows sind als Diagramme lesbar. Jeder im Team — Support-Leitung, Produktmanager, Marketingleitung — kann den Editor öffnen und in dreißig Sekunden verstehen, was der Bot tut. Code-basierte Bot-Definitionen erfordern Lesen. Visuelle Flows werden als Formen wahrgenommen. Schon das verkürzt Review-Zyklen von Tagen auf Minuten.

Edge Cases haben einen festen Platz. Ein klassischer Entscheidungsbaum bricht unter realem Traffic zusammen, weil jeder interessante Flow Schleifen, Wiederholungen, Timeouts und Übergaben enthält. Mit Svyazio können Sie diese explizit verdrahten — ein fehlgeschlagener Webhook wird auf einen error-Zweig geleitet, eine fehlende Eingabe löst eine erneute Aufforderung aus, ein Sitzungs-Timeout öffnet den Posteingang für einen Menschen. Alles sichtbar, alles an konkrete Nodes gekoppelt.

Variablen machen den Bot zustandsbehaftet. Jeder input-Node schreibt in eine Variable. Jeder Webhook kann Teile seiner Antwort in Variablen abbilden. Jeder spätere Node kann sie in Nachrichten interpolieren — Hallo {{name}}, Ihre Bestellung {{order_id}} wird morgen versendet. Der Bot merkt sich Dinge, anstatt bei jedem Schritt von vorn zu beginnen.

Kanäle, auf denen ein Flow funktioniert

Das Website-Widget spricht Socket.IO. Telegram und MAX akzeptieren Inline-Tastaturen. VK hat ein eigenes Tastaturformat. Die Chatbot-Engine übersetzt jeden Node in den passenden Transport: Der buttons-Node wird in Telegram zu einem inline_keyboard, in VK zu einem keyboard-Payload und im Widget zu Socket.IO-Events. Im Editor sehen Sie unabhängig davon stets denselben Flow.

Aufbau eines Flows

Jeder Flow beginnt mit einem einzigen start-Node. Von dort aus reihen Sie Nodes aneinander, indem Sie Verbindungen zwischen ihnen ziehen. Jeder Node hat 0 oder 1 eingehende Kanten und 1 oder mehr ausgehende Kanten. Nodes können zurückspringen, verzweigen und zusammenlaufen — die Engine folgt den Kanten Schritt für Schritt.

Das linke Panel listet alle verfügbaren Node-Typen auf. Die Arbeitsfläche ist der Ort, an dem der Flow lebt. Das rechte Panel zeigt die Eigenschaften des aktuell ausgewählten Nodes. Änderungen werden gespeichert, wenn Sie auf Speichern klicken; sie gehen live, wenn Sie auf Veröffentlichen klicken. Entwürfe und veröffentlichte Versionen sind getrennt, sodass Sie iterieren können, ohne den produktiv laufenden Bot zu zerschießen.

1. Message-Node

Typischer Einsatz: eine Begrüßungsnachricht mit dem Namen des Besuchers aus dem Widget-Profil, gefolgt von einer kurzen Pause vor der nächsten Frage. Die Verzögerung ist begrenzt, um Versehen zu vermeiden: 0 bis 10 Sekunden, serverseitig erzwungen.

2. Buttons-Node

Buttons sind der Ort, an dem ein Großteil Ihrer Verzweigungslogik tatsächlich steckt. Ein Drei-Button-Menü ("Bestellungen / Support / Fragen") erzeugt drei eigenständige ausgehende Pfade — jeder kann zu einem eigenen Sub-Flow mit völlig unterschiedlicher Logik führen. Die Engine wartet auf den Klick, respektiert Rate-Limits (30 Events pro Minute pro Sitzung) und löscht in Telegram/MAX die Inline-Tastatur nach dem Klick, damit der Besucher nicht doppelt tippen kann.

3. Input-Node (mit Validierung)

Die Validierung ist streng, aber hilfreich: Die E-Mail-Prüfung weist offensichtlich fehlerhafte Adressen ab, die Telefonprüfung akzeptiert internationale Formate und normalisiert sie, und die Textprüfung erzwingt schlicht eine nicht leere Antwort. Der Node hält die Sitzung fest, bis der Besucher etwas sendet, das die Prüfung besteht. Trifft innerhalb des Sitzungs-Timeouts nichts ein, übergibt der Bot an einen Menschen, statt endlos zu schleifen.

Hier erfasste Variablen stehen jedem nachfolgenden Node zur Verfügung. Eine spätere Nachricht kann den Besucher mit Namen begrüßen, ein späterer Webhook kann seine E-Mail in den Payload aufnehmen, und der finale Action-Node kann sein Profilfeld setzen, sodass seine Antworten auch über diese Konversation hinaus erhalten bleiben.

4. Condition-Node

Bedingungen sind das Mittel, mit dem Sie Daten in Ablaufsteuerung verwandeln. Hat der Besucher beim Eingabeschritt "abbrechen" eingegeben? Dann auf den Storno-Flow leiten. Ist sein Besucherprofil als wiederkehrender Kunde markiert? Dann die Einleitung überspringen. Hat der Webhook mit status = "vip" geantwortet? Direkt in die Prioritätswarteschlange. Alle gängigen Vergleichsoperatoren sind dabei: gleich, ungleich, enthält, beginnt mit, numerisch größer/kleiner, boolesch true/false und Regex für die Fälle, in denen sonst nichts passt.

5. Action-Node (Übergabe, Variablen, Profil)

Die Übergabe-Aktionen sind entscheidend. Aufgabe eines Bots ist es üblicherweise, zu qualifizieren, Informationen zu sammeln und weiterzuleiten — nicht, den Agenten zu ersetzen. assign_department legt die Konversation in die richtige Warteschlange (Vertrieb, Support, Buchhaltung), assign_agent heftet sie an eine bestimmte Person, und close markiert die Konversation als erledigt, wenn der Bot sie selbstständig abschließt (Lieferstatusabfrage, beantwortete FAQ-Frage usw.). Der Besucher nimmt diese Schritte nicht als separate Ereignisse wahr — die Konversation wird nahtlos mit einem Menschen fortgesetzt.

set_visitor_field ist unauffälliger, aber genauso nützlich. Es schreibt in das dauerhafte Profil des Besuchers. Die vom Bot erfasste E-Mail-Adresse wird zur Profil-E-Mail. Die Telefonnummer wird zu seiner Telefonnummer. Wenn er das nächste Mal zurückkehrt — aus welchem Kanal auch immer — sind die Daten bereits da.

6. Delay-Node

Verzögerungen sind der Unterschied zwischen einem Bot, der wie ein Tastaturkürzel wirkt, und einem, der sich wie ein Gespräch anfühlt. 300–800 ms zwischen kurzen Nachrichten reichen meist aus. Längere Verzögerungen (2–3 Sekunden) wirken gut vor einer Nachricht, die laufende Arbeit bestätigt — "einen Moment, ich prüfe Ihre Bestellung" — vor allem in Kombination mit einem laufenden Webhook-Aufruf.

7. Webhook-Node (HTTP zu jeder API)

Dies ist der Node, der Svyazio von einem Chatbot-Spielzeug in eine Integrationsplattform verwandelt. Eine Bestellung in Ihrem Backend nachschlagen, Ihr CRM abfragen, einen Bonuspunkte-Service anpingen, einen GPT-Completion-Endpoint aufrufen — was HTTP kann, kann auch der Webhook-Node. Sowohl die URL als auch die Header und der Body unterstützen Variableninterpolation, sodass jeder Aufruf zum Kontext der aktuellen Sitzung passt.

Eine typische Konfiguration:

Nachdem dieser Node ausgeführt wurde, stehen {{customer_name}}, {{customer_tier}} und {{order_count}} jedem nachgelagerten Node zur Verfügung. Der direkt folgende Schritt ist typischerweise ein condition-Node, der auf customer_tier == "vip" verzweigt.

Der Webhook-Node hat zwei ausgehende Kanten: success (HTTP 2xx) und error (4xx/5xx, Timeout, SSRF-Block, fehlerhafte Antwort). Wenn Sie nur den Erfolgszweig verkabeln, fallen Fehler auf die Standardkante zurück — nichts bleibt jemals stillschweigend hängen.

Variablen und Template-Syntax

Variablen sind der Klebstoff. Jeder input-Node, jedes Webhook-Response-Mapping und jede set_variable-Aktion schreibt in session.variables. Jede message, jeder buttons-Node und jede Webhook-URL/-Body kann mittels {{variable}}-Interpolation darauf zugreifen. Die Punktnotation funktioniert ebenfalls: Bildet ein Webhook order auf das gesamte Antwortobjekt ab, können Sie später {{order.tracking_number}} referenzieren.

Harte Limits, damit Sitzungen nicht ausufern:

• Höchstens 100 Variablen pro Sitzung
• Höchstens 2.000 Zeichen pro Variablenwert
• Das Sitzungs-Pfadprotokoll (für die Analytik) ist auf 500 Node-Durchläufe begrenzt

Mit einem normalen Flow erreichen Sie diese Grenzen nicht. Sie schützen Sie vor dem pathologischen Fall einer entlaufenen Schleife, die in Variablen schreibt, bis der Speicher voll ist.

Drei reale Flows zum Nachbauen

Beispiel 1: Lead-Qualifizierungs-Bot für ein SaaS

Ziel: drei Fragen stellen, den Lead bewerten, heiße Leads an den Vertrieb leiten, kalte in den Onboarding-Flow.

1. Start → Message ("Hallo! Eine kurze Frage: Was führt Sie heute hierher?")
2. Buttons (Preise / Integrationen / Nur am Schauen) → speichert die Auswahl in intent
3. Input (E-Mail, type = email) → speichert in email
4. Input (Unternehmensgröße: solo / 2-10 / 11-50 / 50+) → speichert in size
5. Condition: intent == "Preise" UND size != "solo" → in den Zweig "heißer Lead"
6. Action: assign_department(Vertrieb) im Zweig für heiße Leads
7. Message im kalten Zweig ("Danke! Hier ist eine Tour, die Ihnen gefallen könnte: [Link]")
8. Action: close nach der Nachricht im kalten Zweig

Gesamte Bauzeit: ~10 Minuten. Kein Code. Funktioniert im Website-Widget und in Telegram identisch.

Beispiel 2: Bestellstatus-Abfrage für E-Commerce

Ziel: Der Besucher fragt nach einem Bestellstatus, der Bot schlägt ihn im Shop-Backend nach, gibt Tracking-Infos zurück und bietet eine Übergabe an, falls etwas nicht stimmt.

1. Input (Bestellnummer, type = text) → order_id
2. Input (E-Mail aus der Bestellung, type = email) → email
3. Delay (1500 ms) + Message ("Ich schaue das nach...")
4. Webhook → GET https://shop-api.example/orders/{{order_id}}?email={{email}}, mappt status und tracking_url
5. Bei success: Message ("Ihre Bestellung ist {{status}}. Tracking: {{tracking_url}}") → Buttons ("Alles klar, danke" / "Es stimmt etwas nicht")
6. Bei "Alles klar": Action: close
7. Bei "Es stimmt etwas nicht" ODER bei Webhook-error: Action: assign_department(Support)

Beispiel 3: Nacht-Bot, der übergibt, sobald Operatoren wieder online sind

Ziel: Nur laufen, wenn alle Agenten offline sind, das Wesentliche erfassen und für die Frühschicht ein Ticket in Telegram ablegen.

Ausgelöst durch die Bedingung operators_offline = offline im Widget-Trigger (kein Flow-Node — das wird in den Wann ausführen-Einstellungen des Bots konfiguriert). Der Bot selbst ist ein einfacher Flow:

1. Start → Message ("Wir sind gerade offline, melden uns aber morgen früh bei Ihnen.")
2. Input (E-Mail) → Input (Was ist Ihre Frage?)
3. Action: set_visitor_field(email) + set_visitor_field(phone, falls erfasst)
4. Webhook → POST an einen Telegram-Kanal-Webhook mit der Zusammenfassung, damit die Frühschicht sie als Erstes sieht
5. Action: close

Übergabe an Menschen und Sitzungssteuerung

Agenten haben immer das letzte Wort. Überall im Dashboard erscheint ein Banner, sobald eine Chatbot-Sitzung in einer Konversation aktiv ist: "Bot X bearbeitet diese Konversation" mit einer Schaltfläche Bot stoppen. Ein Klick und der Bot ist fertig — die Sitzung wechselt in den Status HANDED_OFF, alle ausstehenden Inline-Tastaturen werden aus Telegram/MAX entfernt und die Konversation wird als bearbeitungsbedürftig markiert. Ab dort übernimmt der Agent.

Das ist nicht nur ein Notfallknopf. Es ist der zentrale Integrationspunkt zwischen Bots und Menschen. Bots erledigen die Routine; Agenten übernehmen, wenn es spannend wird. Die vom Bot erfassten Variablen sind für den Agenten sichtbar, sodass er nicht bei null anfangen muss.

Auf der Engine-Seite laufen im Hintergrund einige Schutzmechanismen:

• Ein Redis-gestützter Lock serialisiert gleichzeitige Klicks — der Besucher kann einen Button nicht doppelt antippen und zwei Pfade auslösen.
• Ein Rate-Limiter begrenzt jede Sitzung auf 30 Events pro Minute, damit ein Skript einen Bot nicht in eine Endlosschleife treiben kann.
• Ein Cron-Sweep läuft jede Minute und beendet Sitzungen, die länger als erlaubt auf Eingaben warten — die Konversation wird wieder für Menschen geöffnet, nichts bleibt hängen.

Preise und Limits

Chatbots sind ein Feature des Pro-Tarifs. Der Tarif bündelt zudem den KI-Schreibassistenten, Trigger und automatische Nachrichten, Abteilungen, Analytik, unbegrenzt viele Agenten, White-Label und 10 Telegram-Bots. Beide kostenpflichtigen Tarife enthalten eine 7-tägige kostenlose Testphase, ohne Kreditkarte.

Siehe die vollständige Preisseite oder direkt zur Kontoerstellung.

FAQ