Plataforma de gestão de demandas internas

Contexto e problema

Em muitas empresas, um pedido de um setor para outro começa numa mensagem solta: um e-mail, um canal do Discord. Não existe um lugar único para registrar, o prazo não fica claro e quem pediu fica sem saber se alguém já assumiu.

A proposta foi um portal único de demandas internas, com gestão visual e comunicação automática entre os setores. Este foi o case técnico do processo seletivo em que fui aprovado.

Minha função

Desenvolvi o sistema de ponta a ponta: a API em Flask, a autenticação e os perfis no Supabase, o Kanban no front-end, os fluxos de notificação no n8n e a publicação no Render.

Solução e arquitetura

1. 01AberturaTítulo, prioridade, setor de destino e prazo
   ↓→
2. 02API FlaskSessão, perfil e regras de permissão
   ↓→
3. 03SupabaseAuth e a tabela de demandas
   ↓→
4. 04Kanban do setorEntrada → andamento → pausado → concluído
   ↓→
5. 05n8nRecebe o evento e manda o e-mail certo

• Perfis e permissões. O login, a sessão e a recuperação de senha usam o Supabase Auth; cada pessoa tem um perfil com setor e nível de acesso. Quem é gestor vê todas as demandas, cria usuários e exclui tickets. Quem é colaborador vê só as do próprio setor, e só o setor de destino pode assumir ou mudar uma demanda. Qualquer um pode registrar uma nota no histórico.
• Kanban com SLA. Cada card mostra quanto do prazo já passou, do momento da abertura até o fim do dia do prazo. A partir de 75% aparece "Atenção", a partir de 90%, "Risco crítico", e depois do prazo, "Atrasado".
• Tempo de atendimento. Assumir, pausar e retomar uma demanda registra o responsável e soma os minutos efetivamente gastos.
• Eventos para o n8n. A API dispara três eventos (novo_ticket, ticket_assumido e ticket_concluido) para um webhook do n8n, que manda os e-mails para quem pediu e para quem atende. O n8n também avisa gestores sobre demandas paradas.
• Relatórios. Um botão exporta em CSV as demandas da tela.
• Deploy. Gunicorn no Render, com as chaves em variáveis de ambiente.

Experimente

Recriação da interface do sistema em Flask, Supabase e n8n. Abra um ticket, arraste os cards, troque de perfil e veja, no painel de automações, o evento que o sistema real enviaria ao n8n.

Demonstração com dados fictícios · sem banco de dados

Carregar a demo

O que é igual ao sistema real e o que é simulado

• Igual: as regras de permissão, o cálculo do SLA, o tempo de atendimento e o formato dos eventos enviados ao n8n.
• Como no sistema original, o evento ticket_assumido sai quando o card é arrastado para Atendendo. Os botões Assumir, Retomar e Pausar do detalhe só controlam o cronômetro e não enviam evento.
• Simulado: os dados são fictícios e ficam só no seu navegador. Nenhum e-mail é enviado; a prévia mostra o que o n8n mandaria.
• Fora da demo: login, recuperação de senha e o banco no Supabase.

Stack

• Back-end: Python com Flask, servido pelo Gunicorn.
• Banco e autenticação: Supabase (PostgreSQL e Auth).
• Automação: n8n, com webhook e envio de e-mail.
• Front-end: HTML, CSS e JavaScript, sem framework.
• Hospedagem: Render.

Decisões e trade-offs

O back-end avisa, o n8n decide

A API só publica o que aconteceu, com os dados do ticket. Quem recebe o aviso, com que texto e por qual canal fica no n8n, e muda sem deploy.

trade-offMais um serviço para manter. Na versão publicada, o webhook apontava para o n8n na minha máquina, então os e-mails foram demonstrados ao vivo, e não a partir do Render.

Envio do evento em segundo plano

O disparo roda numa thread separada, com tempo limite de 5 s. Uma falha na automação nunca trava a criação ou a movimentação de uma demanda.

trade-offSe o n8n estiver fora do ar, o evento se perde: hoje ele só é registrado no log, sem nova tentativa.

Permissões checadas na API

As regras de quem vê e de quem pode mudar cada demanda ficam num lugar só, no back-end, e não dependem da interface.

trade-offO servidor usa a chave de serviço do Supabase, que ignora as regras do banco. Por isso toda rota precisa conferir sessão, setor e perfil antes de agir.

SLA calculado a partir do prazo

Uma barra que muda de cor diz mais rápido o que precisa de atenção do que uma lista de datas.

trade-offO cálculo acontece na tela; o banco guarda o prazo e o tempo gasto, mas não o histórico de quando cada demanda entrou em risco.

Resultado

O sistema foi publicado no Render com o fluxo completo: abertura, Kanban por setor, permissões, SLA, exportação e os avisos por e-mail via n8n. Não há métricas de uso, então não há números aqui.

Aprendizados

• Separar o que aconteceu (o evento) de quem precisa saber (a automação) deixa as duas partes mais simples.
• Uma chave de serviço no back-end é prática, mas transfere toda a responsabilidade de segurança para o código da API.
• Uma integração externa nunca deve conseguir derrubar o fluxo principal.