Skip to main content

​
Eingehend

Leite eine beliebige Nummer – gekauft im Marktplatz oder per eigenem Trunk (BYO) mitgebracht – an einen Assistenten weiter:
  1. Telefonnummern → Nummer auswählen → Assistenten zuweisen.
  2. Eingehende Anrufe werden von diesem Assistenten beantwortet, je nach Begrüßungsmodus (zuerst sprechen oder auf den Anrufer warten).
  3. Aufzeichnung (mit Einwilligungsverwaltung, falls aktiviert), Transkription und Anruf-Events laufen automatisch ab.
Die Zuordnung Nummer → Assistent wird pro Anruf neu aufgelöst – du kannst Nummern also jederzeit anders zuweisen, ohne die Nummer selbst anzufassen.

​
Ausgehend

Drei Wege, um Anrufe zu tätigen:
  • Einzelanruf über die Oberfläche – Gib auf einer Assistenten-Seite eine Nummer ein und ruf an: ideal zum Testen.
  • API / MCP – make_call mit assistant_id und to_number, plus optionalen Lead-Daten, die der Assistent im Gespräch nutzen kann (Name, benutzerdefinierte Felder). Siehe die API-Referenz.
  • Kampagnen – Massenausgang über eine Lead-Liste mit Dialer-Logik; siehe Kampagnen.
Details zum Verhalten bei ausgehenden Anrufen:
  • Der Assistent begrüßt erst, wenn der Angerufene abgenommen hat (kein Sprechen ins Klingeln).
  • Unbeantwortete Anrufe werden auf eindeutige Status abgebildet: busy, no_answer, failed – die Retry-Logik von Kampagnen baut darauf auf.
  • Im Begrüßungsmodus: Gesprächspartner spricht zuerst wartet der Assistent auf das „Hallo?” des Angerufenen – spürbar natürlicher bei Kaltakquise.
  • Die optionale Anrufbeantworter-Erkennung (AMD) klassifiziert, wer abgenommen hat (Mensch / Voicemail / IVR), und kann eine hinterlegte Voicemail-Nachricht hinterlassen; siehe Dialer & Compliance.

​
Hinweise bei Fehlern

POST /calls liefert den Anruf sofort mit Status queued. Frage anschließend GET /calls/{id} oder get_call ab oder verarbeite call.completed, um das endgültige Ergebnis zu erhalten. Fehlgeschlagene ausgehende Anrufe enthalten ein anbieterneutrales failure-Objekt:
Häufige Codes sind busy, declined, no_answer, temporarily_unavailable, invalid_destination, authentication_failed, destination_forbidden, trunk_unavailable und no_outbound_trunk. Das Objekt enthält niemals rohe SIP-Antworten, Zugangsdaten, Infrastruktur-IDs oder SDK-Fehlertexte. retryable ist ein Hinweis für deine Integration und verändert die Retry-Einstellungen einer Kampagne nicht. Schlägt ein Cold- oder Warm-Transfer fehl, während der ursprüngliche Anruf weiterläuft, enthält das Event-Log call_transfer_failed beziehungsweise warm_transfer_failed. Diese Events verwenden denselben failure-Vertrag mit operation: cold_transfer oder warm_transfer.

​
Webanrufe

Jeder Assistent lässt sich auch aus dem Browser anrufen – genutzt vom eingebauten Testanruf und dem einbettbaren Web-Widget. Webanrufe erscheinen im Anrufverlauf mit der Richtung web.

​
Anrufergebnisse

Jeder Anruf – unabhängig von der Richtung – liefert: ein Transkript, Dauer und Status, bei Bedarf anbieterneutrale Fehlerhinweise, Latenz-Metriken pro Turn, ein Event-Log (Tool-Aufrufe, Übergaben, Einwilligung, Node-Übergänge), optionale Aufzeichnung und einen call.completed-Webhook.