Routinefragen beantworten. Offene Fälle zuordnen.

Ein KI-Chatbot für Unternehmen beantwortet Fragen über eine Gesprächsoberfläche und kann erlaubte Schritte in verbundenen Systemen auslösen. Für die Auswahl ist entscheidend, welche Aufgabe er zuverlässig abschließen soll. Öffentliche Produktinformationen, persönliche Bestellauskünfte und Änderungen an einer Bestellung sind unterschiedliche Leistungen mit unterschiedlichen Voraussetzungen.

Beginnen Sie mit den häufigsten Anliegen aus Ihren tatsächlichen Servicekanälen. Gruppieren Sie diese nach erwartetem Ergebnis: Information, Datenauskunft, Vorbereitung einer Aktion oder Übergabe an eine Person. Ein allgemeiner Assistent, der über alles sprechen kann, ist nicht automatisch ein guter Kundenservice. Eine begrenzte Anwendung mit richtigen Quellen und einer funktionierenden Übergabe kann den konkreten Bedarf besser erfüllen.

Der Projektumfang sollte diese Ergebnisse einzeln benennen. Formulierungen wie „automatisiert den Support“ lassen offen, ob der Bot lediglich Antworten erzeugt oder tatsächlich einen Vorgang korrekt weiterführt.

Für eine öffentliche Frage kann eine freigegebene Wissensquelle genügen. Eine persönliche Auskunft benötigt zusätzlich einen geeigneten Identitäts- und Berechtigungsnachweis. Eine Änderung braucht schließlich eine klar erlaubte Aktion und eine Rückmeldung des Zielsystems. Diese drei Ebenen sollten auch technisch unterscheidbar bleiben.

Die Eingabe einer Bestellnummer allein darf nicht pauschal als ausreichende Berechtigung behandelt werden. Der konkrete Nachweis hängt vom System und dem Schutzbedarf ab. Der Chat sollte nicht über eine offene Suche beliebige Kundeninformationen auffindbar machen. Prüfen Sie die Berechtigung am Datenzugriff; eine Anweisung im Prompt ersetzt diese Prüfung nicht.

Für Aktionen kommen weitere Fragen hinzu: Darf der Bot nur einen Entwurf erzeugen oder selbst speichern? Welche Beträge, Produkte oder Vorgangsarten sind ausgeschlossen? Muss der Kunde die endgültige Änderung bestätigen? Welche Person kann einen Fehler berichtigen? Der Leitfaden zu Identität und Aktionssicherheit führt durch diese Entscheidungen.

Dieses synthetische Beispiel beschreibt einen entworfenen Serviceprozess. Ein Kunde schreibt: „Das Paket kam erst heute und der Artikel ist kaputt. Schicken Sie mir gleich einen neuen.“ Darin stecken Statusfrage, Reklamation und der Wunsch nach Ersatz. Eine freundliche allgemeine Antwort würde noch keinen dieser Vorgänge zuverlässig abschließen.

Der Chat klärt zunächst den erlaubten Bestellbezug und fragt nur die für den Prozess benötigten Informationen ab. Er kann die aktuelle Reklamationsanleitung erklären und einen Vorgang vorbereiten. Ob er Ersatz selbst auslösen darf, wird separat festgelegt. Fehlt diese Berechtigung oder hängt die Entscheidung von weiteren Nachweisen ab, erzeugt er eine Aufgabe für das Serviceteam.

Eine gute Übergabe enthält den verifizierten Bestellbezug, das Anliegen, bereits gestellte Fragen und den tatsächlichen Status. Der Bot sagt dann beispielsweise, dass eine Ersatzanfrage angelegt wurde. Er behauptet nicht, dass eine neue Lieferung unterwegs sei, solange kein entsprechend bestätigter Vorgang vorliegt.

Fällt die Ticketschnittstelle aus, muss der Chat den offenen Zustand sichtbar machen und einen passenden Ersatzweg anbieten. Eine Aussage wie „Das Team meldet sich“ wäre ohne erfolgreich übermittelte Anfrage unbegründet. Genau dieser Unterschied zwischen Formulierung und nachgewiesenem Ergebnis gehört in die Abnahme.

Eine Übergabe ist mehr als ein Link zum Kontaktformular. Das Team braucht einen Empfänger, eine Zuständigkeit und den erforderlichen Kontext. Außerhalb der Geschäftszeiten kann statt eines Live-Gesprächs ein Ticket oder Rückrufweg erforderlich sein. Diese Unterschiede sollten der Nutzeroberfläche und den Abschlussnachrichten entsprechen.

Microsoft beschreibt in seiner Dokumentation zur menschlichen Übergabe, wie Copilot Studio Gesprächsverlauf und Variablen an einen angebundenen Service weitergeben kann. Ob das im eigenen Projekt funktioniert, hängt von der konkreten Anbindung ab. Ein verfügbarer Produktbaustein ersetzt keine Prüfung des verwendeten Helpdesks.

Vereinbaren Sie Auslöser: ausdrücklicher Wunsch nach einer Person, fehlende Wissensquelle, wiederholtes Missverständnis und ausgeschlossene Aktionen. Prüfen Sie auch, ob ein Mensch die Unterhaltung tatsächlich übernehmen kann und ob der Bot danach keine widersprüchlichen Antworten mehr sendet. Die ausführliche Übergabe-Anleitung enthält passende Prüffälle.

Wählen Sie den Kanal nach dem Kundenweg. Ein Website-Chat kann Informationen am besuchten Produkt anbieten. Ein Messenger kann einen späteren Austausch ermöglichen, bringt aber eigene Plattformregeln und Abrechnung mit. Ein Helpdesk hält Bearbeitung und Zuständigkeit zusammen. Diese Systeme dürfen nicht unbeabsichtigt mehrere unverbundene Vorgänge für dasselbe Anliegen erzeugen.

Für die Website gehören mobile Bedienung, Ladeverhalten und ein sichtbarer alternativer Kontaktweg in die Auswahl. Für WhatsApp sind aktuelle Anbieterbedingungen, Nachrichtentypen, Vorlagen und Kosten gesondert zu prüfen. Die Anleitung zu WhatsApp im Unternehmen behandelt diese Voraussetzungen; die Kostenübersicht trennt Plattform und zusätzliche Betreuung.

Ein vorhandener Helpdesk kann bereits KI-Funktionen enthalten. Prüfen Sie diese an denselben Anliegen, bevor Sie eine weitere Oberfläche einführen. Zusätzliche Umsetzung sollte eine erkennbare Lücke schließen, etwa einen fehlenden Systemzugriff oder einen besonderen Freigabeweg. Der Anbietervergleich hilft, Funktionsversprechen in prüfbare Anforderungen zu übersetzen.

Ein Servicebot braucht freigegebene Antworten zu Produkten, Lieferbedingungen, Öffnungszeiten und erlaubten Aktionen. Ein beliebiger Website-Import kann dabei veraltete Kampagnen oder widersprüchliche Bedingungen übernehmen. Bestimmen Sie pro Themenbereich eine führende Quelle und eine verantwortliche Person. Markieren Sie zeitlich begrenzte Angebote so, dass ihr Ende berücksichtigt werden kann.

Wenn zwei Quellen widersprechen, sollte der Bot keine neue Unternehmensregel daraus formulieren. Der Konflikt gehört zur fachlichen Klärung. Für Österreich, Deutschland und die Schweiz können unterschiedliche Liefergebiete, Währungen oder Vertragsbedingungen gelten. Die Antwort muss den richtigen Geltungsbereich erkennen oder nachfragen. Eine Übersetzung allein passt keine Geschäftsregel an.

Microsoft beschreibt in seinem Überblick zu Kundenservice-Agenten unterschiedliche Wissensquellen und die Anbindung an Serviceplattformen. Für die eigene Einführung zählt die tatsächlich verfügbare Quelle mit ihren Zugriffsbedingungen. Die Anleitung zur Wissenspflege zeigt, wie Änderungen in einen kontrollierten Betrieb gelangen.

Eine hohe Zahl abgeschlossener Chats ist noch keine hohe Lösungsquote. Legen Sie zunächst fest, was als gelöst gilt: eine richtige Auskunft, ein bestätigter Systemvorgang oder eine erfolgreich angenommene Übergabe. Zählen Sie abgebrochene Gespräche nicht automatisch als erledigte Anliegen. Beachten Sie außerdem, ob dieselbe Person kurz danach wegen derselben Frage erneut Kontakt aufnimmt.

In einem erfundenen Monatsbeispiel beginnen 1.000 Chats. 450 liefern eine nach Prüfung ausreichende Information, 250 erzeugen korrekt zugewiesene Tickets, 100 enden mit einer bestätigten Aktion und 200 bleiben abgebrochen oder ungeklärt. Je nach Definition wären 550 direkt gelöst und 250 wirksam übergeben. „80 Prozent automatisch gelöst“ würde diese unterschiedlichen Ergebnisse vermischen.

Erfassen Sie daneben falsche Aussagen, unberechtigte Datenzugriffe, Bearbeitungszeit des Teams und Aufwand für Wissenspflege. Kritische Fehler gehören einzeln untersucht. Eine verbesserte Durchschnittsquote darf nicht verdecken, dass der Bot einer Person fremde Bestelldaten zeigt. Der Qualitätsleitfaden erläutert eine nachvollziehbare Auswertung.

Testen Sie den Chat auf kleinen Bildschirmen, mit Tastatur und mit unterstützenden Technologien. Nutzer sollten die Oberfläche öffnen, Nachrichten lesen, Eingaben korrigieren und den Chat wieder verlassen können. Neue Nachrichten dürfen wichtige Bedienelemente nicht unerreichbar machen. Die WCAG 2.2 bieten einen technischen Bezugspunkt für solche Prüfungen; die konkreten rechtlichen Pflichten sind gesondert zu beurteilen.

Informieren Sie verständlich über die KI-Interaktion und die Nutzung eingegebener Daten. Fragen Sie nur benötigte Informationen ab und legen Sie fest, welche Gesprächsdaten in Helpdesk, Analyse und Protokollen verbleiben. Ein kurzer Chat kann personenbezogene oder vertrauliche Angaben enthalten, auch wenn die ursprünglich geplante Frage öffentlich beantwortbar war.

Der Datenschutzleitfaden behandelt die DACH-Prüfung. Der Leitfaden zur Barrierefreiheit liefert konkrete Bedienfälle. Beide Prüfungen gehören zur Nutzbarkeit des Services und sollten gemeinsam mit den fachlichen Antworten getestet werden.

Vergleichen Sie Abonnement, nutzungsabhängige Abrechnung, Kanalgebühren, Integration, Inhaltsarbeit und laufende Betreuung. Bei einer Abrechnung je „Lösung“ oder Gespräch muss die Definition zum eigenen Serviceziel passen. Fragen Sie außerdem nach Testumgebung, Datenexport, Kontenbesitz und Aufwand bei Änderungen. Die Chatbot-Kostenübersicht hilft beim Aufbau einer vollständigen Kalkulation.

Vor dem Start benötigen Sie einen freigegebenen Themenumfang, dokumentierte Wissensquellen und erwartete Ergebnisse für typische und schwierige Gespräche. Testen Sie mindestens eine unbekannte Frage, einen gewünschten Menschenkontakt, eine fehlgeschlagene Aktion und einen Fall ohne ausreichende Identität. Der Bot muss dabei seine tatsächlichen Grenzen verständlich zeigen.

Benennen Sie anschließend Verantwortliche für Inhalte, technische Störungen und das Serviceergebnis. Prüfen Sie neue Beschwerden und ungeklärte Fragen regelmäßig, bevor Regeln geändert werden. Eine kontrollierte Änderung enthält ihren Grund, die betroffenen Quellen und einen erneuten Test. So wird der Chat zu einem nachvollziehbaren Servicekanal, dessen Nutzen auch nach der ersten Demo beurteilt werden kann.