Skip to main content
Das Web-Widget bringt deinen Assistenten auf deine Website: Besucher klicken auf eine Schaltfläche und sprechen im Browser mit dem Assistenten (kein Telefon und keine App nötig) oder schreiben im Chat mit demselben Assistenten. Das Widget ist verfügbar, wenn es in deinem Plan enthalten ist.

​
Sprache + Chat, ein Assistent

  • Voice – ein Klick startet ein Live-Sprachgespräch mit der vollständigen Konfiguration des Assistenten: Engine-Modus, Stimme, Wissensdatenbank, Tools, Guardrails. Web-Anrufe erscheinen in Verlauf mit der Richtung web.
  • Chat – derselbe Assistent, dieselben Prompts und dieselbe Wissensdatenbank in Textform, für Besucher, die nicht sprechen können oder wollen.
Weil sich beide Kanäle eine Assistentenkonfiguration teilen, pflegst du das Verhalten nur an einer Stelle.

​
Einbetten

Lege unter Settings → Channels → Web Widget ein Widget an und füge anschließend ein Snippet aus dem Editor ein. Wähle Display:
Der Standard – eine Launcher-Bubble in der Ecke. Position und Initial state gelten. Bevorzuge den script-Loader (er setzt allow="microphone" automatisch am iframe):
Fertige Snippets für HTML, React und Markdown findest du im Embed-Panel. Auf White-Label-Domains wird das Widget von deiner Tenant-Domain mit deinem Branding ausgeliefert.

​
Erlaubte Origins

Trage die Website(s) ein, die das Widget einbetten dürfen (exakte Origins wie https://example.com, oder Subdomain-Wildcards wie *.example.com). Localhost wird für die Entwicklung unterstützt. Origins sind beim Erstellen oder Speichern eines Widgets optional.
  • Eine leere Allowlist bedeutet nicht „offen für jede Seite“: Fremde Origins werden blockiert. Nur die Plattform-Domain selbst bleibt erlaubt, damit die Live-Vorschau in der App weiter funktioniert.
  • Trage vor dem Livegang jeden Website-Host ein, der das Snippet lädt. Lädt das Widget auf einer Kundenseite nicht, prüfe zuerst Allowed origins.

​
Anpassung

  • Display – Floating (Launcher in der Ecke) oder Inline (Einbettung im Seitenfluss). Position und Initial state gelten nur für Floating.
  • Colors and branding – Launcher-Farbe, Panel-Akzent, Logo; das Tenant-Branding greift auf White-Label-Domains automatisch.
  • Position – Eckplatzierung des schwebenden Launchers (bei Inline ausgeblendet).
  • Modes – voice-only, chat-only oder both.
  • Voice presence – klassischer Audio-Visualizer oder ein virtueller AI Avatar (siehe unten).
  • Launcher icon – Milian, Chat bubbles, Question mark, Smiley face, Team oder Hand wave. Gilt für chat-only, voice-only und both.
  • Launcher label – Presets (No text als Standard; Help, Ask anything, Assistance, Support, Live Chat, Need help?), übersetzt anhand der Browsersprache des Besuchers. Avatar-only nutzt weiterhin optional eigenen Launcher-Text für den Glass-CTA.
  • Texts – Willkommensnachricht, AI-Hinweis, Datenschutzhinweis.
  • Pre-chat form – optionales Formular, bevor Chat oder Sprachgespräch startet (siehe unten).

​
Virtueller AI Avatar

Virtuelle Avatare benötigen das Feature AI Avatar. Stelle im Widget-Editor Voice presence auf AI avatar und wähle einen Avatar.
  • Layouts
    • Avatar only (full-bleed) – kompakte Karte mit Fokus auf das Gesicht. Floating-Widgets können Expanded oder Minimized starten; Inline zeigt die Karte immer direkt im Layout.
    • Avatar + chat – Avatar-Präsenz mit dem klassischen Chat-/Voice-Panel-Rahmen.
  • Billing – Sprachsitzungen werden zum normalen Talk-Minute-Tarif abgerechnet, zuzüglich des Zuschlags Web widget virtual avatar pro Minute, solange ein virtueller Avatar aktiv ist; reine Text-Chat-Nachrichten werden – gesendet wie empfangen – pro Nachricht zum Web chat (sent)- bzw. Web chat (received)-Satz des Workspace in Credits abgerechnet. Die aktuellen Sätze findest du auf der Usage-Seite; siehe auch So werden Minuten abgerechnet.
  • Ohne AI-Avatar-Zugriff zeigt der Editor eine Upgrade-Option, und die API lehnt das Aktivieren der Avatar-Präsenz ab.

​
Pre-Chat-Formular

Öffne das Widget im Editor, suche Pre-chat form und aktiviere Enable. Besucher füllen dann Felder aus, bevor die Sitzung beginnt.
  • Suggestions stammen aus Kontaktfeldern (Name, E-Mail, Telefon), den Eingabevariablen des gewählten Assistenten und den Audience-Attributen des Workspace. Du kannst auch eigene Keys hinzufügen.
  • Übermittelte Werte werden zu input variables des Anrufs ({{variable_key}}), aktualisieren den Audience-Lead, wenn Identitätsfelder vorhanden sind, und erscheinen in History unter Pre-chat form / Input variables.
  • Pflichtfelder werden geprüft, bevor ein Besucher eine Sitzung starten kann.

​
Das solltest du vor dem Livegang prüfen

1

Mindestens eine erlaubte Origin hinzufügen

Liste jede Website auf, die das Widget einbettet. Ohne Origins können Fremd-Hosts weder Config laden noch Tokens ausstellen.
2

Teste den Assistenten zuerst mit Browser-Anrufen

Das Widget nutzt denselben Web-Call-Pfad wie der Testanruf im Assistenten-Editor – klingt der richtig, passt auch das Widget.
3

Auf Mikrofonberechtigungen achten

Browser verlangen HTTPS für den Mikrofonzugriff. Die Host-Seite darf das Mikrofon nicht per Permissions-Policy blockieren. Script-/Web-Component-Embeds setzen allow="microphone" automatisch am iframe.
4

Aktualisiere deine Datenschutzerklärung

Sprachgespräche werden wie Anrufe verarbeitet (Transkripte, optionale Aufzeichnung mit Consent-Flow). Erwähne das Widget in deiner Datenschutzerklärung.

​
Fehlerbehebung

Vergewissere dich, dass das Embed-Snippet vor dem schließenden </body>-Tag steht, erzwinge einen Hard-Refresh (oder teste in einem privaten Fenster), um gecachtes HTML auszuschließen, prüfe, ob dein Plan das Web-Widget enthält, und suche in der Browser-Konsole nach JavaScript-Fehlern. Kopiere das Snippet neu aus dem Widget-Editor, falls du seitdem den Key des Connectors geändert hast.
Prüfe zuerst Allowed origins. Eine leere Allowlist blockiert absichtlich jeden fremden Host; trage die exakte Origin ein (oder einen *.example.com-Wildcard), auf der das Widget eingebettet ist.
Voice benötigt HTTPS. Prüfe, ob die Seite über HTTPS ausgeliefert wird, der Browser die Mikrofonberechtigung erteilt hat, das Mikrofon in anderen Apps funktioniert und keine VPN- oder Firewall-Regel WebRTC blockiert. Script- und Web-Component-Embeds setzen allow="microphone" automatisch – bei einem rohen iframe-Embed musst du dieses Attribut manuell ergänzen.
Prüfe die Browser-Konsole auf Fehler, bestätige, dass der Assistent bei einem Testanruf/-chat im Assistenten-Editor funktioniert, und lade die Seite neu, um eine frische Widget-Sitzung zu starten.
Antworten kommen unter dem Key des jeweiligen Felds an; wähle also die Suggestion (oder setze den Custom Key), die zur Variable passt, die dein Assistent liest, und speichere das Widget, bevor du erneut testest.
Stelle sicher, dass du die Widget-Einstellungen gespeichert hast, und erzwinge dann einen Hard-Refresh oder teste in einem privaten Fenster; ein alter, gecachter Embed-Snippet kann eine frische Config-Änderung ebenfalls verdecken.
Verwende einen Custom-HTML-Block, platziere das Snippet vor dem schließenden </body>-Tag, und leere nach dem Speichern den Cache eventueller Caching-Plugins. Security-/Firewall-Plugins blockieren gelegentlich das Widget-Script – deaktiviere sie einzeln nacheinander, um die Ursache einzugrenzen.
Kommst du nicht weiter? Teste in einem Inkognito-Fenster und einem zweiten Browser, um Extensions und zwischengespeicherten Zustand auszuschließen, und kontaktiere dann den Support mit einem Screenshot und der Ausgabe der Browser-Konsole.

​
API & MCP

Verwalte Widgets programmatisch über die öffentliche REST-API (/api/v1/widget-connectors) und MCP-Tools (create_widget_connector, update_widget_connector, …). allowed_origins ist optional; leer oder weggelassen blockiert Fremd-Hosts. Scope: assistants:write. Der Zugriff auf Widget und AI Avatar richtet sich nach deinem Plan. Neue Widgets verwenden anfangs das Portrait des gewählten Assistenten als Header-Logo, sofern eines vorhanden ist. Du kannst es später ersetzen oder entfernen.