6 min read
30% menos chamados de suporte em 3 meses: redesenhando o atendimento ao cliente de um grande grupo de shoppings
Um app usado por milhões de clientes de shopping, de adolescentes a idosos, estava gerando mais de 850 chamados por mês só em dúvidas de e-mail, cadastro e senha: problemas resolvíveis sozinhos, se a informação certa estivesse no lugar certo. Liderei o discovery de ponta a ponta do serviço de atendimento e identifiquei que a causa raiz não era falta de conteúdo, e sim um sistema de suporte fragmentado em três camadas sem dono único. Diante de um constraint real de engenharia, priorizei a opção que minha squad conseguia entregar sozinha, negociando espaço numa fila compartilhada: uma reestruturação completa da FAQ, validada com usuários reais antes de ir ao ar. O resultado foi uma redução de 30% nos chamados em 3 meses (3x a meta), com a base reaproveitada para o chatbot futuro e a criação da primeira área de Service Design da Allos, que me convidou a desenhar também o fluxo TO BE do atendimento.
O app da Allos é o principal canal digital do cliente dentro do shopping físico: participação no programa de benefícios, pagamento de estacionamento, localização de lojas, eventos e promoções. Análise dos dados de SAC dos 6 meses anteriores mostrou que os temas de e-mail, cadastro e senha sozinhos somavam mais de 850 chamados, volume desproporcional para dúvidas que deveriam ser autoatendíveis.
Esse volume não vivia só na central: atendentes dentro dos shoppings também absorviam esse atrito presencialmente, sem padronização entre unidades.
A solução não foi o chatbot, o quick win óbvio da matriz de impacto x esforço, porque dependia de uma fila de front compartilhada e de uma aprovação que eu não conseguiria destravar a tempo. Priorizei a opção que minha squad conseguia entregar sozinha: uma reestruturação completa da FAQ, desenhada a partir de um blueprint de ponta a ponta do serviço e validada com 47 usuários reais via teste de usabilidade antes de ir ao ar.
Três movimentos que transformaram um problema lido como falta de conteúdo numa reestruturação real do serviço de atendimento.
Descobri que o problema era estrutural, não de conteúdo
Mapeei o serviço ponta a ponta e estruturei a priorização com o time
Validei a solução com usuários reais antes de publicar
Entrevistei o time de SAC terceirizado (TEL) e o time interno de atendimento da Allos, e visitei presencialmente supervisores de atendimento em shoppings com perfis operacionais distintos (com e sem programa de fidelidade, incluindo uma unidade com sistema legado). O que emergiu não foi falta de FAQ, e sim um serviço fragmentado em três camadas de escalação sem contato direto entre si (SAC terceirizado → espaço cliente do shopping → time interno Allos), com SLA de resposta de até 10 dias em casos que precisavam escalar. Também descobri que já existia um bot de WhatsApp, mas subutilizado: número desatualizado em vários shoppings e sem visibilidade sobre ações de marketing segmentadas, o que gerava reclamações que a própria central não sabia explicar.
Consolidei esses achados em um blueprint AS IS (evidências físicas, ações do usuário, contato direto, backstage, regras de negócio, dores e oportunidades) e facilitei uma dinâmica de árvore de oportunidades que virou base do roadmap do ano. Rodei um benchmark estruturado de ~15 apps de categorias distintas (bancos digitais, delivery, gig economy, e-commerce, entretenimento) para levantar padrões de central de ajuda, chatbot, formulário de contato, notificação de status de chamado e acessibilidade, usado como insumo direto para o desenho da nova FAQ.
Rodei um teste de usabilidade não moderado via Maze com 47 usuários do programa de benefícios, em 3 cenários (conta bloqueada, necessidade de atendimento humano, exploração geral). Resultado: 51% completaram a tarefa direto pela FAQ, 28% conseguiram acionar suporte com sucesso quando precisaram, esforço médio de 2.6 (escala de 1–5). Usei os próprios achados do teste para embasar dois ajustes que entraram no roadmap: ícone de ajuda mais visível na tela de login e redirecionamento automático para o artigo certo em cenários já identificados (ex: bloqueio de conta).
Um case sênior mostra o que foi sacrificado, não só o que funcionou.
O SAC é terceirizado (TEL). Contratos desse tipo costumam ser remunerados por volume atendido ou por capacidade de FTE alocada, então cada um dos ~255 chamados/mês evitados tem custo direto de atendimento evitado, isto é, capacidade liberada sem aumento de headcount.
E-mail, cadastro e senha são ações de gateway para o programa de benefícios. Um usuário travado nelas não se cadastra, não resgata benefício e não segue ativo no programa. Reduzir esse atrito protege o funil de ativação do programa de fidelidade, que sustenta frequência de visita e ticket médio nos shoppings.