Integración de Salesforce con WiFi de invitados para inteligencia de cuentas

PODCAST SCRIPT — "Salesforce Integration with Guest WiFi for Account Intelligence" Purple Technical Briefing Series | Runtime: ~10 minutes | UK English --- [INTRODUCTION & CONTEXT — 1 minute] Bienvenido a la serie Purple Technical Briefing. Soy su anfitrión, y hoy nos adentraremos en algo que muchas organizaciones B2B tienen en su plan de trabajo pero que aún no han logrado resolver del todo: conectar su infraestructura de guest WiFi directamente a Salesforce para generar account intelligence real. Si usted tiene un recinto —un centro de conferencias, un hotel, un piso de exhibición, un campus corporativo— y ofrece guest WiFi, está sentado sobre una mina de oro de datos de intención de primera mano. Cada vez que un prospecto, un socio o un cliente se conecta a su red, le está diciendo algo. Está en el sitio. 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, asociarlo con sus cuentas existentes y activar la respuesta comercial adecuada —ya sea una alerta para un ejecutivo de cuenta, 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 de GDPR y los errores comunes. Comencemos. --- [TECHNICAL DEEP-DIVE — 5 minutes] Comencemos con la arquitectura. En su núcleo, una integración de Salesforce con WiFi tiene tres componentes: la capa de Captive Portal, el middleware de integración y el modelo de datos de Salesforce. El Captive Portal —lo que su invitado ve cuando se conecta— es donde ocurre la captura de identidad. Cuando un visitante se autentica a través de correo electrónico, LinkedIn o un inicio de sesión social, la plataforma captura una dirección de correo electrónico verificada, una marca de tiempo, un identificador de recinto y el registro de consentimiento. Este último no es negociable bajo el GDPR y la Ley de Protección de Datos del Reino Unido de 2018. Necesita un consentimiento explícito y detallado para comunicaciones de marketing, y ese registro de consentimiento debe ser almacenable y auditable. La plataforma de Purple maneja esto de forma nativa, capturando el consentimiento en el punto de autenticación y pasando una bandera de consentimiento a Salesforce junto con los datos de contacto. Ahora, 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 que coincida. Esta es su señal de coincidencia principal. Si se encuentra una coincidencia de dominio, el middleware verifica 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 visita 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 (el dominio es desconocido), se crea un registro de Prospecto (Lead) y se marca para revisión. Esta lógica de enrutamiento de tres vías es la base de un modelo de datos de Salesforce limpio para contactos obtenidos a través de WiFi. La alternativa (enviar todo como un Prospecto sin importar el contexto) crea la pesadilla de calidad de datos que la mayoría de los equipos de RevOps temen: miles de prospectos duplicados, sin asociación de cuentas y ejecutivos de cuenta que pierden señales sobre su cartera de clientes existente. Permítame hablar sobre el modelo de datos de Salesforce con más detalle, porque las decisiones de mapeo de campos que tome aquí tienen consecuencias a largo plazo. En el objeto Prospecto, se desea capturar: Nombre del punto de venta WiFi, Fecha de primera visita, Fecha de última visita, Contador de visitas, Estado de consentimiento y Origen del prospecto configurado en un valor estandarizado como "Guest WiFi". En el objeto Contacto, se aplican los mismos campos, además de una búsqueda de la Cuenta principal. En el objeto Cuenta, se desea un campo de resumen de acumulación que muestre el total de contactos autenticados por WiFi, un campo de Fecha del último visitante y una puntuación de Frecuencia de visitas. 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. Usando Salesforce Flow (o Process Builder si se encuentra en una organización más antigua), se configuran desencadenadores basados en condiciones específicas. La alerta más valiosa es la que llamamos desencadenador de "Visita de cuenta objetivo": cuando un Contacto asociado con una Cuenta etiquetada como cuenta objetivo se autentica en su WiFi, el Ejecutivo de cuenta asignado recibe una Tarea de Salesforce y una notificación de Chatter en cuestión de minutos. El mensaje es simple: "James de Acme Corp se acaba de conectar en su punto de venta de Manchester. Ha visitado tres veces este trimestre". Esa es una señal de acercamiento cálido por la que la mayoría de los equipos de ventas pagarían una cantidad significativa de dinero. Y usted la está generando de forma pasiva, a partir de la infraestructura que ya tiene. Una segunda alerta que vale la pena configurar es el desencadenador de "Re-engagement": 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 están físicamente de vuelta en su órbita, una señal fuerte para conversaciones de renovación. Tercero, 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 envía a una cola de BDR o RevOps para su calificación. No todos los dominios desconocidos son prospectos, pero filtrar por dominios de la empresa (excluyendo Gmail, Outlook y otros proveedores de consumo) le brinda una señal de prospección de alta calidad. En el aspecto 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 Salesforce Connected App, un flujo de MuleSoft o una función simple de AWS Lambda) recibe la carga de datos, realiza la lógica de coincidencia de dominios y llama a la API REST de Salesforce para actualizar (upsert) el registro correspondiente. Esto mantiene la lógica fuera de Salesforce, lo que facilita su mantenimiento y prueba 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 modernos con iOS y Android 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 de 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 CRM. --- [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — 2 minutos] Permítame compartirle las cuatro cosas que diferencian una implementación limpia de una desordenada. Primero: defina su lista de bloqueo de dominios antes de salir a producción. 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 prospectos (Leads). Si no hace esto, inundará su organización de Salesforce con contactos de consumo que no tienen valor comercial y degradarán la calidad de los datos para su equipo de ventas. Cree una lista de bloqueo actualizada y aplíquela en su lógica de middleware. Segundo: acuerde su umbral de conversión de Lead a Contacto con su líder de RevOps antes de la implementación. 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 ejecutivos de cuenta (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 clara de aceptación (opt-in) para marketing, independiente de los términos de servicio para el acceso a 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 indicadores booleanos en la carga de datos de la API. Mapee estos directamente a los campos de Contacto de Salesforce y respételos 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 creen un registro de Salesforce deben registrarse en un objeto personalizado de Salesforce o en una herramienta de monitoreo externa. Sin esto, tendrá fallas silenciosas (visitantes que se conectan pero no se crean registros) y no lo sabrá hasta que alguien note que los datos parecen incompletos. --- [PREGUNTAS Y RESPUESTAS RÁPIDAS — 1 minuto] Bien, hagamos una sesión rápida de preguntas y respuestas sobre las dudas que escucho con más frecuencia. "¿Debo sincronizar con Prospectos (Leads) o Contactos?" — Comience con Contactos para cuentas conocidas, Prospectos para desconocidas. Nunca envíe todo a Prospectos. "¿Qué pasa con el GDPR?" — Consentimiento en el portal, indicador de consentimiento en Salesforce, respételo en cada sistema descendente. No es negociable. "¿Cómo manejo recintos de conferencias donde miles de personas se conectan en un día?" — Limite la tasa de procesamiento de sus webhooks, procese por lotes sus actualizaciones/inserciones (upserts) en Salesforce y use la Bulk API de Salesforce para eventos de alto volumen. No use la REST API estándar para implementaciones a escala de estadios. "¿Puedo usar esto para ABM?" — Absolutamente. Etiquete sus cuentas objetivo en Salesforce, configure un Flow para alertar a sus ejecutivos de cuenta (AEs) sobre cualquier visita de WiFi desde 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 reportan un aumento del 20 al 35 por ciento en el alcance iniciado por los AEs en cuentas existentes, impulsado completamente por las alertas de visitas de WiFi. El pipeline influenciado por contactos obtenidos a través de WiFi generalmente muestra una tasa de cierre de un 15 a un 25 por ciento más alta en comparación con el alcance en frío, porque el visitante ha demostrado un compromiso físico. --- [RESUMEN Y PRÓXIMOS PASOS — 1 minuto] Para resumir: la integración de WiFi con Salesforce es una capacidad madura y lista para implementarse que convierte la infraestructura de red pasiva en una señal activa de inteligencia de cuentas. La arquitectura es sencilla (Captive Portal, middleware de resolución de identidad, upsert de Salesforce), pero el valor radica en las decisiones del modelo de datos, la configuración de alertas y la gobernanza de calidad de datos que establezca a su alrededor. Sus próximos pasos inmediatos: audite sus registros actuales de Cuentas de Salesforce para verificar que el campo de dominio esté completo; esa es su base de coincidencia. Involucre a su líder de RevOps para definir las reglas de enrutamiento de Prospectos frente a Contactos. Y revise la documentación de integración de Salesforce de Purple para comprender la estructura de la carga útil de la API y los eventos de webhook disponibles. Si ofrece WiFi para invitados en un recinto que visitan sus clientes o prospectos, esta integración debería estar activa en un trimestre. Los datos están ahí. Solo necesita 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 la próxima sesión informativa. --- [FIN DEL GUION]