Variable Mapping
Funktion um bei der Anrufanalyse mit Variablen Auswahlfelder zu steuern.
Geschrieben von Jonathan Haueis
Zuletzt aktualisiert Vor 5 Monaten
Einleitung
Variable Mapping ermöglicht, Integrations-Elemente mit Variablen zu steuern. So kann zum Beispiel der Ticketstatus automatisch anhand von Anrufdaten gesetzt werden. Im Folgenden zeigen wir die Konfiguration Schritt für Schritt. Anschließend testen wir die Konfiguration. Zum Schluss erklären wir, wie abhängige Parameter konfiguriert werden.
Einrichtung
Ziel: Die KI erstellt ein HubSpot-Ticket, leitet aus dem Gespräch die Priorität ab und setzt die Ticket-Priorität automatisch.
Dafür öffnen wir zuerst die Anrufanalyse.
Als Nächstes fügen wir eine der umkreisten Integrationen hinzu. In unserem Fall: HubSpot.
Achtung: Falls die hier gezeigten Integrationen nicht angezeigt werden, musst du die gewünschte Integration zuerst mit Smao verbinden.
Als Nächstes verbindest du HubSpot mit dem Start-Element.
Daraufhin erstellen wir in der Anrufanalyse eine Variable und verwenden “Variable Mapping“ zur dynamischen Zuordnung.
Expertentipp: Durch die Verbesserung des Prompts entsteht meist die größte Wirkung!
Als Nächstes gehen wir zu dem Integrations-Element “HubSpot – Create Ticket“, wählen im Feld “Priority“ die Option “Variable Mapping“ und öffnen das Konfigurationsfenster.
Zuerst sehen wir uns den oberen Bereich “Mapping Matrix“ an. Links legen wir eine Bedingung fest. Als Variable wählen wir die zuvor erstellte Variable “Priorität“. In der Mitte steht der Operator. Aktuell verfügbar sind die Optionen: = und ≠. Für unseren Fall benötigen wir =. Als Value wählen wir einen der zuvor definierten Werte. Beginnen wir mit dem Wert Dringend.
Zusatz: Bedingungen können auch verknüpft werden. Wenn der Button “+ Add condition” ausgewählt wird, erscheint eine weitere Bedingung, die mit der ersten verbunden ist.
Als Verbindung kann AND oder OR gewählt werden.
AND - Es müssen beide Bedingungen zutreffen
OR - Es reicht wenn eine Bedingung zutrifft
Für unser Beispiel nicht nötig, daher entfernen wir die zweite Bedingung wieder.
Als Nächstes legen wir das Feld “→ When met“ fest. Die Auswahl enthält die möglichen Werte für dieses Feld. In unserem Fall passt “Urgent“. Dieser Wert wird im Feld “Priority“ gesetzt, wenn die zuvor definierte Bedingung erfüllt ist.
Nun haben wir die erste “Rule“ erfolgreich definiert. Über “+ Add Rule“ fügen wir eine weitere Rule hinzu. Die nächsten “Rules” werden wie folgt definiert:
Hinweis: Die Rules werden von oben nach unten ausgewertet. Die erste zutreffende Rule ist entscheidend.
Das letzte Feld, das nun konfiguriert werden muss, ist der Fallback. Hier wählen wir den Wert, der gesetzt wird, wenn keine der zuvor definierten Bedingungen zutrifft.
Fun Fact: Wer aufmerksam war, erkennt, dass wir uns die letzte Bedingung hätten sparen können, weil der Fallback ohnehin “Low“ setzt. So wird die Konfiguration effizienter.
Danach speichern. Ab jetzt übernimmt die KI die Priorisierung.
Testen
Jetzt prüfen wir, ob alles wie geplant funktioniert. Als Erstes füllen wir die restlichen Felder aus. Dafür habe ich zwei weitere Variablen angelegt:
Achtung: Die Analyse muss dem Assistenten zugeordnet sein. Sonst funktioniert es nicht!
Expertentipp: Klappe im Anrufprotokoll rechts die Analyse aus, um Ergebnisse und ausgefüllte Variablen zu sehen. So erkennst du Fehler schnell und kannst bei Bedarf die Konfiguration korrigieren oder verbessern.
Test 1: Ticket mit Dringender Priorität
Anrufprotokoll:
Hubspot Ticket:
Test 2: Ticket mit Hoher Priorität
Anrufprotokoll:
Hubspot Ticket:
Test 3: Ticket mit Mittlerer Priorität
Anrufprotokoll:
Hubspot Ticket:
Test 4: Ticket mit Niedriger Priorität
Anrufprotokoll:
Hubspot Ticket:
Variable Mapping: Parameter mit Abhängigkeit
Es gibt Parameter, die andere Parameter beeinflussen. Beispielsweise hängen bei HubSpot die vorhandenen Werte des Felds “Status“ davon ab, was im Feld “Pipeline“ ausgewählt wurde.
Wenn ich bei “Pipeline“ den Wert “Variable Mapping“ auswähle, wechselt auch der Wert von “Status“ auf “Variable Mapping“.
Das ist notwendig, weil für jeden möglichen “Pipeline” Wert ein anderer Status gesetzt werden muss. Daher unterscheidet sich das Design eines solchen Parameters leicht:
Wie zu sehen ist, gibt es die Überschrift “Dependency Pipeline = Support Pipeline“. In diesem Fall ist es einfach, denn bei unserem HubSpot-System ist nur eine Pipeline konfiguriert. Es kann aber auch mehrere geben. In einem solchen Fall gäbe es unter diesem Bereich einen identischen Abschnitt für jede dieser Pipelines. Auch hier können wie gewohnt “Rules“ und “Fallbacks“ eingetragen werden.
Expertentipp: Wenn hier keine „Rules“ gewünscht sind, können sie gelöscht und nur ein “Fallback“ eingetragen werden. Dann wird dieser Wert in diesem Szenario immer gesetzt.
