Repensando Manutenção na Prolog

criando o shop360

Todos projetos

Meu instagram

Prolog e a manutenção de frotas explorando o poder do Design!

Repensando a Manutenção na Prolog: mais controle, rastreabilidade e confiança para quem não pode deixar um veículo parar

O Prolog é um sistema de gestão de frotas usado por mais de 900 operações no Brasil e no exterior, com soluções de gestão de pneus, checklist eletrônico e gestão de manutenção. Dentro dele, o módulo de Manutenção é o conjunto de funcionalidades que dá suporte às transportadoras para criar, acompanhar, prever e corrigir problemas dos veículos, mantendo manutenções preventivas e corretivas em dia para que nenhum caminhão pare no meio do caminho e a operação não tenha prejuízo.

Como Product Designer, conduzi a reformulação desse módulo de ponta a ponta: das entrevistas com clientes à prototipação, dos testes de validação ao kickoff com o time de engenharia e à apresentação de resultados. O objetivo era transformar um módulo funcional, mas cheio de atritos, em uma experiência confiável, rastreável e com o controle que operações de todos os portes precisam, de frotas com 50 placas a frotas com mais de 4.000.

1. Discovery: ouvindo anos de reclamações acumuladas

O ponto de partida veio do time de Customer Success, que havia mapeado ao longo dos anos uma série de reclamações recorrentes sobre o módulo. A partir desse histórico, design de produto e os PMs decidiram, com apoio da diretoria, que era hora de atacar o problema de frente e reformular a manutenção como um todo. O discovery deixou claro que não era um ajuste pontual: o processo legado tinha lacunas de funcionalidade, regras inconsistentes e entregas que simplesmente não cumpriam sua função — como o PDF da Ordem de Serviço, com muitas páginas para pouquíssimo conteúdo.

Mapa de afinidades de pesquisa UX (affinity mapping)

2. Pesquisa com clientes: 9 entrevistas, de 50 a 4.000 placas

Entrevistei 9 clientes — justamente aqueles que mais reclamaram e sugeriram melhorias ao longo dos anos. O recrutamento foi feito via WhatsApp, com apoio do CS, e cada conversa durou de 60 a 90 minutos. Um aprendizado central foi o quanto o porte da frota muda a necessidade:

Frotas menores (~50 placas) não têm caminhão reserva. Um veículo parado é uma operação parada — a manutenção corretiva precisa ser rápida e o fluxo, simples.
Frotas grandes (~4.000 placas) precisam que o plano de manutenção (troca de óleo, pastilha de freio, lavagem etc.) rode de forma automática e corriqueira, sem depender da conferência de um humano a cada ciclo — só a execução.

Reunião de discovery com cliente.

3. Os insights que se repetiram

Três dores apareceram de forma quase idêntica em entrevistas diferentes, e viraram o norte do redesign:

"Não consigo confiar nos dados do plano de manutenção."
"Não tenho rastreabilidade de quem fez a manutenção."
"Não há custos detalhados para eu conseguir puxar relatórios."

Confiança, rastreabilidade e detalhamento de custos — foi em torno desses três eixos que a solução foi desenhada.

4. Validação com Lovable e alta fidelidade no Figma

Montei um rascunho navegável no Lovable e o levei para os clientes em chamadas no Google Meet. Em vez de só apresentar, deixei que eles próprios usassem o protótipo com a tela compartilhada, enquanto eu observava onde travavam, o que procuravam e o que fazia sentido. Foi assim que validei o novo Plano de Manutenção e o Farol de Preventivas. Com os feedbacks coletados, evoluí para uma versão de alta fidelidade no Figma, que serviu de base para o kickoff com os desenvolvedores.

Rascunho Lovable → Alta fidelidade

Anotações e organizações de conteúdo.

As quatro frentes do módulo

Ordem de Serviço, o coração da reformulação. A OS é o documento central que agrupa um ou mais problemas de um veículo, consolidando execução, custos, quilometragem e histórico, com três origens (Avulsa, Checklist e Plano de Manutenção) e um ciclo de status com automações. No processo legado, depois que a OS virava "Resolvida", custos, serviços e produtos ficavam travados, não dava para corrigir nada, e as regras de status eram inconsistentes. No novo processo, é possível adicionar, editar e remover custos mesmo com a OS resolvida (com devolução de estoque), as regras de status foram consolidadas e corrigidas, a tela de resolução passou a mostrar só os problemas pendentes e o comportamento de mover itens do estoque ficou bem definido.

Plano de Manutenção, a cobertura preventiva. É a origem que cria OS automaticamente quando um gatilho de KM ou prazo é atingido. Reformulei a criação em cinco etapas (Identificação, Problemas, Gatilhos, Placas e Notificações), com salvamento automático em rascunho, gatilhos sequenciais que disparam uma única vez, KM inicial/final que delimita quando valem e notificações configuráveis por cargo, com antecedência (X dias ou X km, o que vier primeiro), recorrência e canais Web, App, E-mail e WhatsApp.

Print do fluxo de criação de plano em 5 etapas

Relatórios em PDF, de "dump de dados" a documento apresentável. O PDF legado era fixo, sem personalização, com muitas páginas para pouco conteúdo e sem versão resumida. Agora há três caminhos: PDF Personalizado (escolha de seções e tamanho das imagens), Baixar PDF (versão padronizada, download direto) e Imprimir PDF. Incluí ainda download em lote (.zip) com barra de progresso, tratamento de erro parcial e cancelamento.

Manutenção por Placas — a visão pelo veículo. É a gestão da manutenção olhando pela placa, com a regra de vínculo de custos entre OS da mesma placa e de placas diferentes, conectada ao Farol de Preventivas, que classifica as placas conforme a proximidade do gatilho. Vários clientes sugeriram melhorias aqui, e o redesign deixou a funcionalidade mais completa e coesa.

Antes x depois: o PDF da Ordem de Serviço

A versão legado era um relatório funcional, mas cru: título genérico, blocos de dados corridos, um bloco por problema e os anexos jogados no fim. A nova versão é um documento estruturado e white-label, pensado para ser entregue ao cliente final. O que mudou:

Marca e contexto. O cabeçalho passou a trazer o logo do próprio cliente, o número da OS em destaque, uma tag de status (Resolvida / Cancelada) e uma linha de auditoria informando quem alterou o status e quando.
Arquitetura da informação. Dados soltos viraram cards claros com ícones, Veículo, Ordem de Serviço, Informações de abertura e de resolução, agora lado a lado.
Granularidade por problema. Cada problema virou um card numerado, com tag de prioridade, autor, data, marcação de adição manual, status e chips de informação (fornecedor, início, fim, tempo e KM de resolução).
Custos muito mais claros. Custo por problema em colunas de Produtos e Serviços com subtotais, além de uma página nova de Resumo de todos os custos, com extras, descontos e total da OS, que o legado não tinha.
Indicadores e estados. Sinalizadores de "100% dos problemas resolvidos", paginação real, galeria organizada para muitas imagens e tratamento dedicado de estados vazios (sem fotos, sem custos), que antes pareciam bug.

Imagens no lugar certo. Antes isoladas num bloco de anexos no fim; agora dentro do card do próprio problema, no contexto correto.

Dados e Resultados

Aumento de 120% nas vendas do módulo de Manutenção — o valor percebido cresceu e as vendas mais que dobraram.
Redução de 100% nos chamados pedindo exclusão de Ordem de Serviço — o que antes exigia acionar o suporte agora é feito pelo próprio usuário na interface.
Mais liberdade e controle no ciclo de status da OS, incluindo edição de custos após a resolução.
Maior controle na criação de planos de manutenção, com gatilhos e notificações configuráveis.
Rastreabilidade completa — passou a ser possível saber quem fez o quê e quando, via histórico de mudanças.
Redução de churn e maior retenção de clientes — as novas entregas foram determinantes para segurar contas.

Para a Prolog, o impacto foi de negócio: mais vendas, menos chamados de suporte e retenção de clientes. Para o cliente, foi de autonomia — muito mais controle para executar e acompanhar a manutenção de toda a frota, com dados em que finalmente dá para confiar.

O projeto continua

A reformulação começou em julho de 2025 e segue em andamento: o próximo passo é repensar o submódulo de Estoque, ainda não trabalhado. Cada entrega é versionada (v1, v2, v3…) em negociação com engenharia, o que mantém no cliente a sensação constante de que o módulo está evoluindo.