Skip to main content

​
Eingehende Anrufe

Leite eine beliebige Nummer – gekauft im Marktplatz oder per eigenem Trunk (BYO) mitgebracht – an einen Assistenten weiter:
  1. Phone numbers → select number → assign assistant.
  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.

​
Ausgehende Anrufe

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.
  • Campaigns – 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 greeting mode: user speaks first wartet der Assistent auf das „Hallo?“ des Angerufenen – spürbar natürlicher bei Kaltakquise.
  • Die optionale answering machine detection (AMD) klassifiziert, wer abgenommen hat (Mensch / Voicemail / IVR), und kann eine hinterlegte Voicemail-Nachricht hinterlassen; siehe Dialer & Compliance.

​
Hinweise bei Fehlern

POST /api/v1/calls liefert den Anruf sofort mit Status queued. Frage anschließend GET /api/v1/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. Die History zeigt einen kurzen Grund zusammen mit dem gespeicherten SIP-Code, zum Beispiel Anschluss gesperrt · SIP 403. Ein gesperrter Anschluss (caller_blocked) setzt eine eindeutige Rückmeldung voraus; bei einem allgemeinen 403 steht Anruf nicht erlaubt. Routingkonflikte (routing_conflict) und bestätigte Routing-Schleifen (routing_loop) werden unterschieden, ebenso nicht unterstützte Methoden (method_not_allowed), Zeitüberschreitungen beim Verbindungsaufbau (connection_timeout), nicht angenommene Anrufe (no_answer) und abgebrochene Anfragen (cancelled_before_answer). Weitere Meldungen betreffen Anmeldung, Rufnummer, Anrufformat, Routing, Sicherheit und Telefonnetz. Technische Details lassen sich aufklappen. Ein lokales Zeitlimit ohne SIP-Antwort bekommt keinen SIP-Code. Bestehende Anrufe nutzen die gespeicherte Rückmeldung, soweit vorhanden. Dieselben kurzen Gründe stehen über REST, MCP und Anruf-Webhooks zur Verfügung. 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.
Test-Menü des Assistenten mit Web Call und Call

Im Test-Menü des Assistenten startet Web Call einen Sprachtest im Browser. Über Call gibst du ein Ziel für einen ausgehenden Telefontest ein.

​
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.