Kontexte

Kontexte sind frei definierbare Labels, die einer Chatbot-Sitzung zugewiesen werden können. Sie ermöglichen es, denselben Chatbot in verschiedenen Einsatzszenarien unterschiedlich zu verhalten – ohne separate Chatbot-Instanzen aufzusetzen.

Ein Kontext könnte zum Beispiel sein:

• public – für den öffentlichen Website-Messenger
• intranet – für einen internen Mitarbeiter-Chatbot
• support – für ein Kundensupport-Portal

Wie Kontexte wirken

Agenten und Tool-Implementierungen können auf bestimmte Kontexte eingeschränkt werden. Passt der aktive Kontext einer Sitzung nicht zu einem Agenten, wird dieser nicht berücksichtigt. So lassen sich z.B. ein FAQ-Agent nur im öffentlichen Kontext und ein HR-Agent nur im Intranet-Kontext aktivieren – obwohl es sich um denselben Chatbot handelt.

Da auch Tools kontextabhängig konfiguriert werden können, lässt sich steuern, welche Wissensquellen für das Beantworten von Fragen herangezogen werden. Im Kontext public könnte der Chatbot z.B. nur auf öffentliche Inhalte zugreifen, im Kontext intranet zusätzlich auf interne Dokumente und Richtlinien.

Ist kein Kontext konfiguriert, ist der Agent bzw. das Tool in allen Kontexten aktiv.

Konfiguration

Die verfügbaren Kontextnamen werden serverseitig konfiguriert. Welcher Kontext beim Start eines Chats aktiv ist, bestimmt eine projektspezifische Logik, die individuell programmiert wird. Diese Logik kann auf beliebige Informationen zurückgreifen, zum Beispiel:

• Aktuelle URL – z.B. wird auf intranet.example.com automatisch der Kontext intranet gesetzt, auf www.example.com der Kontext public
• Benutzersession – ist ein Nutzer eingeloggt, erhält der Chat einen anderen Kontext als für anonyme Besucher
• Benutzerrolle oder -berechtigung – ein Nutzer mit der Rolle «HR» sieht andere Agenten als ein normaler Mitarbeitender
• Sprache oder Region – für mehrsprachige Portale kann der Kontext je nach aktiver Sprache oder Ländereinstellung variieren
• Einstiegspunkt oder Quelle – ein Chat, der über eine Kampagnenseite gestartet wird, erhält einen anderen Kontext als einer über den allgemeinen Support
• Tageszeit oder Geschäftsstunden – ausserhalb der Öffnungszeiten kann ein abweichender Kontext mit angepasstem Verhalten aktiv sein
• Externe Abhängigkeiten – der Kontext kann auch anhand von Daten aus Drittsystemen bestimmt werden, z.B. dem Status eines Kunden im CRM