Pre Processing¶
Kontext bei Anrufbeginn
Pre Processing fragt Informationen aus Ihrem externen System ab, sobald ein Voice Call startet. Das Ergebnis wird als {pre_call_context} gespeichert und steht dem Agenten im selben Gespräch zur Verfügung.
Nutzen Sie es als Unterstützung für einen funktionierenden Ablauf, nicht als Rettung für einen unklaren Prompt.
Pre Processing ist nützlich, wenn der Agent vor der ersten inhaltlichen Antwort etwas über den Anrufer wissen soll: Kundenname, Account-Stufe, offener Ticketstatus oder anderer kurzer Betriebskontext.
Es ist kein Tool. Ein Tool läuft, wenn der Agent es während des Gesprächs auswählt. Pre Processing ist eine tenantweite Anrufersuche, die automatisch bei Anrufbeginn läuft.
Wo finden?¶
Im Tenant-Menü als Pre Processing.
Die Seite konfiguriert eine Caller Lookup-Abfrage. Diese Abfrage nutzt eine einzelne HTTP-GET-Anfrage an Ihr externes System.
Wie es funktioniert¶
Wenn ein eingehender Voice Call eine Conversation erzeugt, startet Nuvoca die Abfrage.
Die Begrüßung wird trotzdem sofort abgespielt. Wenn die Abfrage noch läuft, wenn der Anrufer zum ersten Mal spricht, wartet die erste Agentenantwort darauf. Danach steht das gespeicherte Ergebnis im Prompt derselben Conversation als {pre_call_context} zur Verfügung.
Der Prompt entscheidet, wie der Agent diesen Kontext nutzt. Die Abfrage liefert nur Informationen; sie definiert nicht den Gesprächsablauf.
Wann Pre Processing sinnvoll ist¶
| Szenario | Gute Nutzung von Pre Processing |
|---|---|
| CRM-Datensatz über Telefonnummer nachschlagen | Kundenname oder Accountstatus vor der ersten Antwort bereitstellen |
| Priorisierte Anrufer erkennen | Tier, SLA oder Prioritätsflag in {pre_call_context} speichern |
| Callback-Flow personalisieren | Bekannte Anrufer natürlicher begrüßen |
| Offenen Ticket- oder Bestellstatus prüfen | Kurzen Statushinweis vor Rückfragen bereitstellen |
| Unklaren Prompt reparieren | Dafür nicht nutzen. Prompt zuerst korrigieren. |
Lookup-Einstellungen¶
| Einstellung | Bedeutung | Empfehlung |
|---|---|---|
| Enable pre-processing lookup | Schaltet die Anrufersuche ein oder aus | Erst aktivieren, wenn der Basisanruf funktioniert |
| Target URL | Externer Endpunkt, der per HTTP GET aufgerufen wird |
Stabilen Endpunkt nutzen, der schnell antwortet |
| Timeout (ms) | Maximale Wartezeit für die Abfrage | Mit dem Standard starten, außer das System braucht mehr Zeit |
| OAuth configuration | Nutzt eine vorhandene OAuth-Konfiguration | Wenn möglich besser als manuelle Authorization-Header |
| Response storage | Legt fest, welcher Teil der Antwort gespeichert wird | Für große Antworten JSON fields nutzen |
Nur GET
Pre Processing nutzt eine einzelne HTTP-GET-Anfrage. Es gibt keine POST-Anfrage und keinen Request Body. Übergeben Sie Werte über Query-Parameter oder Header.
Request-Variablen¶
Die UI zeigt, welche Variablen für die Lookup-Anfrage verfügbar sind. Eine typische erste Variable ist:
{caller_phone_number}— die eingehende Telefonnummer des aktiven Voice Calls
Nutzen Sie Request-Variablen in Query-Parametern oder nicht-sensiblen Headern.
Beispiel für einen Query-Parameter:
| Key | Value |
|---|---|
phone |
{caller_phone_number} |
Header und OAuth¶
Header werden mit der GET-Anfrage gesendet. Nutzen Sie sie für normale Integrationswerte wie API Keys, Tenant IDs oder Routing-Informationen.
Markieren Sie API Keys oder Tokens als sensitive Header-Werte, wenn die UI das anbietet. Wenn Sie eine OAuth configuration auswählen, sollte sie die Autorisierung der Anfrage übernehmen. Vermeiden Sie doppelte Authorization-Logik, außer Ihre Integration verlangt sie.
Response Storage¶
Pre Processing kann die Antwort auf zwei Arten speichern.
| Modus | Was gespeichert wird | Geeignet für |
|---|---|---|
| Whole response | Der vollständige Response Body wird als {pre_call_context} gespeichert |
Kurze, bereits gut lesbare Antworten |
| JSON fields | Ausgewählte JSON-Werte werden in gespeicherte Schlüssel gemappt | Größere JSON-Antworten, bei denen nur wenige Felder relevant sind |
Whole response¶
Nutzen Sie Whole response, wenn das externe System bereits ein kurzes, prompt-freundliches Ergebnis liefert.
Beispiel:
Wenn die Antwort lang oder unübersichtlich ist, speichern Sie nicht alles. Wechseln Sie zu JSON fields.
JSON fields¶
Nutzen Sie JSON fields, wenn das externe System mehr Daten liefert, als der Agent braucht.
Fügen Sie eine Zeile pro Wert hinzu, den Sie behalten möchten:
| Response path | Stored key |
|---|---|
customer.name |
caller_name |
customer.tier |
customer_tier |
ticket.status |
ticket_status |
Starten Sie mit zwei oder drei Feldern. Erweitern Sie erst, wenn der Prompt diese Felder zuverlässig nutzt.
{pre_call_context} im Prompt nutzen¶
Ergänzen Sie im Agenten-Prompt einen kurzen Abschnitt, der erklärt, wie der Lookup-Kontext genutzt werden soll.
## Caller context
If {pre_call_context} contains customer information, use it to personalize the conversation and avoid asking for information that is already known.
If the lookup returned no useful information, continue with the standard callback flow and ask for the caller's name as usual.
Do not mention the lookup itself to the caller.
Der Fallback muss ausdrücklich sein. Externe Systeme können langsam, leer oder zeitweise nicht erreichbar sein.
Lookup testen¶
Nutzen Sie Send Test, bevor Sie die Abfrage in Live-Anrufen verwenden.
Der Test zeigt:
- die konfigurierte HTTP-Anfrage,
- die Verarbeitung der Antwort,
- den abgeleiteten Prompt-Wert, der zu
{pre_call_context}wird.
Wenn der abgeleitete Prompt-Wert zu lang oder schwer lesbar ist, ändern Sie zuerst Response Storage und nicht den Agenten-Prompt.
Häufige Fehler¶
Request Body erwarten¶
Pre Processing ist GET only. Werte gehören in Query-Parameter oder Header.
Kein Fallback für fehlenden Kontext¶
Der Prompt muss auch funktionieren, wenn {pre_call_context} leer ist. Machen Sie den gesamten Ablauf nicht davon abhängig, dass die Abfrage erfolgreich ist.
Zu viele Daten speichern¶
Große CRM-Antworten können den Agenten ablenken. Nutzen Sie bei umfangreichen Antworten lieber wenige gemappte JSON-Felder statt die komplette Antwort.
Pre Processing statt Tools verwenden¶
Pre Processing bereitet Kontext zu Beginn des Anrufs vor. Es sendet keine E-Mails, erstellt keine Tickets und aktualisiert keine externen Systeme. Nutzen Sie dafür Tools oder Post Processing.
Als Nächstes lesen¶
- Agent-Optionen, um
{pre_call_context}sicher in Prompts einzubauen - Prompting, um Kontextanweisungen klar zu halten
- Voice Debug Monitor, um Lookup-Ergebnisse während eines Anrufs zu prüfen
- Post Processing für Aktionen nach dem Anruf