Types de nœuds
Chaque action dans un flux conversationnel est un nœud. Les nœuds sont reliés par des arêtes qui définissent l'ordre d'exécution. Les nœuds principaux sont : trois nœuds d'entrée qui démarrent un appel (Start Inbound ou Chatbot pour les appels entrants, Start Outbound pour les appels passés par une campagne), un nœud Agent conversationnel, et deux nœuds terminaux qui transfèrent l'appel ou y mettent fin. Des nœuds de flux optionnels peuvent être rendus disponibles sur demande.
Interpolation de variables
N'importe quel champ texte dans n'importe quel nœud supporte l'interpolation de variables. Utilisez les doubles accolades :
Bonjour {{caller_name}}, votre commande {{order_number}} est en route.
À l'exécution, le moteur remplace chaque placeholder par la valeur actuelle de cette variable. Si la variable n'a pas encore été définie, le placeholder est résolu en chaîne vide. Tapez {{ (pour une substitution) ou [[ (pour une référence) dans n'importe quel champ texte de l'éditeur de flux pour ouvrir une liste déroulante d'autocomplétion de toutes les variables disponibles. Taper @@ fonctionne toujours comme alias hérité. Sur les champs multiligne (prompts, messages, corps de requête), un bouton + variable se trouve en haut à droite du champ comme alternative visible aux déclencheurs à taper, il ouvre le même sélecteur et insère @{{nom}} à la position du curseur.
Un placeholder peut aussi lire un seul élément d'une liste ou un champ d'un objet : {{dossiers[0].appareil}} est le champ appareil du premier élément de la liste dossiers ([0] est le premier élément, [1] le deuxième), et {{client.adresse.ville}} lit un champ imbriqué. Un élément ou un champ qui n'existe pas donne une chaîne vide. Voir Bonnes pratiques de prompt, Un élément d'une liste.
Nœuds d'entrée
Les nœuds d'entrée sont le premier nœud exécuté quand un appel se connecte. Chaque flux a exactement un nœud d'entrée entrant (un nœud Welcome ou Chatbot, id fixe start) : il ne peut pas être supprimé ni dupliqué, et faire glisser un nouveau nœud Welcome ou Chatbot depuis la palette le remplace. Un flux peut en plus porter un nœud d'entrée sortant, affiché sur le canevas comme Start Outbound (id fixe start_outbound), où commencent les appels passés par une campagne. Un workflow doit en avoir un avant qu'une campagne puisse l'utiliser. Un workflow Chatbot ne peut pas en avoir : un chatbot n'a pas de sens d'appel. Règles de la palette et façon de l'ajouter : Éditeur de flux → Nœuds de départ : entrant et sortant.
Nœud Welcome
Le point d'entrée des appels entrants, affiché sur le canevas comme Start Inbound. Le nœud Start Outbound est lui aussi un nœud Welcome, avec les mêmes champs, dédié aux appels passés par une campagne (voir Appels sortants). Il prononce un message d'accueil configurable, puis entre soit en mode LLM conversationnel (quand des routes de sortie sont configurées), soit avance automatiquement vers le nœud suivant connecté.
Comportement :
- Avec routes de sortie, prononce le message d'accueil, attend le premier énoncé de l'appelant, et l'évalue contre les routes configurées. Les routes conversationnelles sont classifiées par un LLM qui s'exécute en parallèle du modèle principal, économisant ~250 ms par rapport à une approche séquentielle ; les routes basées sur une règle sont vérifiées instantanément, sans aucun appel LLM. Voir Routes de sortie basées sur des règles.
- Sans routes de sortie, prononce le message d'accueil et avance immédiatement vers le nœud suivant (utile comme annonce pure avant un Transfer ou un Hangup).
| Propriété | Défaut | Description |
|---|---|---|
| Message d'accueil | - | Texte que l'agent prononce, puis attend la réponse de l'appelant : aucun message LLM automatique ne le suit. Prononcé via TTS quand l'appel se connecte. Supporte {{variable}}. Laissez vide pour le silence. |
| Routes de sortie | aucune | Routes nommées qui transitent vers la branche correspondante, soit conversationnelles (le LLM classifie le premier énoncé de l'appelant contre une description en langue naturelle), soit basées sur une règle (une condition déterministe sur un résultat d'outil ou une variable, vérifiée instantanément sans classificateur). Voir Routes de sortie basées sur des règles. |
| Prompt système | - | Prompt système LLM utilisé quand le nœud est en mode conversationnel (routes de sortie présentes). |
| Interruptible | - | Si activé, l'appelant peut interrompre le message d'accueil en parlant par-dessus. |
| Surcharges Voice & AI | valeurs agent | L'onglet Voice & AI du dialogue du nœud remplace les réglages STT, LLM et TTS au niveau de l'agent pour ce nœud uniquement, et porte le contrôle Conversation Behavior (silence) propre au nœud. Tout champ laissé tel quel hérite de l'onglet Initialisation de l'agent. Même onglet et même sémantique que sur le nœud Agent, voir ci-dessous. |
Appels sortants
Un appel passé par une campagne commence au nœud Start Outbound du workflow une fois que la personne a décroché. Vous l'ajoutez depuis la palette sous Start Node → Outbound ; il a son propre message d'accueil, son propre prompt et ses propres routes de sortie, si bien qu'un appel sortant ne joue jamais le message d'accueil entrant. Un workflow doit définir ce nœud avant que le formulaire de campagne l'accepte, et il ne peut pas être supprimé tant qu'une campagne en dépend. Les workflows construits avant l'existence de ce nœud continuent d'exécuter leur nœud Welcome entrant pour les appels sortants. Ce qui se passe entre le décrochage et le message d'accueil (attendre ou non que la personne parle en premier, combien de temps, que faire si personne ne parle, un délai avant le premier énoncé) se règle sur l'agent, dans Paramètres → Outbound Behavior, pas sur le nœud : voir Configuration de l'agent → Comportement sortant. Dans le message et le prompt du nœud, {{call_direction}} vaut outbound sur ces appels, et les colonnes CSV mappées de la campagne sont disponibles comme variables ({{first_name}}…).
Nœud Chatbot
Point d'entrée pour les appels chatbot propulsés par RAG. Contrairement aux nœuds Welcome/Agent qui utilisent le fournisseur LLM standard, le nœud Chatbot utilise un fournisseur CHATBOT dédié (configuré dans la section Connexions du compte propriétaire de l'agent). Il prononce un message d'accueil optionnel puis entre en mode conversationnel continu jusqu'à ce que l'appelant raccroche.
| Propriété | Défaut | Description |
|---|---|---|
| Fournisseur chatbot | - | Le fournisseur de type CHATBOT qui gère la conversation. Doit être configuré par un administrateur dans la section Connexions du compte propriétaire de l'agent. Le fournisseur est lié à la création du nœud et affiché en lecture seule dans la boîte de dialogue : pour utiliser un autre fournisseur, ajoutez un nouveau nœud Chatbot. |
| Message d'accueil | - | Message TTS optionnel joué avant le premier énoncé utilisateur. Supporte {{variable}}. |
| Routes de sortie | aucune | Routes nommées. Quand une route correspond, le flux transite hors du nœud Chatbot vers la branche connectée. Les routes de sortie du Chatbot sont toujours conversationnelles, classifiées à partir de la réponse du chatbot ; les routes basées sur une règle (voir ci-dessous) ne sont disponibles que sur les nœuds Welcome et Agent. |
| Réglages STT / TTS du nœud | valeurs agent | Configure des fournisseurs STT et TTS différents de ceux de l'agent, pour ce nœud uniquement. |
Nœud Agent
Nœud Agent
Le nœud conversationnel principal. Entre en mode conversation LLM libre avec un prompt système personnalisé. L'appelant parle, le STT transcrit, le LLM génère une réponse en streaming, le TTS joue l'audio. Ce cycle se répète jusqu'à ce que le LLM transite via une route de sortie, ou que l'appelant raccroche.
| Propriété | Défaut | Description |
|---|---|---|
| Prompt système | - | Instructions pour le LLM. Supporte {{variable}}. Définissez ici la personnalité, les objectifs, le ton et les contraintes de l'agent. |
| Routes de sortie | aucune | Routes nommées, soit conversationnelles (un classificateur parallèle vérifie chaque énoncé utilisateur contre une description en langue naturelle ; en cas de correspondance, l'appel LLM principal est annulé, ~250 ms économisés), soit basées sur une règle (une condition déterministe sur un résultat d'outil ou une variable, vérifiée instantanément sans classificateur). Chaque route peut porter un court message de transition (voir ci-dessous). Voir Routes de sortie basées sur des règles. |
| Message d'accueil (à l'entrée depuis un autre nœud) | - | Phrase scriptée prononcée à l'entrée du nœud via une route. L'agent la prononce puis attend l'appelant : aucun tour LLM et aucun RAG ne s'exécutent ensuite. Laissez vide pour déclencher à la place un tour d'entrée proactif (voir ci-dessous). Supporte {{variable}}. |
| Surcharges Voice & AI | valeurs agent | Un seul onglet, Voice & AI, regroupe toutes les surcharges par nœud dans l'ordre d'affichage : Écoute (STT) (fournisseur, langue, mots-clés), Modèle IA (LLM) (fournisseur, modèle, température), Parole (TTS) (fournisseur, voix, vitesse), et Conversation Behavior (ci-dessous). Tout champ laissé tel quel hérite de l'onglet Initialisation de l'agent ; chaque contrôle affiche ce qu'il hérite actuellement, ex. Inherit from Initialization (currently: OpenAI). Sur un agent multilingue, la langue devient Follow the caller ou Pin to une langue, voix et vitesse se règlent par langue, et les textes du nœud reçoivent des traductions Other languages, voir Configuration de l'agent → Langue par étape. |
| Conversation Behavior | hérite | Comportement d'inactivité propre au nœud, en bas de l'onglet Voice & AI, sous forme de sélecteur à trois options. Inherit from Initialization (par défaut) affiche un résumé en une ligne de ce que font les réglages au niveau de l'agent ; Customise for this node révèle Take turn after silence, les relances de silence propres au nœud, dans l'ordre (une prononcée à chaque période de silence, ajoutées et supprimées ligne par ligne) et When the caller still stays quiet — la sortie empruntée une fois les relances épuisées : hériter de celle du workflow, terminer l'appel, ou poursuivre à une étape choisie dans une liste déroulante. Tout ce qui n'est pas modifié continue d'hériter ; Off for this node désactive entièrement les relances de silence sur ce nœud, quelle que soit la durée du silence de l'appelant. Utile lorsqu'une étape d'un workflow français s'exécute en anglais et ne doit pas rejouer la relance de silence française. |
| Mots-clés STT | valeurs agent | Mots-clés au niveau du nœud, saisis sous forme d'étiquettes dans le groupe Écoute (STT), qui améliorent la précision de reconnaissance pour ce nœud uniquement. Une fois définis, un sélecteur de mode apparaît : Add to Initialization keywords (par défaut) les fusionne avec la liste au niveau agent, Replace Initialization keywords n'utilise que la liste du nœud. Voir Configuration de l'agent → Reconnaissance vocale. |
| Web Services | valeurs agent | Quels comptes Web Service sont disponibles comme outils LLM dans ce nœud. Remplace la liste de l'agent pour ce nœud uniquement. |
| Base de connaissances | valeurs agent | Active la recherche RAG sur les bases de connaissances sélectionnées pour les réponses LLM de ce nœud. Le bouton Filtrer les résultats peu pertinents définit un seuil de pertinence par nœud (stocké sous minScore) qui écarte les correspondances faibles avant qu'elles n'atteignent le contexte du LLM. |
Message de transition des routes de sortie : chaque route de sortie peut avoir une courte phrase de passation (ex : "Permettez-moi de vérifier cela…") prononcée quand cette route se déclenche. Elle est jouée en parallèle avec le démarrage du nœud de destination, récupération RAG, construction du prompt et message d'accueil s'exécutent pendant que le message est prononcé, masquant ainsi la latence plutôt que de l'ajouter. L'audio du nœud de destination est mis en file d'attente derrière lui, garantissant l'ordre. Quand la route mène à un nœud Hangup, Transfer, Appel API ou MCP, même en passant par un nœud Branch, l'appel attend d'abord la fin du message : avant de raccrocher ou de transférer, et avant que la requête parte (une API qui transfère l'appelant ne peut pas couper la phrase). L'appelant entend toujours la phrase en entier.
Tour d'entrée proactif : quand un nœud Agent est atteint depuis un autre nœud et que son message d'accueil est vide, l'agent déclenche un tour immédiatement à l'entrée au lieu d'attendre que l'appelant parle. Ce tour d'entrée diffuse un message avec les outils du nœud activés et exécute l'auto-RAG à l'entrée, si bien que le nœud peut répondre tout de suite à la question routée ou appeler un outil (par exemple récupérer un planning) dès qu'il prend la main, plutôt que d'annoncer « je vérifie… » et de rester bloqué jusqu'à ce que l'appelant le relance. Si vous renseignez au contraire le message d'accueil, l'agent prononce simplement cette phrase scriptée et attend, sans appel LLM d'entrée ni RAG, utile lorsque l'ouverture est une question à laquelle vous voulez que l'appelant réponde.
Une action et une question dans la même réponse : quand l'agent pose une question à l'appelant et déclenche, dans la même réponse, un des outils du nœud, l'outil n'est pas encore exécuté, car il agirait avant que l'appelant puisse répondre. L'agent peut l'exécuter au tour suivant, une fois que l'appelant a répondu. Une réponse qui ne pose aucune question exécute son outil normalement. Dans le détail de l'appel, le tour affiche Une action a attendu la réponse de l'appelant.
Historique de conversation : l'historique complet de conversation inter-nœuds est conservé comme une liste de messages unique. Chaque tour assistant porte un agent_label pour que les nœuds suivants puissent lire une transcription claire par locuteur dans le contexte LLM.
// Exemple de route de sortie
[Welcome : "Merci d'appeler. Comment puis-je vous aider ?"]
routes de sortie : billing, support, cancel
→ billing: [Agent : prompt système = instructions spécialiste facturation]
→ support: [Agent : prompt système = instructions support technique]
→ cancel: [Agent : prompt système = instructions spécialiste rétention]
// Le classificateur s'exécute en parallèle à chaque tour utilisateur.
// Quand l'utilisateur dit "Je voudrais annuler" :
// → le classificateur correspond à la route "cancel"
// → l'appel LLM principal est annulé
// → le flux transite immédiatement vers la branche cancel
Routes de sortie basées sur des règles
Chaque route de sortie d'un nœud Welcome ou Agent est de l'un de ces deux types, choisi via un sélecteur dans l'onglet Routes de sortie du dialogue du nœud :
| Type | Libellé dans l'éditeur | Mode d'évaluation |
|---|---|---|
| Conversationnelle | « L'appelant dit quelque chose » (L'agent interprète — un instant de réflexion) | Une description en texte libre lue par le LLM classificateur en fonction de la conversation. Flexible, mais ajoute un léger délai de routage et ne peut pas observer de manière fiable ce que l'agent ne peut pas voir, comme le fait qu'un appel d'outil se soit réellement exécuté. |
| Basée sur une règle | « Une règle est remplie » (Instantané et exact) | Une condition structurée vérifiée par le moteur de flux lui-même, sans classificateur, sans appel LLM, sans attente. L'appel avance dès que la condition devient vraie. |
Préférez une règle chaque fois que la transition dépend réellement de quelque chose que le flux connaît déjà de manière déterministe, « l'outil a réussi », « cette variable est définie », plutôt que de ce que l'appelant a dit. Cela referme un vrai mode d'échec : une description conversationnelle du type « quand le dossier a été créé » dépend de l'exécution effective d'un outil, mais le classificateur ne peut juger que la conversation, pas le résultat de l'outil, il peut donc se déclencher trop tôt et abandonner l'appel d'outil en cours. L'éditeur détecte ce cas : une description conversationnelle qui nomme un outil avec une formulation évoquant son exécution (« créé », « soumis », « renvoyé »…) affiche un avertissement ambre avec un bouton Convertir en règle en un clic. La plateforme indique aussi au classificateur quels outils d'écriture du nœud n'ont pas encore été exécutés, mais cette indication est faite au mieux et certains modèles la manquent encore : une règle sur « un outil réussit » est la seule option garantie correcte pour une transition qui dépend du résultat d'un outil.
Une route basée sur une règle porte une seule condition, construite à partir d'un sélecteur en forme de phrase (« Quand ») :
| Condition | Opérateur | Vérifie |
|---|---|---|
| Un outil réussit / un outil échoue | - | L'outil nommé s'est exécuté à ce tour et a renvoyé un succès ou un échec. Les outils disponibles sont les actions Web Service et les actions Composio activées sur le nœud. Les actions de même nom sur deux web services sont numérotées dans le sélecteur. |
| Une variable… | is_set | La variable contient une valeur non vide. |
| Une variable… | equals / not_equals | Comparaison de chaîne insensible à la casse avec une valeur (qui peut elle-même contenir {{variable}}). |
| Une variable… | contains | Correspondance de sous-chaîne insensible à la casse. |
Les nœuds avec des outils activés préconfigurent les nouvelles routes de sortie sur une règle liée au premier outil, le schéma le moins susceptible d'abandonner un appel d'outil. Les nœuds sans outil restent en conversationnel par défaut, comme auparavant.
- Une route « un outil échoue » part dès l'échec de l'outil : l'agent ne s'excuse pas pour réessayer avant, et l'action d'écriture du nœud n'est pas exécutée.
- Sur le nœud de départ, une règle dont la variable est déjà remplie par une action de démarrage part juste après l'accueil, sans attendre l'appelant.
- Deux web services avec une action du même nom : une ancienne règle enregistrée sur ce nom ne correspond à aucun. Choisissez à nouveau l'outil dans la liste numérotée et enregistrez.
Répondre d'abord, puis router
Une règle sur une variable est vérifiée dès que l'appel arrive à l'étape. Si la variable est déjà remplie à ce moment-là (par une action de démarrage ou une étape précédente, par exemple), l'appel repart aussitôt et l'étape ne dit rien. Pour que l'étape réponde d'abord, cochez Seulement après la réponse de cette étape sous la règle : la règle est alors ignorée à l'entrée dans l'étape et avant qu'elle réponde à l'appelant, puis vérifiée après sa réponse.
Utilisez-la sur une étape conçue pour donner une réponse puis passer à la suite, par exemple confirmer un rendez-vous puis continuer. L'option n'est proposée que pour les règles sur une variable : une règle sur un outil attend déjà la réponse de l'étape.
Tester ces routes
Le panneau Tester ces routes en bas de l'onglet Routes de sortie permet de simuler à sec les routes d'un nœud sans passer d'appel. Définissez des valeurs hypothétiques pour les variables du nœud et un résultat hypothétique pour chaque outil (réussi / échoué / non exécuté), le panneau évalue alors chaque route basée sur une règle exactement comme le ferait le runtime, et marque la première qui correspond comme la route que l'appel emprunterait, instantanément. Les routes conversationnelles ne peuvent pas être simulées ainsi, les évaluer est le travail du classificateur au moment de l'appel : le panneau les étiquette donc en direct et, quand leur description référence une variable, prévisualise la description avec vos valeurs hypothétiques substituées, à titre indicatif.
Renvoyer une étape vers elle-même
Une route de sortie d'un nœud Welcome, Agent ou Chatbot peut ramener au même nœud, par exemple pour reprendre l'étape depuis le début. Tirez depuis la poignée de la route jusqu'à l'entrée du nœud lui-même : le lien est dessiné en boucle. Seules les routes de sortie le permettent, pas la sortie par défaut.
À chaque passage par cette route, l'appelant entend de nouveau le message de transition de la route et le message d'entrée de l'étape : l'audit du flux affiche donc un avertissement sur le nœud. Le flux s'enregistre et s'exécute quand même tel qu'il est dessiné. Une étape peut revenir sur elle-même jusqu'à 3 fois de suite sans que l'appelant parle entre-temps ; une fois de plus et l'appel se termine au lieu de tourner en boucle.
Nœuds système
Nœud Transfer
Transfère l'appel en plaçant un appel sortant vers la cible et en pontant les deux branches. En cas de succès, la branche agent se déconnecte et le flux s'arrête, l'appelant continue avec la destination du transfert.
| Propriété | Défaut | Description |
|---|---|---|
| Transférer vers | Un numéro de téléphone | Affiché quand les transferts SIP sont activés pour votre organisation. Un numéro de téléphone compose le numéro cible via le réseau téléphonique. Une destination SIP joint directement votre propre plateforme de centre d'appels en SIP : voir Transférer vers votre centre d'appels en SIP. |
| Numéro cible | - | Destination au format E.164. Supporte {{variable}} pour le routage dynamique, ex : {{support_queue_number}} défini par un nœud précédent. Affiché pour Un numéro de téléphone. |
| Message avant transfert | - | Prononcé à l'appelant avant le déclenchement du transfert. Supporte {{variable}}. Gardez-le en dessous de 2 secondes. |
| Identifiant appelant personnalisé | appelant original | Le numéro affiché à la destination du transfert. Laissez vide pour transmettre le numéro original de l'appelant. |
| Délai d'attente | 30 s | Durée de sonnerie de la cible avant de déclarer l'échec. Plage : 5–120 s. |
| Navigation IVR — séquence DTMF | - | Optionnel. Chiffres envoyés automatiquement après le décroché de la cible, pour naviguer dans un menu IVR (SVI), ex : 1w3 (appuie sur 1, pause, appuie sur 3). Caractères autorisés : 0-9, *, #, A-D, et w (pause de 0,5 s). Supporte {{variable}}, ex : un poste collecté. Laissez vide pour un transfert normal. |
| Attente avant envoi | 0 s | Affiché uniquement si une séquence DTMF est définie. Secondes laissées au message d'accueil du SVI après le décroché, avant l'envoi des chiffres. Plage : 0–30 s. Un délai sans séquence n'envoie rien. |
| En-têtes SIP | - | Optionnel, destinations SIP uniquement. Jusqu'à 10 en-têtes supplémentaires envoyés avec l'appel de transfert, lus par le centre de contacts qui le reçoit. Les noms commencent par X- ; les valeurs supportent {{variable}}. Voir En-têtes SIP. |
Handles de sortie : le nœud Transfer possède un handle de sortie failure. Si le transfert échoue (délai d'attente, occupé, erreur réseau), l'exécution suit l'arête failure. Si aucune arête d'échec n'est connectée et que le transfert échoue, l'appel se termine.
Transfer (vers : +33142000000, message: "Je vous transfère vers la facturation.")
↓ success → le flux s'arrête (appel transféré)
↓ failure → Hangup ("Transfert échoué. Veuillez nous rappeler.")
Après un Transfer réussi, la session agent se termine. La transcription, les variables collectées et les événements d'appel sont tous conservés dans l'enregistrement d'appel jusqu'au point de transfert.
Naviguer dans un IVR après transfert (DTMF)
Lorsque la cible du transfert est un menu automatisé (IVR / SVI) plutôt qu'une personne, renseignez la séquence DTMF pour atteindre automatiquement la bonne option. Après le décroché de la cible, Manivox attend le délai Attente avant envoi, puis compose les chiffres ; chaque w ajoute une pause de 0,5 s entre les tonalités. Pendant toute la navigation, l'appelant continue d'entendre la sonnerie, sans invite de menu ni bip, et n'est ponté sur la ligne qu'une fois la séquence terminée.
Numéro cible : +33142000000
Séquence DTMF : 2w{{ticket_id}}#
Attente avant envoi : 4 s
Après le décroché, cela attend 4 s le message d'accueil, appuie sur 2, marque une pause, compose le ticket_id collecté, puis #.
Les chiffres ne sont envoyés qu'après le décroché de la destination : le handle failure se déclenche donc normalement en cas de non-réponse ou d'occupation. Comme les menus IVR varient, passez un appel de test réel contre le vrai IVR avant de mettre un transfert DTMF en production.
Transférer vers votre centre d'appels en SIP
Quand votre centre de contacts dispose de sa propre plateforme SIP, une étape de transfert peut la joindre directement au lieu de composer un numéro. L'appel ne passe pas par le réseau téléphonique, et les en-têtes SIP que vous ajoutez arrivent jusqu'à votre plateforme.
- Demandez-nous d'activer les transferts SIP pour votre organisation.
- Un administrateur de l'organisation ajoute la plateforme dans Paramètres → Destinations SIP : un nom, le nom d'hôte public ou l'adresse IPv4, le port (5060 par défaut). Les appels passent en UDP. Les adresses privées et internes sont refusées. Une organisation peut avoir jusqu'à 20 destinations.
- Dans l'étape de transfert, choisissez Transférer vers : Une destination SIP (votre centre d'appels), sélectionnez la destination dans Destination SIP et renseignez si besoin File d'attente ou poste (la partie avant le
@, par exemplequeue-42ou{{file}}). Seuls les lettres, chiffres et. _ ~ + * # ! -sont conservés, et l'adresse qui sera composée s'affiche sous le champ. Le lien Gérer les destinations SIP ouvre la page des paramètres.
Transférer vers : Une destination SIP
Destination SIP : Centre de contacts Lisbonne (cc.example.com:5060, UDP)
File d'attente ou poste : queue-42
Compose : sip:queue-42@cc.example.com:5060
Si aucune destination n'est choisie, si la destination est désactivée ou supprimée, ou si les transferts SIP sont désactivés pour votre organisation, le transfert n'est pas passé et l'étape prend sa sortie failure. L'audio est en G.711 (A-law ou µ-law, 8 kHz) : votre plateforme doit accepter l'un des deux.
Transmettre du contexte au centre de contacts (en-têtes SIP)
Un centre de contacts qui reçoit le transfert peut lire des en-têtes supplémentaires sur l'appel pour le router vers la bonne file ou afficher la bonne fiche client. Ajoutez-les sous En-têtes SIP : un nom, une valeur et un encodage. Ils ne sont proposés que pour les destinations SIP : le réseau téléphonique ne les transmet pas jusqu'à la destination.
X-Reason: {{motif_appel}}
X-Customer-Id: {{numero_client}}
X-Lang: {{language}}
- Les noms commencent par
X-, suivi de lettres, chiffres ou tirets (66 caractères au plus). Un même nom ne peut pas servir deux fois, majuscules ou non. Une étape peut envoyer jusqu'à 10 en-têtes.X-Call-Id,X-Original-DIDet tous les nomsX-MANITERM-…sont définis par la plateforme sur chaque transfert et ne peuvent pas être modifiés :X-Call-Idest l'identifiant de l'appel, que le CRM destinataire peut utiliser avec l'API de handoff. - Les valeurs vides ne sont pas envoyées. Si une variable est encore vide au moment du transfert, l'en-tête est omis plutôt qu'envoyé vide.
- Une valeur tient sur une ligne. Les retours à la ligne et tabulations d'une variable deviennent des espaces, et les valeurs sont coupées à 256 caractères.
- Encodage : Texte envoie la valeur telle quelle, accents compris. Encodé URL envoie des codes
%XXà la place (par exemple%C3%A9pouréet%0Apour un retour à la ligne). Ne le choisissez que si le système qui reçoit le décode.
Demandez au destinataire quels noms d'en-tête il lit, et passez un transfert de test pour confirmer qu'ils arrivent : un opérateur peut supprimer les en-têtes qu'il ne transmet pas.
Nœud Hangup
Termine l'appel. Prononce le message d'au revoir (si configuré), puis signale la session pour terminer. Chaque chemin de flux devrait se terminer par un nœud Hangup, ne laissez jamais de branches sans point de terminaison.
| Propriété | Défaut | Description |
|---|---|---|
| Message d'au revoir | - | Texte prononcé avant la déconnexion. Supporte {{variable}}. Laissez vide pour un raccrochage silencieux. |
| Raison | completed | Stockée dans le champ de raison de raccrochage de l'enregistrement d'appel. Valeurs : completed, transferred, error, user_hangup. |
Nœuds de flux (optionnels)
Au-delà des types de nœuds principaux, la plateforme propose un ensemble de nœuds de flux pour un contrôle déterministe et scripté de la conversation. Les nœuds de flux optionnels sont Router, Condition, API Call, Branch et Variable. Ils sont disponibles sur demande : désactivés par défaut, ils n'apparaissent dans la palette qu'une fois que Manivox les a activés pour votre organisation. Pour les utiliser, contactez votre interlocuteur Manivox ou le support.
Les exemples ci-dessous suivent un même flux : le service client d'un magasin de vélos. L'appelant est accueilli, un Router l'envoie vers le bon service, un nœud Agent lui demande son numéro de commande, un API Call consulte la commande, un Branch choisit la suite selon le statut de la commande, et une Condition décide si une commande en retard part vers un conseiller.
Nœud Router
Envoie l'appelant vers une route parmi plusieurs, selon ce qu'il demande. Le router ne parle jamais : il lit la conversation et choisit la route dont la description correspond à la demande. Juste après une question (l'accueil, par exemple), il attend la réponse de l'appelant ; quand l'appelant attend déjà une réponse, par exemple parce qu'un nœud Agent l'a renvoyé vers le router avec une nouvelle question, il oriente tout de suite.
Quand l'utiliser : comme un standard qui ne parle pas. Dans l'exemple, le nœud Welcome demande « Que puis-je faire pour vous ? » et le Router envoie l'appelant vers Commande (suivi de commande), Atelier (réparations) ou la route default (toute autre demande). Chaque service est un nœud Agent avec un prompt court et ciblé, et chacun peut renvoyer l'appelant vers le Router quand le sujet change. Pour aiguiller tout de suite sur une valeur déjà connue (une variable ou le résultat d'un outil), utilisez plutôt un nœud Branch.
| Propriété | Description |
|---|---|
| Routing instructions (optional) | Des consignes en plus pour les cas limites, quand les descriptions des routes ne suffisent pas. Dans l'exemple : une question sur la livraison d'un vélo acheté en ligne va toujours vers Commande, même si l'appelant parle de réparation. |
| Routes | Une par destination : un nom de route, affiché sur le nœud et sur sa sortie, et une description de ce que demande l'appelant quand cette route est la bonne. |
| Default route | La route prise quand aucune route ne convient. Une route nommée default est utilisée automatiquement. |
| Fallback question | Prononcée quand aucune route ne convient et qu'il n'y a pas de route par défaut. Le router attend alors la réponse et oriente sur celle-ci. Inutilisée tant qu'une route par défaut est définie. |
Nœud API Call
Appelle un endpoint HTTP externe en cours de flux, sans aucun LLM impliqué, et mappe la réponse sur des variables. Comme les autres nœuds de flux, il est disponible sur demande : il n'apparaît dans la palette qu'une fois que Manivox l'a activé pour votre organisation.
Quand l'utiliser : pour lire ou envoyer des données à un point précis du flux, sans laisser le LLM décider quand appeler un outil. Dans l'exemple, une fois que le nœud Agent a collecté {{numero_commande}}, l'API Call envoie GET https://api.horizon-velo.example/orders/{{numero_commande}} et mappe $.status vers statut_commande et $.days_late vers jours_retard. On Error est réglé sur Fallback message : si le système de commandes ne répond pas, l'agent dit « Je n'arrive pas à consulter votre commande pour le moment » et le flux suit la sortie rouge à droite du nœud, reliée ici à un Transfer vers un conseiller. Quand cette sortie n'est pas reliée, succès et échec continuent tous deux par la sortie principale.
| Propriété | Défaut | Description |
|---|---|---|
| Mode | API brute | API brute construit la requête à la main (méthode, URL, en-têtes, corps). Service Web réutilise un compte Web Service déjà configuré dans Connexions, exposé sous forme de deux listes déroulantes plutôt que de champs bruts. |
| Service web / Action (mode Service Web) | - | Deux listes déroulantes, alimentées par les Web Services configurés pour votre organisation : choisissez un service, puis une de ses actions. Changer de service réinitialise l'action ; les paramètres requis par l'action sont saisis en JSON. |
| Méthode / URL / En-têtes / Corps de la requête (mode API brute) | GET | Champs de requête HTTP standards. L'URL, les valeurs d'en-tête et le corps JSON supportent tous l'interpolation {{variable}}, et la zone de texte du corps dispose du même bouton d'insertion + variable que les prompts et messages. |
| Authentification (mode API brute) | En-têtes ci-dessous | En-têtes ci-dessous envoie les en-têtes que vous saisissez, tels quels. Connexion de service web signe l'appel avec une des connexions de service web du compte (clé API, Basic, Bearer ou OAuth 2.0), choisie dans Connexion. Un jeton OAuth est obtenu et renouvelé pour vous, et n'apparaît jamais dans les journaux d'appel. L'URL doit commencer par l'URL de base de la connexion, affichée sous la liste (une variable peut compléter le chemin, pas l'hôte), sinon l'agent ne peut pas être enregistré. L'en-tête d'authentification de la connexion remplace un en-tête du même nom saisi plus bas. Une connexion qui envoie ses identifiants dans le corps de la requête ne peut pas signer un appel brut : utilisez pour elle le mode Service Web. |
| Variable de sortie / Mappage de reponse (mode Raw API) | - | La variable de sortie contient la réponse brute ; le mappage de réponse extrait en plus des champs spécifiques vers leurs propres variables via JSONPath (ex : $.data[0].email). Quand le chemin d'une ligne renvoie une liste de longueur variable (ex : $.data[*]), cliquez sur Liste d’éléments sur cette ligne et choisissez les quelques champs à garder pour chaque élément : la variable contient alors une ligne courte par élément et {{name_count}} le nombre d'éléments renvoyés, comme dans Listes d’éléments. En mode Web Service le mappage de réponse n'apparaît pas : c'est le mapping propre à l'action (avec ses transformations de nettoyage), configuré sur le compte Web Service, qui s'applique, et la fenêtre liste les variables que l'action remplit. La variable de sortie reste disponible pour remplacer celle de l'action, sauf pour une action dont Conserver la réponse complète est désactivé : elle ne garde que ses champs mappés et ne stocke pas la réponse entière. |
| Délai d'attente | 30000 ms | Durée d'attente de la réponse avant de considérer l'appel comme échoué. |
| En cas d'erreur | continue | continue (Continuer), ignore l'échec et poursuit. stop (Arrêter), termine l'appel. fallback (Message de secours), prononce un message configuré avant de poursuivre. |
Nœud Branch
Aiguille le flux de manière déterministe selon la valeur d'une variable, sans faire intervenir le LLM. À utiliser quand l'étape suivante dépend uniquement de données déjà collectées (un code de statut, une réponse oui/non, un niveau d'abonnement) plutôt que de l'interprétation de ce qu'a dit l'appelant.
Quand l'utiliser : quand une variable prend une valeur parmi quelques valeurs connues et que chaque valeur demande son propre chemin. Dans l'exemple, le Branch lit statut_commande, rempli par l'API Call : expediee mène à un nœud Agent qui donne le lien de suivi, en_preparation mène à une Condition qui vérifie le retard, livree mène à un nœud Agent qui propose de l'aide pour le montage, et Default (un statut inconnu ou vide) mène au conseiller.
| Propriété | Défaut | Description |
|---|---|---|
| Variable | - | La variable dont la valeur décide de la route. Elle doit déjà être définie par un nœud précédent, le nœud Branch ne la collecte pas. |
| Cas | 1 cas vide | Une liste de cas, chacun avec une valeur à comparer. Chaque cas produit son propre handle de sortie, connectez une branche différente à chacun. Quand la variable a un ensemble de valeurs connu ({{is_callback}} vaut True ou False, {{call_direction}} vaut inbound ou outbound…), le champ valeur est une liste déroulante de ces valeurs au lieu d'une zone de texte libre. |
| Default | toujours présent | Un handle de sortie fixe emprunté quand la variable ne correspond à aucun cas. Connectez-le à une branche de repli. |
Correspondance : le nœud compare la valeur de la variable à chaque valeur de cas via une correspondance de chaîne exacte insensible à la casse (les espaces de début et de fin sont ignorés). Le premier cas correspondant l'emporte ; si aucun cas ne correspond, le flux suit le handle default. Le nœud se déclenche immédiatement et de manière déterministe à l'entrée, il n'attend pas que l'appelant parle, la variable de routage doit donc déjà contenir une valeur.
Branch (variable : {{membership_tier}})
→ "gold": [Agent : prompt support prioritaire]
→ "silver": [Agent : prompt support standard]
→ default: [Agent : prompt qui demande à l'appelant de confirmer son niveau]
Nœud Condition
Teste une condition et continue par l'une de ses deux sorties, True ou False, sans faire intervenir le LLM. Comme le nœud Branch, il se déclenche dès que le flux l'atteint et n'attend pas l'appelant.
Quand l'utiliser : pour une décision oui/non, en particulier un seuil qu'un Branch ne sait pas exprimer. Dans l'exemple, une commande encore en préparation arrive sur la Condition Retard important ?, qui compare jours_retard avec Greater Than 5. Au-delà de 5 jours de retard, l'appelant part directement vers un conseiller ; sinon, un nœud Agent explique le délai. Les libellés True et False (Plus de 5 jours, Dans les temps) ne font que renommer les sorties sur le canevas.
| Propriété | Description |
|---|---|
| Condition Type | Variable comparison (par défaut) ou Expression. |
| Variable / Operator / Compare Value | Mode Variable comparison. Equals, Not Equals et Contains comparent du texte, sans tenir compte de la casse. Greater Than et Less Than comparent des nombres ; une valeur qui n'est pas un nombre donne False. Exists vaut True quand la variable a été définie. |
| Expression | Mode Expression, pour un test sur plusieurs variables, en syntaxe Python : and, or, not, et des guillemets autour d'une variable qui contient du texte, par exemple "{{statut_commande}}" == "en_preparation" and {{jours_retard}} > 5. Une expression qui ne peut pas être évaluée compte comme False. |
| True Label / False Label | Noms facultatifs des deux sorties. |
Nœud Variable
Définit ou modifie une variable sans rien dire, puis passe à l’étape suivante. Opérations : Définir (enregistrer une valeur, qui peut copier une autre variable avec {{autre}}), Ajouter, Incrémenter / Décrémenter (de la valeur, 1 si vide), et Chercher dans une table.
Chercher dans une table cherche une valeur dans une des tables de correspondance du compte : choisissez la table et la valeur à chercher, par exemple {{code_postal}} collecté à l’étape précédente. L’étape affiche les variables qu’elle crée : une par colonne de la table, plus les lignes trouvées et leur nombre (0 = introuvable). Enchaînement type : une étape Agent collecte le code postal, une étape Variable cherche l’agence, une étape Branche vérifie le nombre, et une étape Transfert appelle {{workshop_phone}}.
Modèles courants
Flux entrant sur un seul sujet
[Welcome : "Merci d'appeler le support. Comment puis-je vous aider ?"]
routes de sortie : human_requested, resolved
→ human_requested: [Transfer : +33142000000, message: "Je vous mets en relation."]
↓ failure
[Hangup : "Aucun agent disponible. Veuillez rappeler."]
→ resolved: [Hangup : "Heureux d'avoir pu vous aider. Bonne journée !"]
Flux entrant multi-sujet
[Welcome : "Bienvenue ! Dites facturation, support ou commercial."]
routes de sortie : billing, support, sales
→ billing: [Agent : spécialiste facturation, prompt système = contexte facturation]
route de sortie : transfer_human
[Transfer : {{billing_queue}}]
↓ failure
[Hangup : "Notre équipe est injoignable. Réessayez plus tard."]
→ support: [Agent : spécialiste support]
route de sortie : transfer_human
[Transfer : {{support_queue}}]
↓ failure
[Hangup : "Notre équipe est injoignable. Réessayez plus tard."]
→ sales: [Agent : spécialiste commercial]
[Hangup : "Merci de votre intérêt !"]
Appel sortant
[Start Outbound : "Bonjour {{first_name}}, c'est … qui vous appelle au sujet de …" (Paramètres de l'agent → Outbound Behavior : attendre un premier mot jusqu'à 3 s, puis parler quand même)
routes de sortie : interested, callback, not_interested
→ interested: [Agent : agent de qualification, prompt système = contexte commercial]
route de sortie : transfer_sales
[Transfer : {{sales_rep_number}}]
↓ failure
[Hangup : "Notre équipe vous contactera par e-mail."]
→ callback: [Agent : "Quand souhaitez-vous que nous vous rappelions ?"]
route de sortie : date_confirmed
[Hangup : "Parfait, nous vous appellerons le {{callback_date}}."]
→ not_interested: [Hangup : "Pas de problème. Bonne journée !"]
Les workflows créés avant l'existence du nœud Start Outbound exécutent cette ouverture sur leur nœud Welcome entrant à la place.