Em desenvolvimento
Mapeamento e navegação ao vivo de URA
Backend de um app de telefonia que mapeia a URA de uma empresa e percorre o menu numa ligação ao vivo antes de passar a chamada no destino. Sob NDA: sem demo pública, código-fonte ou nome de fornecedor.
Quem tem este problema
Ligar para uma empresa grande quase sempre é ouvir uma URA, adivinhar qual opção leva a uma pessoa e começar de novo quando o palpite erra. O cliente, uma startup de telefonia para consumidor ainda não lançada, queria um app que mostra o menu antes da ligação e depois navega por você. Entender o menu foi a parte mais fácil. O difícil é o tempo: as URAs fazem pausa no meio da saudação, continuam recitando opções depois que você aperta uma tecla, ignoram teclas apertadas na hora errada e dão poucos segundos para responder antes de recomeçar.
Meu papel
Serviços FastAPI para mapeamento de URA e navegação ao vivo, integração com a API do app e controle de sessões telefônicas.
Decisões que tomei
- Dois motores dividem o mesmo pipeline de chamada: o explorador mapeia menus e o navegador percorre o caminho escolhido durante uma ligação.
- Um mapeamento interrompido ou incompleto não substitui o último mapa completo. A navegação confirma o envio da tecla e recusa opções que a URA não ofereceu.
- O serviço de chamada ao vivo roda isolado em um worker porque o estado da sessão fica em memória; os motores compartilham controle de chamada, transcrição e camada de decisão.
- Números digitados pelo usuário são mascarados no ponto de discagem. O fluxo de gravação de chamadas foi removido.
Limites que continuam
- O app ainda não foi lançado e o trabalho está sob NDA; não há demo pública, código-fonte ou nome de fornecedor.