Intégration de Salesforce avec le Guest WiFi pour l'Account Intelligence

SCRIPT DE PODCAST — « Intégration de Salesforce avec le Guest WiFi pour l'Account Intelligence » Série de briefings techniques Purple | Durée : ~10 minutes | Anglais britannique --- [INTRODUCTION & CONTEXTE — 1 minute] Bienvenue dans la série de briefings techniques Purple. Je suis votre hôte, et aujourd'hui nous abordons un sujet que de nombreuses entreprises B2B ont sur leur feuille de route mais n'ont pas encore tout à fait résolu : connecter votre infrastructure guest WiFi directement à Salesforce pour générer une véritable intelligence de compte. Si vous disposez d'un site — un centre de conférences, un hôtel, un salon professionnel, un campus d'entreprise — et que vous proposez du guest WiFi, vous êtes assis sur une mine d'or de données d'intention de première partie (first-party intent data). Chaque fois qu'un prospect, un partenaire ou un client se connecte à votre réseau, il vous transmet une information. Il est sur place. Il est engagé. Et à l'heure actuelle, pour la plupart des organisations, ce signal disparaît dans la nature. Ce que nous allons voir aujourd'hui, c'est comment changer cela. Comment acheminer cet événement d'authentification WiFi vers Salesforce, le faire correspondre à vos comptes existants et déclencher la bonne réponse commerciale — qu'il s'agisse d'une alerte pour un Account Executive, de l'enrichissement d'un enregistrement de contact ou d'un signalement pour que votre équipe RevOps agisse. Il s'agit d'un briefing pratique. Nous passerons en revue l'architecture, les décisions relatives au modèle de données, les considérations liées au GDPR et les pièges courants. C'est parti. --- [ANALYSE TECHNIQUE APPROFONDIE — 5 minutes] Commençons par l'architecture. À la base, une intégration WiFi Salesforce comporte trois composants : la couche Captive Portal, le middleware d'intégration et le modèle de données Salesforce. Le Captive Portal — ce que votre invité voit lorsqu'il se connecte — est l'endroit où se fait la capture d'identité. Lorsqu'un visiteur s'authentifie par e-mail, LinkedIn ou une connexion sociale, la plateforme capture une adresse e-mail vérifiée, un horodatage, un identifiant de site et l'enregistrement du consentement. Ce dernier point est non négociable en vertu du GDPR et du UK Data Protection Act 2018. Vous avez besoin d'un consentement explicite et granulaire pour les communications marketing, et cet enregistrement de consentement doit être stocké et auditable. La plateforme de Purple gère cela nativement, en capturant le consentement au moment de l'authentification et en transmettant un indicateur de consentement à Salesforce aux côtés des données de contact. C'est dans le middleware d'intégration que l'intelligence entre en jeu. Le moteur d'intégration de Purple reçoit cet événement d'authentification et effectue ce que nous appelons la résolution d'identité. La première étape est une correspondance de domaine : prendre l'adresse e-mail, en extraire le domaine — disons acme-corp.com — et interroger Salesforce pour trouver des enregistrements de Compte (Account) ayant un site web ou un champ de domaine de messagerie correspondant. C'est votre principal signal de correspondance. Si une correspondance de domaine est trouvée, le middleware vérifie ensuite si un enregistrement de Contact existe déjà pour cette adresse e-mail spécifique. Si c'est le cas, vous mettez à jour l'enregistrement existant — enregistrez une nouvelle activité, mettez à jour l'horodatage de dernière visite, incrémentez un compteur de visites. Si aucun Contact n'existe mais que le Compte existe, vous créez un nouveau Contact et l'associez à ce Compte. Si aucun des deux n'existe — le domaine est inconnu — vous créez un enregistrement de Lead et le signalez pour examen. Cette logique d'acheminement à trois voies est le fondement d'un modèle de données Salesforce propre pour les contacts issus du WiFi. L'alternative — pousser tout en tant que Lead quel que soit le contexte — crée le cauchemar de qualité des données que la plupart des équipes RevOps redoutent : des milliers de leads en double, aucune association de compte, et des Account Executives qui manquent des signaux sur leur portefeuille de clients existant. Laissez-moi vous parler plus en détail du modèle de données Salesforce, car les décisions de mappage de champs que vous prenez ici ont des conséquences à long terme. Sur l'objet Lead, vous souhaitez capturer : le nom du site WiFi, la date de première visite, la date de dernière visite, le nombre de visites, le statut du consentement et la source du lead définie sur une valeur standardisée telle que « Guest WiFi ». Sur l'objet Contact, les mêmes champs s'appliquent, plus une relation de recherche (lookup) vers le Compte parent. Sur l'objet Compte, vous souhaitez un champ de résumé de cumul (roll-up summary) indiquant le nombre total de contacts authentifiés par WiFi, un champ de date du dernier visiteur et un score de fréquence de visite. Ce sont ces champs au niveau du Compte qui rendent cette intégration véritablement utile pour la vente basée sur les comptes (account-based selling). Passons maintenant au mécanisme d'alerte. C'est là que la valeur commerciale devient tangible. En utilisant Salesforce Flow — ou Process Builder si vous êtes sur une ancienne organisation —, vous configurez des déclencheurs basés sur des conditions spécifiques. L'alerte la plus précieuse est ce que nous appelons le déclencheur « Visite de compte cible » : lorsqu'un Contact associé à un Compte marqué comme compte cible s'authentifie sur votre WiFi, l'Account Executive attribué reçoit une Tâche Salesforce et une notification Chatter en quelques minutes. Le message est simple : « James d'Acme Corp vient de se connecter sur votre site de Manchester. Il a visité trois fois ce trimestre. » C'est un signal d'approche chaleureux pour lequel la plupart des équipes commerciales paieraient cher. Et vous le générez passivement, à partir d'une infrastructure que vous possédez déjà. Une deuxième alerte qui vaut la peine d'être configurée est le déclencheur de « Réengagement » : un Contact inactif depuis plus de quatre-vingt-dix jours se connecte à votre WiFi. Cela fait remonter à la surface des contacts perdus ou froids qui sont physiquement de retour dans votre orbite — un signal fort pour des conversations de renouvellement. Troisièmement, l'alerte « Nouveau domaine » : une connexion WiFi à partir d'un domaine de messagerie qui ne correspond à aucun Compte existant. Cela est acheminé vers une file d'attente de BDR ou de RevOps pour qualification. Tous les domaines inconnus ne sont pas des prospects, mais le filtrage des domaines d'entreprise — en excluant Gmail, Outlook et d'autres fournisseurs grand public — vous donne un signal de prospection de haute qualité. Du côté de l'intégration technique, Purple expose une API REST et prend en charge les webhooks sortants. Le modèle recommandé pour l'intégration Salesforce est une approche de type webhook-vers-middleware : Purple déclenche un webhook à chaque événement d'authentification, une couche de middleware légère — qui peut être une Connected App Salesforce, un flux MuleSoft ou une simple fonction AWS Lambda — reçoit la charge utile (payload), exécute la logique de correspondance de domaine et appelle l'API REST de Salesforce pour effectuer un upsert de l'enregistrement approprié. Cela permet de conserver la logique en dehors de Salesforce, ce qui la rend plus facile à maintenir et à tester de manière indépendante. Pour les organisations disposant de la plateforme MuleSoft Anypoint de Salesforce, la documentation de l'API de Purple fournit un modèle de connecteur pré-intégré. Pour celles qui n'ont pas MuleSoft, une définition de service externe Salesforce pointant vers l'API de Purple, combinée à un Flow, permet d'obtenir le même résultat sans code personnalisé. Une autre considération technique : la randomisation des adresses MAC. Les appareils iOS et Android modernes randomisent leur adresse MAC à chaque connexion réseau, ce qui signifie que vous ne pouvez pas utiliser l'adresse MAC comme identifiant d'appareil persistant pour le suivi des visiteurs récurrents. L'adresse e-mail, capturée lors de l'authentification, est votre identifiant persistant fiable. C'est une autre raison pour laquelle l'authentification par Captive Portal basée sur l'e-mail est architecturalement supérieure à l'authentification par simple clic ou par appareil seul pour l'intégration CRM. --- [RECOMMANDATIONS D'IMPLÉMENTATION & PIÈGES — 2 minutes] Laissez-moi vous présenter les quatre éléments qui séparent un déploiement propre d'un déploiement chaotique. Premièrement : définissez votre blocklist de domaines avant la mise en service. Les domaines de messagerie grand public — Gmail, Yahoo, Hotmail, iCloud, Outlook — doivent être exclus de la correspondance de Compte et de la création de Lead. Si vous ne le faites pas, vous inonderez votre organisation Salesforce de contacts grand public sans valeur commerciale, ce qui dégradera la qualité des données pour votre équipe commerciale. Créez une blocklist mise à jour et appliquez-la dans votre logique de middleware. Deuxièmement : convenez de votre seuil de conversion de Lead en Contact avec votre responsable RevOps avant le déploiement. Une erreur courante consiste à créer des Leads à partir d'événements WiFi et à ne jamais les convertir, de sorte qu'ils restent indéfiniment dans une file d'attente de Leads. Définissez une règle : si un Lead provenant d'un domaine d'entreprise connu effectue plus de deux visites en l'espace de trente jours, convertissez-le automatiquement en Contact et associez-le au Compte correspondant. Cela permet de garder votre pipeline propre et vos AE concentrés. Troisièmement : ne faites pas l'impasse sur l'architecture de consentement. En vertu du GDPR, vous avez besoin d'une base légale pour le traitement, et pour les communications marketing, cette base est le consentement. Votre Captive Portal doit présenter une option d'inscription (opt-in) claire pour le marketing, distincte des conditions d'utilisation pour l'accès WiFi. La plateforme de Purple prend en charge des catégories de consentement granulaires — accès WiFi, e-mail marketing, partage avec des tiers — et les transmet sous forme d'indicateurs booléens dans la charge utile de l'API. Mappez-les directement vers les champs de Contact Salesforce et respectez-les dans vos règles d'automatisation marketing. Quatrièmement : dotez votre intégration d'un système de journalisation des erreurs dès le premier jour. Les événements d'authentification qui ne parviennent pas à correspondre ou à créer un enregistrement Salesforce doivent être consignés dans un objet Salesforce personnalisé ou un outil de surveillance externe. Sans cela, vous ferez face à des échecs silencieux — des visiteurs se connectent mais aucun enregistrement n'est créé — et vous ne le saurez que lorsque quelqu'un remarquera que les données semblent incomplètes. --- [QUESTIONS-RÉPONSES RAPIDES — 1 minute] Très bien, passons à une session rapide de questions-réponses sur les questions que j'entends le plus souvent. « Dois-je synchroniser vers des Leads ou des Contacts ? » — Commencez par des Contacts pour les comptes connus, et des Leads pour les inconnus. Ne poussez jamais tout vers les Leads. « Qu'en est-il du GDPR ? » — Consentement au niveau du portail, indicateur de consentement dans Salesforce, respectez-le dans chaque système en aval. Non négociable. « Comment gérer les lieux de conférence où des milliers de personnes se connectent en une journée ? » — Limitez le débit de traitement de vos webhooks, regroupez vos upserts Salesforce par lots et utilisez l'API Bulk de Salesforce pour les événements à fort volume. N'utilisez pas l'API REST standard pour des déploiements à l'échelle d'un stade. « Puis-je utiliser cela pour l'ABM ? » — Absolument. Marquez vos comptes cibles dans Salesforce, configurez un Flow pour alerter vos AE lors de toute visite WiFi provenant de ces comptes, et vous disposez d'un signal d'intention physique qu'aucun outil ABM numérique ne peut reproduire. « Quel est le ROI ? » — Les entreprises qui utilisent l'intégration Salesforce de Purple signalent une augmentation de 20 à 35 % des prises de contact initiées par les AE sur les comptes existants, entièrement générée par les alertes de visite WiFi. Le pipeline influencé par les contacts issus du WiFi affiche généralement un taux de clôture supérieur de 15 à 25 % par rapport à la prospection à froid, car le visiteur a fait preuve d'un engagement physique. --- [RÉSUMÉ & PROCHAINES ÉTAPES — 1 minute] Pour résumer : l'intégration WiFi de Salesforce est une capacité mature et déployable qui transforme une infrastructure réseau passive en un signal d'intelligence de compte actif. L'architecture est simple — Captive Portal, middleware de résolution d'identité, upsert Salesforce — mais la valeur réside dans les décisions relatives au modèle de données, la configuration des alertes et la gouvernance de la qualité des données que vous mettez en place autour. Vos prochaines étapes immédiates : auditez vos enregistrements de Comptes Salesforce actuels pour vérifier l'exhaustivité des champs de domaine — c'est votre base de correspondance. Engagez votre responsable RevOps pour définir les règles d'acheminement entre Leads et Contacts. Et passez en revue la documentation d'intégration Salesforce de Purple pour comprendre la structure de la charge utile de l'API et les événements de webhook disponibles. Si vous proposez du guest WiFi sur un site visité par vos clients ou prospects, cette intégration devrait être opérationnelle d'ici un trimestre. Les données sont là. Il vous suffit de les connecter. Merci pour votre écoute. Si vous souhaitez approfondir l'un des sujets abordés aujourd'hui, le guide de référence technique complet est disponible sur purple.ai. Nous vous donnons rendez-vous pour le prochain briefing. --- [FIN DU SCRIPT]