Floki Compras — Marketplace · FoodService · 2023 EM CONSTRUÇÃO
Problema
Um modelo funcional, mas impossível de escalar.
A Floki Compras era uma startup de foodservice B2B que conectava restaurantes a grandes fornecedores. O modelo original era assistido: clientes enviavam listas de compras a representantes comerciais, que submetiam os pedidos na plataforma. Especialistas realizavam a cotação cruzando as listas com planilhas diárias de fornecedores, e o cliente aprovava via WhatsApp antes do envio. Funcionava — mas dependia inteiramente de pessoas em cada etapa. O cliente nunca tocava na plataforma diretamente, e cada pedido exigia intervenção de representantes, especialistas e equipe de operações. Para crescer, a empresa precisava de um caminho diferente.
A interface SaaS — construída para representantes, não para o cliente final.
O fluxo original — três ciclos, todos dependentes de intermediários humanos.
Uma transformação apressada que criou novos problemas.
A decisão de evoluir para marketplace foi tomada antes que a plataforma estivesse pronta. Na primeira tentativa, preços foram inseridos nos cards de produtos e o resultado foi chamado de "versão marketplace" — mas a estrutura subjacente não havia mudado. Os usuários não conseguiam identificar de qual fornecedor cada produto estava sendo comprado, não tinham visibilidade dos valores mínimos de pedido por fornecedor e o sistema não separava itens por fornecedor no carrinho. Submeter um pedido válido de forma independente era estruturalmente impossível — não por falta de vontade, mas porque as informações necessárias para isso simplesmente não estavam na plataforma.
Os representantes conseguiam operar porque tinham acesso privilegiado ao que a interface não mostrava: planilhas diárias de todos os fornecedores, contato direto com os especialistas da Floki, relacionamento com os fornecedores e experiência acumulada de compra. Eles eram, na prática, a camada de informação que a plataforma não entregava.
Minha missão.
Redesenhar o fluxo e a interface para tornar essa camada de informação parte explícita do produto — de forma que qualquer cliente pudesse navegar, montar seu pedido, entender as regras de cada fornecedor e finalizar a compra sem depender de nenhum intermediário. Pesquisa com a equipe de operações revelou oportunidades adicionais no backoffice que também fizeram parte do escopo.
Solução
Da cotação assistida ao self-service: a evolução do fluxo.
O Marketplace V1 reduziu os ciclos do fluxo e removeu a aprovação via WhatsApp — mas o representante comercial ainda submetia os pedidos e o Tratamento do pedido continuava sendo um processo manual e fragmentado entre planilhas, notas e backoffice. O pedido chegava ao especialista, que validava contra as planilhas dos fornecedores: válido seguia para tratamento e envio; inválido retornava para recomposição entre especialista, representante e cliente.
Marketplace V1 — menos ciclos, mas representante e tratamento manual ainda presentes.
No Marketplace V2, dois avanços simultâneos definiram a solução. Na plataforma, clientes passaram a acessar diretamente — o objetivo estratégico era tornar o representante progressivamente dispensável, com restaurantes comprando de forma autônoma como em qualquer marketplace. Na operação, shadowing com os especialistas revelou a fragmentação do Tratamento do pedido; o novo fluxo integrou backoffice e planilhas em um processo mais ágil e preciso.
Arquitetura de informação definindo a estrutura de navegação do produto e os limites de acesso por entidade de usuário.
Um catálogo construído para a lógica do B2B.
A transformação do fluxo exigiu que informações antes invisíveis se tornassem parte explícita da interface. Cada card do catálogo passou a exibir produto, preço por unidade e fornecedor responsável — dados que os representantes acessavam externamente via planilhas e relacionamentos, agora disponíveis diretamente na plataforma para qualquer usuário.
O catálogo com atribuição de fornecedor visível em cada card — a informação que o modelo anterior não entregava.
O bottomsheet: restrições operacionais sem interromper a navegação.
Para expor as restrições de valor mínimo sem poluir a experiência de browsing, foi criado um bottomsheet acionado a partir da barra de carrinho. Ele resume o estado dos carrinhos abertos por fornecedor — valor acumulado e distância do pedido mínimo — aparecendo apenas quando o usuário está ativamente engajado com o carrinho.
Tokens primitivos definindo a paleta bruta — a camada de fundação antes das atribuições semânticas.
O carrinho: restrições visíveis, caminho para resolvê-las.
A tela de carrinhos separa os itens por fornecedor e torna o estado de cada um explícito. Quando o valor mínimo não foi atingido, um aviso em vermelho indica exatamente quanto falta — e um botão retorna o usuário ao catálogo com filtro aplicado automaticamente para aquele fornecedor. Quando o mínimo é atingido, o aviso desaparece e o checkout é liberado. O sistema bloqueia pedidos inválidos estruturalmente, sem depender de validação humana posterior.
Tokens semânticos mapeando valores primitivos para papéis funcionais em toda a interface.
Um checkout respeitando as regras de cada fornecedor.
Com a separação por fornecedor estabelecida, o checkout passou a exibir condições específicas para cada pedido — endereço de entrega, janela de recebimento disponível e métodos de pagamento aceitos por aquele fornecedor. Uma separação impossível no modelo anterior, onde a ausência dessa distinção tornava irrelevante qual método de pagamento o cliente escolhia.
Sistema tipográfico construído com Work Sans — escolhida pela legibilidade e pelo tom profissional adequado a ambientes clínicos.
Marketplace V1 — menos ciclos, mas representante e tratamento manual ainda presentes.
Testes
Duas frentes de pesquisa, métodos distintos.
Com donos de restaurantes conduzi entrevistas qualitativas para entender sua experiência com o processo de compra e o relacionamento com os representantes. Com os especialistas realizei uma sessão de shadowing de um dia completo, onde a fragmentação do Tratamento do pedido ficou evidente como gargalo estrutural e originou a melhoria no backoffice.
Um protótipo de alta fidelidade com lógica real.
Para os testes de usabilidade remotos, construí um protótipo no Figma com variáveis, estados condicionais e lógica calculada — 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.
O que os testes confirmaram e revelaram.
Usuários compreenderam a plataforma e demonstraram satisfação com a experiência. Um comportamento recorrente chamou atenção: ao visualizar o bottomsheet, vários usuários tentaram tocar no nome e logo do fornecedor esperando filtrar o catálogo para mostrar apenas os produtos daquele fornecedor. A interação não existia no protótipo, mas o modelo mental era claro.
A resposta ao comportamento observado.
A interação foi incorporada à versão final: tocar no fornecedor no bottomsheet aplica um filtro ao catálogo, com uma tag removível aparecendo na barra de filtros abaixo das categorias. O que os testes revelaram como expectativa virou funcionalidade — por observação, não por suposição.
Resultado
O que funcionou.
A separação por fornecedor resolveu estruturalmente o que o modelo anterior deixava sem resposta. Com carrinhos independentes, valores mínimos visíveis e checkout específico por fornecedor, o cliente passou a ter acesso direto à informação que antes só existia fora da plataforma — nas planilhas, nos relacionamentos e na experiência dos representantes. Os pedidos chegavam ao backoffice estruturados e válidos, reduzindo drasticamente o trabalho manual da equipe de operações. A melhoria no backoffice, derivada do shadowing, complementou essa redução integrando planilhas e backoffice em um fluxo mais ágil. Pesquisa pós-lançamento confirmou que parte dos clientes passou a acessar a plataforma diretamente — o comportamento que o produto foi desenhado para viabilizar.
O que eu faria diferente.
A etapa intermediária — onde preços foram adicionados sem as adaptações estruturais necessárias — criou uma experiência quebrada que chegou aos usuários antes de estar pronta. Uma transformação desse porte deveria ser validada internamente antes de qualquer exposição ao cliente. O custo de uma experiência incompleta para a percepção do produto é difícil de reverter.
Impacto.
A versão final entregou o que o modelo anterior não conseguia: uma plataforma onde qualquer cliente poderia submeter pedidos válidos de forma independente, sem depender do conhecimento privilegiado dos representantes. Erros de pedido, pagamento e valor mínimo — antes parte do fluxo esperado — tornaram-se eventos raros. O trabalho abriu caminho para a integração futura direta entre plataforma e fornecedores, eliminando completamente a necessidade de intermediação humana no processo de compra.
