URA resolutiva no onboarding de fibra

Lead Product Designer, Onboarding, Nio Internet, 2025-2026

Hipótese declarada no business case: 47% de contenção. Apurado no MBR de Jun/26: 46%. A URA bateu na meta com 1pp de margem.

---

Contexto

A Nio é uma operadora de fibra óptica brasileira. Entre comprar o plano e a internet começar a funcionar, o cliente atravessa uma jornada de instalação que envolve agendamento, visita técnica, possível reagendamento, e às vezes pendências documentais ou de endereço. Durante esse intervalo, ele frequentemente liga pra Central, pra confirmar data, pedir adiantamento, perguntar sobre o técnico.

A URA dessa Central, no momento em que entrei, não fazia nada. O cliente discava, digitava CPF, ouvia “fique tranquilo, vamos te atender”, e era transferido pra fila do humano. Esperava 1,5 minuto em média pra ouvir uma resposta que cabia em 8 segundos: “dia 25, das 14 às 18h, tá tudo certo?”.

98% das ligações transbordavam. A URA não era um sistema de atendimento. Era um intercomunicador caro.

A hipótese que organizou o trabalho

Antes de desenhar qualquer fluxo, declaramos uma hipótese explícita no business case:

Cliente em instalação procura informação sobre o pedido, mas não necessariamente precisa de humano pra obter essa informação. Se a URA conseguisse entregar essa informação ativamente, projetamos que aproximadamente 47% das ligações se conteriam no canal automatizado.

O 47% não foi chute. Veio do cruzamento entre dois dados: o mix de motivos pelos quais o cliente liga (77,9% pra liberar agendamento, 17,3% pra cancelamento, 5% pra casos complexos) e o benchmark de mercado em resolutividade de URA (40-60% pra empresas como Nubank, iFood e telecoms).

Sem hipótese declarada, qualquer resultado vira “sucesso”. Com hipótese, dá pra discordar do método se ele não entregar.

Isso virou a coluna do projeto. Cada nova capacidade que entrou na URA depois desse momento foi um teste contra essa hipótese, não uma feature solta.

Como construímos o conteúdo

A maioria das URAs falha por um motivo simples: voz robótica e linguagem corporativa em momento de ansiedade real do cliente. Quem liga já tá tenso com a instalação que já comprou. Se a primeira coisa que ouve é “caro cliente, sua solicitação foi processada”, a URA confirma a ansiedade em vez de tirar.

Trabalhei com a UX writer do time pra calibrar cada script linha por linha. Três princípios guiaram o conteúdo:

Padronização entre canais. O cliente que recebe uma mensagem do Nio no WhatsApp não pode ouvir uma URA com voz diferente. A mesma marca, a mesma temperatura, o mesmo modo de falar.

Informação primeiro, gentileza depois. Sem “fique tranquilo”, sem “um momento por favor”. Direto pro “dia 25, das 14 às 18h, está tudo certo?”. A gentileza vem depois da informação, não como preâmbulo dela.

Reconhecimento do contexto emocional. Quando o cenário é pendência técnica ou área de risco, momentos em que o cliente já tá frustrado, o tom reconhece isso explicitamente antes de propor próximo passo.

A URA não deixou de ser educada. Ela deixou de ser cerimoniosa.

O método em seis fases

Cada fase teve hipótese, piloto com controle, leitura, e só depois escala.

Fase 1, Discovery

Mapeamento do volume real de ligações (620/dia sobre instalação), validação do custo unitário com o time de operações, alinhamento com benchmark de mercado, e leitura do mix de motivos. Foi nessa fase que a hipótese de 47% se formou.

Fase 2, Estratégia

Estruturação dos fluxos da URA resolutiva, confirmação, reagendamento, deslocamento do técnico, lembrete de documento, transferência só pra casos complexos. Business case fechado, com cenários conservador, realista e otimista.

Fase 3, Desenvolvimento 1 (Março/26)

MVP da vocalização do agendamento. Subiu em duas pernas controladas:

Grupo	Contenção
Controle (sem régua)	0%
Testado (com régua)	~8,5%

Esse foi o resultado que destravou as fases seguintes. Quando voltei pra pedir dev pra Fase 4, eu não estava mais defendendo hipótese, estava defendendo método que já entregou.

Fase 4, Desenvolvimento 2 (Abril/26)

Vocalização do pendenciamento. Aqui apareceram dois resultados em sequência.

Primeiro, +1,3pp de retenção imediata só por permitir que o cliente ouvisse o motivo da pendência sem precisar falar com humano.

Depois, quando expandimos a vocalização pros cenários que historicamente iam 100% pro atendente, pendência técnica, área de risco, cancelamento, a leitura de maio mostrou que aproximadamente metade dos clientes que cai nesses cenários se contém na URA. Ouve a informação, fica satisfeito, desliga.

Cenários que pareciam exigir humano respondem a comunicação bem estruturada. Designer que pressupõe que humano é necessário, é designer que ainda não testou.

Fase 5, Desenvolvimento 3 (Abril/26)

Status de execução do SA. Em refinamento técnico no momento desta publicação. Apuração na próxima leitura.

Fase 6, Desenvolvimento 4 (Maio/26)

Reagendamento via URA. Em piloto controlado. Leitura parcial mostra contenção real, mas como ainda é piloto e a perna de controle segue indo 100% pro humano, o número definitivo vem na próxima leitura.

O resultado consolidado

Em junho, fizemos a primeira leitura completa da URA, todas as réguas operando juntas, com volume estabilizado.

Métrica	Hipótese declarada	Apurado MBR Jun/26
Redução de transbordo pro humano	47%	46%

A hipótese de 47% foi declarada em fevereiro de 2026, antes do primeiro fluxo entrar em produção. O resultado de 46% foi apurado em junho, depois de seis fases. Diferença de 1pp.

Por que isso importa pra além da URA

A maioria dos cases de design no Brasil sofre de uma falha estrutural: o resultado é apresentado sem âncora contra o que comparar. “Melhoramos a experiência” vira “sucesso” automaticamente. Não dá pra discordar, não tem com o quê.

A diferença que esse projeto fez não foi a URA em si. Foi declarar a meta em fevereiro, defender o número em business case, escalar em pilotos controlados, e apurar contra a própria projeção seis meses depois. Quando a meta é declarada antes, o resultado tem significado real. Quando não é declarada, qualquer movimento parece progresso.

A meta declarada antes é o que separa método de coincidência.

Time

PM de Onboarding, Especialista de Jornada, UX writer do time, LPD de Plataforma Conversacional, e eu como Lead Product Designer compomos o núcleo do projeto. Apoio dos times de Plataforma Conversacional (URA e WhatsApp), Operações de Onboarding, e Desenvolvimento.