Zurück zum BlogProduct Update

Warm Transfers: Outcomes und Consultation Notes

Famulors Update vom 29.08.2026 ergänzt klassifizierte Transfer-Outcomes, optionale Consultation Notes und klarere Fallbacks nach fehlgeschlagenen Übergaben.

Sarah Müller29. August 20266 Min. Lesezeit
Warm Transfers: Outcomes und Consultation Notes

Inhalt zusammenfassen mit:

Famulor hat Warm Transfers am 29.08.2026 erweitert. Wenn eine Übergabe nicht abgeschlossen wird, kann der Assistent mit einem klassifizierten Outcome zum Anrufer zurückkehren. Hat der Supervisor geantwortet und gesprochen, können optionale Consultation Notes zusätzlich die relevante Nachricht bereitstellen. Das Update verändert damit den Teil nach dem Anruf beim Ziel, ohne den grundsätzlichen Ablauf aus Halten, Briefing und Verbinden zu ändern. Die Transferarten im Überblick erklärt der Guide zur Übergabe eines KI-Anrufs an einen Menschen.

Das Wichtigste in Kürze

  • Ein nicht abgeschlossener Warm Transfer liefert immer einen klassifizierten Grund: busy, declined, no_answer oder temporarily_unavailable.
  • Consultation Notes sind im Flow Builder und beim Warm transfer Tool optional. Bei Loop Recall sind sie immer aktiv.
  • Das Supervisor-Transkript bleibt im Call Record, auch wenn das Teilen der Notes deaktiviert ist.
  • Wenn niemand antwortet, entstehen keine Consultation Notes. Der Assistent erhält nur das Outcome.
  • Ein failed-Event dokumentiert den Transferstatus. Der klassifizierte Grund steht im anbieterneutralen Failure-Objekt.

Was sich am 29.08.2026 geändert hat

Das Update betrifft den Moment, in dem ein Warm Handoff endet, bevor beide Seiten verbunden sind. Der Assistent muss einen nicht abgeschlossenen Versuch nicht mehr als undifferenzierten Fehler behandeln. Er erhält einen von vier klassifizierten Gründen und die ausdrückliche Anweisung, niemals eine Aussage zu erfinden, die der Supervisor nicht gemacht hat (Changelog vom 29.08.2026).

Situation Information für den Assistenten Consultation Notes
Ziel ist besetzt busy Keine, weil niemand gesprochen hat
Ziel lehnt ab declined Nur verfügbar, wenn der Supervisor gesprochen hat und das Teilen aktiv ist
Keine Antwort bis zum Timeout no_answer Keine, weil niemand gesprochen hat
Ziel ist vorübergehend nicht erreichbar temporarily_unavailable Keine, weil niemand gesprochen hat

Das Verhalten gilt für den Warm-transfer-Node im Flow Builder, das Warm transfer Tool und Famulor Loop Recall. Im Flow Builder und im Tool legt Share supervisor conversation with the AI (consultation notes) fest, ob der Assistent das Supervisor-Gespräch sieht. Für Loop Recall gibt es kein separates Transferformular. Deshalb sind Notes dort immer aktiv. Der frühere Produktguide zum Warm Transfer erklärt weiterhin das Grundprinzip. Dieses Update betrifft gezielt den Rückweg.

So läuft ein vollständiger Warm Transfer ab

Ein Warm Transfer folgt weiterhin vier Schritten. Der Anrufer wird gehalten, der Assistent ruft das Ziel an, das Ziel erhält eine KI-generierte Zusammenfassung und beide Seiten werden erst nach der Annahme verbunden. Die Node-Referenz des Flow Builders dokumentiert Ziel, ausgehende Rufnummer, Ansagen, Summary Instructions, Timeout, Wartemusik und Fallback.

Kommt die Verbindung nicht zustande, kann die Steuerung zur ursprünglichen Unterhaltung zurückkehren. Der Assistent nutzt dann das klassifizierte Outcome und, falls erlaubt und vorhanden, die Consultation Notes. Ein Supervisor kann mitteilen, dass er den Anruf nicht übernehmen kann, und um einen späteren Rückruf bitten. Der Assistent darf diese Nachricht weitergeben. Er darf aber keinen Grund, kein Versprechen, keine Uhrzeit und keine Anweisung ergänzen, die der Supervisor nicht genannt hat.

Warm Transfer und die Weitergabe an einen anderen KI-Assistenten sind unterschiedliche Aktionen. Bei Letzterer übernimmt eine andere KI das Gespräch, wie das Update zur Live-Übergabe an einen anderen Assistenten erläutert. Consultation Notes beziehen sich hier auf das Supervisor-Gespräch bei einem menschlichen Warm-Transfer-Versuch.

Praktische Checkliste für die Konfiguration

Konfigurieren Sie den Rückweg genauso bewusst wie die erfolgreiche Verbindung:

  1. Wählen Sie den Einstiegspunkt. Nutzen Sie den Warm-transfer-Node für einen deterministischen visuellen Ablauf. Verwenden Sie das Warm transfer Tool, wenn der Assistent anhand des Gesprächs entscheiden soll. Der Überblick zum Flow Builder liefert den Kontext für Node-basiertes Routing.
  2. Entscheiden Sie über Consultation Notes. Aktivieren Sie die Option, wenn der Assistent nach einem nicht abgeschlossenen Handoff eine relevante Supervisor-Nachricht weitergeben soll. Lassen Sie sie aus, wenn der Rückweg nur das klassifizierte Outcome verwenden soll. Das Transkript bleibt im Call Record.
  3. Setzen Sie den Ringing Timeout. Zulässig sind 5 bis 120 Sekunden, Standard sind 30 Sekunden. Testen Sie den Wert mit dem tatsächlichen Annahmeverhalten des Zielteams.
  4. Wählen Sie einen Fallback. Bei fehlender Antwort oder Ablehnung kann der Assistent das Gespräch fortsetzen, den Anruf beenden oder einen Blind Transfer ausführen. Für eine Rückkehr mit Nachricht muss das ursprüngliche Gespräch aktiv bleiben.
  5. Überwachen Sie Events und Fehlerdetails. Warm Transfers schreiben die Events started, completed und failed. Schlägt ein Transfer bei aktivem Ursprungsanruf fehl, enthält das Event Log warm_transfer_failed. Das anbieterneutrale Failure-Objekt trägt den klassifizierten Code (Ergebnisse für ein- und ausgehende Anrufe).

Verwenden Sie das Event failed nicht als Grund gegenüber dem Anrufer. Lesen Sie den Failure-Code, führen Sie den konfigurierten Fallback aus und behandeln Sie eine Supervisor-Nachricht getrennt von der Telefonieklassifizierung.

Fünf Tests vor dem Rollout

Prüfen Sie diese Fälle für jedes Ziel und jede geplante Fallback-Kombination:

Test Aufbau Erwartetes Ergebnis
1. Übergabe angenommen Supervisor antwortet und akzeptiert Beide Seiten werden verbunden; die Eventfolge erreicht completed
2. Abgelehnt, Notes aktiv Supervisor bittet um späteren Rückruf und lehnt dann ab Assistent kehrt zurück, erhält declined und gibt nur die relevante Aussage weiter
3. Abgelehnt, Notes aus Supervisor spricht, das Teilen ist deaktiviert und er lehnt ab Assistent erhält declined, aber keine Notes; Transkript bleibt im Call Record
4. Ziel besetzt Ziel meldet besetzt Assistent erhält busy, es entstehen keine Notes und der Fallback läuft
5. Keine Antwort und nicht erreichbar Ein Lauf endet im Timeout, ein weiterer mit vorübergehend nicht erreichbarem Ziel Codes lauten no_answer und temporarily_unavailable; beide Läufe erzeugen keine Notes

Prüfen Sie außerdem Wartemusik, Connected Message, Timeout-Grenzen und ob ein Continue-Fallback an einer verständlichen Stelle im ursprünglichen Flow fortsetzt. Der Assistent darf nicht behaupten, der Supervisor habe die Anfrage abgelehnt, einen Rückruf versprochen oder einen Grund genannt, sofern diese Aussage nicht in den geteilten Notes steht.

Warum die Trennung wichtig ist

Das Update trennt drei Aufzeichnungen mit unterschiedlichen Aufgaben. Transfer-Events zeigen den Lebenszyklus. Das Failure-Objekt vereinheitlicht Provider-Outcomes. Consultation Notes enthalten nur den Supervisor-Kontext, den der Assistent verwenden darf. Diese Trennung erleichtert Tests und verhindert, dass ein Telefonieergebnis als menschliche Aussage dargestellt wird.

Die Nachvollziehbarkeit bleibt erhalten. Wenn Sie das Teilen der Notes deaktivieren, wird das Supervisor-Transkript nicht aus dem Call Record entfernt. Ihr Team kann den Ablauf nach dem Anruf prüfen, ohne das Gespräch während des Live-Rückwegs automatisch an den Assistenten zu übergeben.

Häufig gestellte Fragen

Sieht der Assistent immer das Supervisor-Transkript?

Nein. Im Flow Builder und im Warm transfer Tool bestimmen Consultation Notes, ob der Assistent das Gespräch erhält. Das Transkript wird trotzdem im Call Record gespeichert. Bei Loop Recall sind Notes immer aktiv.

Was passiert, wenn niemand antwortet?

Der Assistent erhält das klassifizierte Outcome, etwa busy, no_answer oder temporarily_unavailable. Es gibt keine Consultation Notes, weil kein Supervisor-Gespräch stattgefunden hat.

Ist failed der Grund, den der Assistent nennen soll?

Nein. failed ist ein Transfer-Eventstatus. Das anbieterneutrale Failure-Objekt enthält den klassifizierten Grund. Der Assistent soll dieses Outcome korrekt beschreiben und eine Supervisor-Nachricht nur weitergeben, wenn geteilte Notes sie belegen.

Nächster Schritt

Prüfen Sie alle aktiven Warm-Transfer-Konfigurationen, entscheiden Sie, wo Consultation Notes sinnvoll sind, und führen Sie vor dem Einsatz die fünf Testfälle durch. Wenn Sie das Verhalten mit Ihrem eigenen Flow und Ihren Transferzielen bewerten möchten, buchen Sie eine persönliche Demo.

Über die Autorin

Sarah Müller verfasst Produkt- und Implementierungsupdates für Famulor. Bei Fragen zu diesem Update erreichen Sie den Support. Hinweise zur Datenverarbeitung finden Sie in der Datenschutzerklärung.

SM
Sarah Müller

Autor bei Famulor

KI-Telefonassistent

Alles inklusive, ein Tarif. Famulor testen

Voice AI, Workflows und Integrationen in einer Plattform.

Famulor AI eingehender Anruf auf einem Smartphone
Newsletter

Anrufe automatisiert. Kunden begeistert.

Abonniere unseren Newsletter, um die neuesten Nachrichten, Produktupdates und kuratierte KI-Inhalte zu erhalten.