Es ist wichtig, dies klarzustellen: Es handelt sich um eine Auswahl von Routen, nicht um eine Bewertung der technischen Qualität.
Beide Systeme basieren auf den Prozessen „Benutzer verstehen, Informationen abrufen, Aktionen ausführen“, der Hauptunterschied liegt jedoch im Zugangspunkt. Sprachgesteuerte Kundendienste finden statt im Telefon: Sie sind sofort erreichbar, erfordern keine Eingabe und sind für ältere Menschen sowie mobile Nutzer geeignet. Allerdings werden bei jeder Interaktion Kosten berechnet, und Fehler führen dazu, dass der Benutzer den Vorgang erneut starten muss. Textbasierte Chatbots hingegen existieren auf Websites und in LINE: Sie ermöglichen eine langsamere Kommunikation, das Einfügen von Links und Bildern sowie die automatische Aufzeichnung von Gesprächsverläufen. Allerdings können sie nicht mit Kunden kommunizieren, die ausschließlich telefonisch Kontakt aufnehmen möchten. Daher stellt die erste Frage immer: Woher kommen Ihre Kunden derzeit?
Wo liegen die Unterschiede in den Kostenstrukturen?
Die Kostenstruktur für Text-basierte Chatbots ist relativ einfach: einmalige Einrichtung plus Nutzung des Modells-APIs. Bei der Sprach-basierenden Kundenbetreuung gibt es jedoch drei zusätzliche Ebenen: die Telekommunikationsebene (Gebühren für die Rufnummer und Gesprächsminuten), die Sprachverarbeitungs- und -syntheseebene (Kosten basierend auf der Nutzung von Audio) sowie die Kapazitäts-Ebene (die Anzahl der gleichzeitigen Anrufe bestimmt die Konfiguration der Leitungen und der Rechenleistung). Aus diesem Grund haben wir unseren MVP für Text-basierte Chatbots mit einem öffentlichen Preis von 30.000 TWD angeboten, während wir bei Sprachprojekten weiterhin darauf bestehen, zunächst die Rahmenbedingungen zu prüfen und dann ein Angebot zu erstellen. Es ist uns aufgefallen, dass Angebote, die ohne Kenntnis der spezifischen Anforderungen (z. B. PBX, gleichzeitige Anrufe und Aufzeichnung) erstellt werden, oft nicht den tatsächlichen Bedürfnissen entsprechen.
Unterschiedliche Fehlermuster führen zu unterschiedlichen Designs für Sicherheitsnetze.
Die Hauptrisiken von Text-basierten Robotern liegen im Verständnis: Fehlinterpretationen, "Halluzinationen" des Modells, falsche Antworten – diese können durch die Qualität der Wissensdatenbank, die Einschränkungen der Antworten und die Überleitung an einen menschlichen Mitarbeiter minimiert werden. Neben diesen Risiken gibt es auch sprachliche Risiken: Fehler bei der Spracherkennung, Hintergrundgeräusche, Akzente, Unterbrechungen während des Gesprächs. Daher müssen die sprachgesteuerten Prozesse so gestaltet sein, dass eine Wiederholung zur Bestätigung möglich ist (wichtige Felder, in denen der Benutzer die Informationen einmal überprüfen kann), dass bei geringer Sicherheit ein menschlicher Mitarbeiter eingeschaltet wird und der Status nach einer Unterbrechung gespeichert wird. Wenn Sie einen Anbieter bewerten, fragen Sie direkt: "Was passiert, wenn die Erkennung fehlerhaft ist?". Unklare Antworten sind nur hypothetische Szenarien.
Wie man es wählt: Rückwärts aus dem Verhalten der Zielgruppe, nicht aus technischen Aspekten
Die Entscheidungsfindung basiert auf einer pragmatischen Herangehensweise: Überprüfen Sie Ihre aktuellen Kundenservice-Aufzeichnungen. Wenn der Großteil der Kommunikation über Telefon erfolgt und die Zielgruppe eine bevorzugte mündliche Kommunikation (z. B. lokale Dienstleistungen, ältere Kundengruppen) bevorzugt – dann sollte der Schwerpunkt auf der Sprachausgabe liegen. Wenn die Kommunikation hauptsächlich über LINE und Webformulare erfolgt und die Fragen sich gut für eine textbasierte Antwort eignen (z. B. E-Commerce, Terminvereinbarungen) – dann sollte der Schwerpunkt auf Text liegen. Beginnen Sie mit der größeren Gruppe und validieren Sie den Prozess, bevor Sie die andere Gruppe erweitern. Wenn das Budget begrenzt ist, ist ein Text-basierter Chatbot ein einfacherer Einstieg, da er die Komplexität der Sprach- und Telefonkommunikation reduziert.
Beide Optionen kombinieren: Gemeinsame Rückseite, der Pfad ist lediglich der Eingang.
Eine ausgereifte Architektur sieht vor, Sprache und Text als zwei separate, aber miteinander verbundene Eingänge zu betrachten: Gemeinsame Wissensdatenbank: (Wartung einer einzigen Datenbank); Gemeinsame Backend-Funktionen: (Abrufen von Bestellungen, Erstellung von Arbeitsaufträgen, Weiterleitung an menschliche Mitarbeiter über eine gemeinsame API); Anpassbare Dialogstrategien je nach Kanal: (Sprache sollte kurz und informell sein, Text kann Links enthalten) Ein Beispiel für diese Strategie ist unser öffentliches GoGoCha-Beispiel: Telefon, Website und LINE erhalten alle dieselbe Backend-Funktion für die Auftragsabwicklung. Es ist egal, welchen Kanal man zuerst implementiert; das Wichtigste ist, dass das Backend von Anfang an für mehrere Kanäle ausgelegt ist, um spätere Neuimplementierungen zu vermeiden.
