Floki Compras
Pesquisa · FoodService · Marketplace · 2023
6 min
Problema
Um modelo funcional, mas impossível de escalar
A Floki Compras foi uma startup que conectou restaurantes a grandes fornecedores. O modelo original era um SaaS assistido: clientes enviavam listas de compras a representantes comerciais, que submetiam os pedidos na plataforma. Então, especialistas da Floki buscavam a melhor cotação cruzando os itens da lista com planilhas dos fornecedores. A cotação da lista era enviada ao cliente, que autorizava a compra via WhatsApp.
O cliente final dificilmente interagia de forma direta com a plataforma, e cada pedido exigia intermediação de representantes e especialistas Floki. Atendíamos com eficiência alguns clientes, mas não seria possível gerar tração e escala com este formato de serviço.
A interface SaaS — construída para representantes, não para o cliente final.
Além de ser um modelo menos comum no mercado (possível detrator de adoção e usabilidade), o fluxo contava com uma grande quantidade de etapas e ciclos, demandando muito do time operacional e prejudicando a agilidade do atendimento.
O fluxo original — três ciclos, todos dependentes de intermediários humanos.
Buscando uma experiência realmente escalável
Minha missão foi redesenhar todo o fluxo, transformando o sistema em um marketplace e assegurando que qualquer usuário pudesse submeter pedidos válidos desde o primeiro acesso à plataforma.
Por sorte, pude contar com exemplos consolidados entre e-commerces e marketplaces, viabilizando a realização de benchmarks ricos em referências e o reaproveitamento de padrões largamente conhecidos pelo público online.
Solução
Nova perspectiva, novos problemas
Na primeira versão dessa transição, os preços passaram a ser exibidos nos cards de produtos, mas a estrutura subjacente não sofrera adaptações. A decisão da empresa se deu pela necessidade em adquirir escala rapidamente, mas ainda não era possível identificar que fornecedor vendia cada produto, os valores mínimos exigidos por fornecedores, entre outros elementos cruciais para fechamento de pedido.
Submeter um pedido válido seguia sendo estruturalmente impossível para usuários comuns, porque as informações necessárias para isso não eram apresentadas.
Versão inicial do marketplace, com adição do preço ao card mas sem adaptação completa do fluxo.
Representantes conseguiam operar neste cenário com alguma eficácia por terem acesso ao que a interface não mostrava: planilhas de produtos de todos os fornecedores, contato direto com os especialistas da Floki e experiência de compra acumulada. Eles eram, na prática, a camada de informação que a plataforma não entregava.
Fluxo Marketplace V1 — Menos ciclos, mas representante e tratamento manual ainda necessários.
Melhoria incremental ainda insuficiente
Esta primeira virada da plataforma reduziu ciclos, descartando por exemplo, a etapa de aprovação pelo WhatsApp, mas os pedidos ainda exigiam intermediação e tratá-los seguia sendo um processo exaustivo. Pedidos válidos eram tratados e enviados aos fornecedores; quando inválidos, retornavam para recomposição entre especialista, representante e cliente.
Um novo catálogo construído para a lógica do B2B
Como o plano previa alterações em quase todas as telas, começamos pelo catálogo, com a intenção de replicar de forma coerente as alterações no decorrer de todo fluxo enquanto acompanhávamos como as etapas seguintes seriam impactadas.
Tornamos parte explícita da interface informações que antes eram invisíveis. Cada card passou a exibir o produto, o preço por unidade de medida (Un, Kg, Lata, etc.) e o fornecedor responsável.
O catálogo com atribuição de fornecedor visível em cada card (nome e logo alterados por questões de privacidade) — a informação que o modelo anterior não entregava.
Para deixar evidentes as restrições de valor mínimo sem poluir a experiência de browsing, adicionamos um bottomsheet ao catálogo, acionado a partir do botão de carrinho. Ele resume o estado dos carrinhos abertos, relacionando o valor acumulado ao valor mínimo de cada fornecedor, e só fica disponível quando o usuário adiciona ao menos um item ao carrinho.
O bottomsheet — restrições operacionais no momento certo, sem poluir o browsing.
Requisitos visíveis e caminho nítido
Para a nova tela de carrinho, passamos a exibir separadamente os itens de cada fornecedor em carrinhos representados por abas, e adicionamos indicativos visuais para facilitar a compreensão sobre os estados de cada um.
valor < mínimo fornecedor: um aviso é exibido, indicando exatamente quanto falta para atingi-lo, junto a um botão que direciona o usuário ao catálogo com filtro aplicado para produtos do respectivo fornecedor, facilitando o preenchimento do carrinho. Além disso, o botão de seguir para o checkout fica desabilitado.
valor >= mínimo fornecedor: Nenhum aviso é exibido e o avanço para o checkout é liberado.
Novo fluxo em interfaces.
Um checkout que respeita as regras de cada fornecedor
O checkout passou a considerar as particularidades de cada fornecedor, fazendo recorte por área de atuação, oferecendo aos clientes apenas opções de entrega dentro da janela praticada pelo fornecedor e apresentando somente os métodos de pagamento aceitos por este.
A ausência destes elementos autorizava o envio de pedidos com pagamento PIX e entrega para quinta-feira pela manhã, por exemplo, quando o fornecedor trabalhava apenas com cartões e fazia entregas segundas, quartas e sextas, exigindo renegociação com o cliente.
Novo checkout, respeitando formas de pagamento e janelas de entrega de cada fornecedor.
Mais oportunidades para melhorias
Durante o projeto, tivemos que nos aproximar do time de operações para entender que problemas eram mais recorrentes na submissão de pedidos válidos e descobrir como acontecia o tratamento destes.
Este contanto nos deu a oportunidade de realizar uma pesquisa utilizando a metodologia shadowing, para entedermos profundamente cada etapa do processo operacional. Como resultado, mapeamos com clareza os processos e encontramos oportunidades para incrementos relevantes a partir de ações do time de tecnologia.
O time discutiu e avaliou que seria possível realizar melhorias no backoffice com pouco esforço e assim, reduzir em aproximadamente 20% o número de etapas do processo de operações, que consistia em troca de tabs contínua, coleta de informações externas e registros em bloco de notas, tornando o trabalho mais simples para o time responsável e reduzindo potencialmente a taxa de erros durante o tratamento de pedidos.
Arquitetura de informação definindo a estrutura de navegação do produto e os limites de acesso por entidade de usuário.
Testes
Duas frentes de pesquisa para mitigar riscos
Na fase final do projeto, realizamos pesquisas para mapear e reduzir nossos riscos com o lançamento:
Entrevistas com donos de restaurantes: para compreender se haviam problemas não mapeados em nossa solução ou outro impeditivo que não as limitações técnicas da plataforma.
Testes de usabilidade com representantes comerciais e usuários comuns: buscando cenários não vislumbrados, erros críticos, problemas de usabilidade e oportunidades de melhoria da experiência.
Um protótipo de alta fidelidade com lógica similar à real
Para os testes de usabilidade remotos, construímos um protótipo no Figma. O progresso da barra de mínimo, as mudanças de cor entre estados válido e inválido, o bloqueio do botão de checkout e os contadores de carrinho funcionavam de forma dinâmica e responsiva às ações do usuário. O objetivo era simular a experiência real da plataforma com precisão suficiente para capturar comportamentos genuínos. Você pode explorar o protótipo clicando aqui.
A lógica por trás do protótipo — condicionais reais calculando progresso, cor e disponibilidade de checkout a cada adição de produto.
O protótipo em uso — barra de progresso, estados de carrinho e bloqueio de checkout funcionando dinamicamente.
Como setup para os testes, utilizamos o Google Meet, com imagens da câmera frontal do facilitador e do usuário, compartilhamento da tela do celular com execução do protótipo e gravação ativada para análises posteriores do time de design.
Aprendendo com os usuários
Durante os testes de usabilidade, não foram encontradas falhas criticas de interação, e a familiaridade com o uso do sistema aconteceu rapidamente. Isso provavelmente se deu pelo aproveitamento de padrões amplamente conhecidos pelo público online. Além disso, observamos que pelo menos 3 usuários tentaram realizar uma ação que, até o momento, não resultava em nada.
Ao abrir o bottomsheet e constatar que o valor mínimo não havia sido atingido, os usuários tentavam clicar na região que contém o nome e logo do fornecedor. Eles verbalizaram que esperavam assim, aplicar um filtro ao catálogo, exibindo apenas itens deste fornecedor para facilitar a construção de um carrinho válido.
Observando este comportamento, analisando as sessões de teste e discutindo posteriormente com o time, decidimos adicionar a funcionalidade à versão de lançamento. Entendemos que "atingir o valor mínimo" era uma ação chave na plataforma, e que uma funcionalidade com pouco investimento técnico (este tipo de filtro já era utilizado no aviso exibido no carrinho) que ajudasse nesse quesito, apresentava valor justificável para priorização.
Filtro de fornecedor adicionado com base nos aprendizados do teste de usabilidade.
Resultado
Redução de demanda operacional, experiência self-service entregue e menos erros
Após o lançamento do projeto, realizamos entrevistas e consultas tanto com representantes comerciais, quanto com donos de restaurantes e especialistas da operação. Em nossas conversas com representantes e proprietários, identificamos um aumento relevante da percepção de qualidade da experiência, e a existência de proprietários que já estavam comprando sozinhos através da plataforma, mesmo sem que houvesse empenho da Floki em divulgar as novas funcionalidades e estimular o uso autônomo do sistema até então.
Em nossas consultas ao time de operações para acompanhamento da entrega, fomos informados de que a taxa de erros operacionais e o tempo para tratamento de pedidos havia caído consideravelmente, principalmente por conta das limitações implementadas na plataforma e nas melhorias feitas no backoffice.
O que eu faria diferente
A etapa intermediária, onde preços foram adicionados sem as adaptações estruturais necessárias, ofereceu uma experiência confusa para os usuários e uma demanda intensa para o time de operações. Uma transformação como essa precisa ser muito bem calculada, levando em conta o possível prejuízo à percepção de produto que uma experiência incompleta e confusa pode causar.
