Webhooks de agentes de voz: como enviar dados após a chamada

Prepare um destino com uma função clara

Quando a conversa termina, o webhook envia uma notificação automática ao endereço de conexão de outro sistema. Defina primeiro o trabalho que esse sistema fará: registrar um pedido, criar uma tarefa ou atualizar um relatório. Escolha os dados disponíveis na configuração atual do Tigy e mantenha a distinção entre pedido recebido e ação concluída.

Não envie toda a conversa por padrão se o processo só precisa de um identificador e um resultado. Combine os campos necessários com quem mantém o sistema de destino.

Escolha os dados enviados após a chamada

No Tigy, abra as opções de webhook do agente. Informe o endereço fornecido pela equipe de integração e escolha, entre as variáveis disponíveis, os dados que devem ser enviados. Payload é o nome técnico desse conjunto de dados: por exemplo, a referência da conversa e o motivo do contato.

Combine com o responsável pelo destino o formato e o método de envio pedidos pela configuração. Não copie campos de um exemplo sem conferir se estão disponíveis no painel. Faça uma chamada de teste e confirme os dados que chegaram ao sistema.

Diferencie receber de processar

O sistema de destino pode receber a notificação e ainda falhar ao salvar o registro. Peça ao responsável pela integração que confira o processamento, os dados obrigatórios e a associação à conversa correta. Você pode verificar se a tarefa realmente apareceu na fila que a equipe utiliza.

Projete o receptor para reconhecer o mesmo evento quando ele aparecer novamente. Essa é uma decisão da sua integração; não presuma uma garantia de entrega ou uma política de repetição sem verificá-la.

Acompanhe uma conversa até o destino

Execute uma chamada de teste, compare os campos selecionados com o payload recebido e confirme a criação do registro esperado. Examine os logs do receptor quando houver rejeição ou ausência da requisição.

Documente quem acompanha falhas e como a equipe recupera um atendimento não registrado. Um webhook transporta dados; a próxima ação depende do processo que você construiu no destino.

Confira o recebimento sem criar tarefas duplicadas

Considere um pedido fictício de retorno. Ao encerrar a chamada, a notificação leva a referência da conversa e o motivo do contato. Confira se o destino recebeu esses dados e criou a tarefa que a equipe realmente utilizará.

Peça à equipe de integração que envie a mesma notificação duas vezes no teste. O resultado deve continuar sendo uma tarefa para aquele pedido, sem duplicação. Depois teste um novo pedido legítimo do mesmo cliente para verificar se ele não foi descartado.

Projete o receptor para repetição e ordem variável

Um evento pode precisar ser entregue novamente ou chegar depois de outro evento relacionado. O receptor externo deve identificar o trabalho já realizado e decidir se atualiza, ignora ou investiga. Criar um ticket novo a cada recebimento transforma recuperação de entrega em duplicidade operacional.

Defina uma chave consistente com o contrato e guarde o resultado da operação. Em um exemplo fictício, a execução associada a uma solicitação já criou um ticket; um segundo recebimento consulta esse resultado em vez de criar outro. Essa proteção é implementada pela integração, não pelo texto do agente.

Teste o mesmo payload duas vezes, dados incompletos e indisponibilidade do sistema de destino. Confira o comportamento do receptor e a fila de erros. Não afirme que haverá uma política específica de repetição do Tigy sem verificar seu contrato atual; seu receptor deve tratar repetição de forma segura independentemente dessa expectativa.

Transforme dados em uma pendência que alguém consegue atender

Escolha campos que orientam o próximo trabalho: motivo, contato autorizado, ação tentada, resultado e pendência. Um resumo precisa distinguir fala do cliente e confirmação do sistema. “Cliente pediu remarcação” não deve virar “remarcação concluída” porque a conversa terminou.

Defina destinatário e responsabilidade antes de ativar a entrega. Uma notificação em um canal sem responsável pode aumentar visibilidade sem produzir atendimento. Registre quem revisa falhas de envio e como localizar solicitações que não chegaram ao destino.

No piloto, acompanhe a conversa, a chegada da notificação, a criação do registro e o trabalho da equipe. A equipe de integração precisa preparar um endereço acessível, combinar o formato dos dados e testar esse percurso completo. Combine como proteger o acesso antes de usar dados reais.

Defina o resultado que será enviado

O webhook pós-chamada conecta o resultado da conversa a um sistema que continua o atendimento. Antes de selecionar campos, defina o uso: criar uma tarefa, registrar interesse, atualizar um relatório ou avisar uma equipe. Cada finalidade exige dados diferentes. Enviar tudo disponível sem um consumidor definido aumenta exposição e dificulta interpretar o evento.

Nas configurações do agente, informe o endereço de conexão fornecido pela equipe de integração, o método de envio solicitado e os dados disponíveis que deseja enviar. A notificação ocorre quando a chamada termina. Confira as opções atuais do painel em vez de copiar campos de um exemplo antigo. Combine o formato com quem mantém o sistema de destino.

Separe fatos coletados de conclusões do atendimento. Um cliente expressar interesse não significa que uma venda foi confirmada. Uma solicitação registrada não significa que foi resolvida. Escolha nomes de campo que preservem essas diferenças e escreva o significado para quem recebe. Um status chamado “sucesso” sem definição pode produzir automações comerciais incorretas.

Considere uma empresa fictícia que quer registrar pedidos de retorno. O payload mínimo pode representar a referência da conversa, os dados aprovados para contato e o interesse relatado. O destino precisa saber se o cliente concordou com o próximo passo. Uma transcrição completa talvez não seja necessária para criar a tarefa; selecione o que o processo realmente usa.

Defina também o que fazer com campos ausentes. Uma pessoa pode encerrar antes de informar email ou recusar contato. O receptor não deve preencher essa lacuna com um valor inventado nem interpretar ausência como autorização. O contrato deve permitir uma solicitação incompleta ou escolher não criar a tarefa, conforme a regra da operação.

Faça o receptor reconhecer uma entrega repetida

O sistema receptor precisa tratar uma notificação repetida sem repetir efeitos desnecessários. A documentação do Tigy recomenda processamento idempotente. Isso significa que receber o mesmo evento duas vezes não deve criar dois contatos ou duas tarefas quando ambos representam o mesmo resultado de chamada. Não dependa de uma expectativa de entrega única para proteger a operação.

Escolha uma chave de associação adequada ao contrato disponível. Uma referência estável de conversa pode ajudar a distinguir repetição de um novo contato. Se o mesmo cliente liga outra vez, isso pode ser um evento novo, com outra intenção. Usar apenas telefone ou email como chave pode apagar uma solicitação legítima ou misturar resultados de chamadas distintas.

O receptor deve validar formato, método e autenticação antes de processar. Campos vindos do evento não substituem regras de autorização no sistema de destino. Uma identificação de empresa ou cliente precisa ser associada ao contexto autorizado do serviço, evitando que um valor recebido escolha livremente o acesso a outro conjunto de dados.

Planeje a diferença entre aceitação e conclusão no receptor. Ele pode confirmar recebimento e processar depois, mas precisa manter uma maneira de investigar a pendência. Um código de sucesso não prova que a tarefa comercial final ocorreu, se o próprio contrato separa essas etapas. O relatório deve mostrar recebimento, processamento e resultado conforme o desenho da integração.

Peça à equipe de integração que teste notificações repetidas e envios ao mesmo tempo em um ambiente de teste. Confira quantos registros foram criados. Depois envie um pedido novo do mesmo cliente e verifique se ele não foi descartado. O objetivo é distinguir repetição de um mesmo pedido de um contato novo legítimo, e não apenas verificar se a conexão respondeu.

Selecione dados para a finalidade e o acesso

Escolher poucos campos úteis melhora manutenção e revisão. Se a equipe precisa apenas de motivo do contato e informação de retorno, não envie toda a gravação por padrão. O responsável deve aprovar o que vai ao sistema de destino e quem pode consultar. Um webhook pode distribuir dados para um local com permissões diferentes da plataforma de origem.

Revise informações livres, como resumos e transcrições. Elas podem conter detalhes não previstos no esquema de campos. Não assuma que um payload pequeno é pouco sensível porque tem apenas uma propriedade de texto. O conteúdo dessa propriedade importa. Mantenha regras de acesso e retenção coerentes com o uso definido pela empresa.

Não inclua credenciais no corpo como dados de negócio nem as copie para exemplos públicos. Defina a proteção do receptor com a equipe responsável e restrinja registros de depuração ao necessário. Logs ajudam a investigar falhas, mas também podem replicar conteúdo. A equipe precisa saber onde procurar a evidência sem expor segredos ou reproduzir registros completos em canais inadequados.

Se o receptor dispara comunicação, confirme que o evento contém uma intenção e condição suficientes para isso. Interesse geral não autoriza automaticamente uma sequência de mensagens. O processo deve respeitar o próximo passo combinado na conversa. Teste uma pessoa que recusa retorno para conferir que o sistema não cria a mesma ação usada no caso de concordância.

Investigue a cadeia inteira de entrega

Quando a tarefa não aparecer, confira em ordem: a chamada terminou, a notificação foi enviada, o destino recebeu os dados e o registro foi criado? Uma resposta correta do agente não prova envio, e uma conexão funcionando não prova criação da tarefa. Peça ajuda ao responsável pela etapa que falhou antes de alterar os dados enviados ou as instruções.

Mantenha uma chamada de ensaio com resultado conhecido e verifique os campos recebidos. Confira uma correção feita pelo cliente e uma informação ausente. Depois teste rejeição de autenticação e formato incompatível no receptor, sem usar dados reais. A evidência deve mostrar como a equipe identifica a falha e retoma a solicitação pelo processo aprovado.

Depois de alterar campos ou destino, repita o teste completo. Uma mudança que parece apenas editorial pode alterar a interpretação de status no receptor. A integração está pronta quando entrega informação fiel e produz o próximo passo correto, com repetição e pendências tratadas.