Passer au contenu principal
Le failover est une fonctionnalité avancée disponible uniquement pour les agents entrants. Elle n’est pas activée par défaut. Contactez votre Customer Success Manager pour l’activer.
Les workflows de failover sont particulièrement utiles pour gérer les erreurs de manière personnalisée et garantir la continuité de service :
  • Transférer l’appel vers un conseiller en cas d’infrastructure indisponible
  • Jouer un message d’indisponibilité adapté au contexte
  • Router intelligemment les appels selon le profil client malgré l’erreur
Le workflow de failover se compose de deux étapes principales obligatoires :
  1. Déclencheur de failover - Initialise le workflow avec le contexte pré-appel disponible
  2. Retour de l’action de failover - Définit l’action à exécuter (transfert d’appel ou message vocal)

​
Configuration du déclencheur de failover

Le déclencheur de failover est le point de départ de votre workflow. Il vous donne accès au contexte pré-appel pour déterminer la meilleure stratégie de secours.
1

Créer un échantillon de données

Pour tester efficacement votre workflow, vous devez générer un échantillon de données représentatif :
  1. Dans l’interface de configuration, localiser la section Générer un échantillon de données
  2. Cliquer sur le bouton Charger un échantillon de données
2

Configurer les données de test

Une fois l’échantillon chargé, vous pouvez personnaliser les données selon vos besoins :
  1. Copier et coller les données dans la zone Test input data
  2. Modifier les valeurs pour simuler différents contextes
  3. Cliquer sur Tester pour valider la configuration
Le workflow de failover reçoit le contexte pré-appel qui était disponible avant l’erreur, ainsi que les variables système (numéro de l’appelant, agent concerné, etc.). Il ne reçoit pas d’informations sur la raison qui a déclenché le failover.
S’assurer que le format JSON est valide avant de tester votre configuration. Un format incorrect entraînera des erreurs lors de l’exécution du workflow.

​
Configuration du retour

La dernière étape du workflow permet de définir l’action de failover qui sera exécutée pour gérer l’erreur.
Le workflow de failover peut fonctionner de deux manières :
  1. Sans retour d’action : Le workflow effectue uniquement des actions (appels API, notifications, etc.) et l’appel sera raccroché à la fin de l’exécution du webhook
  2. Avec retour d’action : Le workflow se termine par un Return Context contenant une action de failover (message vocal ou transfert d’appel)
Le retour de l’action de failover permet de :
  • Définir le comportement de secours adapté au contexte
  • Transférer intelligemment l’appel vers les bonnes ressources
  • Personnaliser les messages d’erreur selon le profil client
  • Garantir une expérience utilisateur cohérente malgré l’erreur technique
Dans l’interface de l’étape Return Context, vous pouvez définir la structure de la réponse au format JSON en utilisant le sélecteur de données pour accéder aux variables des étapes précédentes.

Configurez les actions de failover

​
Structure du retour

Dans l’interface de l’étape Return Context, vous devez retourner une action de failover au format JSON. Deux types d’actions sont disponibles :

​
Option 1 : Transfert d’appel

Transfère l’appel vers un numéro de téléphone ou une destination SIP. Transfert vers un numéro de téléphone : 
{
  "type": "FAILOVER_TRANSFER_CALL",
  "config": {
    "phone": "+33199001234",
    "ringTimeout": 30
  }
}
Transfert via connexion SIP : 
{
  "type": "FAILOVER_TRANSFER_CALL",
  "config": {
    "phone": "sip-destination-id",
    "sipOutboundConnectionId": "connection-id",
    "headers": {
      "X-Customer-Tier": "premium"
    },
    "standardSipHeaders": {
      "User-To-User": "custom value"
    },
    "ringTimeout": 30
  }
}
Paramètres :
  • type : Doit être "FAILOVER_TRANSFER_CALL"
  • config.phone :
    • Sans connexion SIP : Numéro de téléphone au format international (ex: +33199001234)
    • Avec connexion SIP : Identifiant de la destination SIP
  • config.ringTimeout : Durée maximale de sonnerie en secondes avant d’interrompre le transfert et de reprendre l’appel avec l’agent (défaut : 30)
  • config.sipOutboundConnectionId (optionnel) : Identifiant de la connexion SIP sortante à utiliser
  • config.headers (optionnel) : En-têtes SIP personnalisés (format clé-valeur). Utilisable uniquement si sipOutboundConnectionId est spécifié
  • config.standardSipHeaders (optionnel) : En-tête SIP standard User-To-User à personnaliser. Utilisable uniquement si sipOutboundConnectionId est spécifié. Format : {"User-To-User": "valeur"}

​
Option 2 : Message vocal

Joue un message vocal puis termine l’appel. 
{
  "type": "FAILOVER_SAY",
  "config": {
    "sentence": "Nos services sont temporairement indisponibles. Merci de rappeler ultérieurement.",
    "language": "fr-FR"
  }
}
Paramètres :
  • type : Doit être "FAILOVER_SAY"
  • config.sentence : Le texte à prononcer à l’appelant
  • config.language : La langue du message (format ISO : fr-FR, en-US, etc.)
L’appel sera automatiquement terminé après la lecture du message. Assurez-vous que votre message est clair et complet.