Skip to main content

​
Appels entrants

Acheminez n’importe quel numéro — acheté sur la marketplace ou apporté via un Trunk SIP en BYO — vers un assistant :
  1. Phone numbers → select number → assign assistant.
  2. Les appels entrants sont pris en charge par cet assistant, selon son mode d’accueil (parler en premier, ou attendre que l’appelant parle).
  3. L’enregistrement (avec gestion du consentement si activé), la transcription et les événements d’appel se font automatiquement.
L’association numéro → assistant est résolue à chaque appel : vous pouvez donc réattribuer un numéro à tout moment sans toucher au numéro lui-même.

​
Appels sortants

Trois façons de passer des appels :
  • Appel unique depuis l’interface — sur la page d’un assistant, saisissez un numéro et appelez : idéal pour tester.
  • API / MCP — make_call avec assistant_id et to_number, ainsi que des données de lead facultatives que l’assistant peut utiliser en conversation (nom, champs personnalisés). Voir la référence API.
  • Campaigns — appels sortants en masse sur une liste de leads avec logique de composition ; voir Campagnes.
Détails du comportement en sortant :
  • L’assistant ne salue qu’une fois que l’appelé a décroché (pas de prise de parole pendant la sonnerie).
  • Les issues sans réponse sont mappées sur des statuts clairs : busy, no_answer, failed — la logique de relance des campagnes s’appuie dessus.
  • Avec le greeting mode: user speaks first, l’assistant attend le « Allô ? » de l’appelé — nettement plus naturel pour les appels à froid.
  • La answering machine detection (AMD), optionnelle, identifie qui a décroché (humain / messagerie vocale / SVI) et peut laisser un message vocal configuré ; voir Dialer et conformité.

​
Indications en cas d’échec

POST /api/v1/calls renvoie immédiatement l’appel mis en file d’attente. Interrogez GET /api/v1/calls/{id}, utilisez get_call, ou consommez call.completed pour obtenir le résultat final. Les appels sortants en échec incluent un objet failure indépendant du fournisseur :
Les codes courants incluent busy, declined, no_answer, temporarily_unavailable, invalid_destination, authentication_failed, destination_forbidden, trunk_unavailable, et no_outbound_trunk. retryable est une indication destinée à votre intégration. Cela ne modifie pas les réglages de relance des campagnes. Si un transfert à froid ou à chaud échoue alors que l’appel d’origine reste actif, le journal d’événements de l’appel contient call_transfer_failed ou warm_transfer_failed. Ces événements utilisent la même structure failure, avec operation: cold_transfer ou warm_transfer.

​
Appels web

Chaque assistant peut aussi être appelé depuis le navigateur — c’est ce qu’utilisent l’appel de test intégré et le widget web embarquable. Les appels web apparaissent dans l’historique des appels avec la direction web.

​
Résultats d’appel

Chaque appel — quelle que soit sa direction — produit : une transcription, une durée et un statut, des indications d’échec indépendantes du fournisseur le cas échéant, des métriques de latence par tour de parole, un journal d’événements (appels d’outils, transferts, consentement, transitions de nœuds), un enregistrement optionnel, et un webhook call.completed.