iFood · 2022
Handshake: confiabilidade com baixo atrito
O desafio não era criar mais uma etapa no fluxo do entregador. Era garantir que cada pedido chegasse à pessoa certa sem comprometer velocidade, experiência ou escala.
- Meu papel
- Senior Product Designer
Logística Latam - Empresa
- iFood
- Ano
- 2022
Resumo
No iFood, um pedido passa por uma sequência simples: um entregador chega ao restaurante, retira o pedido e segue para a entrega. Mas dois desses momentos não possuíam qualquer mecanismo de validação.
Na chegada ao restaurante, alguns entregadores confirmavam presença antes de realmente chegar, comprometendo métricas importantes da operação. Já na retirada do pedido, não existia uma forma confiável de garantir que o entregador certo retirasse o pedido certo. Sem essa prova, dois problemas conviviam: de um lado fraudes e roubos, de outro trocas de pedido que aconteciam por engano, no aperto da operação.
Como Product Designer da equipe, conduzi a pesquisa, a ideação e a validação de dois novos fluxos da jornada do entregador, criando novos pontos de validação que aumentaram a confiabilidade da operação sem comprometer a experiência de quem entrega.
O problema
O problema tinha escala. Todos os meses, milhares de pedidos eram impactados pela ausência desses mecanismos de validação. Sem uma forma de comprovar quem havia chegado ao restaurante e quem havia retirado cada pedido, a operação perdia confiabilidade. Parte das perdas vinha de fraude, parte vinha de erro honesto na entrega do pedido, e o iFood absorvia integralmente os custos dos pedidos cancelados nos dois casos.
- 9.700 pedidos/mês cancelados por ausência de validação na retirada.
- 886 pedidos/mês associados a roubo de pacotes.
- 0,68% dos pedidos apresentavam trocas na retirada.
- 100% do valor dos pedidos cancelados era absorvido pelo iFood.
Desafio
Criar dois novos pontos de validação na jornada do entregador, garantindo que o entregador certo retirasse o pedido certo, no restaurante certo, sem aumentar o atrito da operação, comprometer a experiência de quem entrega ou impactar indicadores como Contact Rate.
Abordagem
Pessoas antes da tecnologia
Comecei entrevistando entregadores para entender onde a operação realmente falhava. As conversas revelaram duas lacunas importantes: não existia uma forma confiável de validar a chegada ao restaurante nem a retirada do pedido. Eles descreveram tanto esquemas de fraude já conhecidos no campo quanto trocas de pedido que aconteciam por engano, quando várias sacolas parecidas saíam ao mesmo tempo.
Entender a causa antes de discutir soluções
Facilitei sessões de ideação com engenharia e designers dos times de Restaurante e Consumidor. Antes de discutir tecnologia, utilizamos 5 Why's para identificar a causa raiz dos problemas e alinhar uma solução única para toda a jornada.
Validar a hipótese antes de escalar
Antes de desenvolver qualquer solução, precisávamos comprovar que um novo fluxo realmente reduziria tanto a fraude quanto a troca de pedidos, aumentando a confiabilidade da operação. A prioridade era validar o comportamento antes de investir na implementação.
Começar pelo menor risco
Escolhemos iniciar pela validação de chegada ao restaurante, um fluxo com menor potencial de impacto no Contact Rate. Os aprendizados dessa primeira etapa serviram como base para desenhar a validação da retirada do pedido.
Aprender antes de escalar
O primeiro teste rodou em janeiro de 2022, no pico do almoço, em dois restaurantes do McDonald's escolhidos por perfis opostos de operação: o ponto mais movimentado da rede e uma unidade dentro de shopping center. Ali a pergunta era de comportamento, não de métrica: o entregador entendia o fluxo, não o via como etapa extra e reconhecia o valor de impedir que outro entregador levasse o pedido.
Deixar os microtempos provarem a hipótese
O segundo teste, em sete unidades, respondia uma pergunta específica: o que acontece com os microtempos DRE (a caminho do restaurante) e NRE (no restaurante) quando a chegada passa a ser validada? O Contact Rate saltou de cerca de 5% para 12% na ativação e logo se estabilizou — curva de aprendizado, não rejeição. E o NRE caiu quase pela metade (de 5,7 para 2,8 minutos no ponto mais crítico) enquanto o DRE subiu, confirmando o check-in falso e revelando os microtempos reais da operação.
Tratar cada risco antes de escalar
Os testes expuseram riscos operacionais e cada um virou um ajuste no fluxo. Câmera danificada cancelava e realocava o pedido automaticamente, sem o suporte poder corrigir o status: passamos a permitir a mudança automática via ticket, validando a localização pelo geofence. Restaurantes que não trocavam o código ou deixavam o QR fora de vista atrasavam a operação: criamos um guia explicando as vantagens de manter o código visível e atualizado. E grandes redes com múltiplos identificadores por loja ganharam um ID principal definido.
Escalar em ondas
Com os riscos endereçados, o rollout seguiu em ondas: ativação ao longo de um mês em todos os pontos do McDonald's e, na sequência, expansão para os demais pontos de grandes contas (KA). Só então, com o check-in consolidado e as lições absorvidas, partimos para o segundo fluxo da jornada: a validação da retirada do pedido no checkout.
Protótipo navegável
O caminho feliz de ponta a ponta: chegue ao restaurante, escaneie o QR code na parede para o check-in e finalize com o código da nota fiscal no checkout.
User flow do check-in (MVP)
Desenhei o fluxo de validação da chegada do entregador ao restaurante: um caminho principal em três etapas e rotas alternativas para lidar com exceções, priorizando uma abordagem baseada em confiança antes de aplicar qualquer penalização.
Decisões de design
Decisões pensadas para o MVP: validar o valor da solução com o menor investimento possível antes de evoluir para uma versão mais robusta.
- 01
QR code na parede, não no app
Para validar presença física no restaurante, o entregador escaneia um QR code fixado no local. A solução reduz a complexidade tecnológica ao mínimo necessário: uma interação simples, barata e escalável para um problema de milhões de entregas.
- 02
QR codes rotativos
Para evitar que uma foto do código fosse reutilizada em outro momento, cada restaurante possui múltiplos QR codes que alternam conforme a data. Assim, o sistema dificulta tentativas de check-in falso sem adicionar fricção ao entregador.
- 03
Código na nota, não outro QR
A experiência do check-in mostrou que a qualidade e o estado da câmera do celular tornavam a leitura de QR pouco confiável. Por isso o checkout usou um código alfanumérico impresso na própria nota fiscal: o funcionário passa o código, o entregador digita e a validação libera a entrega, sem depender da câmera.
- 04
Erros tratados com confiança
Nem todo erro indica uma tentativa de fraude. Um código desatualizado na loja correta pode ser validado automaticamente após alguns minutos, enquanto tentativas inválidas recebem múltiplas chances antes de qualquer penalização. O fluxo assume boa-fé até que existam sinais reais de abuso.
Resultados
Preparo mais rápido
O McDonald's registrou queda no tempo de preparo já no piloto de 7 pontos
Hipótese confirmada
NRE caiu e DRE subiu, provando o check-in falso e destravando microtempos reais
R$ 260 milhões
Em pedidos mensais protegidos contra fraude de checkout
User flow do checkout (MVP)
O checkout pedia mais controle que o check-in: é no encontro entre entregador e pedido que as perdas de fato acontecem, seja por má-fé, seja por engano. Aqui a validação sai da parede e vai para a nota fiscal: o funcionário do restaurante passa um código alfanumérico de quatro dígitos, o entregador digita para confirmar que está com o pedido certo e o funcionário valida — com a mesma tolerância a erro antes de qualquer bloqueio.
O melhor design nem sempre vive na tela. No Handshake, a interface era um QR code na parede do restaurante e o impacto se media em pedido certo na mão certa.
Próximo projeto
Atelier: quando um Design System deixa de ser biblioteca e vira infraestrutura