Nous utilisons des cookies
Nous utilisons des cookies et des technologies similaires pour améliorer votre expérience, analyser le trafic et personnaliser le contenu. Vous pouvez accepter tous les cookies ou rejeter ceux non essentiels.
19 Oct 2026
La plupart des entreprises qui sondent leurs clients après un achat suivent le même scénario : exporter les commandes de l’ERP ou de la plateforme e-commerce une fois par jour, les rapprocher d’une liste de contacts, puis envoyer un e-mail CSAT trois jours plus tard. Techniquement, ça fonctionne. Mais cela traite chaque commande comme un événement identique, ignore le fait que « livré », « retourné » et « ticket ouvert » sont des moments totalement différents appelant des questions totalement différentes, et cela accuse toujours un jour de retard sur la réalité.
La solution n’est pas un meilleur export. Il s’agit de traiter chaque événement commercial — commande passée, expédiée, livrée, retournée, remboursée, ticket de support résolu — comme son propre déclencheur, qui envoie le bon sondage, à la bonne personne, au bon moment, avec le contexte de commande déjà attaché. C’est un problème de connexion, pas un problème de conception de sondage, et il vaut mieux être honnête sur ce que cette connexion exige réellement.
Un déclencheur unique par lot lié à « commande créée » ne peut pas distinguer un client dont le colis est arrivé à temps d’un client dont le colis est coincé dans un entrepôt. Il ne peut pas distinguer un acheteur pour la première fois de quelqu’un qui en est à sa dixième commande. Et il ne peut certainement pas vous dire que la commande en question était en réalité un retour, et non un achat — car au moment où l’export CSV s’exécute, le retour a déjà été fondu dans « commande » sous forme d’un simple champ de statut générique.
Le résultat, ce sont des sondages qui posent la mauvaise question au mauvais moment : un e-mail NPS qui arrive le même jour qu’une livraison retardée, ou un sondage de satisfaction générique envoyé à quelqu’un en plein processus de retour et qui veut simplement se faire rembourser. Rien de tout cela n’est un échec de rédaction du sondage. C’est un échec de plomberie — le système de feedback n’a jamais reçu l’événement spécifique, seulement un instantané quotidien.
Dès lors que l’on considère le cycle de vie commercial comme une séquence d’événements distincts plutôt qu’une seule ligne dans un tableau, la stratégie de sondage devient beaucoup plus évidente :
Chacun de ces cas mérite un jeu de questions différent, un canal différent, et dans plusieurs cas une urgence différente. Une expédition retardée peut justifier une prise de contact proactive immédiate ; un ticket résolu peut justifier un CSAT le jour même. Les exports par lot aplatissent tout cela en une seule étape indifférenciée « envoyer un sondage ».
Pour les distributeurs et détaillants du marché intermédiaire utilisant Tally Prime, le connecteur Tally Prime est le chemin le plus direct entre un événement commercial et un déclenchement de sondage. Il s’installe sous forme de fichier TDL et lit directement les types de bons standard et personnalisés d’une société Tally — bons de vente, avoirs, reçus, fiches de stock, tout ce que l’entreprise suit. Chaque type de transaction peut être configuré indépendamment : sa propre méthode d’authentification (clé API, authentification de base, OAuth 2.0 avec renouvellement automatique des jetons, ou requêtes signées HMAC), son propre mode de déclenchement (temps réel à l’enregistrement, par lot à intervalle de 5 à 60 minutes, planifié quotidien/hebdomadaire/mensuel, ou export ponctuel manuel), et son propre identifiant de workflow.
Cette granularité par type de transaction est ici essentielle. Les bons de vente peuvent fonctionner en mode temps réel et déclencher immédiatement un workflow lorsqu’une commande est facturée. Les avoirs — c’est-à-dire les retours — peuvent fonctionner sur le même paramètre temps réel mais être acheminés vers un workflow complètement différent qui lance un formulaire de prise en charge RMA au lieu d’un sondage de satisfaction. Les fiches de stock, qui n’exigent pas de réaction instantanée, peuvent être regroupées par lot dans un workflow nocturne dédié à l’analyse.
Toutes les entreprises n’utilisent pas Tally. Shopify, Magento, un système de gestion de commandes sur mesure, ou un outil de traitement des commandes développé en interne peuvent tous transmettre les événements du cycle de vie des commandes à SurveyAnalytica sous forme de charges utiles webhook génériques, que le moteur de workflow accepte comme un type de déclencheur à part entière, au même titre que les événements de clickstream et les événements de cycle de vie des threads. Le mécanisme est identique quelle que soit la source : un événement arrive avec des champs structurés (ID de commande, ID client, liste de SKU, statut, horodatage), et une condition de workflow décide de la suite en fonction du champ statut — « livré » emprunte une branche, « retour_demandé » en emprunte une autre.
Pour les organisations soumises à des contrôles réseau d’entreprise stricts, le trafic sortant du workflow peut passer par un proxy HTTP, HTTPS (tunnelisé via CONNECT) ou SOCKS5, ce qui compte plus qu’il n’y paraît — de nombreuses équipes informatiques du marché intermédiaire n’approuveront pas une nouvelle intégration SaaS tant qu’elles n’auront pas confirmé qu’elle respecte les règles de sortie existantes.
Les événements de commande vous disent ce qui s’est passé. Ils ne vous disent pas ce qui y a mené. Les SDK Clickstream Publisher (web, React Native, Flutter, iOS, Android) capturent la session de navigation avant un achat — pages produits consultées, abandon de panier, temps passé sur la page de politique de retour — et l’appel identify relie cette session anonyme au contact connu une fois que le client se connecte ou passe à la caisse. Cela signifie qu’au moment où un événement de commande passée déclenche un workflow, le même ID de contact dispose déjà d’un historique comportemental attaché, ce qui constitue un contexte utile lorsqu’il s’agit de déterminer si un faible score CSAT est un incident isolé ou une tendance.
Voici une construction concrète pour un distributeur du marché intermédiaire utilisant Tally Prime pour la facturation et l’exécution des commandes :
Rien dans cette construction n’a nécessité de développement sur mesure. Il a fallu mapper correctement les champs des bons vers des variables de workflow, choisir le bon mode de déclenchement par type de transaction, et décider quelle branche chaque événement devait emprunter — un travail de configuration, pas de code.
Il convient d’être direct sur le coût de mise en place, car les éditeurs qui ne vendent que la couche sondage n’ont rarement à l’être. Connecter les événements commerciaux aux workflows de feedback exige : un ID client ou contact présent dans la charge utile du système source (si votre ERP n’en capture pas un de manière fiable, le rapprochement échoue avant même de commencer) ; une configuration correcte par type de transaction dans le connecteur, y compris l’authentification et le mode de déclenchement ; un travail DNS si vous souhaitez des domaines d’envoi de marque ou un domaine de portail participant personnalisé ; et quelqu’un dans l’équipe qui comprenne à la fois le modèle de données du système source et le moteur de workflow suffisamment bien pour mapper correctement les champs. Rien de tout cela n’est exotique, mais ce n’est pas non plus un réglage de cinq minutes, et tout guide d’intégration qui laisse entendre le contraire passe sous silence la partie qui détermine réellement si le pipeline tient sous un volume réel de commandes.
Le schéma décrit ci-dessus fonctionne parce que SurveyAnalytica traite les événements commerciaux comme des déclencheurs de workflow natifs, sans exiger une étape d’import distincte. Le moteur de workflow accepte les charges utiles webhook, les événements de connecteur, les événements de clickstream et les événements de cycle de vie des threads comme des types de déclencheurs équivalents, et la configuration par type de transaction dans le connecteur Tally Prime signifie qu’un bon de vente et un avoir issus du même système comptable peuvent générer des expériences de sondage totalement différentes, sans middleware sur mesure.
Les sections répétables résolvent le problème structurel que les créateurs de sondages génériques ne gèrent pas — un retour comportant quatre articles ne devrait pas produire un seul bloc de texte fusionné et illisible, il devrait produire quatre réponses analysées indépendamment, avec une numérotation d’articles stable pour le reporting en aval. Et comme la même plateforme héberge le sondage, le workflow et la couche analytique, les cartes KPI et les scores de sentiment générés à partir d’un formulaire RMA sont immédiatement disponibles sur un tableau de bord opérationnel, sans étape séparée d’export et de rapprochement.
Rien de tout cela ne remplace la nécessité d’avoir des ID clients propres dans vos systèmes sources, ni de réaliser correctement la configuration DNS et d’authentification — ce travail de fond incombe à l’acheteur, pas à la plateforme. Ce que cela supprime, c’est le besoin d’une couche d’intégration distincte simplement pour qu’un événement de commande puisse, en premier lieu, déclencher le bon sondage.
Build surveys, run campaigns, and analyze responses with AI — free to start.
L’écart entre « nous envoyons des sondages post-achat » et « nous savons exactement pourquoi ce client est mécontent et quelle commande en est la cause » n’est pas un problème de conception de sondage — c’est un problème de connexion. Commande passée, expédiée, livrée, retournée et remboursée sont cinq moments différents qui méritent cinq questions différentes, déclenchées par l’événement réel plutôt que par un traitement par lot nocturne. Réglez correctement le déclencheur, et l’insight suivra naturellement ; ratez-le, et aucune conception astucieuse de questions ne pourra corriger un sondage qui arrive au mauvais moment en posant la mauvaise question.
No comments yet. Be the first to comment!