Toda manhã um Excel novo era criado e alimentado com estoque inicial, pedidos de clientes e projeção de vendas. A saída era a lista do que comprar. Depois alguém digitava o pedido de cada fornecedor no WhatsApp, um por um.
Uma distribuidora de hortifrúti trocou a planilha diária de compras, os pedidos digitados no WhatsApp e as listas impressas de separação por um sistema de armazém que atualiza o estoque do chão, em tempo real, pelo celular.
“O Jestor trouxe um novo nível de eficiência para a nossa operação. Automatizando compras e dando autonomia de dados para cada pessoa do time, passamos a ter dado em tempo real de verdade. O armazém agora é tão orientado a tecnologia quanto o escritório, e o tempo que ia para planilha hoje vai para planejar e melhorar o core do negócio.”

A plataforma de e-commerce continuou como canal de pedido do cliente. O WhatsApp continuou como canal com fornecedor. A projeção de vendas continuou como insumo externo. Os bancos de dados anteriores continuaram e estavam sendo conectados. O sistema fica entre o canal de pedidos e o chão do armazém; não substitui nenhuma das duas pontas.
A Frexco conecta pequenos e médios produtores diretamente a restaurantes e consumidores, operando a própria cadeia do campo até a porta do cliente. Nasceu em 2019 em Piedade, no interior de São Paulo, e, na época deste case, atendia mais de 500 restaurantes e tinha passado de USD 100 mil de receita recorrente mensal, segundo dados que ela mesma publicou. Em setembro de 2025 concluiu uma fusão com a Arado, plataforma mineira do mesmo segmento; o grupo resultante projetava R$ 100 milhões de receita anualizada no fim de 2025.
Hortifrúti é negócio perecível e de giro alto. Compra demais e o excedente vai para o lixo; compra de menos e o pedido do cliente chega incompleto. O modelo da Frexco depende de prever demanda bem o bastante para manter os dois erros pequenos, e a previsão só é tão boa quanto o número de estoque de onde ela parte. Uma caixa que estraga, uma carga devolvida, um palete contado errado: cada um mexe no número sobre o qual a previsão foi construída.
Por isso o gargalo era operacional, não comercial. A empresa já tinha clientes e já tinha como projetar demanda. O que não tinha era um jeito de o chão do armazém contar ao escritório o que aconteceu na hora em que aconteceu. Enquanto não tinha, toda previsão partia de um dado com um dia de idade.
“O Jestor trouxe um novo nível de eficiência para a nossa operação. Automatizando compras e dando autonomia de dados para cada pessoa do time, passamos a ter dado em tempo real de verdade. O armazém agora é tão orientado a tecnologia quanto o escritório, e o tempo que ia para planilha hoje vai para planejar e melhorar o core do negócio.”
Toda manhã um Excel novo era criado e alimentado com estoque inicial, pedidos de clientes e projeção de vendas. A saída era a lista do que comprar. Depois alguém digitava o pedido de cada fornecedor no WhatsApp, um por um.
A equipe de armazém contava no papel e, de tempos em tempos, digitava a contagem num computador na base. Essa etapa existia só para digitalizar o que já tinha sido coletado à mão. Entre uma atualização e outra, o escritório trabalhava com números já vencidos.
A equipe separava contra uma lista de quantidades esperadas e continuava conferindo os pedidos novos para saber se a lista já estava curta.
O padrão por trás das três: o trabalho físico era em tempo real e o dado era em lote. Nada no processo estava quebrado ainda. Mas catálogo crescendo e venda crescendo significavam que a distância entre o que estava no chão e o que estava na planilha ia abrir até algo quebrar.
“O Jestor trouxe eficiência para praticamente cada etapa do processo. Não ter que digitar pedido à mão é uma bênção, e poder fazer tudo pelo celular garante que as coisas só precisam ser feitas uma vez. E é fácil: alguns processos são só marcar um checkbox.”
| O que fazia isso antes | O que faz hoje |
|---|---|
| Um Excel novo por manhã, preenchido à mão com estoque, pedidos e projeção | Lista de compras diária gerada automaticamente a partir de estoque atual, pedidos, projeção de vendas e prazo de entrega de cada fornecedor, ordenada por fornecedor |
| Pedidos a fornecedores digitados um a um no WhatsApp | Mensagem de WhatsApp gerada por fornecedor; cada pedido marcado como Feito e depois Recebido |
| Estimativa de estoque atualizada à mão depois de comprar | Marcar o pedido como Feito cria a estimativa de estoque; marcar como Recebido atualiza o número |
| Digitação periódica no computador da base, a partir de contagem em papel | Cada pessoa do armazém vê o estoque e registra alteração de quantidade pelo celular, com acesso filtrado ao que precisa |
| Contagem de fim de dia para acertar o estoque | Sem sessão de acerto: a quantidade é registrada na hora, então o número está atual |
| Lista de separação impressa, conferida contra pedidos novos | Lista de separação gerada automaticamente e atualizada sempre que a demanda passa da projeção inicial |
| E-mails, mensagens, planilhas e ferramentas de fluxo para compras internas | Um fluxo de solicitação e aprovação para itens internos, com histórico de compras e preços |
O que não foi trocado. A plataforma de e-commerce continuou como canal de pedido do cliente. O WhatsApp continuou como canal com fornecedor. A projeção de vendas continuou como insumo externo. Os bancos de dados anteriores continuaram e estavam sendo conectados. O sistema fica entre o canal de pedidos e o chão do armazém; não substitui nenhuma das duas pontas.
Chegam da plataforma de e-commerce.
Estoque atual, pedidos, projeção de vendas e prazo dos fornecedores são combinados na lista do dia, ordenada por fornecedor.
O comprador revisa a lista e envia a cada fornecedor a mensagem de WhatsApp gerada.
Fora do sistema, no canal que os fornecedores já usam.
Feito cria a estimativa de estoque; Recebido atualiza o número.
Gerada a partir de pedidos e estoque, e atualizada quando a demanda passa da projeção.
A equipe do armazém separa e registra pelo celular, na hora, alteração de quantidade, perda ou devolução.
O estoque atualizado alimenta a lista de compras do dia seguinte.
Os elos difíceis são o 5 e o 7. Sistema nenhum enxerga que a caixa chegou faltando ou que o lote estragou de madrugada; uma pessoa tem que dizer. O desenho aceita isso e faz com que dizer custe o mínimo: um checkbox no celular, no momento em que se percebe, em vez de uma anotação em papel levada a um computador horas depois. Tudo que é automático na cadeia depende de esses dois elos humanos continuarem fáceis.
| Indicador | Resultado | De onde sai |
|---|---|---|
| Preparação da lista de compras | De uma planilha montada à mão todo dia para uma lista gerada automaticamente, ordenada por fornecedor | Case publicado, seções "Antes" e "Depois" |
| Pedido a fornecedor | De pedidos digitados um a um para uma mensagem gerada por fornecedor | Case publicado; descrição da própria equipe |
| Latência do dado de estoque | De atualização periódica no computador da base e contagem de fim de dia para registro no galpão na hora do evento | Case publicado; não existe medição de latência |
| Lista de separação | De lista impressa conferida à mão para lista viva que se atualiza quando a demanda passa da projeção | Case publicado |
| Compras internas | De e-mails, mensagens, planilhas e ferramentas dispersas para um fluxo de solicitação e aprovação com histórico de preço | Relato da gerente de compras no case publicado |
Nenhum número de tempo ou custo é afirmado aqui porque nenhum foi medido. O case publicado descreve o que foi trocado e como, e cita a equipe sobre o efeito. Não reporta horas economizadas, contratações evitadas ou taxa de erro antes e depois. Quem procura esses números deve ler a ausência como informação, não como descuido deste texto.
"Tempo real" quer dizer registrado no momento do evento, por quem viu. Não quer dizer sensor nem detecção automática. O número de estoque é tão atual quanto o último checkbox que alguém marcou no galpão. É uma melhora grande sobre a contagem de fim de dia; não é promessa de latência zero.
Os números de porte não são resultado. 500+ restaurantes e USD 100 mil+ de MRR descrevem o tamanho da operação para a qual o sistema foi construído. Nada na fonte atribui nenhum dos dois ao sistema, e este case também não.
A taxa de perda que a Frexco declarou à imprensa não entra como resultado. Em 2021, o cofundador disse ao Brazil Journal que a perda de produto na Frexco não passava de 2%, contra cerca de 30% na cadeia de hortifrúti. O número é autodeclarado, anterior a este case e não é atribuível ao sistema descrito aqui. Fica registrado na seção de contexto, não na de resultado.
Vale dizer, porque é o que normalmente aparece inflado.
Toda descrição do antes e do depois vem da equipe da Frexco conforme publicado. Nenhum processo foi cronometrado ou observado de forma independente.
O case não reporta custo por pedido, horas por ciclo de compra, pessoas no galpão ou taxa de perda antes e depois. São os números que um comprador mais quer, e não estão aqui.
O case foi publicado em abril de 2022. O porte, o catálogo e os processos da empresa mudaram desde então; em setembro de 2025 ela se fundiu com a Arado. Não sabemos se o sistema descrito aqui roda sem alteração dentro do grupo.
O case original inclui uma citação sobre times de desenvolvimento construindo rápido na plataforma. Hoje o Jestor constrói e mantém o sistema em nome do cliente, então essa fala descreve um modelo que a empresa não vende mais e não é usada como evidência.
Na época do texto, a Frexco estava conectando o sistema aos números de estoque da plataforma de e-commerce e a bancos de dados antigos. O case descreve intenção, não integração pronta.
A contagem de restaurantes e o MRR aparecem no cabeçalho do case sem data de medição. São tratados aqui como "na época do case" e nada mais preciso.
O case original atribui uma citação a um especialista de TI cujo sobrenome impresso não bate com o nome do arquivo da foto. A citação foi omitida por outro motivo (ver acima), e o nome não é usado.
| Indicador | Número | Fonte |
|---|---|---|
| Perda de hortifrúti no Brasil por falha logística, transporte e embalagem | Até 30% da produção | Embrapa, citada por imprensa setorial em janeiro de 2026 |
| Alimentos desperdiçados no Brasil por ano | Cerca de 55,4 milhões de toneladas, cerca de 30% da produção; 10,8 milhões de toneladas nas etapas de pós-colheita, armazenagem e transporte | Pacto Contra a Fome, citado por imprensa setorial em janeiro de 2026 |
| Perda pós-colheita de frutas e hortaliças | Entre 40% e 50% | FAO, citada pela Embrapa em página institucional sem data |
| Perda de frutas e hortaliças entre colheita e varejo, mundo | 25,4% em 2023, contra 23,2% em 2015; o maior índice entre todos os grupos de alimento | FAO, portal de dados do indicador ODS 12.3.1, atualizado em junho de 2026 |
O índice da própria FAO coloca frutas e hortaliças acima de todos os outros grupos e piorando ao longo de oito anos. A razão que a FAO dá é a mesma deste case: perecibilidade alta e exigência de manuseio. Uma distribuidora cujo número de estoque atrasa um dia em relação à realidade compra e separa contra um retrato que o produto perecível já mudou.
Os 10,8 milhões de toneladas do Pacto Contra a Fome caem em pós-colheita, armazenagem e transporte, que é o caminho entre o produtor e a porta do restaurante. Parte dessa perda é física: amassado, calor, tempo. Parte é de informação: comprar mais do que vai vender porque o número que dizia quanto havia já estava errado. O sistema deste case ataca a segunda.
"Entre 40% e 50%" e "um terço de toda a comida" descendem de uma estimativa da FAO de 2011 que a própria organização substituiu por dois índices separados (perda antes do varejo e desperdício do varejo em diante). O número velho continua em material institucional, inclusive de órgãos públicos. Quem monta uma tese sobre perda de alimentos deve usar o índice atual do trecho da cadeia em que opera, não a manchete de 2011.
O processo antigo da Frexco não era mal desenhado. Era uma planilha, um aplicativo de mensagem e uma impressora fazendo um trabalho para o qual não foram feitos, e fazendo bem o bastante até o catálogo crescer. A pergunta que um sistema sob medida precisa responder é o que acontece no ano dois: um app de armazém que ninguém pode mexer vira a nova planilha em três anos, com login.
Um construtor toca cada pedido do começo ao fim, com um sempre em execução.
Um novo fluxo, uma nova automação ou um novo relatório entram pelo mesmo canal, sem virar projeto novo.
Se o que foi construído não está bom, ele é refeito. Revisões ilimitadas dentro da assinatura.
Assento nunca é a régua de cobrança, o que importa quando comprador, equipe de armazém, motorista e escritório tocam a mesma operação.
As pessoas aprendem a usar o app delas como aprendem qualquer app, abrindo. Construir, configurar e manter continua do nosso lado.
Exportação completa a qualquer momento, por CSV e API. Conformidade SOC 2, sem taxa de saída. Dá para pausar em um clique e os sistemas continuam rodando.
As descrições de antes e depois e as citações vêm do case que o Jestor publicou em abril de 2022, escrito a partir de entrevistas com a equipe da Frexco. São o relato da própria equipe e não foram auditadas. Uma citação do case original foi omitida porque descreve um modelo de trabalho que o Jestor não oferece mais.
Contagem de restaurantes e MRR: cabeçalho do case publicado, sem data no texto, tratados como da época da publicação. Fundação em 2019 em Piedade (SP) e fusão com a Arado em setembro de 2025: Exame e Portal Fusões & Aquisições, setembro de 2025. Taxa de perda de 2%: Brazil Journal, maio de 2021, autodeclarada pelo cofundador.
FAO, portal de dados do indicador ODS 12.3.1 (atualizado em junho de 2026). Embrapa e Pacto Contra a Fome, conforme citados por imprensa setorial em janeiro de 2026. Embrapa, página institucional sobre perdas e desperdício, sem data.
Nenhum tempo economizado, custo economizado, headcount, taxa de erro ou taxa de perda é afirmado como resultado, porque nenhum foi medido na fonte. A taxa de perda de 2% aparece apenas como contexto, com sua origem e sua data.