Telefonia SIP no Tigy: roteamento de chamadas para agentes de voz

Prepare o agente de prompt

Abra o workspace correto, selecione o agente e confira suas instruções. Use uma apresentação identificável no piloto, como o nome da unidade atendida. Salve e faça um teste no editor; isso estabelece uma referência para comparar com a chamada telefônica.

Ative a conexão SIP

Nas configurações de telefonia do agente, habilite a criação do destino SIP quando necessário e copie o endereço completo mostrado na tela. Pense nesse endereço como o destino da ligação, específico daquele agente. Não o copie de memória nem use o endereço de outro agente.

Configure a origem telefônica

No seu sistema compatível com SIP, encaminhe as chamadas ao endereço SIP completo copiado. A configuração da origem depende do serviço usado e de suas permissões. Combine com o administrador qual rota será alterada, quais contatos entram no piloto e como revertê-la.

Faça uma chamada rastreável

Ligue pela origem pretendida, confirme a apresentação, faça uma pergunta conhecida e revise o registro do agente. Anote horário e identificação da execução. Se o destino estiver errado, investigue o roteamento antes de mudar o prompt.

Valide as exceções

Teste indisponibilidade do destino e, se configurada, transferência para a equipe. Confira o comportamento da origem quando a chamada não completa. Não deduza qualidade de áudio, cobertura ou capacidade de uma única chamada bem-sucedida.

Como confirmar que a chamada chegou ao agente certo?

Registre o workspace, agente, origem telefônica e endereço SIP completo copiado das configurações. Faça uma chamada com pergunta sintética identificável e procure a execução correspondente pelo horário e pelo agente. Uma saudação semelhante em dois agentes pode esconder um erro de destino.

Se a chamada chega ao agente errado, compare o destino copiado e a rota na origem antes de alterar o prompt. Se não chega, investigue a entrega telefônica. Depois de confirmar a associação, teste áudio, ferramentas e transferência separadamente; conexão SIP não comprova todas essas capacidades.

Defina o que o piloto telefônico precisa demonstrar

Um piloto SIP deve responder perguntas diferentes do teste de conversa no editor. Ele precisa mostrar que a origem encaminha ao agente correto, que o áudio permite atendimento e que o encerramento segue o percurso esperado. Um bom prompt não resolve uma rota incorreta.

Escolha uma tarefa simples e verificável para a primeira chamada. Em um exemplo fictício, o agente informa o horário de uma unidade usando a fonte aprovada. Isso permite observar associação, apresentação e resposta antes de acrescentar ações externas ou transferência.

Registre origem da chamada, agente pretendido e responsável pela configuração externa. Não copie credenciais para um documento de testes. Use informações suficientes para rastrear o percurso sem expor dados de autenticação ou contatos pessoais desnecessários.

Defina também como retornar ao atendimento anterior se o piloto falhar. Essa operação pertence ao sistema telefônico e precisa ser conhecida por quem mantém a rota. Não prometa recuperação automática apenas porque o teste tem uma alternativa descrita em texto.

Confira o endpoint específico do agente selecionado

Cada agente tem seu próprio destino SIP. Copie o endereço completo nas configurações de telefonia e entregue-o ao responsável pela central ou serviço de chamadas. Ele deve encaminhar a ligação para esse destino. Confira qual agente atende antes de começar os testes de conversa.

Confira a identidade do agente antes e depois da configuração. Em um workspace com vários agentes, nomes parecidos podem levar à cópia do número errado. Use uma identificação operacional clara e uma chamada de teste reconhecível, sem incluir dados sensíveis.

Publicar uma mudança de comportamento não significa reatribuir o número de outro agente. Mantenha a distinção entre a versão da conversa e a associação telefônica. Se o atendimento chega ao agente incorreto, investigue o destino copiado e a rota da origem.

Teste uma ligação direta pelo percurso pretendido e localize a execução correspondente. Compare horário, agente e pergunta de teste. Essa evidência ajuda a confirmar a associação sem depender apenas do texto de apresentação, que pode ser semelhante entre configurações.

Observe áudio e turnos no canal de destino

Uma ligação conectada ainda pode apresentar dificuldade de áudio. Verifique se as duas partes são ouvidas, se a fala permanece compreensível e se pausas e interrupções produzem o comportamento esperado. Não declare qualidade pelo simples estabelecimento da chamada.

Use frases curtas com nomes, datas e números representativos. Compare o que foi dito, reconhecido e respondido. Se um dado muda na transcrição, investigue a entrada de áudio e a configuração do transcritor antes de culpar uma regra do prompt.

Inclua uma pessoa que interrompe para corrigir informação. O agente deve usar o pedido atual e manter clareza sobre o próximo passo. Uma boa resposta em texto não comprova que a interação falada funciona no canal telefônico.

Registre condições do teste para conseguir repetir. Origem, ambiente e configuração relevante ajudam a comparar resultados. Evite transformar um teste com áudio limpo em garantia para todos os ambientes. Amplie a amostra conforme o piloto representa situações reais de atendimento.

Valide ações e transferência como verificações próprias

Depois de confirmar rota e conversa básica, teste cada ação incluída no recorte. A ferramenta precisa estar configurada e selecionada no agente. A resposta verbal deve corresponder ao resultado externo, incluindo recusa e indisponibilidade.

Se houver transferência, verifique suporte do canal, destino e configuração. Não deduza compatibilidade de um teste de voz no editor pelo navegador. A transferência direta no Tigy não envia automaticamente o contexto; qualquer entrega de registro exige um mecanismo separado e validado.

Em um exemplo fictício, o agente consulta uma solicitação e depois tenta encaminhar à equipe. Registre consulta, estado recebido, tentativa de transferência e resultado observado. Cada etapa responde uma pergunta diferente sobre continuidade.

Inclua uma ferramenta que falha e um destino indisponível. A conversa deve explicar o limite sem anunciar ação concluída. O piloto precisa mostrar que a pessoa recebe um próximo passo verdadeiro também quando o caminho ideal não funciona.

Investigue a falha na etapa em que ela aparece

Se a chamada não chega ao agente, comece pela rota da origem e pelo destino configurado. Se chega ao agente errado, compare associação e endereço SIP copiado. Alterar a resposta do modelo não corrige essas condições.

Se a chamada chega corretamente, mas a pessoa não é entendida, compare áudio e transcrição disponível. Se a interpretação está certa e a ferramenta falha, examine parâmetros, autorização e retorno externo. Esse encadeamento evita mudanças amplas sem diagnóstico.

Use uma pergunta de teste identificável e horário registrado para correlacionar evidências. Não faça muitas alterações simultâneas; isso dificulta saber qual corrigiu o problema. Repita a mesma verificação depois da mudança e confira um caso que já funcionava.

Se a evidência não permite concluir a causa, preserve a dúvida. Um teste inconclusivo não deve receber classificação de sucesso. Encaminhe a investigação ao responsável pela dependência com descrição concreta do esperado e do observado.

Amplie com capacidade e manutenção verificadas

Uma ligação individual não comprova simultaneidade ou estabilidade em maior volume. Confira limites e condições das dependências com a configuração e o contrato reais. Evite publicar números de capacidade que não foram verificados para o projeto.

Planeje uma ampliação gradual e observe demanda, falhas e continuidade. Separe execução do agente, telefonia e tarefa concluída. O resultado de atendimento pode depender de API ou equipe humana, mesmo quando a rota SIP funciona corretamente.

Mantenha responsáveis por destino, configuração do agente e integrações. Quando mudar uma unidade ou substituir um agente, revise a associação telefônica e os casos de teste. Não presuma que alterações editoriais ou de publicação atualizam toda a rota externa.

Conclua cada etapa com evidência de origem, agente, áudio e resultado. Um piloto confiável oferece um atendimento que a equipe consegue explicar e manter. A próxima expansão deve seguir essa evidência, com uma alternativa operacional pronta para os limites conhecidos.

Faça uma segunda pessoa reproduzir a verificação

Antes de ampliar, peça a outra pessoa responsável que repita a chamada pelo mesmo percurso. Ela deve conseguir identificar o agente esperado, encontrar a execução e explicar o resultado sem orientação informal de quem configurou. Essa revisão revela lacunas no registro e ajuda a manter a operação quando a equipe muda.