O Portal do Cliente conecta dois perfis que dependem um do outro todos os meses: o escritório de contabilidade, que opera e entrega serviços, e o cliente desse escritório, que solicita, acompanha, compartilha documentos e recebe resultados.
O nome do produto escondia uma relação mais complexa. De um lado, profissionais do escritório de contabilidade configuravam serviços, atendiam solicitações, publicavam informações, compartilhavam documentos e geravam entregas. Do outro, o cliente do escritório acessava o Portal para acompanhar essa relação: ativar o perfil, consultar CND, abrir solicitações, ler respostas, receber notícias, trocar documentos e acessar relatórios.
Os dois perfis utilizavam o mesmo ecossistema, mas tinham objetivos, responsabilidades e pontos de fricção diferentes. Melhorar apenas uma tela para um dos lados poderia deslocar o problema para o outro.
É quem opera a relação e precisa manter dezenas de atividades conectadas ao longo do mês.
É quem recebe o serviço e precisa entender o que está disponível, o que precisa fazer e o que já foi entregue.
Conversei com os diferentes atores envolvidos na jornada para evitar uma leitura limitada à interface. O objetivo era entender tanto a experiência percebida pelos usuários quanto as regras, integrações, limitações e comunicações que existiam por trás dela.
Entendi tarefas recorrentes, expectativas, pontos de espera e momentos de maior insatisfação dos dois perfis.
Mapeei como estados, navegação e feedbacks eram implementados e onde a experiência encontrava restrições.
Investiguei sincronizações, validações, integrações e dados que sustentavam ações aparentemente simples no Portal.
Conectei os fluxos às necessidades operacionais, responsabilidades entre áreas e valor esperado para o serviço.
Considerei notícias, mensagens, notificações e outros pontos de contato que continuavam a experiência fora da tela principal.
O insight central: muitos problemas que apareciam na interface começavam antes dela — em processos, integrações, regras e handoffs entre áreas.
O Service Blueprint foi a ferramenta central para conectar o que cada perfil fazia com o que o produto e a organização precisavam executar por trás. Em vez de uma sequência de telas, o mapa revela evidências, ações do usuário, frontstage, backstage, processos de suporte, tempos e pontos críticos.
Jornada do escritório. O mapa mostra uma operação mais extensa: criação de usuário, CND, Box-e, Manifestação de NF-e, notificações, parâmetros, solicitações, notícias, documentos e relatórios — todos conectados a ações de frontstage, backstage e suporte.
Jornada do cliente do escritório. A experiência é mais enxuta, mas depende diretamente do fluxo operacional do escritório: ativação, CND, solicitações, respostas, notícias, documentos e relatórios.
Ao sobrepor as curvas de satisfação com os blueprints, ficou mais fácil localizar onde uma etapa operacional gerava fricção percebida. O escritório apresentava uma jornada mais longa e variável; o cliente permanecia neutro em boa parte do fluxo, mas tinha quedas fortes em momentos específicos.
A amostra de melhorias reforçou onde a atenção deveria se concentrar. CND, Documents e Solicitações de serviços aparecem como as maiores concentrações, seguidas por criação de usuário, configurações de notificações e relatórios.
O tema aparece com alto volume na amostra e também como queda de satisfação nas duas jornadas.
Compartilhar, visualizar e sincronizar documentos atravessava os dois perfis e dependia de ações de frontstage e backstage.
O cliente abre e acompanha; o escritório recebe, processa e responde. Qualquer quebra nessa passagem afeta os dois perfis.
Problemas de ativação e reutilização de e-mail tinham impacto antes mesmo de o cliente conseguir usar o Portal plenamente.
Essa separação evitou redesenhar sintomas. Para cada oportunidade, a pergunta passou a ser: a solução é uma nova interface, uma mudança de processo, uma integração melhor ou uma comunicação mais clara?
Depois de mapear os dois perfis, os pontos críticos puderam ser discutidos com uma linguagem comum. As decisões deixaram de partir apenas de uma tela e passaram a considerar quem iniciava a ação, quem precisava responder, quais sistemas participavam e qual evidência o usuário recebia no final.
O trabalho criou uma visão end-to-end do Portal do Cliente e ajudou a separar problemas de interface de problemas de processo, tecnologia e comunicação. Com essa base, foi possível direcionar a evolução de fluxos críticos e reduzir o risco de melhorar a experiência de um perfil às custas do outro.
Para recrutamento, este case representa principalmente minha capacidade de investigar antes de desenhar, trabalhar com múltiplos stakeholders, modelar serviços complexos e transformar evidência em decisões de produto.
O Portal do Cliente não era apenas uma interface entre empresa e usuário. Era a camada que conectava o escritório de contabilidade ao cliente do escritório — e toda a operação necessária para essa relação funcionar.