Case 02 · Zurich Seguros · Stefanini

De facelift a plataforma

O pedido era um redesenho visual do sistema de pagamentos a fornecedores. Terminou em quatro produtos que reorganizaram como o dinheiro circula entre fornecedores e times internos.

Meu papel
Product Design, do facelift à plataforma
Escopo
4 produtos, web e mobile
Período
confirmar período
Status
confirmar status atual
Seguros · pagamentos a fornecedores
ZurichZ Plan, Z Cadastro, painel interno e app
Detalhe do dashboard do Zurich Plan.
01O pedido

Começou como uma camada visual nova.

O pedido inicial era um facelift: uma interface nova sobre o sistema que os fornecedores da Zurich já usavam para subir notas fiscais, acompanhar pagamentos e lidar com prazos e validações.

O ponto de partida

Um redesenho de tela, sem mexer no processo por trás dela.

Tela de entrada do Zurich Plan, com login do fornecedor e o botão Quero ser Fornecedor.
A porta de entrada do Zurich Plan. O botão "Quero ser Fornecedor" já apontava para o cadastro, que viraria o segundo produto.
02A tensão

O sistema não sustentava o processo.

Fornecedores tinham dificuldade de uso. A equipe interna operava com pouca visibilidade. Operações críticas dependiam de e-mail e de planilhas paralelas.

Cada fornecedor seguia uma lógica diferente. Cada gestor tinha seu próprio jeito de aprovar. Cada decisão dependia de quem estava disponível para responder um e-mail.

Fornecedor

Sobe nota, acompanha pagamento e liga para a Zurich quando não entende o status.

Operação interna

Gerencia dados, aprova e comunica, com pouca visibilidade do que está pendente.

Gestor

Aprova do desktop. Em reunião ou viagem, o fluxo para e o fornecedor espera.

O conflito

Trocar só a interface deixaria cada decisão dependendo de quem estava disponível para responder um e-mail.

03A investigação

Mapeei as dependências antes de redesenhar as telas.

Revisei os fluxos mais complexos e mapeei as dependências reais entre os módulos. Organizei a jornada de ponta a ponta, do fornecedor ao cadastro, à operação e à aprovação. Nas conversas com os gestores, cada necessidade de negócio virou requisito, e cada requisito virou tela.

Fornecedor Cadastro Operação Aprovação

A jornada que o sistema antigo tratava como telas soltas.

A primeira virada

O sistema misturava visão estratégica com operacional. Separar o que é decisão do que é execução virou o critério para tudo que veio depois.

04A construção

Um produto de cada vez, sobre a mesma base.

A reorganização do fluxo na primeira fase já teve efeito na operação. Isso gerou confiança no cliente e abriu espaço para os produtos seguintes. De facelift, o escopo virou plataforma.

Fase 1 · Z Plan Portal de fornecedores
  • Fluxos que separam decisão de execução
  • Painéis distintos para visão estratégica e operacional
  • O fornecedor resolve sozinho o que antes exigia ligar para a Zurich
Fase 2 · Z Cadastro Cadastro de fornecedores
  • Formulários próprios para 3 tipos de fornecedor
  • Barra de progresso: o fornecedor sabe quanto falta
  • Validação no momento, não três etapas depois
Fase 3 · Painel interno Visão da operação
  • Dados, aprovações e comunicados em um lugar só
  • Quem aprova, quem está esperando, o que está pendente
  • Comunicação direta com o fornecedor
Fase 4 · App para gestores Aprovação no celular
  • Aprovação rápida, fora da mesa
  • O fluxo não para porque o gestor está em reunião
  • Notificação do que precisa de decisão
Como acelerei

Os componentes padronizados no primeiro produto viraram a base dos seguintes. Cada produto novo saiu mais rápido que o anterior.

05As decisões

Cada perfil passou a ver o que importa para o trabalho dele.

As decisões que mais mudaram o produto não foram visuais. Foram sobre quem decide o quê, onde e quando.

O cadastro deixou de ser troca de e-mails
ANTES
E-mailPlanilha longaRespostaCorreção

Cada fornecedor era um caso à parte. Cada nova entrada gerava retrabalho, sem controle nem visibilidade.

DEPOIS
Tipo de fornecedorFormulário próprioValidado na hora

O cadastro virou um fluxo rastreável, com a comunicação dentro do sistema.

Cadastro de fornecedor com uma janela que pede para escolher entre Serviços Administrativos, Sinistros e Sinistros – Livre Escolha antes de começar.
Antes do primeiro campo, o fornecedor escolhe o próprio perfil: serviços administrativos, sinistros ou sinistros de livre escolha. Cada um abre um formulário diferente.
A aprovação saiu da mesa
ANTES
Aguardando gestor

Aprovar dependia do desktop. Quando o gestor estava fora do escritório, o fluxo travava e o fornecedor esperava.

DEPOIS
NotificaçãoAprovado no app

O app avisa o que precisa de decisão, e a operação segue sem esperar o gestor voltar para a mesa.

Duas telas do app da Zurich: dashboard com aprovações e forecast, e a lista de contas a pagar com aprovar e reprovar por fornecedor.
O app do gestor: o resumo do dia e as contas a pagar, com aprovar e reprovar em cada fornecedor.
Estratégico e operacional em lugares diferentes
ANTES

A mesma tela misturava a visão estratégica com a operacional e sobrecarregava o usuário com informação que não era dele.

DEPOIS

Painéis distintos para perfis distintos. Cada um vê a informação na hierarquia certa para o próprio trabalho.

O princípio que ficou

Separar o que é decisão do que é execução. Quando isso fica claro na tela, o processo para de depender de e-mail.

06O momento atual

De facelift a quatro produtos integrados.

Comecei como a designer responsável pelo facelift e terminei responsável por uma plataforma de quatro produtos. Não tenho métrica financeira para mostrar. O sinal que tenho é concreto: o cliente seguiu pedindo novas frentes, porque cada entrega resolveu mais do que o pedido inicial.

4produtos integrados
3perfis de fornecedor no cadastro
Web e mobilefornecedor, operação e gestor
1 basede componentes para todos os produtos
O que fica

Não foi só sobre interface. Foi sobre organizar como o dinheiro circula dentro da operação.