Como notificar a equipe após chamadas de agentes de voz

Escolha dados úteis

Escolha informações úteis, como motivo do contato, referência da conversa e estado do pedido, quando disponíveis na configuração. Evite enviar a conversa inteira se a tarefa precisa apenas de três dados. Peça ao responsável pela conexão que confira o conteúdo realmente recebido, pois os nomes e dados disponíveis dependem da configuração.

Autentique o receptor

Peça ao responsável pela integração que configure e teste a verificação de acesso do sistema que recebe o aviso. Um endereço difícil de adivinhar não basta para protegê-lo. O sistema deve recusar envios não autorizados antes de guardar dados ou avisar a equipe.

Registre antes de distribuir

Combine como identificar cada aviso e acompanhar seu processamento. Peça ao responsável pelo sistema que confira se receber o mesmo aviso duas vezes cria apenas a tarefa correta, sem duplicações. A equipe deve conseguir localizar esse trabalho e saber se ele foi recebido, encaminhado ou ficou pendente.

Conecte o canal escolhido

Escolha onde a equipe deve receber o aviso e peça ao responsável pela integração que conecte esse canal com as permissões necessárias. Esse envio adicional precisa de configuração própria; não é um conector nativo presumido. Teste separadamente o recebimento dos dados, a entrega da mensagem e a continuidade do atendimento.

Teste a continuidade

Teste credencial inválida, campo ausente, evento repetido e destino indisponível. Confira registros e o trabalho que chega à equipe. Se o canal final falhar, preserve o estado para tratamento pelo receptor sem anunciar uma garantia de reenvio do Tigy.

Quando usar webhook em vez de ferramenta durante a chamada?

Use uma ferramenta durante a conversa quando o agente precisa consultar um dado ou executar uma ação antes de responder. Use o webhook pós-chamada para enviar os dados selecionados ao receptor ao final. O envio posterior não deve ser usado como prova de uma reserva ou consulta que a pessoa precisava confirmar durante o atendimento.

Em um exemplo fictício de retorno comercial, o receptor recebe contato autorizado, motivo e referência da execução e cria uma tarefa. A notificação no canal escolhido exige a API e as permissões desse canal; não é um conector nativo presumido. Valide autenticação, repetição de evento e quem assume o trabalho.

Defina o que a equipe deve fazer ao receber o aviso

Uma notificação útil representa uma ação que alguém consegue executar. Enviar toda conversa para uma caixa compartilhada pode aumentar o volume sem melhorar a continuidade. Antes de configurar o aviso, defina quais resultados merecem acompanhamento, quem recebe cada categoria e o que essa pessoa precisa fazer. Um pedido de retorno, uma dúvida sem resposta e uma solicitação já concluída não exigem necessariamente o mesmo destino.

Em uma empresa fictícia, o agente registra interesse comercial e envia dados ao sistema da equipe. O aviso deve permitir localizar o contato, entender o pedido e iniciar o próximo passo. Se o cliente pediu apenas o horário de funcionamento e recebeu a resposta, talvez não exista trabalho posterior. A decisão sobre quais avisos enviar deve ser tomada pela operação, sem presumir que mais notificações significam melhor atendimento.

Defina o critério pelo resultado, e não por palavras soltas. A pessoa pode mencionar “ligar depois” como hipótese ou corrigir que prefere outro canal. O aviso deve usar a intenção confirmada. Se a solicitação já foi registrada anteriormente, um contato repetido pode exigir atualização do mesmo caso em vez de criação de uma nova tarefa. Essa interpretação depende de regras claras no receptor e de dados suficientes para relacionar eventos.

Escreva um pequeno contrato operacional: categoria do aviso, responsável, informações mínimas e estado esperado depois do recebimento. Não precisa começar com um processo amplo. Uma categoria limitada, como pedidos confirmados de retorno comercial, permite verificar a utilidade do aviso antes de ampliar. A notificação só melhora a experiência quando chega a um destino real e transforma o resultado da conversa em trabalho compreensível para a equipe.

Envie contexto suficiente, sem copiar tudo por padrão

O conteúdo do aviso deve responder a perguntas práticas: quem pediu, o que pediu, o que foi confirmado e qual resultado ocorreu. Um identificador da conversa ajuda a localizar o registro quando for necessário revisar mais detalhes. Não é preciso enviar a transcrição inteira a todos os destinatários por padrão. O conjunto de campos deve ser proporcional à ação que a equipe vai executar e ao acesso que ela tem.

Em um pedido fictício de retorno, nome confirmado, contato, assunto e preferência podem ser suficientes. A preferência deve continuar identificada como preferência, sem virar compromisso de horário. Se a ferramenta registrou um protocolo, inclua-o quando disponível. Se a consulta falhou, preserve esse estado para que a pessoa que recebe o aviso não presuma uma confirmação inexistente.

Separe fatos relatados de fatos verificados. “O cliente informa que pagou” e “o sistema confirmou pagamento” exigem evidências diferentes. O aviso deve manter essa distinção, porque a equipe pode tomar uma decisão com base no resumo. Uma síntese que transforma relato em conclusão pode causar erro mesmo quando a conversa foi cuidadosa. Revise o texto do aviso como parte do atendimento, não apenas como detalhe técnico da integração.

Nas configurações do agente, selecione as informações disponíveis que a equipe precisa receber. Peça ao responsável pela conexão que teste o envio e o que acontece quando um dado falta. Não presuma que qualquer informação desejada está disponível ou que um campo vazio tem um significado específico. A mensagem deve mostrar claramente o que foi informado e o que ainda precisa ser perguntado.

Diferencie envio, recebimento e atendimento realizado

Terminar uma chamada, receber o aviso e atender o pedido são etapas diferentes. O sistema pode receber os dados sem criar a tarefa, ou criar a tarefa sem indicar quem cuida dela. Confira o caminho completo: a mensagem chegou, o pedido pode ser encontrado e alguém assumiu o trabalho? Só uma confirmação de recebimento não comprova essa continuidade.

Em um exemplo fictício, o receptor aceita os dados e devolve sucesso, mas o contato de retorno está ausente. A mensagem não permite executar a ação. O receptor deve validar campos essenciais e encaminhar falhas para revisão pelo processo definido. Se há uma fila de processamento, registre o estado necessário para investigar a diferença entre recebimento e criação de tarefa. Não transforme aceitação técnica em confirmação de atendimento humano.

Teste com uma chamada concluída e acompanhe o percurso até o registro externo. Confira formato, autenticação, campos, categoria e destino. Depois confirme que uma pessoa com a permissão adequada encontra a tarefa. Um aviso enviado para uma área inacessível ao responsável não oferece continuidade real. A documentação do Tigy orienta verificar logs do sistema receptor para investigar falhas de entrega; a operação externa precisa fornecer a evidência do processamento posterior.

Defina a mensagem ao cliente de acordo com o que o agente consegue confirmar. “Sua solicitação foi registrada” exige um registro confirmado no contexto relevante. “A equipe já está atendendo” exige outra evidência. Se o aviso ocorre ao fim da chamada, não prometa durante a conversa um resultado posterior que ainda não foi verificado. A formulação deve ser precisa sobre o pedido e sobre o processo aprovado, evitando um compromisso que a entrega técnica não sustenta.

Prepare o receptor para repetição e dados incompletos

O sistema que recebe avisos deve reconhecer repetições e evitar tarefas duplicadas. Esse comportamento é chamado de processamento idempotente: o mesmo aviso, recebido mais de uma vez, não deve criar o mesmo trabalho várias vezes. Peça ao responsável pela integração que implemente e teste essa proteção. Uma instrução ao agente não controla a repetição dos envios depois da chamada.

Considere uma chamada fictícia com pedido de retorno. Se a mesma notificação chega duas vezes, a equipe não deveria ganhar dois compromissos independentes para o mesmo resultado. Mas duas chamadas diferentes da mesma pessoa podem representar pedidos distintos. A regra de deduplicação precisa considerar o evento e o objetivo, sem descartar automaticamente qualquer aviso com o mesmo telefone. Confundir esses casos pode esconder uma demanda nova.

Defina o tratamento de contato ausente, categoria desconhecida e estado incompatível. Alguns avisos podem ser aceitos para revisão manual, enquanto outros não permitem continuar. O receptor deve registrar o motivo e oferecer um caminho de correção. Evite transformar um campo vazio em valor presumido, como atribuir um responsável padrão sem verificar se ele atende aquela categoria.

Teste repetição exata, chamada nova, campo ausente e indisponibilidade do serviço que cria tarefas. Confira o resultado externo e a capacidade de investigar. O objetivo é manter um registro confiável do que foi recebido e do que foi feito, sem circulação desnecessária de dados. A política concreta de retenção e acesso pertence à organização. A integração deve permitir que a equipe corrija uma falha sem repetir efeitos já executados nem perder a relação com a conversa original.

Revise a fila para descobrir falhas de continuidade

Depois do piloto, acompanhe avisos recebidos, tarefas criadas e tarefas que a equipe conseguiu usar. Essas medidas respondem a perguntas diferentes. Uma taxa alta de entrega não prova que os campos estão completos; uma fila grande não prova que o agente identifica pedidos corretamente. Inspecione exemplos de cada categoria e converse com os responsáveis pelo acompanhamento antes de ampliar o volume.

Compare pedidos sem responsável, contato inválido, categoria corrigida, duplicação e retorno que exigiu repetir a coleta. Registre também situações em que o cliente procurou novamente a empresa porque não sabia o próximo passo. Essa análise pode mostrar uma mensagem final ambígua, uma regra de envio inadequada ou um problema de processamento externo. Não atribua toda falha de continuidade ao texto do prompt.

Monte testes permanentes de pedido normal, campo corrigido, ausência de informação, repetição e receptor indisponível. Depois de alterar variáveis ou regras externas, repita esses cenários e confira o resultado final. Se a equipe muda sua forma de receber solicitações, atualize o contrato operacional. Uma notificação antiga pode continuar chegando sem ser útil no processo novo.

Comece por um grupo limitado de pedidos e expanda quando a equipe confirmar que o registro chega ao lugar certo e permite agir. Preserve um responsável por revisar exceções. O aviso pós-chamada é uma ponte entre conversa e operação; sua qualidade depende tanto do conteúdo quanto do destino e do processamento. O resultado esperado é continuidade verificável: pedido compreendido, registro acessível e próximo passo real. Esse objetivo é mais concreto que enviar uma mensagem para cada ligação e presumir que alguém resolverá o restante.