Cases | Rick Benetti

Truss Int

Rick Benetti — Mon, 01 Dec 2025 00:00:00 +0000

translationKey: case-truss-int

O cenário

Truss Int desenvolve hardware e software para gestão de ativos móveis e fixos — embarcações, frotas terrestres e aéreas — para operações latino-americanas.

Como Product Designer, redesenhei a plataforma usada pela LHG, empresa paraguaia-brasileira que transporta minérios e carga por hidrovias entre Brasil, Paraguai e Uruguai — de Corumbá, MS, até Montevidéu.

O problema

A plataforma rodava em base russa em fim de vida — sem atualização garantida, sem suporte, sem evolução possível.

Em paralelo, a operação real da LHG vivia em planilhas dispersas que ninguém conseguia consolidar. O sistema antigo era de consulta, não de gestão. Quando algo parava na operação, ninguém sabia identificar onde nem por quê.

Como reconstruir um sistema crítico de logística internacional em 5 meses — sem documentação, sem garantia de continuidade e com a operação real vivendo em planilhas?

A abordagem

01 · Conversas iniciais

Entrevistas com a equipe técnica da Truss Int. O briefing descrevia uma plataforma a substituir. Parecia um problema de interface.

02 · A descoberta na 4ª interação

A gerente paraguaia não usava o sistema para operar. Usava planilhas.

O sistema russo era de consulta — a operação real vivia em arquivos dispersos. O que parecia um problema de interface era na verdade um problema de modelo: o sistema não refletia como a operação funcionava.

03 · Reconstrução de lógica

Sem documentação. O trabalho foi arqueológico: mapear o que o sistema registrava, o que as planilhas completavam e onde estavam os gaps reais.

O sistema russo permitia a consulta de dados que depois eram alimentados em outro sistema — gerando uma visão estática das embarcações, sem gestão real.

O mapeamento

O sistema precisava deixar de registrar dados para passar a operar a frota — planejamento, execução e monitoramento no mesmo lugar.

Módulo	O que resolve
Mapa	GPS de todas as embarcações em tempo real, com velocidade, geozonas e rota
Planejamento	Viagens, tripulação, carga e bunker — sem duplicação manual
Equipamentos	Velocidades, status e histórico por rebocador
Mosaico	Visão simultânea de múltiplas embarcações
Eventos	Registro e rastreamento de ocorrências operacionais
TopOff	Controle de abastecimento integrado ao planejamento

Consulta virou gestão. GPS, tripulação, carga, rotas e câmeras — integrados em uma plataforma única.

O resultado

6 módulos funcionais entregues em 5 meses de desenvolvimento ativo — cobrindo do cadastro de frota ao monitoramento em tempo real com câmeras ao vivo.

10 meses de projeto no total, 5 de desenvolvimento ativo. A plataforma cobre toda a operação da LHG entre Brasil, Paraguai e Uruguai.

Um sistema que a operação finalmente usa — porque foi construído a partir de como ela realmente funciona, não de como o sistema anterior imaginava que deveria funcionar.

Locaweb

Rick Benetti — Sat, 01 Jul 2023 00:00:00 +0000

translationKey: case-locaweb

O cenário

Locaweb é a líder de hospedagem digital do Brasil, com 350+ mil clientes ativos. Em maio de 2022 entrei como Product Designer no squad do painel de hospedagem — o produto onde o cliente gerencia domínios, e-mails, DNS, banco de dados e instalação de aplicativos.

Conhecia a operação como ex-cliente e concorrente — o que virou vantagem na pesquisa.

O problema

O painel era defasado. Mas o problema real ia além do visual: era operacional e linguístico.

O cliente não conseguia resolver sozinho configurações críticas — principalmente DNS — e o termo “meu site” usado em toda a interface causava confusão profunda sobre o que era a hospedagem em si.

35% das chamadas ao call center eram sobre essas duas dores: DNS e dúvidas sobre o status do produto.

Como reorganizar um painel de 350 mil clientes — quando o problema estava além da tela, estava também na linguagem do produto?

A abordagem

01 · Benchmark e dados

2,5 meses ouvindo o mercado e o suporte. Benchmark com painéis externos de hospedagem e SaaS. Em paralelo, categorização dos chamados do call center para mapear padrões.

O que vinha de fora orientava a referência. O que vinha de dentro definia o gargalo real.

02 · A descoberta terminológica

No meio da construção da arquitetura de informação, o padrão ficou claro: a palavra “meu site” confundia o cliente. Não era nomenclatura — era a raiz da operação travada.

Hospedagem ≠ Site.

Convencer a empresa a trocar o termo foi parte do trabalho.

03 · Validação e jornadas

Testes de usabilidade validaram a troca terminológica: “Hospedagem” deu clareza imediata onde “site” falhava.

Redesenhamos 15+ jornadas e estruturamos material que alimentou desenvolvimento por 2 anos.

Quando você muda a palavra que o cliente lê, muda também o problema que ele acha que tem.

O mapeamento

O painel foi reorganizado por tarefa do cliente — não por estrutura técnica da Locaweb.

Mudança	O que foi feito
Terminologia	“Meu site” → “Hospedagem” em toda a interface
Estrutura	Cards orientados por tarefa: instalar WordPress, gerenciar domínios, configurar e-mails
Design System	Cabeçalho com domínio em destaque replicado em Cloud, E-mail e Servidor Dedicado

O sistema saiu do painel e virou linguagem comum entre produtos. O que começou no squad acabou pertencendo à empresa.

O resultado

35% → 0% nas chamadas ao call center sobre DNS e status de produto — entre dezembro de 2022 e fevereiro de 2023.

O painel foi lançado em dezembro de 2022. Em três meses, o call center registrou a queda completa nas duas dores que respondiam por 35% do volume de suporte.

O que ficou além da métrica

Material para 2 anos — jornadas, arquitetura de informação e regras de decisão alimentaram o desenvolvimento da Locaweb por 2 anos depois do lançamento.

Respiro operacional — com o call center liberado da fila de DNS, a empresa pôde planejar melhorias de self-service que estavam em backlog há anos.

Sistema replicado — cabeçalho, ícones e padrões visuais foram adotados em Cloud, E-mail e Servidor Dedicado — virou linguagem comum entre produtos da Locaweb.

Não foi só sobre zerar chamados. Foi sobre devolver à operação o tempo que ela perdia explicando o produto.

Serasa

Rick Benetti — Thu, 01 Apr 2021 00:00:00 +0000

translationKey: case-serasa

O cenário

Serasa é o maior bureau de crédito do Brasil. Em 2020, o produto exibia um marketplace de cartões de parceiros como gatilho contextual no dashboard logado — na Home, em Saúde Financeira e em Meu CPF.

O modelo era genérico: o mesmo card para qualquer perfil, sem personalização por comportamento, score ou momento da navegação.

O problema

O CTR raramente passava de 4% ao dia — apesar de ciclos anteriores de iteração técnica que tinham subido a régua de OKR de 4% para 6%, depois para 12%.

A meta trimestral existia. O caminho técnico para atingir, não. O time não tinha cluster, não tinha gatilho condicional, não tinha método de teste rápido. Cada nova feature dependia de release longo, sem como validar antes.

Como destravar o CTR de oferta de cartão em ambiente regulado, depois de ciclos técnicos terem travado em 4%?

A abordagem

O time tinha tecnologia. Faltava método de descoberta — e isso só veio com a pesquisa antes da tela.

01 · Investigação prévia

Desk research em Hotjar, PowerPoints históricos e Reclame Aqui. Entrevistas com 4 papéis-chave — PO, PM, Diretor de Cartão de Crédito e Data Analyst. O que foi tentado, por que não escalou, o que os dados revelavam que ninguém estava olhando.

02 · Os gatilhos contextuais

O gatilho genérico falhava porque ignorava contexto. Mapeei 4 variáveis condicionais:

Tempo decorrido na navegação
Cluster do usuário
Limite disponível por cluster
Ausência de cartão atual

03 · Arquitetura de informação do card

5 elementos no novo card — cada um testável e mensurável separadamente:

Nome do cartão
Logo do parceiro
Termômetro de chance de aprovação
Indicação de zero anuidade
CTA contextual

O mapeamento

O novo card foi modelado para responder em 3 contextos do dashboard logado — cada um com lógica condicional própria, testada antes do release.

Contexto	Posição	Gatilho
Home	Abaixo do card de receita	Cluster + ausência de cartão
Saúde Financeira	Abaixo do status do score	Cluster + score Bom/Excelente
Meu CPF	Abaixo do histórico de pagamentos	Consulta recente + cluster

Cada gatilho responde a um contexto específico — não é o mesmo card mostrado três vezes.

O resultado

CTR de 4% → 22-26% em ciclos sucessivos de OKR — multiplicando o resultado em mais de 5x onde ciclos técnicos anteriores tinham travado.

Os testes condicionais ainda em 2020 levaram a média para 14% diários. Em janeiro de 2021, com a nova arquitetura lançada, o CTR estabilizou em 22% na média semanal e 26% no pico.

A meta original era 12%. Chegamos a mais do dobro.

Não foi sobre dobrar uma meta. Foi sobre destravar uma curva que tinha parado de subir.

Cooperguincho

Rick Benetti — Tue, 01 Jan 2008 00:00:00 +0000

translationKey: case-cooperguincho

O cenário

Em 2006, um amigo abriu a Cooperguincho em São Paulo. Atendia pessoas que não tinham seguro de carro — porque seguro era caro demais.

Começou com 3 motoristas próximos, comunicação por SMS, e-mail e telefone. Sem app, sem CRM, sem plano de retenção. Cada acionamento era uma transação avulsa.

O problema

O negócio funcionava — mas era refém da emergência.

O cliente só lembrava do guincho quando o carro quebrava, gerando um ticket baixo, com frequência imprevisível, sem retenção. Cada motorista parado era prejuízo. Cada cliente atendido sumia até a próxima quebra.

Como transformar uma operação que só existe na emergência em um serviço com receita previsível?

A abordagem

01 · A reclamação consistente

10 entrevistas, 1 padrão claro.

Seguro é caro pela idade. Guincho avulso é caro toda vez. Duas pistas surgiram: km rodado mais barato ou guincho parcelado.

02 · A hipótese que caiu por terra

Desenhamos a jornada e o modelo desmoronou: parcelar 2 acionamentos por ano não resolvia o desespero do cliente nem sustentava o caixa.

03 · A inspiração que destravou

Olhando como rastreadores veiculares operavam, encontramos o modelo: pacote de vantagens por mensalidade fixa.

Cobertura previsível para o cliente. Receita previsível para a operação.

Teste e modelagem

Antes da régua final, um piloto: testamos a hipótese de assinatura com 5 pessoas a R$29,90/mês — o limite que o caixa suportava sem quebrar.

O modelo funcionou: cobertura básica em São Paulo, regras claras, retenção real.

A régua que estruturou a operação em 2008

Plano	Preço	Cobertura
Básico	R$49,90/mês	Até 150 km em SP · 1 uso de guincho/ano
Intermediário	R$89,90/mês	Tudo do Básico + chaveiro + prestador
Premium	R$129,90/mês	Até 300 km · cidade + região metropolitana

1 uso/ano não era limitação — era o que sustentava o modelo. 10 meses de mensalidade diluíam o custo de cada serviço.

O resultado

50+ clientes fixos em 3 meses.

O caixa virou previsível. Cada novo cliente diluía o custo operacional sem aumentar proporcionalmente a estrutura.

Com o crescimento, a próxima fronteira ficou clara: a qualidade do atendimento dos guincheiros e a precisão das informações trocadas com o cliente viraram o novo gargalo. O modelo de receita estava resolvido. O modelo de experiência era o próximo capítulo.

O próximo nível: 250 clientes

Ao desenhar o modelo, mapeamos o ponto de inflexão futuro: aos 250 clientes fixos, a operação teria escala para fechar parceria com fornecedores de rastreador veicular — incluindo o serviço como benefício adicional por custo marginal.

O serviço continuaria evoluindo de oferta avulsa para plataforma de proteção do carro.

translationKey: case-cooperguincho

Era Service Design completo: pesquisa, modelagem, validação, escala e roadmap.

Em 2008, antes de o termo circular no Brasil.