Como configurar callbacks de entrega de SMS no Zapier

Um callback de entrega só é útil se atualizar o registo certo. Num fluxo de trabalho do Zapier, isso pode significar atualizar um contacto no CRM quando o fornecedor informa que uma mensagem foi entregue — ou deixar o contacto inalterado quando o evento pertence a outra campanha. O essencial é associar o evento do fornecedor ao registo de destino sem tratar todas as atualizações recebidas como se fossem iguais.

Este guia explica como configurar callbacks de SMS no Zapier, desde a escolha de um registo até à verificação do Zap concluído.

1. Escolha o registo que o Zap deve atualizar

Comece por escolher um destino. Pode ser um contacto no CRM, uma encomenda ou um registo de campanha, consoante o local onde a equipa consulta os resultados dos SMS. Decida que tipo de atualização será útil nesse registo: um campo de status de entrega, uma data e hora ou uma nota que inclua o identificador da mensagem.

Em seguida, identifique um valor estável que associe o callback ao registo. O ID da mensagem atribuído pelo fornecedor costuma ser uma boa opção, se o seu sistema o tiver guardado quando o SMS foi enviado; o número de telefone do destinatário pode servir, mas apenas se a aplicação de destino conseguir identificar o registo sem ambiguidades. Se uma lista importada tiver números de telefone duplicados, usar apenas o número para fazer a correspondência pode atualizar o contacto errado.

Anote o campo de pesquisa da aplicação de destino antes de criar o Zap. Por exemplo, se o CRM pesquisar por um campo personalizado de ID da mensagem, confirme que o processo de envio guarda nesse campo o mesmo ID. O callback não consegue estabelecer essa ligação por si só se o registo do SMS original não tiver um valor correspondente.

2. Crie um gatilho de webhook no Zapier

Crie um Zap e escolha um gatilho de webhook, como Catch Hook. O Zapier deverá apresentar um URL gerado para esse gatilho; copie-o para uma nota de trabalho segura enquanto configura o fornecedor.

O URL gerado é o endereço para o qual o fornecedor de SMS enviará um evento de entrega. Trate-o como uma configuração privada: evite publicá-lo num documento partilhado ou enviá-lo numa mensagem comum.

Mantenha a primeira versão simples. Ligue o gatilho de webhook a um destino de teste ou a um registo claramente identificado como teste, em vez de o ligar ao registo de um cliente ativo. Assim, poderá inspecionar os dados recebidos pelo gatilho antes de uma alteração de status afetar um fluxo de trabalho em produção.

3. Envie um evento de entrega de exemplo ao gatilho

Use o callback de teste do fornecedor de SMS, se estiver disponível, ou envie um SMS de teste e aguarde pelo callback.

Quando o evento chegar, inspecione os campos capturados no Zapier. Procure o identificador da mensagem, o valor do destinatário, o status indicado pelo fornecedor e qualquer data e hora do evento. Os nomes dos campos podem estar abreviados ou ser específicos do fornecedor, por isso compare um valor capturado com a documentação do fornecedor antes de o associar a um campo do CRM.

Um exemplo é um começo, não um teste completo. Se o fornecedor puder enviar um evento de entrega e outro de falha, capture cada um separadamente e registe qual campo muda. Sem um exemplo de falha, o Zap pode tratar corretamente as entregas bem-sucedidas, mas ignorar uma mensagem que não pôde ser entregue.

Para fluxos de trabalho de email acionados por eventos, a diferença entre um evento recebido e o registo que este deve afetar é abordada também em eventos de webhook de emails transacionais. Os produtos são diferentes, mas inspecionar os dados efetivamente recebidos antes de associar os campos continua a ser uma boa prática.

4. Associe os status do fornecedor a etiquetas úteis

O fornecedor pode enviar um valor de status que não corresponde às etiquetas da aplicação de destino. Decida o que a equipa precisa de ver e, em seguida, use as ferramentas de formatação ou ramificação disponíveis no Zapier para converter os valores específicos do fornecedor nessas etiquetas.

Por exemplo, o CRM pode usar «Entregue» e «Falhou», enquanto o fornecedor utiliza outros termos. Associe apenas valores que tenha confirmado nos eventos capturados ou na documentação.

Defina a correspondência de forma explícita. Uma pequena lista de regras pode ajudar antes de configurar o Zap:

• Valor do fornecedor confirmado como entregue: defina a etiqueta de destino como «Entregue».
• Valor do fornecedor confirmado como falhado: defina a etiqueta de destino como «Falhou» ou use a etiqueta escolhida pela equipa.
• Valor desconhecido ou em falta: mantenha o status inalterado ou encaminhe o evento para revisão.

Este último caso é importante. Se surgir um novo status do fornecedor após uma alteração de configuração, uma regra genérica que classifique todos os valores desconhecidos como «Entregue» pode criar um resultado falso no CRM. Consulte as definições de status do fornecedor e ajuste o mapeamento quando um evento real apresentar um valor inesperado.

5. Associe cada callback ao registo de destino correto

Para perceber como associar webhooks de SMS a contactos, adicione a ação da aplicação de destino que procura ou atualiza um registo e associe o identificador da mensagem ou do destinatário, recebido no callback, ao campo de pesquisa da aplicação. Confirme que o fornecedor inclui um valor que a aplicação de destino consegue efetivamente pesquisar. Se o callback incluir um ID de mensagem, mas o CRM guardar apenas números de telefone, o Zap precisa de uma forma fiável de relacionar esses dois valores antes de poder atualizar o registo correto.

Teste a pesquisa com um registo que consiga identificar. Um contacto de teste com um nome claramente assinalado ajuda a perceber se o Zap encontrou o registo pretendido ou se não encontrou correspondências. Se a pesquisa puder devolver vários registos possíveis, pare e corrija a chave de correspondência em vez de deixar o fluxo de trabalho escolher sem uma regra clara.

Evite criar automaticamente um novo registo de cliente, a menos que isso faça parte intencional do processo; caso contrário, um valor de callback mal escrito ou desconhecido pode gerar registos desnecessários.

Os eventos de SMS podem incluir dados do destinatário, por isso associe apenas os campos de que a equipa precisa para agir. Para uma análise relacionada sobre o tratamento de dados noutro canal de mensagens, consulte o rastreamento de emails e a conformidade com a privacidade. Neste Zap, isso pode significar não incluir o número de telefone numa nota de texto livre, se uma etiqueta de status e o ID da mensagem forem suficientes.

6. Evite aplicar atualizações desatualizadas ou repetidas

Antes de ligar o Zap a um registo ativo, decida como deve tratar callbacks repetidos e status recebidos com atraso. Caso contrário, um evento antigo pode substituir um status mais recente ou o mesmo evento pode gerar notas duplicadas.

Se a aplicação de destino tiver um campo de data e hora, guarde a hora do evento juntamente com o status e use-a para determinar se uma atualização é mais recente. Um campo com a hora de receção pode ser útil para resolver problemas, mas talvez não indique qual dos eventos do fornecedor ocorreu primeiro.

Se o fluxo de trabalho não conseguir comparar IDs de eventos ou datas e horas de forma fiável, mantenha a ação simples: atualize um único campo de status em vez de acrescentar uma nova nota por cada callback e consulte o histórico de tarefas se surgirem alterações duplicadas.

7. Teste o Zap completo com dados reais de callbacks

Execute um teste desde o gatilho até à ação de destino. Confirme que o callback chega ao registo pretendido, que o status do fornecedor é convertido na etiqueta esperada e que os campos não relacionados permanecem inalterados. Um teste bem-sucedido do gatilho, por si só, não comprova que a etapa de pesquisa selecionou o contacto certo.

Teste pelo menos um evento que deva atualizar um registo e um caso que não deva fazê-lo, como um callback sem um identificador correspondente, se o fornecedor puder gerar um. Verifique o próprio destino após cada execução. O Zapier pode indicar que uma ação foi executada, mas verificar os valores visíveis no registo é a confirmação prática de que a equipa precisa.

Se uma execução não produzir o resultado esperado, consulte o histórico de tarefas do Zapier e compare os valores capturados pelo gatilho com os campos usados nas ações de pesquisa e atualização. Verifique se o ID da mensagem está em branco, se o mapeamento do status não contemplou um valor do fornecedor ou se a aplicação de destino encontrou outro registo. Faça uma alteração de cada vez e volte a testar todo o fluxo. Assim, poderá confirmar como atualizar o status de entrega de SMS no CRM sem afetar campos ou registos que não devem ser alterados.

Antes de trocar o registo de teste por um destino ativo, confirme em conjunto o Zap selecionado, o URL do gatilho, o campo de pesquisa e o mapeamento do status. Anote os valores de status do fornecedor que confirmou; se um teste posterior apresentar um valor novo, suspenda a regra de atualização até perceber o que esse valor significa.