Integración de Salesforce con WiFi de invitados para Account Intelligence

GUION DE PODCAST — "Integración de Salesforce con WiFi de invitados para Account Intelligence" Serie de informes técnicos de Purple | Duración: ~10 minutos | Inglés del Reino Unido --- [INTRODUCCIÓN Y CONTEXTO — 1 minuto] Bienvenidos a la serie de informes técnicos de Purple. Soy su anfitrión, y hoy nos adentraremos en algo que muchas organizaciones B2B tienen en su hoja de ruta pero que aún no han logrado resolver del todo: conectar su infraestructura de WiFi de invitados directamente con Salesforce para generar verdadera Account Intelligence. Si dispone de un recinto (un centro de conferencias, un hotel, una feria comercial, un campus corporativo) y ofrece WiFi de invitados, está sentado sobre una mina de oro de datos de intención de primera mano (first-party intent data). Cada vez que un cliente potencial, un socio o un cliente se conecta a su red, le está diciendo algo. Está en el lugar. Está interactuando. Y en este momento, para la mayoría de las organizaciones, esa señal desaparece en el éter. Lo que vamos a cubrir hoy es cómo cambiar eso. Cómo enrutar ese evento de autenticación de WiFi hacia Salesforce, hacerlo coincidir con sus cuentas existentes y activar la respuesta comercial adecuada, ya sea una alerta para un Account Executive, el enriquecimiento de un registro de contacto o una señal para que su equipo de RevOps actúe. Este es un informe práctico. Analizaremos la arquitectura, las decisiones del modelo de datos, las consideraciones del GDPR y los errores comunes. Comencemos. --- [ANÁLISIS TÉCNICO DETALLADO — 5 minutos] Comencemos con la arquitectura. En su esencia, una integración de WiFi con Salesforce consta de tres componentes: la capa del Captive Portal, el middleware de integración y el modelo de datos de Salesforce. El Captive Portal (lo que ve su invitado al conectarse) es donde se realiza la captura de identidad. Para la inteligencia B2B, se requiere estrictamente la autenticación por correo electrónico o el inicio de sesión único (SSO) de LinkedIn. La autenticación mediante un solo clic o solo por SMS (como se analiza en [SMS vs Email Verification for Guest WiFi: Which to Choose](/guides/sms-vs-email-verification-guest-wifi)) no proporciona el identificador persistente necesario para una coincidencia sólida en el CRM. Crucialmente, esta capa también debe gestionar el cumplimiento normativo. Bajo el GDPR y la Ley de Protección de Datos del Reino Unido de 2018, se necesita un consentimiento explícito y granular para las comunicaciones de marketing, y ese registro de consentimiento debe ser almacenable y auditable. La plataforma de Purple gestiona esto de forma nativa, capturando el consentimiento en el punto de autenticación y transmitiendo una marca de consentimiento a Salesforce junto con los datos de contacto. Ahora bien, el middleware de integración es donde ocurre la inteligencia. El motor de integración de Purple recibe ese evento de autenticación y realiza lo que llamamos resolución de identidad. El primer paso es una coincidencia de dominio: tomar la dirección de correo electrónico, extraer el dominio (por ejemplo, acme-corp.com) y consultar en Salesforce cualquier registro de Cuenta con un sitio web o campo de dominio de correo electrónico coincidente. Esta es su señal de coincidencia principal. Si se encuentra una coincidencia de dominio, el middleware comprueba si ya existe un registro de Contacto para esa dirección de correo electrónico específica. Si es así, se actualiza el registro existente: se registra una nueva actividad, se actualiza la marca de tiempo de la última vez que se le vio y se incrementa un contador de visitas. Si no existe un Contacto pero la Cuenta sí, se crea un nuevo Contacto y se asocia a esa Cuenta. Si no existe ninguno de los dos (el dominio es desconocido), se crea un registro de Lead y se marca para su revisión. Esta lógica de enrutamiento de tres vías es la base de un modelo de datos de Salesforce limpio para contactos procedentes de WiFi. La alternativa (enviar todo como un Lead independientemente del contexto) crea la pesadilla de calidad de datos que la mayoría de los equipos de RevOps temen: miles de leads duplicados, sin asociación de cuentas y Account Executives que pierden señales sobre su cartera de clientes existente. Permítanme hablar sobre el modelo de datos de Salesforce con más detalle, porque las decisiones de mapeo de campos que tomen aquí tienen consecuencias a largo plazo. En el objeto Lead, querrá capturar: WiFi Venue Name, First Seen Date, Last Seen Date, Visit Count, Consent Status y Lead Source establecido en un valor estandarizado como "Guest WiFi". En el objeto Contacto, se aplican los mismos campos, además de una búsqueda (lookup) a la Cuenta principal. En el objeto Cuenta, querrá un campo de resumen de propagación (roll-up summary) que muestre el total de contactos autenticados por WiFi, un campo Last Visitor Date y una puntuación de Visit Frequency. Estos campos a nivel de Cuenta son los que hacen que esta integración sea genuinamente útil para la venta basada en cuentas. Ahora, el mecanismo de alerta. Aquí es donde el valor comercial se vuelve tangible. Utilizando Salesforce Flow (o Process Builder si se encuentra en una organización más antigua), configurará desencadenadores basados en condiciones específicas. La alerta más valiosa es la que llamamos el desencadenador de 'Visita de cuenta objetivo': cuando un Contacto asociado con una Cuenta etiquetada como cuenta objetivo se conecta a su WiFi, el Account Executive asignado recibe una Tarea de Salesforce y una notificación de Chatter en cuestión de minutos. El mensaje es sencillo: 'James de Acme Corp se acaba de conectar en su recinto de Manchester. Ha realizado tres visitas este trimestre'. Esa es una de las señales de contacto directo más valiosas que la mayoría de los equipos de ventas pagarían mucho dinero por obtener. Y la está generando de forma pasiva, a partir de una infraestructura que ya posee. Una segunda alerta que vale la pena configurar es el desencadenador de 'Reactivación': un Contacto que ha estado inactivo durante más de noventa días se conecta a su WiFi. Esto saca a la luz contactos perdidos o fríos que vuelven a estar físicamente en su órbita, una señal sólida para conversaciones de renovación. En tercer lugar, la alerta de 'Nuevo dominio': un inicio de sesión de WiFi desde un dominio de correo electrónico que no coincide con ninguna Cuenta existente. Esto se enruta a una cola de BDR o RevOps para su cualificación. No todos los dominios desconocidos son clientes potenciales, pero filtrar por dominios de empresas (excluyendo Gmail, Outlook y otros proveedores de consumo) le ofrece una señal de prospección de alta calidad. Por el lado de la integración técnica, Purple expone una API REST y admite webhooks salientes. El patrón recomendado para la integración con Salesforce es un enfoque de webhook a middleware: Purple activa un webhook en cada evento de autenticación, una capa de middleware ligera (que puede ser una Connected App de Salesforce, un flujo de MuleSoft o una función simple de AWS Lambda) recibe el payload, realiza la lógica de coincidencia de dominios y llama a la API REST de Salesforce para realizar un upsert del registro correspondiente. Esto mantiene la lógica fuera de Salesforce, lo que facilita su mantenimiento y pruebas de forma independiente. Para las organizaciones que cuentan con la plataforma MuleSoft Anypoint de Salesforce, la documentación de la API de Purple proporciona una plantilla de conector preconstruida. Para aquellas que no tienen MuleSoft, una definición de Servicio Externo de Salesforce que apunte a la API de Purple, combinada con un Flow, logra el mismo resultado sin código personalizado. Una consideración técnica más: la aleatorización de direcciones MAC. Los dispositivos iOS y Android modernos aleatorizan su dirección MAC en cada conexión de red, lo que significa que no se puede utilizar la dirección MAC como un identificador de dispositivo persistente para el seguimiento de visitantes recurrentes. La dirección de correo electrónico, capturada en la autenticación, es su identificador persistente confiable. Esta es otra razón por la cual la autenticación en el Captive Portal basada en correo electrónico es arquitectónicamente superior a la autenticación de un solo clic o basada únicamente en el dispositivo para fines de integración con el CRM. --- [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — 2 minutos] Permítanme darles las cuatro cosas que diferencian un despliegue limpio de uno desordenado. Primero: defina su lista de bloqueo de dominios antes de la puesta en marcha. Los dominios de correo electrónico de consumo (Gmail, Yahoo, Hotmail, iCloud, Outlook) deben excluirse de la coincidencia de Cuentas y de la creación de Leads. Si no lo hace, inundará su organización de Salesforce con contactos de consumo que no tienen valor comercial y degradará la calidad de los datos para su equipo de ventas. Cree una lista de bloqueo mantenida y aplíquela en su lógica de middleware. Segundo: acuerde su umbral de conversión de Lead a Contacto con su responsable de RevOps antes del despliegue. Un error común es crear Leads a partir de eventos de WiFi y nunca convertirlos, por lo que permanecen en una cola de Leads indefinidamente. Defina una regla: si un Lead de un dominio de empresa conocido realiza más de dos visitas en un plazo de treinta días, conviértalo automáticamente en Contacto y asócielo a la Cuenta coincidente. Esto mantiene su pipeline limpio y a sus AE enfocados. Tercero: no omita la arquitectura de consentimiento. Bajo el GDPR, necesita una base legal para el procesamiento, y para las comunicaciones de marketing, esa base es el consentimiento. Su Captive Portal debe presentar una opción de inclusión (opt-in) clara para el marketing, independiente de las condiciones del servicio para el acceso al WiFi. La plataforma de Purple admite categorías de consentimiento granulares (acceso a WiFi, correo electrónico de marketing, uso compartido con terceros) y las transmite como marcas booleanas en el payload de la API. Mapee estas directamente a los campos de Contacto de Salesforce y respételas en sus reglas de automatización de marketing. Cuarto: instrumente su integración con registro de errores desde el primer día. Los eventos de autenticación que no coincidan o no logren crear un registro en Salesforce deben registrarse en un objeto personalizado de Salesforce o en una herramienta de monitoreo externa. Sin esto, tendrá fallos silenciosos (visitantes que se conectan pero no se crean registros) y no lo sabrá hasta que alguien note que los datos parecen escasos. --- [PREGUNTAS Y RESPUESTAS RÁPIDAS — 1 minuto] Muy bien, hagamos una sesión rápida de preguntas y respuestas sobre las dudas que escucho con más frecuencia. "¿Debería sincronizar con Leads o Contactos?" — Comience con Contactos para cuentas conocidas y Leads para las desconocidas. Nunca envíe todo a Leads. "¿Qué pasa con el GDPR?" — Consentimiento en el portal, marca de consentimiento en Salesforce, respételo en cada sistema descendente. No es negociable. "¿Cómo gestiono los recintos de conferencias donde se conectan miles de personas en un día?" — Limite la tasa de procesamiento de sus webhooks, agrupe sus upserts de Salesforce en lotes y utilice la API Bulk de Salesforce para eventos de gran volumen. No utilice la API REST estándar para despliegues a escala de estadios. "¿Puedo usar esto para ABM?" — Absolutamente. Etiquete sus cuentas objetivo en Salesforce, configure un Flow para alertar a sus AE sobre cualquier visita de WiFi de esas cuentas, y tendrá una señal de intención física que ninguna herramienta digital de ABM puede replicar. "¿Cuál es el ROI?" — Las organizaciones que utilizan la integración de Salesforce de Purple informan de un aumento del 20 al 35 por ciento en el contacto iniciado por los AE en cuentas existentes, impulsado en su totalidad por las alertas de visitas de WiFi. El pipeline influenciado por contactos procedentes de WiFi suele mostrar una tasa de cierre entre un 15 y un 25 por ciento más alta en comparación con el contacto en frío, porque el visitante ha demostrado una interacción física. --- [RESUMEN Y PRÓXIMOS PASOS — 1 minuto] Para resumir: la integración de WiFi con Salesforce es una capacidad madura y desplegable que convierte la infraestructura de red pasiva en una señal activa de Account Intelligence. La arquitectura es sencilla (Captive Portal, middleware de resolución de identidad, upsert en Salesforce), pero el valor reside en las decisiones del modelo de datos, la configuración de alertas y la gobernanza de la calidad de los datos que establezca a su alrededor. Sus próximos pasos inmediatos: audite sus registros actuales de Cuentas de Salesforce para verificar la integridad del campo de dominio; esa es su base de coincidencia. Involucre a su responsable de RevOps para definir las reglas de enrutamiento de Lead frente a Contacto. Y revise la documentación de integración de Salesforce de Purple para comprender la estructura del payload de la API y los eventos de webhook disponibles. Si ofrece WiFi de invitados en un recinto donde le visitan sus clientes o clientes potenciales, esta integración debería estar activa en un trimestre. Los datos están ahí. Solo tiene que conectarlos. Gracias por escuchar. Si desea profundizar en cualquiera de los temas tratados hoy, la guía de referencia técnica completa está disponible en purple.ai. Nos vemos en el próximo informe. --- [FIN DEL GUION]