Vivo Fixa

Contexto

A Vivo operava internet, TV por assinatura e telefone fixo como três produtos em silos, com jornadas de compra fragmentadas. O projeto, na Accenture Song, era unificar os três numa jornada só — e toda essa jornada começa no mesmo lugar: a consulta de disponibilidade, que descobre quais pacotes existem para aquele endereço.

É a porta de entrada do funil inteiro. Se a consulta falha, nenhum dos três produtos chega a ser oferecido — não importa quão boa seja a página de planos depois dela.

Desafio

O problema central era que a consulta só sabia dizer sim ou não. E o "não" concentrava situações completamente diferentes entre si — algumas definitivas, outras a semanas de distância de virarem "sim".

• Infraestrutura legada e regras de negócio complexas, com cada um dos três produtos carregando seus próprios requisitos obrigatórios.
• Endereços que o sistema não resolvia, especialmente em condomínios, onde número e complemento têm significados diferentes dos de uma casa.
• Coleta de dados sensíveis sem justificativa visível para o usuário, num momento em que ele ainda não recebeu nada em troca.
• Público amplo e diverso, com níveis muito diferentes de letramento digital — o que tornou a conformidade WCAG um requisito de funcionamento, não de polimento.

Meu papel

Atuei como Product Designer dentro de uma operação de consultoria, liderando a frente de UX Research e Arquitetura da Informação e construindo a interface web para desktop e mobile:

• Entrevistas com usuários e com stakeholders
• Análise de clickstream e analytics da jornada atual
• Inventário e auditoria de conteúdo
• Sitemap e arquitetura da informação
• Wireframe, interface e protótipo navegável
• Review, handoff e entrega para desenvolvimento

Pesquisa

Cruzei três fontes: entrevistas com usuários, entrevistas com stakeholders — incluindo desenvolvedores e o departamento de infraestrutura — e clickstream e analytics da jornada em produção. As entrevistas técnicas foram decisivas: elas explicaram por que um endereço atendido ainda assim podia não receber o serviço.

Três oportunidades saíram desse cruzamento:

Arquitetura da informação

O sitemap foi construído depois das entrevistas com desenvolvedores e infraestrutura, e não antes. Essa ordem é o ponto: a estrutura precisava espelhar como a disponibilidade é realmente apurada, senão a interface prometeria caminhos que o sistema não conseguiria cumprir.

A ramificação principal separa casa de condomínio logo após o endereço — porque condomínio exige complemento e tem uma cadeia de dependências própria (obra, contrato, capacidade de rede) que uma casa não tem. Da disponibilidade saem dois destinos: pacotes, quando há oferta, e prospecção, quando não há.

Consulta de endereço

O tratamento do número de endereço foi uma das três oportunidades levantadas — e um dos pontos onde a jornada mais quebrava. A solução combinou autocompletar, para reduzir a digitação e os erros de grafia, com dicas contextuais em cada campo, explicando o que preencher quando o endereço não segue o padrão.

Cada estado de erro ganhou mensagem própria por campo — nome, e-mail, telefone e complemento — em vez de um alerta genérico no topo do formulário. E o timeout, que antes deixava a pessoa sem resposta, passou a ter tela e caminho de saída.

Estados de indisponibilidade

Esta é a decisão central do projeto. Um endereço sem oferta não é um caso só: as entrevistas com infraestrutura revelaram quatro motivos distintos, com prazos e responsáveis diferentes. Tratá-los como um único "não disponível" descartava usuários que estavam a semanas de poder contratar.

Desenhei um estado para cada motivo, com linguagem e ação próprias:

• Sem cobertura — a região ou o endereço não é atendido por internet de alta velocidade e TV. É o único caso realmente definitivo; a saída é deixar contato para prospecção.
• Rede saturada — o endereço é atendido, mas não há pontos de acesso disponíveis para os apartamentos. A rede está em expansão, então a tela informa o prazo e oferece aviso quando liberar.
• Quebra técnica — há obra de adaptação pendente no condomínio. A tela pergunta se a obra já foi concluída, transformando o usuário em fonte de informação que a Vivo ainda não tinha.
• Quebra comercial — falta o contrato com a administração do condomínio. A tela pede os dados da administração para a Vivo destravar a negociação.

Nos quatro casos, o endereço consultado fica visível na tela e há sempre um "fazer nova consulta". Ninguém termina a jornada num beco sem saída.

Sem cobertura

Rede saturada

Quebra técnica

Quebra comercial

Dados sensíveis

A terceira oportunidade da pesquisa era o tratamento de dados sensíveis. No estado de quebra comercial, a Vivo precisa dos dados da administração do condomínio — um pedido que, sem contexto, soa invasivo e trava o preenchimento.

Em vez de só coletar, desenhei uma tela que explica por que aquele dado é necessário: o papel legal da administração, quem arca com os custos de adaptação, e o compromisso de devolver o local como estava. A informação que destrava o preenchimento é a mesma que reduz a dúvida — e ela fica a um toque de distância, não escondida nos termos de uso.

Resultados

Após o deploy e o teste de validação final da jornada unificada:

O ganho que não aparece nessas três porcentagens é o de recuperação: endereços que antes saíam da jornada com um "não disponível" agora saem com um prazo, um aviso agendado ou um dado que a Vivo precisava para destravar a própria infraestrutura.

Stack e ferramentas

Pesquisa

Lookback · Google Meet · Clickstream e analytics

Design

Sketch · InVision · Miro · Octopus

Entrega

Review · Handoff · Documentação de fluxo

Método

Entrevistas com stakeholders · Arquitetura da Informação · WCAG