Case 01 · Gente Serviços · 2026

Atendimento N1

O primeiro atendimento da assistência 24h, redesenhado para uma operação que passou a atender clientes com regras muito diferentes entre si.

Meu papel
Product Design e, na prática, também PO
Período
Agosto e setembro de 2026
Entregas
Protótipo navegável, regras de negócio e style guide
Status
Ainda não lançado
Assistência 24h
Gente ServiçosAtendimento N1
Detalhe da tela de revisão do Atendimento N1.
01A mudança de escala

Tudo começou quando o negócio ficou maior.

A Gente Serviços deixou de apoiar apenas a própria seguradora. Baterias Moura, ABLA, prefeituras e outros clientes passaram a fazer parte da operação. Cada novo contrato trazia regras, perfis e exceções diferentes.

Gente Seguradora Baterias Moura ABLA Prefeituras Outros contratos

Cada contrato com regras, perfis e exceções próprios, atendidos pela mesma operação.

O ponto de partida

A empresa avançava; a base do atendimento ainda pertencia a outro momento.

02A tensão

A operação do futuro ainda vivia em um portal do passado.

O sistema tinha quase dez anos. Foi criado quando experiência do usuário ainda não orientava o produto e, com o tempo, acumulou campos, exceções e regras conhecidas principalmente por quem já dominava a rotina.

Tela de acionamento no portal anterior: formulário com dados gerais, dados do item, dados do segurado e checklist em blocos separados, e um menu lateral com treze opções.
O portal anterior. Dados de cliente e de pessoas borrados.
O conflito

Escalar o negócio sem rever essa base também significava escalar esforço, dúvida e dependência da memória.

03A investigação

Antes de abrir o Figma, eu entrei na operação.

Percorri o portal atual de ponta a ponta, conduzi uma análise heurística e conversei com atendimento, produto e tecnologia. Eu precisava enxergar o que era problema de interface, o que era regra de negócio e o que só existia na experiência das pessoas.

Interface

O que a tela atrapalhava, mesmo quando a regra estava clara.

Regra de negócio

O que o contrato exigia e não podia mudar por decisão de design.

Experiência das pessoas

O que só existia na memória de quem já dominava a rotina.

Chamada de vídeo com o time da operação, com o protótipo do Atendimento N1 aberto na tela compartilhada.
Uma das rodadas com a operação, em 11 de setembro: o protótipo aberto na chamada, com dados de teste.
A primeira virada

As entrevistas deixaram de ser opinião e viraram um mapa de campos, bloqueios, exceções e oportunidades.

04A construção

As regras começaram a virar um novo caminho.

Usei o Double Diamond para organizar a incerteza. O que descobrimos virou fluxo; o fluxo virou um protótipo funcional em HTML; e o protótipo tornou cada hipótese concreta o bastante para ser discutida e testada.

Descoberta Fluxo Protótipo em HTML Discussão e teste

As cinco etapas do novo atendimento

  1. 1Cliente
  2. 2Item
  3. 3Ocorrência
  4. 4Serviços
  5. 5Revisão
Checklist do guincho: cobertura disponível e limite no topo, o motivo colisão vindo da etapa anterior e dez perguntas de detalhe abertas porque houve batida.
O checklist do guincho. O motivo vem da etapa anterior, e as dez perguntas de detalhe só abrem porque houve batida.
Como acelerei

O Claude Code ajudou na implementação. A arquitetura do fluxo, as regras e as decisões de experiência continuaram sendo conduzidas por mim e pelo time.

05As viradas de produto

A cada rodada, uma regra escondida aparecia.

O saldo tinha dois significados. A liberação comercial parecia uma pergunta, mas precisava pausar o fluxo. A mesma cor representava atenção e bloqueio. Em cinco rodadas, essas ambiguidades viraram decisões claras na interface.

O saldo tinha dois significados
ANTES
Carga de bateria · 0 de 2

A mesma forma servia para o que restava e para o que já tinha sido usado. Cobertura intacta podia ser lida como esgotada.

DEPOIS
restam 2 de 2 por anoesgotadonão contratado

Uma gramática só, em toda a tela.

Bloco de veículo e apólice: cada serviço com quantas vezes ainda pode ser usado no ano e o limite por uso, o chaveiro com utilizações esgotadas em vermelho, e a pergunta de liberação comercial.
Veículo e apólice no protótipo: o que resta, o limite de cada uso e o que já se esgotou. Embaixo, a liberação comercial avisa que o atendimento pausa até a resposta.
A liberação comercial precisava pausar o fluxo
ANTES
Pede avalServiçoOrigemDestinoGrava

O atendimento seguia coletando tudo. Quem responde para onde vai o guincho entende que o guincho vai sair.

DEPOIS
Pede liberação Pausado · protocolo gerado

Pedir liberação é pausar. O cliente sai da ligação com um número, e nada mais é coletado até a resposta.

Uma cor, um significado
ANTES
Cliente VIPBloqueado

Vermelho fazia dois trabalhos: pedir atenção e impedir. O que perdia força era justamente o que precisava parar a ligação.

DEPOIS
Azul: ação e seleção Vermelho: o que impede Laranja: atenção Verde: conferido

Um cliente VIP é uma atenção, não um problema. Virou laranja.

O princípio que ficou

Quando a regra já é conhecida, o sistema deve orientar a decisão em vez de transferi-la para o atendente.

06O momento atual

O resultado desta fase é um produto que pode ser percorrido.

Hoje, o novo Atendimento N1 reúne vinte cenários navegáveis, um style guide aplicado e documentação de regras. O sistema ainda não foi lançado, então a história termina por enquanto com evidências de processo, consistência e aprendizado.

20cenários navegáveis
5rodadas com a operação
Style guideaplicado ao protótipo
Regrasdocumentadas para operação, produto e tecnologia
Fila de atendimentos do N1 com protocolo, solicitante, segurado ou empresa, placa, serviços, status e valor.
A fila do N1, com status que dizem com quem cada atendimento está.
Painel gerencial com atendimentos do dia, tempo médio, SLA, tempo por etapa, volume por hora e desempenho por atendente.
O painel gerencial do protótipo, com dados simulados: onde o tempo do atendimento vai e quem está indo rápido demais.
A história continua

O protótipo não encerra o projeto. Ele cria uma base comum para operação, produto e tecnologia seguirem decidindo juntos.