Tudo começou com uma conversa rápida. Meu gestor chegou e disse: “Precisamos de um acompanhamento semanal do estoque de propostas por superintendência. Dá pra fazer?”.

Até então, essa tarefa não era feita de forma consistente. Não porque fosse difícil no papel, mas porque executá-la manualmente para 11 superintendências era inviável.

O que acontecia na prática? Não acontecia. A rotina era tão pesada que o acompanhamento era feito esporadicamente, quando sobrava tempo. E quando era feito, os erros eram constantes: gráfico trocado, valor da meta errado, destinatário incorreto. A informação chegava errada ou simplesmente não chegava.

A demanda foi deixada de lado por meses. Até que meu gestor reativou o assunto e perguntou se eu conseguiria automatizar. Eu disse que sim.

Eu sabia que o maior risco não era técnico, era de aderência. O código precisava entregar exatamente o que o analista faria manualmente, senão ninguém confiaria.

1. Entendendo a lógica de negócio

A primeira semana foi só conversa. Entendi como os analistas calculavam o "mês limite do estoque" — a lógica usava percentuais cumulativos sobre a meta anual. Mas tinha uma pegadinha: o valor contratado no ano também entrava na conta. Se eu somasse errado, a projeção mensal ficava distorcida.

# Lógica validada com o time de negócios
def estoque(super, meta):
    credito = sum(base_credito[super])   # estoque atual
    contratado = sum(base_contratacao[super])  # valor já contratado no ano
    total = credito + contratado
    
    for i, perc in enumerate(percentuais):
        if total/meta <= perc:
            return meses[i]  # mês correspondente

2. O desafio dos gráficos

Gerar gráfico no Python é fácil. Inserir no Excel, na aba certa, com a cor da empresa, protegido e com o título correto... essa foi a parte mais demorada.

Usei openpyxl para criar chartsheets, mas descobri que o gráfico só aceitava referências de uma aba de dados. Solução: criar abas auxiliares e ocultá-las como "veryHidden", protegendo o workbook com senha. O usuário final nem vê, mas o gráfico funciona perfeitamente.

3. O e-mail que não podia falhar

O corpo do e-mail era um HTML gigante, com placeholders espalhados: nome do interlocutor, meta, valores calculados, projeção de meses, ticket médio, quantidade de propostas necessárias...

No começo, eu substituía tudo com .replace(). Funcionava, mas era frágil. Reestruturei para usar funções específicas de formatação e centralizei a lógica de cada cálculo. Hoje, se a regra de negócio mudar, eu altero um único ponto do código.

A primeira versão rodou. Os gráficos saíram. Os e-mails foram enviados.

E veio o retorno: “O título do gráfico está repetido”, “A cor da barra não é a da empresa”, “O valor do ticket médio está em reais, mas deveria estar em milhares”.

Foram semanas de ajustes finos. Corrigi formatação, padronizei cabeçalhos, inseri tratamento para bases vazias, normalizei datas e criei funções de limpeza para evitar erros.

No final, o código ficou robusto o suficiente para rodar sem supervisão. Hoje, o processo que antes era ignorado agora entra na caixa de entrada dos superintendentes toda semana, sem falhas, com 5 minutos de execução.

Projeto em produção desde então. O código é executado semanalmente e qualquer ajuste na regra de negócio é implementado em horas, não dias.

Picos de faturamento: abril (R$ 1,06M) e dezembro (R$ 1,02M).

A lição: Meses como Janeiro (48,75%) e Fevereiro (48,44%) vendem menos, mas tem uma ótima margem de lucro.

Criei uma coluna no Power BI que compara cada produto com a média geral de faturamento e margem. O resultado é uma classificação em 4 grupos, que me permitiu enxergar o problema principal.

A base é muito saudável: o risco de depender de um único grande cliente é baixíssimo.

Top 10 clientes < 1% do faturamento total.

Mas os melhores clientes (Diamante/Ouro) mostraram um problema. Eles gastam 27% do seu dinheiro nos produtos de baixa performance (os de baixa margem). Ou seja, eles estão acostumados a comprar o que é mais famoso, mas não o que é mais rentável para a confeitaria.

O lucro de R$ 2,45 Mi é a diferença entre o faturamento (R$ 8,49 Mi) e o custo total (R$ 6,03 Mi). A folha de pagamento não é a vilã. O problema real é o custo dos produtos, especialmente o custo dos itens de baixa performance.

• 15 produtos "Vermelhos" drenando quase 1/4 do faturamento total.
• Alta dependência dos picos de Abril e Dezembro. E se um deles der errado?
• Clientes Diamantes comprando os produtos errados (os "Vermelhos"). É um hábito que precisa ser mudado.

Este projeto nasceu da necessidade de tornar a disciplina diária mais engajante. Aplicando conceitos de gameficação com Python, criei um sistema onde cada atividade produtiva rende XP, conquistas desbloqueiam recompensas, e faltas geram penalidades.

Uma cliente trabalhava em uma empresa que oferecia cursos de segurança do trabalho. No final de cada curso, os alunos faziam uma prova e quem tirava nota acima de 7 recebia um certificado validado pelo ClickSign.

Em um projeto crítico no setor de Agronegócio do Banco do Nordeste, foi identificada a necessidade de enriquecer a base de clientes com informações de contato atualizadas, incluindo DDD, telefone/celular e uma flag indicando disponibilidade no WhatsApp para comunicação.

Os dados eram obtidos através de uma consulta SQL complexa que cruzava múltiplas tabelas do sistema bancário, porém inconsistências estruturais comprometiam a qualidade da informação.

• Identificador Incompatível: O código do cliente retornado pelo SQL possuía um dígito adicional, impossibilitando o relacionamento direto com a base principal de clientes.
• Duplicidade Maciça: A base de telefones apresentava repetição excessiva, com alguns clientes possuindo o mesmo número registrado milhares de vezes em diferentes datas.
• Distorção de Métricas: A junção direta das tabelas geraria multiplicação indevida de valores financeiros, comprometendo a precisão dos relatórios executivos.

O processo garantiu que cada cliente permanecesse representado por uma única linha no modelo final, preservando a integridade dos dados e evitando inconsistências nos indicadores financeiros. A solução foi implementada em produção e atende diariamente mais de 500 usuários da área de Agronegócio.

Todo analista de dados já recebeu uma base com esses problemas: datas em formatos diferentes, valores como texto, cidades sem padronização e IDs duplicados. Resolver manualmente consome horas, mas com Python, a solução leva 2 minutos.

A equipe de análise gastava 8 horas semanais coletando, tratando e consolidando dados de 5 fontes diferentes (Excel, CSV, API, Banco de Dados, PDF) para gerar relatórios de performance.

O processo era propenso a erros humanos, inconsistências nos dados e atrasos na entrega para a diretoria.