Configurer les accusés de réception SMS dans Zapier

Un accusé de réception n’est utile que s’il met à jour la bonne fiche. Dans un workflow Zapier, cela peut consister à mettre à jour un contact dans un CRM lorsqu’un fournisseur signale qu’un message a été distribué — ou à ne pas modifier le contact si l’événement concerne une autre campagne. L’essentiel est de relier l’événement du fournisseur à la bonne fiche de destination, sans traiter toutes les mises à jour reçues comme si elles étaient interchangeables.

Ce guide explique comment configurer les accusés de réception SMS dans Zapier, du choix d’une fiche à la vérification du Zap finalisé.

1. Choisissez la fiche que votre Zap doit mettre à jour

Commencez par choisir une destination : un contact dans un CRM, une commande ou une fiche de campagne, selon l’endroit où votre équipe consulte les résultats des SMS. Déterminez à quoi doit ressembler une mise à jour utile : un champ indiquant l’état de distribution, un horodatage ou une note comprenant l’identifiant du message. Si votre objectif est de mettre à jour un contact CRM avec un webhook SMS, précisez également quel champ de ce contact doit recevoir l’information.

Identifiez ensuite une valeur stable permettant de relier l’accusé de réception à cette fiche. L’identifiant du message attribué par le fournisseur est souvent un bon candidat, si votre système l’a enregistré lors de l’envoi du SMS. Le numéro de téléphone du destinataire peut convenir uniquement si l’application de destination permet de retrouver une seule fiche sans ambiguïté. Si une liste importée contient des numéros en double, une recherche basée uniquement sur le numéro risque de mettre à jour le mauvais contact.

Avant de créer le Zap, notez le champ de recherche utilisé par l’application de destination. Par exemple, si le CRM effectue la recherche à partir d’un champ personnalisé contenant l’identifiant du message, vérifiez que votre processus d’envoi enregistre le même identifiant dans ce champ. Un accusé de réception ne peut pas établir ce lien à lui seul si la fiche du SMS d’origine ne contient aucune valeur correspondante.

2. Créez un déclencheur webhook dans Zapier

Créez un Zap et choisissez un déclencheur webhook, comme Catch Hook. Zapier devrait afficher une URL générée pour ce déclencheur. Copiez-la dans une note de travail sécurisée pendant que vous configurez le fournisseur.

Cette URL est l’adresse que le fournisseur de SMS appellera pour transmettre un événement de distribution. Gardez-la confidentielle : ne la publiez pas dans un document partagé et ne l’envoyez pas dans un message ordinaire.

Limitez la portée de la première version. Reliez le déclencheur webhook à une destination de test ou à une fiche de test clairement identifiée, plutôt qu’à la fiche d’un client actif. Vous pourrez ainsi examiner les données reçues par le déclencheur avant qu’un changement d’état n’affecte un workflow en production.

3. Envoyez un exemple d’événement de distribution au déclencheur

Utilisez l’accusé de réception de test du fournisseur de SMS, s’il en propose un, ou envoyez un SMS de test et attendez son accusé de réception.

Une fois l’événement reçu, examinez les champs capturés dans Zapier. Repérez l’identifiant du message, la valeur du destinataire, l’état transmis par le fournisseur et l’horodatage de l’événement. Les noms de champs peuvent être abrégés ou propres au fournisseur : comparez une valeur capturée avec la documentation de ce dernier avant de la mapper à un champ du CRM.

Un seul exemple ne suffit pas à effectuer un test complet. Si le fournisseur peut envoyer un événement de distribution réussie et un événement d’échec, capturez-les séparément et notez le champ qui change. Sans exemple d’échec, vous risquez de créer un Zap qui gère correctement les messages distribués, mais ne fait rien lorsqu’un message ne peut pas être remis.

La distinction entre un événement reçu et la fiche qu’il doit modifier est également abordée dans le contexte des workflows d’e-mails transactionnels dans cet article sur les événements webhook des e-mails transactionnels. Les produits sont différents, mais il reste utile d’examiner les données réelles de l’événement avant de mapper les champs.

4. Associez les états du fournisseur à des libellés utiles

La valeur d’état envoyée par le fournisseur peut ne pas correspondre aux libellés utilisés dans votre application de destination. Déterminez ce que votre équipe doit voir, puis utilisez les outils de formatage ou de branchement disponibles dans Zapier pour convertir les valeurs propres au fournisseur en ces libellés.

Par exemple, votre CRM peut utiliser « Distribué » et « Échec », alors que le fournisseur emploie d’autres termes. Ne mappez que les valeurs que vous avez vérifiées dans les événements capturés ou dans la documentation.

Définissez clairement les correspondances. Une courte liste de règles peut vous aider avant de configurer le Zap :

• Valeur du fournisseur confirmant la distribution : définissez le libellé de destination sur « Distribué ».
• Valeur du fournisseur confirmant un échec : définissez le libellé de destination sur « Échec », ou sur le libellé choisi par votre équipe.
• Valeur inconnue ou manquante : ne modifiez pas l’état ou envoyez l’événement pour vérification.

Ce dernier cas est important. Si un nouvel état apparaît après une modification de la configuration, une règle générale qui étiquette toute valeur inconnue comme « Distribué » pourrait produire un résultat erroné dans le CRM. Vérifiez la définition des états du fournisseur et adaptez le mappage si un événement réel révèle une valeur inattendue.

5. Associez chaque accusé de réception à la bonne fiche de destination

Ajoutez l’action de l’application de destination qui recherche ou met à jour une fiche, puis mappez l’identifiant du message ou du destinataire contenu dans l’accusé de réception au champ de recherche de l’application. Vérifiez que le fournisseur inclut une valeur que l’application de destination peut réellement rechercher. Si l’accusé de réception contient un identifiant de message, mais que votre CRM n’enregistre que les numéros de téléphone, le Zap doit disposer d’un moyen fiable de relier ces deux valeurs avant de pouvoir mettre à jour la bonne fiche.

Testez la recherche sur une fiche que vous pouvez reconnaître. Un contact de test au nom clairement identifiable vous aidera à vérifier si le Zap a trouvé la bonne fiche ou s’il n’a obtenu aucun résultat. Si la recherche peut renvoyer plusieurs fiches, arrêtez-vous et corrigez la clé de correspondance au lieu de laisser le workflow choisir sans règle claire.

Évitez de créer automatiquement une nouvelle fiche client, sauf si cela fait délibérément partie de votre processus ; sinon, une valeur d’accusé de réception mal saisie ou inconnue risque d’encombrer votre système.

Les événements SMS peuvent contenir des données sur les destinataires : ne mappez que les champs dont votre équipe a besoin pour agir. Pour en savoir plus sur le traitement des données dans un autre canal de messagerie, consultez cet article sur le suivi des e-mails et le respect de la vie privée. Dans ce Zap, cela peut vouloir dire ne pas inclure de numéro de téléphone dans une note en texte libre si un libellé d’état et l’identifiant du message suffisent.

6. Évitez d’appliquer des mises à jour obsolètes ou répétées

Avant de relier le Zap à une fiche active, décidez comment il doit gérer les accusés de réception répétés et les états reçus en retard. Sans cela, un événement ancien pourrait remplacer un état plus récent, ou le même événement pourrait générer des notes en double.

Si votre application de destination propose un champ d’horodatage, enregistrez-y l’heure de l’événement avec l’état et utilisez-la pour déterminer si une mise à jour est plus récente. Un champ indiquant l’heure de réception peut faciliter le dépannage, mais il ne permet pas forcément de savoir quel événement du fournisseur s’est produit en premier.

Si le workflow ne peut pas comparer de manière fiable les identifiants d’événement ou les horodatages, privilégiez une action prudente : mettez à jour un seul champ d’état au lieu d’ajouter une note pour chaque accusé de réception, et consultez l’historique des tâches si des modifications en double apparaissent.

7. Testez l’ensemble du Zap avec de véritables données d’accusé de réception

Lancez un test depuis le déclencheur jusqu’à l’action de destination. Pour suivre la distribution des SMS dans Zapier, vérifiez que l’accusé de réception atteint la bonne fiche, que l’état du fournisseur devient le libellé attendu et que les champs sans rapport avec cette mise à jour restent inchangés. La réussite du test du déclencheur ne prouve pas à elle seule que l’étape de recherche a sélectionné le bon contact.

Testez au moins un événement qui doit mettre à jour une fiche et un cas qui ne le doit pas, par exemple un accusé de réception sans identifiant correspondant, si votre fournisseur peut en produire un. Vérifiez la destination après chaque exécution. Zapier peut indiquer qu’une action a été exécutée, mais ce sont les valeurs visibles dans la fiche que votre équipe doit vérifier concrètement.

Si une exécution ne se déroule pas comme prévu, consultez l’historique des tâches dans Zapier et comparez les valeurs reçues par le déclencheur aux champs utilisés dans les actions de recherche et de mise à jour. Vérifiez si l’identifiant du message est vide, si le mappage de l’état n’a pas pris en compte une valeur du fournisseur ou si l’application de destination a trouvé une autre fiche. Apportez une seule correction à la fois, puis testez à nouveau l’ensemble du parcours.

Avant de passer d’une fiche de test à une destination en production, vérifiez ensemble le Zap sélectionné, l’URL du déclencheur, le champ de recherche et le mappage des états. Notez les valeurs d’état du fournisseur que vous avez confirmées ; si un test ultérieur produit une nouvelle valeur, suspendez la règle de mise à jour jusqu’à ce que vous sachiez ce qu’elle signifie.