Zum Hauptinhalt springen

Launch-Checkliste

Verwenden Sie diese Checkliste, bevor Sie ChattyBox Kunden zugänglich machen. Sie findet die häufigsten Lücken in der Einrichtung, durch die ein Chatbot zwar installiert, aber noch nicht einsatzbereit wirkt.

Für einen Support-Rollout kombinieren Sie diese Checkliste mit dem Leitfaden für KI-Chatbots im Kundensupport, damit Antworten aus öffentlichen Inhalten einen klaren Eskalationsweg für kontospezifische, sensible oder ungelöste Fragen haben.

Inhaltsbereitschaft​

  • Es wurden öffentliche, crawlbare Inhalte ausgewählt, aus denen der Chatbot antworten soll.
  • Private Seiten, Admin-, Checkout- und Kontoseiten, Entwürfe und Staging-Inhalte sind durch bewusste Quellenauswahl ausgeschlossen, nicht nur durch robots.txt, das der Crawler nicht beachtet. Die Quellenauswahl ersetzt nicht die Zugriffskontrollen Ihrer Website.
  • Sie haben Startseite, Sitemap, manuelle URLs oder Crawl bewusst gewählt. Der Crawl prüft zuerst die konventionellen Sitemap-Pfade; nur wenn keiner davon URLs liefert, folgt er Links. Eine unvollständige Sitemap wird nicht durch Link-Crawling ergänzt.
  • Wichtige Seiten zu Produkt, Preisen, Richtlinien, Support, FAQ, Onboarding und Fehlerbehebung sind enthalten.
  • Mehrsprachige Websites enthalten die Sprachversionen, aus denen das Widget erwartungsgemäß antworten soll.

Scraping-Validierung​

  • Der Scrape ist beendet, gespeicherte/ausgewählte Zahlen wurden verglichen und die erwarteten Seiten sind vorhanden. Abgeschlossen garantiert weder, dass alle URLs erfolgreich verarbeitet wurden, noch dass der Inhalt für Antworten bereit ist.
  • Die Anzahl indexierter Seiten entspricht dem erwarteten Wert für Ihren Tarif und den Umfang des Launches.
  • Teilweise indexiert-Seiten wurden auf abgeschnittenen Text jenseits des 512-KiB-Limits geprüft; lange Seiten wurden bei Bedarf aufgeteilt.
  • Die separate Embedding-Verarbeitung ist abgeschlossen und repräsentative Abrufe wurden getestet.
  • Kürzlich bearbeitete oder migrierte Seiten wurden erneut gescrapt.
  • Fehlende Seiten wurden auf Authentifizierung, Bot-Challenges, fehlgeschlagene/unsichere Weiterleitungen, Quellenfilter oder reine JavaScript-Inhalte geprüft. Wichtiger Text muss im abgerufenen HTML ohne JavaScript-Rendering verfügbar sein.
  • Veraltete, bereits gespeicherte Seiten wurden unter Wissensbasis → Seiten gelöscht, nicht nur aus der Sitemap entfernt; passen Sie die Quellen an, damit sie nicht erneut entdeckt werden.

Nutzung und Zugriffsrechte​

  • Der Projekteigentümer kann auf das Dashboard zugreifen und den Chatbot verwalten; öffentliche Schlüssel und die Mitgliedschaft in einer Organisation gewähren keinen Dashboard-Zugriff.
  • Unter Abrechnung und Nutzung (/settings/account) reicht das Nachrichtenkontingent für Tests und den Launch-Traffic aller Chatbots des Eigentümers. Chatbot testen verbraucht dieses Kontingent ebenfalls.
  • Die Limits für gespeicherte Seiten und das separate monatliche Seitenaktualisierungsbudget wurden geprüft. Dieses Budget wird zwischen den Projekten des Kontoinhabers geteilt. Manuelle Index-Neuaufbauten verbrauchen es ebenfalls und haben die tarifabhängige Abkühlzeit.
  • Der Aktualisierungsplan passt zum Tarif: Free höchstens wöchentlich, kostenpflichtige Tarife höchstens täglich. Manuelle Scrape-Wiederholungen warten nach Erstellung des neuesten Jobs mindestens 7 Tage (Free) oder 24 Stunden (kostenpflichtige Tarife), auch wenn der Job fehlgeschlagen ist.
  • Bei Pro/Business ist PAYG entweder deaktiviert, pro Funktion begrenzt oder bewusst ohne Ausgabenlimit eingestellt, wodurch unbegrenzte nutzungsabhängige Gebühren anfallen können. PAYG hebt weder die Aktualisierungs-Abkühlzeit des Crawlers noch das monatliche Budget auf.
  • Falls eine Konfigurationssperre verwendet wird, sind ihre nicht rückgängig zu machenden Einschränkungen und der separate Workflow mit geheimem Deployment-Token bekannt.

Antwortqualität​

  • Sie haben echte Testfragen aus Anwendungsfällen für Vertrieb, Support, Onboarding und Dokumentation gestellt.
  • Repräsentative Antworten stützen sich auf indexierte Inhalte; für nicht belegte Fragen wird der vorgesehene Fallback ausgegeben. Prüfen Sie die Antworten: Ein erfolgreicher Test garantiert nicht die Qualität jeder künftigen Antwort.
  • Bei hilfreichen Antworten werden Quellenangaben angezeigt.
  • Links in den Quellenangaben öffnen die erwarteten öffentlichen Quellseiten.
  • Schwache Antworten wurden durch bessere Quellinhalte oder zusätzliche Seiten behoben und anschließend erneut gescrapt.
  • Wenn die Persona geändert wurde, prüfen Sie, ob der Speicherstatus die Speicherung bestätigt; beheben Sie Validierungsfehler oder versuchen Sie fehlgeschlagene Speicherungen erneut, bevor Sie testen. Testen Sie den erzwungenen Fallback separat; der Persona-Text ersetzt nicht die konfigurierte Antwort bei fehlendem Kontext.
  • Testfragen enthalten den nötigen Kontext: Für dieselbe Konversation erhält der Antwortgenerator höchstens 12 der letzten gespeicherten Nachrichten, jeweils auf 2.000 Zeichen gekürzt, nicht den vollständigen Verlauf.

Widget-Installation​

  • Das Widget ist auf den vorgesehenen öffentlichen Seiten installiert.
  • Das Skript wird pro Seite nur einmal geladen.
  • Das Skript enthält data-api-key.
  • Das Skript enthält data-api-url.
  • Automatisch erkennen / Festgelegt und Script-Überschreibung erlauben sind bewusst gesetzt. data-locale setzt sich nur bei erlaubter Überschreibung durch, auch im Modus Festgelegt.
  • Widget-Oberflächensprache, Frage-/Antwortsprache und indexierte Sprachversionen wurden separat getestet.
  • Das Widget öffnet sich und sendet in einem Inkognito-Fenster eine Testfrage.
  • Tests im mobilen Viewport bestätigen, dass Launcher und Chatpanel verwendbar sind.

API-Schlüssel und optionale Ursprungseinschränkungen prüfen​

  • Der vorgesehene öffentliche Schlüssel ist unter Installieren → Installation auf der Website ausgewählt; seine Einstellungen werden unter Schlüssel und Domains verwaltet.
  • Eine Rotation wurde abgeschlossen, indem der neue Schlüssel vor dem Löschen des alten installiert und getestet wurde. Schlüsselnamen schränken Umgebungen nicht ein.
  • Der öffentliche Schlüssel wurde auf den vorgesehenen Produktions-, Preview-/Staging- und localhost-Websites getestet. Prüfen Sie seine Einschränkungen: Ein für eine Website vorbereiteter Schlüssel kann bereits auf diesen Ursprung beschränkt sein; Schlüssel ohne Einschränkungen funktionieren auf allen Browser-Ursprüngen.
  • Wenn die optionale zusätzliche Absicherung aktiviert ist, enthält Schlüssel und Domains → Origins bearbeiten die vorgesehenen exakten Ursprünge (Schema, Hostname und Port müssen übereinstimmen). Ursprungseinschränkungen authentifizieren keine Besucher; öffentliche Browser-Schlüssel sind keine Geheimnisse.
  • Keine privaten Server-API-Schlüssel, Admin-Tokens oder Geheimnisse befinden sich in Frontend-Code, GTM, benutzerdefiniertem CMS-HTML oder dem Quelltext der Seite.

Browser- und Deployment-Prüfungen​

  • Die Browserkonsole enthält keine ChattyBox-Fehler.
  • Die Content Security Policy erlaubt das Widget-Skript und die API-URL, falls Ihre Website CSP verwendet.
  • Werbeblocker oder Einwilligungstools blockieren das Widget nicht auf den vorgesehenen Seiten.
  • Die endgültig bereitgestellte Website und nicht nur die lokale Entwicklung wurde getestet.

Nach dem Launch​

  • Prüfen Sie Konversationen → Verlauf in jedem Tarif sowie Analysen / Unbeantwortete Fragen in Pro/Business.
  • Interpretieren Sie Analysen als höchstens 5.000 erfasste Interaktionen der letzten 30 Tage einschließlich Chatbot-Tests; dies belegt weder die Antwortqualität noch ausschließlich Besucher-Traffic.
  • Prüfen Sie erkannte Lücken, testen Sie verbesserte Inhalte erneut und markieren Sie Lücken manuell als gelöst. Die Standardliste blendet gelöste Lücken aus; Gelöste Lücken einbeziehen. und Rückgängig zeigen sie an bzw. öffnen sie erneut. Bei erneutem Auftreten wird eine gelöste Lücke nicht automatisch wieder geöffnet.
  • Wenn Seitenzuordnung wichtig ist, prüfen Sie Beliebte Trigger. Das gehostete Widget sendet Seitenkontext und behält den URL-Pfad bei, entfernt aber Query-Parameter und Fragment. Laden oder behalten Sie das Widget nicht auf sensiblen/privaten Routen. In einer SPA entfernt ein Ausschluss-Trigger ein bereits initialisiertes Widget nicht; bauen Sie es ausdrücklich ab. Das Headless-SDK sendMessage() sendet keinen Kontext der Quellseite.
  • Ergänzen Sie fehlende Dokumentation, FAQs oder Beispiele auf Grundlage echter Besucherfragen.
  • Scrapen Sie aktualisierte Seiten nach Inhaltsänderungen erneut, sobald Abkühlzeit und Aktualisierungsbudget es zulassen.
  • Rotieren Sie öffentliche Widget-Schlüssel bei Bedarf; aktualisieren Sie Ursprungseinschränkungen nur, wenn sie aktiviert sind und sich die zugelassenen Domains ändern.
  • Das Löschen einer Konversation setzt die Nutzung nicht zurück und löscht keine Analyse-Einträge; diese Daten werden getrennt gespeichert.

Wenn ein Punkt fehlschlägt, verwenden Sie vor dem Launch die Fehlerbehebung.