Retour au blogIntergration

Webhooks de fin de conversation : automatisation fiable pour WhatsApp et le chat web

Un modèle d'entreprise pour des webhooks Famulor fiables : transcriptions, pièces jointes, idempotence, tentatives de renvoi, rejeu et automatisation CRM.

Famulor Redaktion26 juillet 20268 min de lecture

Résumer le contenu avec:

Un webhook de fin de conversation transforme une discussion WhatsApp ou un chat web terminé en un événement métier exploitable. Plutôt que de copier manuellement les transcriptions, une entreprise peut envoyer les résultats structurés directement vers un CRM, un service d'assistance, un entrepôt de données ou un outil d'automatisation. La question cruciale n'est pas seulement de savoir si un webhook est envoyé. En production, le pipeline doit rester fiable face aux délais d'attente, aux événements en double, aux pièces jointes multimédias et aux conversations s'étalant sur plusieurs jours.

Une fois la conversation terminée, Famulor peut transmettre la transcription complète, les variables extraites, les variables d'entrée, les données du client et de l'expéditeur, ainsi que les horodatages. Les événements WhatsApp peuvent également inclure des images, des fichiers audio, vidéo et des documents en tant que pièces jointes. Ce modèle vous montre comment transformer cette charge utile en une intégration de niveau entreprise.

Ce que couvre le webhook de fin de conversation

Le webhook est conçu pour un travail asynchrone après une conversation. Les résultats typiques incluent la création d'un prospect, la mise à jour d'un ticket, l'archivage d'un résumé ou le lancement d'un flux de travail de suivi. Il diffère d'une action en cours d'appel : les actions en cours d'appel accèdent aux systèmes pendant une interaction en direct ; le webhook de fin de conversation transmet le résultat une fois que la conversation WhatsApp ou via le widget web est terminée.

Zone de donnéesChamps clésObjectif typique
Identitéconversation_id, assistant_id, typeCorrélation, routage et déduplication
Résultatextracted_variables, input_variablesChamps CRM, qualification et décisions de flux de travail
Historiquetranscript, formatted_transcriptTraçabilité, assurance qualité et contexte de support
Tempstimestamp, timestamp_unix, created_at, ended_atOrdonnancement, mesure des SLA et durée
Médiaattachments avec type, URL et nom de fichierTraitement de documents ou d'images
Canalcustomer_phone, customer_name, senderCorrespondance des contacts et logique adaptée au canal

L'architecture cible fiable : accuser réception rapidement, traiter plus tard

Un point de terminaison de webhook doit effectuer le moins de travail synchrone possible. Il reçoit l'événement, valide sa structure de base, stocke la charge utile inchangée et place une tâche dans une file d'attente. Les mises à jour CRM, l'analyse des médias, les notifications et les transformations plus importantes interviennent ensuite. Cela permet au point de terminaison de renvoyer rapidement une réponse 2xx et d'éviter les renvois inutiles.

Famulor webhook architecture with timestamp, validation, retry, and storage stages
Un pipeline de webhook résilient sépare l'ingestion, la validation, la déduplication, le traitement et le stockage.
  1. Ingérer l'événement : Limitez la taille de la charge utile, analysez le JSON et validez les champs requis tels que conversation_id et status.
  2. Stocker tel quel : Enregistrez la charge utile brute avec l'heure de réception et un état de livraison interne. Cela crée une source auditable pour les futurs rejeux.
  3. Dédupliquer : Pour les événements de fin de conversation, conversation_id est une clé métier utile. La base de données ne doit pas enregistrer deux fois la même finalisation comme un nouveau cas.
  4. Traiter de manière asynchrone : Un processus effectue le mappage des champs, les mises à jour CRM, la création de tickets, l'analyse et les notifications.
  5. Enregistrer le résultat : Capturez le système cible, le résultat de l'API, le nombre de tentatives et la classe d'erreur. Cela transforme un « webhook envoyé » en un processus mesurable.

Les tentatives de renvoi sont un filet de sécurité, pas une logique de traitement

Si le point de terminaison configuré échoue ou ne renvoie pas un statut 2xx, Famulor tente à nouveau la livraison après 30, 60 et 120 secondes. Après trois tentatives infructueuses, la livraison est marquée comme échouée. Ce calendrier absorbe les incidents réseau et de plateforme brefs, mais il ne remplace pas une file d'attente ou l'idempotence dans le système de destination.

La règle fondamentale est simple : le renvoi ne doit pas déclencher deux fois la même action métier. Une mise à jour CRM est plus sûre qu'une opération de création aveugle. Pour les actions en aval, une table d'idempotence dédiée peut stocker conversation_id + action_name. Le processus peut alors déterminer s'il a déjà créé un ticket, envoyé un e-mail ou mis à jour une opportunité commerciale.

Rejeu et pistes d'audit pour les opérations quotidiennes

Famulor enregistre le résultat de la livraison du webhook, y compris son statut et sa réponse. Les équipes peuvent renvoyer le webhook pour une conversation individuelle, tandis que les vues de liste prennent en charge la réévaluation et le renvoi en masse. Cela devient précieux lorsqu'un CRM était temporairement indisponible ou qu'un mappage de champ a été corrigé.

Un processus de rejeu contrôlé nécessite trois règles :

  • Le rejeu est idempotent : La destination met à jour le même enregistrement au lieu de créer des doublons.
  • L'original et la transformation restent séparés : La charge utile brute est immuable ; les données transformées reçoivent une version.
  • Chaque tentative est visible : Enregistrez l'heure, l'initiateur, la version de transformation et le résultat.

La référence complète des champs et le comportement de renvoi sont documentés dans la documentation du webhook de fin de conversation Famulor.

Mapper d’intégration

Quels systèmes Voice AI doit-il connecter ?

Sélectionnez vos outils et obtenez un chemin d’intégration rapide.

Intégrations sélectionnées: 4

1Clarifier source et owner
2Vérifier webhook/API
3Construire le pilote
4Définir monitoring et escalade

Traiter les pièces jointes multimédias en toute sécurité

Les conversations WhatsApp peuvent inclure des images, de l'audio, de la vidéo et des documents. Le webhook expose un tableau attachments avec un type, une URL et un nom de fichier. Ne traitez pas ces URL comme des fichiers internes de confiance. Un pipeline multimédia sain télécharge le contenu côté serveur, applique des limites de taille et de type, analyse les fichiers et ne les conserve que pour l'objectif métier déclaré.

  • Validez le type de contenu réel, pas seulement l'extension du nom de fichier.
  • Définissez des limites de temps de téléchargement et de traitement.
  • Séparez les données personnelles par rôle et par locataire.
  • Journalisez la conservation, la suppression et l'accès.
  • Déplacez les échecs d'analyse vers une file d'attente de lettres mortes sans perdre l'événement original.

Pour les messages WhatsApp sortants, le webhook d'accusés de lecture ajoute des statuts tels que sent, delivered, read et failed. Ce webhook est signé avec HMAC-SHA256. Vérifiez la signature sur le corps de la requête intact et dédupliquez les mises à jour de statut par ID de message et par statut.

Transformer les événements techniques en indicateurs opérationnels significatifs

Un projet de webhook n'est pas prêt pour la production tant que son état n'est pas visible. Un tableau de bord opérationnel utile peut commencer par un ensemble d'indicateurs restreint :

  • Part des événements acceptés à la première tentative
  • Temps de bout en bout entre la fin de la conversation et une mise à jour réussie de la destination
  • Nombre et ancienneté des tâches en attente ou échouées
  • Taux de rejeu et classe d'erreur la plus courante
  • Part des événements avec pièces jointes et taux d'échec du traitement multimédia
  • Taux de champs requis manquants dans le mappage CRM

Ces indicateurs révèlent bien plus que des problèmes d'infrastructure. Une augmentation soudaine des champs de qualification manquants peut indiquer qu'une invite ou un flux de conversation a changé. L'observabilité des webhooks relie donc les opérations de la plateforme à la qualité de l'IA conversationnelle.

Liste de contrôle de mise en œuvre

  1. Activez le webhook de fin de conversation pour l'assistant et configurez un point de terminaison HTTPS.
  2. Définissez le schéma cible pour le CRM, le service d'assistance ou l'entrepôt de données.
  3. Créez un magasin d'événements bruts et une clé d'idempotence unique.
  4. Définissez le comportement de la file d'attente, du processus, des tentatives de renvoi et de la file d'attente de lettres mortes.
  5. Sécurisez le chemin multimédia avec des règles de type de contenu, de taille, de détection de logiciels malveillants et de conservation.
  6. Testez WhatsApp, le widget web, les chats sur plusieurs jours, la reprise par un humain et les scénarios de pièces jointes.
  7. Simulez une livraison échouée et prouvez que le rejeu ne crée aucun doublon.
  8. Documentez les alertes et la responsabilité pour les événements bloqués.

Les équipes sans architecture d'automatisation peuvent commencer par la plateforme d'automatisation Famulor ou s'intégrer via l'API et leur propre file d'attente. Pour les flux de travail spécifiques à WhatsApp, Famulor WhatsApp AI fournit la couche de canal.

FAQ

En quoi un webhook de fin de conversation est-il différent d'un webhook post-appel ?

Le webhook de fin de conversation couvre les conversations par chat sur WhatsApp et le widget web. Les appels téléphoniques utilisent le webhook post-appel. Les deux peuvent lancer des flux de travail en aval, mais leurs charges utiles et leurs métadonnées de canal diffèrent.

Le même événement peut-il arriver plusieurs fois ?

Oui. Le renvoi est une possibilité normale avec les webhooks, surtout après un délai d'attente ou une réponse autre que 2xx. Le récepteur doit donc rendre chaque étape de traitement idempotente.

Quel ID utiliser pour la déduplication ?

Pour la finalisation d'une conversation par chat, conversation_id est la clé métier centrale. Pour les actions individuelles en aval, combinez l'ID de conversation avec un nom d'action.

Le gestionnaire HTTP doit-il mettre à jour le CRM directement ?

Cela peut fonctionner pour un petit test, mais une file d'attente est plus fiable en production. Le gestionnaire peut accuser réception rapidement tandis qu'un processus met à jour les systèmes externes avec une gestion des erreurs indépendante.

Quelle est la meilleure façon de commencer ?

Commencez par une destination et un résultat clair, tel que « mettre à jour un prospect qualifié dans le CRM ». Ajoutez l'analyse multimédia, les notifications et les automatisations supplémentaires uniquement une fois que ce chemin est observable et sécurisé contre les rejeux.

Famulor Redaktion
Famulor Redaktion

Rédacteur chez Famulor

Assistant téléphonique IA

Tout inclus, un tarif. essayez Famulor

IA vocale, automatisations et intégrations dans une plateforme.

Appel entrant Famulor AI sur un smartphone
Newsletter

Répondez d'abord. Croissez vite.

Abonnez-vous pour recevoir les dernières nouvelles, les mises à jour de produits et le contenu IA sélectionné.