Integração do Salesforce com Guest WiFi para Inteligência de Contas

GUIÃO DE PODCAST — "Integração do Salesforce com Guest WiFi para Inteligência de Contas" Série de Briefings Técnicos Purple | Duração: ~10 minutos | Inglês do Reino Unido --- [INTRODUÇÃO E CONTEXTO — 1 minuto] Bem-vindo à Série de Briefings Técnicos Purple. Sou o vosso anfitrião e hoje vamos abordar algo que muitas organizações B2B têm no seu roadmap, mas que ainda não conseguiram resolver por completo: ligar a vossa infraestrutura de guest WiFi diretamente ao Salesforce para gerar inteligência de contas real. Se têm um espaço físico — um centro de conferências, um hotel, um pavilhão de feiras comerciais, um campus corporativo — e disponibilizam guest WiFi, estão sentados numa mina de ouro de dados de intenção first-party. Sempre que um potencial cliente, parceiro ou cliente se liga à vossa rede, está a dizer-vos algo. Está no local. Está envolvido. E neste momento, para a maioria das organizações, esse sinal desaparece no éter. O que vamos cobrir hoje é como mudar isso. Como encaminhar esse evento de autenticação de WiFi para o Salesforce, fazer a correspondência com as vossas contas existentes e acionar a resposta comercial correta — quer seja um alerta para um Account Executive, o enriquecimento de um registo de contacto ou uma sinalização para a vossa equipa de RevOps agir. Este é um briefing prático. Vamos analisar a arquitetura, as decisões do modelo de dados, as considerações do GDPR e as armadilhas comuns. Vamos a isso. --- [ANÁLISE TÉCNICA DETALHADA — 5 minutos] Comecemos pela arquitetura. Na sua essência, uma integração de WiFi com o Salesforce tem três componentes: a camada de Captive Portal, o middleware de integração e o modelo de dados do Salesforce. O Captive Portal — o que o vosso convidado vê quando se liga — é onde ocorre a captura de identidade. Quando um visitante se autentica através de email, LinkedIn ou um login social, a plataforma captura um endereço de email verificado, um carimbo de data/hora, um identificador do local e o registo de consentimento. Este último é não negociável sob o GDPR e a Lei de Proteção de Dados do Reino Unido de 2018. Precisam de consentimento explícito e granular para comunicações de marketing, e esse registo de consentimento deve ser armazenado e auditável. A plataforma da Purple lida com isto nativamente, capturando o consentimento no momento da autenticação e passando uma sinalização de consentimento para o Salesforce juntamente com os dados de contacto. Agora, o middleware de integração é onde a inteligência acontece. O motor de integração da Purple recebe esse evento de autenticação e realiza o que chamamos de resolução de identidade. O primeiro passo é uma correspondência de domínio: pegar no endereço de email, extrair o domínio — por exemplo, acme-corp.com — e consultar o Salesforce para encontrar quaisquer registos de Conta com um campo de website ou domínio de email correspondente. Este é o vosso sinal de correspondência primário. Se for encontrada uma correspondência de domínio, o middleware verifica se já existe um registo de Contacto para esse endereço de email específico. Se existir, atualizam o registo existente — registam uma nova atividade, atualizam o carimbo de data/hora da última visualização, incrementam um contador de visitas. Se não existir nenhum Contacto mas a Conta existir, criam um novo Contacto e associam-no a essa Conta. Se nenhum dos dois existir — o domínio é desconhecido — criam um registo de Lead e sinalizam-no para revisão. Esta lógica de encaminhamento de três vias é a base de um modelo de dados limpo no Salesforce para contactos provenientes de WiFi. A alternativa — enviar tudo como Lead independentemente do contexto — cria o pesadelo de qualidade de dados que a maioria das equipas de RevOps teme: milhares de leads duplicados, nenhuma associação de conta e Account Executives a perder sinais sobre a sua carteira de clientes existente. Deixem-me falar sobre o modelo de dados do Salesforce em maior detalhe, porque as decisões de mapeamento de campos que tomam aqui têm consequências a longo prazo. No objeto Lead, querem capturar: Nome do Local de WiFi, Data da Primeira Visualização, Data da Última Visualização, Contagem de Visitas, Estado do Consentimento e Origem do Lead definida para um valor padronizado como "Guest WiFi". No objeto Contacto, aplicam-se os mesmos campos, além de uma pesquisa (lookup) para a Conta-mãe. No objeto Conta, querem um campo de resumo de roll-up que mostre o total de contactos autenticados por WiFi, um campo de Data do Último Visitante e uma pontuação de Frequência de Visitas. Estes campos ao nível da Conta são o que torna esta integração genuinamente útil para vendas baseadas em contas (account-based selling). Agora, o mecanismo de alerta. É aqui que o valor comercial se torna tangível. Utilizando o Salesforce Flow — ou o Process Builder se estiverem numa organização mais antiga — configuram acionadores com base em condições específicas. O alerta mais valioso é o que chamamos de acionador de "Visita de Conta-Alvo": quando um Contacto associado a uma Conta etiquetada como conta-alvo se autentica no vosso WiFi, o Account Executive atribuído recebe uma Tarefa do Salesforce e uma notificação do Chatter em poucos minutos. O mensagem é simples: "O James da Acme Corp acabou de se ligar no vosso local de Manchester. Já visitou três vezes este trimestre." Esse é um sinal de abordagem quente pelo qual a maioria das equipas de vendas pagaria muito dinheiro. E estão a gerá-lo passivamente, a partir de uma infraestrutura que já possuem. Um segundo alerta que vale a pena configurar é o acionador de "Reenvolvimento": um Contacto que esteve inativo por mais de noventa dias liga-se ao vosso WiFi. Isto faz surgir contactos perdidos ou frios que estão fisicamente de volta à vossa órbita — um forte sinal para conversas de renovação. Terceiro, o alerta de "Novo Domínio": um início de sessão de WiFi a partir de um domínio de email que não corresponde a nenhuma Conta existente. Isto é encaminhado para uma fila de BDR ou RevOps para qualificação. Nem todos os domínios desconhecidos são potenciais clientes, mas filtrar por domínios de empresas — excluindo Gmail, Outlook e outros fornecedores de consumo — dá-vos um sinal de prospeção de alta qualidade. Do lado da integração técnica, a Purple expõe uma API REST e suporta webhooks de saída. O padrão recomendado para a integração com o Salesforce é uma abordagem de webhook para middleware: a Purple aciona um webhook em cada evento de autenticação, uma camada leve de middleware — que pode ser uma Connected App do Salesforce, um fluxo do MuleSoft ou uma função simples de AWS Lambda — recebe o payload, executa a lógica de correspondência de domínio e chama a API REST do Salesforce para fazer o upsert do registo apropriado. Isto mantém a lógica fora do Salesforce, tornando-a mais fácil de manter e testar de forma independente. Para organizações com a MuleSoft Anypoint Platform do Salesforce, a documentação da API da Purple fornece um modelo de conector pré-construído. Para quem não tem MuleSoft, uma definição de Serviço Externo do Salesforce a apontar para a API da Purple, combinada com um Flow, alcança o mesmo resultado sem código personalizado. Mais uma consideração técnica: a randomização de endereços MAC. Os dispositivos iOS e Android modernos randomizam o seu endereço MAC em cada ligação de rede, o que significa que não podem usar o endereço MAC como um identificador de dispositivo persistente para rastreamento de visitantes recorrentes. O endereço de email, capturado na autenticação, é o vosso identificador persistente fiável. Esta é outra razão pela qual a autenticação no Captive Portal baseada em email é arquitetonicamente superior à autenticação por clique ou apenas por dispositivo para fins de integração com o CRM. --- [RECOMENDAÇÕES DE IMPLEMENTAÇÃO E ARMADILHAS — 2 minutos] Deixem-me dar-vos as quatro coisas que separam uma implementação limpa de uma confusa. Primeiro: definam a vossa lista de bloqueio de domínios antes de entrarem em produção. Os domínios de email de consumidores — Gmail, Yahoo, Hotmail, iCloud, Outlook — devem ser excluídos da correspondência de Contas e da criação de Leads. Se não o fizerem, vão inundar a vossa organização do Salesforce com contactos de consumidores que não têm valor comercial e degradam a qualidade dos dados para a vossa equipa de vendas. Construam uma lista de bloqueio mantida e apliquem-na na vossa lógica de middleware. Segundo: acordem o vosso limiar de conversão de Lead para Contacto com o vosso responsável de RevOps antes da implementação. Um erro comum é criar Leads a partir de eventos de WiFi e nunca os converter, fazendo com que fiquem numa fila de Leads indefinidamente. Definam uma regra: se um Lead de um domínio de empresa conhecido visitar mais de duas vezes em trinta dias, convertam automaticamente para Contacto e associem à Conta correspondente. Isto mantém o vosso pipeline limpo e os vossos AEs focados. Terceiro: não ignorem a arquitetura de consentimento. Sob o GDPR, precisam de uma base legal para o processamento e, para comunicações de marketing, essa base é o consentimento. O vosso Captive Portal deve apresentar um opt-in claro para marketing, separado dos termos de serviço para acesso ao WiFi. A plataforma da Purple suporta categorias de consentimento granulares — acesso ao WiFi, email de marketing, partilha com terceiros — e passa-as como sinalizações booleanas no payload da API. Mapeiem-nas diretamente para os campos de Contacto do Salesforce e respeitem-nas nas vossas regras de automação de marketing. Quarto: equipem a vossa integração com registo de erros desde o primeiro dia. Os eventos de autenticação que falhem ao corresponder ou ao criar um registo no Salesforce devem ser registados num objeto personalizado do Salesforce ou numa ferramenta de monitorização externa. Sem isto, terão falhas silenciosas — visitantes a ligarem-se mas sem registos a serem criados — e não saberão até que alguém note que os dados parecem escassos. --- [PERGUNTAS E RESPOSTAS RÁPIDAS — 1 minuto] Muito bem, vamos fazer uma sessão rápida de perguntas e respostas sobre as questões que oiço com mais frequência. "Devo sincronizar para Leads ou Contactos?" — Comecem com Contactos para contas conhecidas, Leads para desconhecidas. Nunca enviem tudo para Leads. "E quanto ao GDPR?" — Consentimento no portal, sinalização de consentimento no Salesforce, respeitem-no em todos os sistemas a jusante. Não negociável. "Como lido com locais de conferências onde milhares de pessoas se ligam num dia?" — Limitem a taxa de processamento dos vossos webhooks, agrupem os vossos upserts do Salesforce em lotes e utilizem a API Bulk do Salesforce para eventos de grande volume. Não utilizem a API REST padrão para implementações à escala de estádios. "Can I use this for ABM?" — Absolutamente. Etiquetem as vossas contas-alvo no Salesforce, configurem um Flow para alertar os vossos AEs sobre qualquer visita de WiFi dessas contas, e terão um sinal de intenção física que nenhuma ferramenta digital de ABM consegue replicar. "Qual é o ROI?" — As organizações que utilizam a integração de Salesforce da Purple relatam um aumento de 20 a 35 por cento nas abordagens iniciadas por AEs em contas existentes, impulsionado inteiramente por alertas de visitas de WiFi. O pipeline influenciado por contactos provenientes de WiFi mostra tipicamente uma taxa de fecho 15 a 25 por cento superior em comparação com abordagens frias, porque o visitante demonstrou envolvimento físico. --- [RESUMO E PRÓXIMOS PASSOS — 1 minuto] Para concluir: a integração de WiFi com o Salesforce é uma capacidade madura e implementável que transforma a infraestrutura de rede passiva num sinal ativo de inteligência de contas. A arquitetura é simples — Captive Portal, middleware de resolução de identidade, upsert no Salesforce — mas o valor está nas decisões do modelo de dados, na configuração de alertas e na governação de qualidade de dados que definem em torno dela. Os vossos próximos passos imediatos: auditem os vossos registos de Conta atuais do Salesforce para verificar a integridade do campo de domínio — essa é a vossa base de correspondência. Envolvam o vosso responsável de RevOps para definir as regras de encaminhamento de Lead versus Contacto. E revejam a documentação de integração de Salesforce da Purple para compreender a estrutura do payload da API e os eventos de webhook disponíveis. Se disponibilizam guest WiFi num local que os vossos clientes ou potenciais clientes visitam, esta integração deve estar ativa no prazo de um trimestre. Os dados estão lá. Só precisam de os ligar. Obrigado por ouvirem. Se quiserem aprofundar qualquer um dos tópicos abordados hoje, o guia de referência técnica completo está disponível em purple.ai. Vemo-nos no próximo briefing. --- [FIM DO GUIÃO]