A oferta estava na loja e não estava no aplicativo — todo dia
Quem comprava pelo aplicativo de delivery pagava preço cheio num produto que estava em oferta na gôndola. Subir a oferta era manual, ninguém tinha tempo, e então simplesmente não subia.
- 10 a 15 h
- por mês devolvidas a quem montava a lista à mão — 120 a 180 h por ano
- 26 em 125
- linhas erradas na página antiga, medidas às 8h24 de um dia útil qualquer
- 121
- linhas conferidas contra o relatório do sistema de gestão, com zero divergência
DIAGNÓSTICO OPERACIONAL
Como era antes
Todo dia, uma pessoa exportava o relatório de ofertas do sistema de gestão, abria no Excel, arrastava uma fórmula de markup linha por linha, classificava por setor e limpava as duplicidades. Vinte a trinta minutos, todos os dias, sempre pela mesma pessoa.
E havia uma página que mostrava essas ofertas para o parceiro. Ela era um arquivo gerado de manhã e republicado “quando alguém lembrava”. Às 8h24 de um dia útil, medi o que ela estava mostrando: 26 linhas erradas em 125 — sete ofertas que já não valiam, dezoito ofertas vigentes que faltavam, e um preço divergente.
O detalhe que muda a leitura de tudo: na prática, a oferta não chegava ao canal. Subir era manual, não havia tempo, e o cliente do aplicativo pagava preço cheio num produto que estava em oferta na loja ao lado.
ENGENHARIA E ARQUITETURA
O que eu fiz
Duas pontas do mesmo problema.
A lista deixou de ser montada à mão: o sistema lê as ofertas vigentes, aplica a regra de preço do canal e envia o arquivo pronto, no mesmo horário, todo dia. O markup foi conferido nas 121 linhas da primeira rodada contra o relatório original — zero divergência.
E a página virou consulta ao vivo, com cache curto, em vez de arquivo gerado de manhã. A diferença apareceu no próprio dia da virada: às 11h14 ela mostrava três ofertas a mais que o arquivo gerado às 8h29 — três esfihas lançadas no meio da manhã, que a versão antiga só mostraria no dia seguinte.
Uma decisão de projeto que parece pequena e não é: quando a fonte de dados não responde, a página falha visivelmente. Ela não mostra uma lista vazia. Lista vazia o leitor interpreta como “hoje não tem oferta” — e aí o erro vira informação errada em vez de erro.
RESULTADOS MENSURÁVEIS
O que mudou
10 a 15 horas por mês voltaram para quem montava a planilha — 120 a 180 horas por ano. E a lista que chega ao parceiro passou a bater com a loja, no horário em que ele olha.
O que ainda não posso chamar de resultado: o efeito comercial no canal. Três mudanças aconteceram na mesma semana, e separar quanto cada uma trouxe seria invenção. Além disso, esse efeito depende da contrapartida do parceiro, que é dele, não minha. Reportar isso como meu resultado seria o tipo de número que a diretoria desconta na hora — com razão.
DINÂMICA DE OPERAÇÃO
Uma coisa que eu descobri tarde, e você descobriria também
O gargalo não morre, ele muda de lugar. Resolvido o meu lado, são cerca de 136 ofertas por dia — e ninguém digita 136 itens manualmente todos os dias. O limite passou a ser quantas a pessoa do outro lado consegue subir.
E isso é deliberado, não esquecimento: naquele canal, oferta que entra por integração não conta como investimento do lojista. O caminho manual existe por uma razão comercial. Dá para automatizar e perder o benefício, ou manter manual e aceitar o teto. Escolher entre os dois é decisão de negócio, não de engenharia — e essa é exatamente a conversa que um sistema bem-feito devolve para a mesa.
O QUE EU APRENDI
O baseline era zero, e isso mudou a conversa inteira. Eu ia argumentar que o parceiro passaria a destacar mais produtos. O certo era outro: não havia oferta nenhuma no canal. Quando o ponto de partida é zero, você não precisa provar incremento — precisa provar que a coisa existe. E quando o gargalo sai do seu lado, ele não some: migra para o lado de quem digita.
OUTROS PROJETOS DA MESMA DOR