Diana no Portal
Um agente de WhatsApp que passou a ajudar parceiros dentro do portal de cadastro.
O contexto
Ninguém vende antes de terminar o setup
Todo parceiro novo do iFood passa por um portal de ativação. São seis etapas obrigatórias, cerca de 40 minutos de configuração, antes da loja ir ao ar.
- Pagamento · 1 min
- Entrega · 10 min
- Horário · 5 min
- Minha loja · 5 min
- Financeiro · 10 min
- Cardápio · 10 min
- Conclusão
~40 min
de configuração, em 6 etapas obrigatórias
antes da loja ir ao ar
O problema
E, quando travava, ele travava sozinho
Entrevistas e forms recorrentes no produto apontavam falta de suporte durante a ativação: a mesma dor, pesquisa após pesquisa.
O portal oferecia um FAQ estático, no rodapé da tela, sem nenhum canal para tirar dúvida no momento em que ela aparece.
A leitura: o parceiro não desistia por falta de vontade. Ele parava numa dúvida que ninguém estava lá para responder.
17.258
sessões web sem nenhuma ajuda em tempo real
entre janeiro e março de 2026
A oportunidade
A ajuda já existia. Só não estava onde a dúvida acontecia.
A Diana é o agente de onboarding do iFood. Ela já funcionava como canal autônomo de captação e cadastro, e também respondia dúvidas sobre a plataforma.
Tudo isso acontecia só pelo WhatsApp, fora do fluxo de quem estava configurando a loja. Quem estava no portal, no meio do setup, não alcançava nada disso.
Diana · iFood ✓onlineA hipótese
E se a Diana morasse dentro do portal?
Se a inteligência da Diana estivesse dentro do portal, o parceiro resolveria a dúvida sem sair do fluxo e chegaria ao primeiro pedido mais rápido e com mais qualidade.
O obstáculo: pelo roadmap normal levaria meses para entrar na fila de desenvolvimento, e exigiria alinhar a prioridade de dois times. O portal e a Diana são times separados, com backlogs próprios.
A aposta do time
Total Football
Na Vibe Coding Week, o time testou uma ideia: com IA, o mesmo profissional atua em mais de uma área sem perder a profundidade da sua especialidade. Designer entra em código, engenharia entra em design.
Para mim não era experimento novo. Eu já vinha subindo código no produto, adequando componentes ao design system e ajustando conteúdo direto na interface. A semana só abriu espaço para ir mais longe.
Antes de construir, entender a arquitetura com quem a construiu
O webchat do portal reaproveita o mesmo endpoint da Diana. Um roteador decide pelo canal: no webchat, a resposta é síncrona e pula os agentes especializados, indo direto para a revisão.
A mudança no core foi de cerca de 15 linhas, retrocompatível e testada. A rota pelo gateway foi feita pela engenharia.
diagrama simplificado, com nomes ilustrativos
Meu processo
- 01 · Figma
Esboço no Figma
Estados, hierarquia e comportamento definidos antes de qualquer linha de código. É aqui que eu decido o que o componente precisa fazer.
- 02 · Claude Code
>criar o webchat a partir do frame do Figma
Read docs/api-contract.md
Write WebChat.tsx
+128Edit ChatLauncher.tsx
+34Edit tokens.css
+12Bash npm run build
✓ sem errosTradução no Claude Code
O esboço vira contexto. O componente nasce dentro dos padrões do repositório, lendo a documentação que o próprio time escreveu.
- 03 · Microinterações?
repousohoveraberto
duração240 msescala1 → 1,07brilho0 → 100%Refino das microinterações
Transição, brilho e resposta ao hover, ajustados iteração a iteração até o gesto parecer natural.
o vídeo do passo 1 é uma gravação real do Figma; os passos 2 e 3 são simulações do processo
Quem fez o quê
- Eu
Front-end, design e microinterações
A interface do webchat e o comportamento de cada estado, codados com Claude Code.
- Outro designer
Back-end
Roteamento por canal e o contrato de API para o time do portal.
- Engenharia
Revisão e a rota no gateway
A camada de gateway, mais delicada, ficou com quem tem a profundidade para isso.
Cinco dias, do zero ao MVP
- Dia 1
Entender
A arquitetura, com os devs que a construíram.
- Dias 2 a 4
Construir
Front e back, e os merge requests abertos.
- Dia 5
MVP rodando
Internamente, já usável.
- Depois
Iterar
Ajustes finos da engenharia.
Tem alguém ali, não um FAQ
A solução começa no gesto: o ícone de dúvida vira a Diana quando o mouse se aproxima. É o convite, antes de qualquer conversa.
Diana consultora,dentro do setup
O ícone de ajuda vira a Diana quando o parceiro passa o mouse.
Quick questions por etapa: no financeiro ela sugere perguntas de financeiro, no cardápio sugere perguntas de cardápio.
A mesma base do WhatsApp, agora com resposta síncrona e adaptada ao portal.
- ResponsivoComo cadastro minha conta?Te explico aqui mesmo.
Do desktop ao celular
O mesmo chat se ajusta à largura da tela, sem uma versão separada pra cada tamanho.
- Design system
- cor
color.brand - textoAa
font.display - espaço
space.scale - raio
radius.card
Tokens, não valores soltos
Cor, texto, espaço e raio vêm do design system do produto, e o componente já nasce no padrão.
- cor
- FluidezFinanceiroCardápioHorárioComo cadastro minha conta?Quando recebo os repasses?
A pergunta certa, na etapa certa
A Diana sugere o que o parceiro provavelmente quer saber agora e responde sem tirá-lo do fluxo.
Resultados · teste A/B, base crescente (30/30 → 50/50) · 26.08 a 21.09
Um setup com mais qualidade leva o parceiro à primeira venda
+1,60 p.p.
Ativado → 1º pedido
51,00% para 52,68%
~100
primeiros pedidos incrementais no período
impacto absoluto
O que mudou foi a qualidade do setup, e isso apareceu na etapa seguinte: mais parceiros chegando à primeira venda.
Portal → 1º pedido: +1,10 p.p. Portal → Ativado: 0,00 p.p. Foram 5.470 parceiros no controle e 5.522 na variante, medidos no painel oficial.
Controle × variante
+1,60 p.p.O que eu tirei disso
- 01
A fronteira ficou invisível, a profundidade não
Consigo construir e subir código. A rota no gateway continua sendo da engenharia, e saber onde eu paro é parte do trabalho.
- 02
Qualidade de código com IA não se garante na revisão
Tiramos as boas práticas da cabeça dos devs e viramos documentação. Quem entrou depois no time herdou o padrão.
- 03
O gargalo migrou
Antes o difícil era construir. Agora é decidir o que vale construir, e isso continua sendo decisão de produto e design.
- 04
Dois times, um atalho
O que destravou não foi só a ferramenta. Foi conseguir provar a hipótese sem disputar a prioridade de dois backlogs.