Como conectar um número telefônico ao agente de voz no Tigy

Prepare o agente e a conexão

Conectar um número ao agente de voz exige três verificações: agente publicado, configuração do provedor e associação do número ao agente correto. A documentação de chamadas recebidas do Tigy AI descreve Twilio, Telnyx e conexões VoIP via SIP (Session Initiation Protocol, protocolo de sinalização para sessões de comunicação), com procedimentos específicos. Siga o caminho do provedor escolhido e confirme a conexão com uma chamada real.

No exemplo com Twilio, tenha um número da conta e as credenciais necessárias. Mantenha o token na configuração de telefonia e confira se a conta tem acesso ao número informado.

Associe o número ao agente correto

Adicione a configuração do provedor no Tigy e cadastre o número com seu código de país. Selecione o agente no campo de fluxo de entrada e salve. O destino é determinado pelo número configurado.

Confira o workspace e o agente selecionado. Um teste bem-sucedido no editor não comprova que aquele número está associado à mesma configuração.

Siga a chamada pelos dois sistemas

Ligue para o número configurado e observe se o agente atende e responde. Consulte os registros do provedor e do Tigy para localizar uma falha antes ou depois da conexão.

Na integração com Twilio, peça ao responsável pela telefonia que confira também a notificação automática que encaminha a chamada ao Tigy, chamada webhook de voz. A conexão precisa permitir que o provedor envie esses eventos. Anote qualquer aviso de sincronização para investigar com essa pessoa.

Valide o atendimento no canal real

Depois de confirmar o recebimento, teste áudio, números, consulta externa e encaminhamento previsto. Uma transferência exige configuração compatível; não presuma que todo recurso do navegador se comporta da mesma forma no telefone.

Registre qual número, agente e versão foram usados. Alterações posteriores devem incluir uma nova chamada de verificação, além dos testes do prompt.

Faça uma chamada com evidência rastreável

Prepare pergunta conhecida, consulta com dados fictícios e exceção. Ligue, anote horário e encontre a execução. Confira que a apresentação e a fonte correspondem à configuração publicada.

Se não há execução, investigue rota e provedor. Se há, mas o áudio falha, examine condições do canal. Se a ferramenta falha, investigue seu contrato separadamente. A sequência reduz mudanças desnecessárias no prompt.

Quando houver transferência, teste destino sem resposta e formato correto. A conexão não entrega automaticamente contexto ao atendente no Tigy. Um registro de apoio exige integração e verificação próprias.

Altere a rota com um caminho de recuperação

Defina quem pode modificar a telefonia e como voltar ao atendimento anterior. Verifique a ação com o responsável, sem depender de uma lembrança informal durante a falha.

Abra o piloto num recorte limitado e acompanhe chamadas que não chegam ou não completam. Compare horários e origem para encontrar padrões. Uma ligação bem-sucedida não comprova capacidade em todos os cenários.

Depois de trocar agente ou número, faça nova chamada identificável. A configuração deve ser comprovada pelas próximas conversas, preservando a operação enquanto a equipe aprende.

Confira agente publicado, configuração e número separadamente

A conexão telefônica depende de partes distintas. O agente precisa de uma versão adequada para execução. A configuração de telefonia precisa das credenciais e das condições do provedor utilizado. O número precisa estar associado ao agente que deve atender. Publicar o agente não cria automaticamente essa associação. Uma chamada que não chega ao atendimento pode falhar em qualquer dessas partes, e a investigação deve identificar qual etapa não foi concluída.

Em uma empresa fictícia, a equipe publica um agente de recepção e testa por voz no navegador. Depois liga para o número da empresa e ouve o atendimento anterior. O teste no navegador mostrou comportamento do agente, mas não mostrou o encaminhamento telefônico. Confira a configuração do número e o destino associado. Reescrever o prompt não corrige uma chamada que continua indo para outro atendimento.

Comece por um número e um objetivo limitado. Isso permite verificar a configuração sem misturar vários agentes, unidades e destinos. Registre workspace, configuração de telefonia, número e agente esperado. Use a interface e a documentação correspondente ao provedor disponível. Não presuma que campos de uma integração são idênticos aos de outra ou que uma credencial de outra conta permite operar o número escolhido.

Confira também a autorização de uso no workspace antes do teste. A conta estar conectada não garante que uma nova execução pode começar. Se há bloqueio de uso ou cobrança, revise o estado mostrado antes de alterar o atendimento. O resultado da primeira verificação deve ser concreto: a chamada ao número configurado inicia uma conversa com o agente esperado, em uma versão conhecida. Só depois avalie detalhes de áudio e comportamento comercial.

Essa separação torna a implantação mais fácil de revisar. A equipe pode demonstrar publicação, associação e chamada real sem depender de uma única afirmação genérica de que a telefonia foi conectada.

Configure a integração sem espalhar credenciais

A configuração de telefonia deve usar os dados exigidos pela integração selecionada. Confira que pertencem à conta que controla o número e mantenha segredos fora do prompt, de documentos públicos e de relatos de suporte. Uma captura pode mostrar o estado da configuração sem revelar token. A pessoa que mantém a integração precisa de acesso adequado, mas isso não exige compartilhar a senha pessoal de outro responsável.

Em um exemplo fictício, a equipe cria uma configuração reconhecível e adiciona o número. Um erro de credencial impede a chamada, embora o número pareça correto no painel. Investigue a relação entre conta, configuração e provedor antes de mudar a associação do agente repetidamente. Se há mensagem de erro, registre a etapa e a descrição. Não envie o segredo junto da evidência para demonstrar que foi copiado.

Verifique o formato do número conforme o campo e a documentação utilizada. Confundir número de origem, número que recebe chamadas e destino de transferência produz problemas distintos. Uma chamada de entrada deve chegar ao número configurado para receber e ao agente associado. A transferência, se existir, usa outro destino e precisa de teste próprio. Não trate uma integração que recebe chamadas como prova de que qualquer encaminhamento humano funciona.

As rotas e eventos do provedor também fazem parte da configuração. Use os valores documentados para sua integração e confira os registros disponíveis quando a chamada não chega. Se o provedor recebeu a ligação, mas o Tigy não iniciou o atendimento esperado, investigue o caminho entre os sistemas. Se a chamada nem chega ao provedor, a origem do problema é outra. Essa ordem reduz alterações desnecessárias.

Depois de trocar credenciais ou responsabilidades, teste novamente o percurso real. Uma configuração antiga pode continuar visível sem que sua autenticação esteja válida. O objetivo é manter uma conexão verificável e sob responsabilidade definida, com evidência suficiente para diagnóstico e sem circulação de segredos por canais que não precisam deles.

Teste conversa e ferramentas pelo número que será utilizado

Depois de confirmar que a chamada chega ao agente, teste o objetivo do atendimento no canal telefônico. A saudação, a compreensão de nomes e números, a confirmação de dados e o uso de ferramentas precisam funcionar nesse percurso. O teste por texto ajudou a lógica; o teste no navegador ajudou a voz; a chamada pelo número acrescenta as condições da telefonia. Uma evidência não substitui automaticamente as outras.

Em uma loja fictícia, o piloto começa por informar horários e consultar pedidos com uma ferramenta de teste. Faça uma chamada comum, outra com número corrigido e outra com consulta indisponível. Confira a resposta ouvida e a ação realizada. Se o agente reconhece um identificador errado, a resposta pode parecer correta para outro pedido; a revisão deve conferir o parâmetro enviado e o resultado. Uma gravação disponível ajuda a investigar a experiência de áudio.

Inclua pausas e interrupções naturais. Uma pessoa pode falar devagar para ditar um código ou corrigir um dado durante a resposta. As configurações de conversa influenciam quando o agente escuta e responde. Não tente corrigir tudo com orientações de tom no prompt. Separe reconhecimento, interpretação, tempo de ferramenta e término de turno para escolher o ajuste certo.

Se o atendimento oferece transferência, teste somente capacidades compatíveis com o canal e a configuração. No Tigy, a transferência telefônica direta não entrega automaticamente o histórico ao humano. Uma integração separada deve cuidar do contexto quando necessário. Confira destino, indisponibilidade e continuidade antes de prometer que a pessoa será encaminhada com todas as informações.

Use ferramentas e dados de teste para operações que gravam registros ou enviam mensagens. O piloto telefônico pode executar ações reais se elas estiverem configuradas. Verifique os sistemas externos para confirmar o resultado e evitar duplicação. A aceitação do piloto deve mostrar que o número chega ao agente certo e que o atendimento funciona com precisão, não apenas que uma voz respondeu à chamada.

Mantenha uma sequência de diagnóstico depois do lançamento

Quando o atendimento muda depois da implantação, investigue em ordem. Confira número chamado, configuração, agente associado e versão utilizada. Depois verifique início da execução, resposta de áudio e ação da ferramenta, conforme o problema. Uma chamada que chega ao agente errado exige outra correção que uma consulta externa lenta. Separar as etapas evita reescrever o atendimento para resolver uma falha de encaminhamento.

Em um exemplo fictício, a equipe altera o agente no editor e salva, mas as chamadas continuam com a resposta antiga. Salvar e publicar são ações diferentes. Confira o histórico e a versão publicada, depois faça uma conversa nova no número pretendido. Se a associação aponta para outro agente, corrija o destino conforme o processo. A investigação precisa acompanhar a configuração efetivamente utilizada, não apenas a que alguém acredita ter editado.

Guarde identificadores e horários de chamadas problemáticas para revisar Runs e registros disponíveis da integração. Não copie credenciais para os relatos. Para áudio, ouça a gravação quando houver. Para ferramenta, confira ação e retorno quando disponíveis. Para ligação que não iniciou execução, investigue o percurso telefônico antes de procurar uma transcrição que talvez não exista.

Revise o piloto quando mudam credenciais, número, destino, instruções ou ferramentas. Uma integração que funcionou no lançamento precisa continuar sob manutenção. Defina quem acompanha falhas e quem atualiza as condições do atendimento. Se existe alternativa humana, verifique horários e destinos atuais, sem tratar a disponibilidade do agente como prova de disponibilidade da equipe.

O resultado esperado é uma operação explicável: a equipe sabe qual número recebe, qual agente responde e quais ações ele pode executar. Uma coleção pequena de testes reais do canal permite conferir essa relação depois de mudanças. Isso sustenta uma implantação mais previsível, com diagnóstico baseado em evidência e sem prometer transferência, consulta ou continuidade que o caminho configurado não consegue oferecer.