Criar um App Web para Rastrear Expirações de Contratos de Fornecedores

O que um rastreador de expiração de contratos deve resolver

Um rastreador de expiração de contratos existe para evitar momentos de “isso nos pegou de surpresa”: renovações inesperadas, janelas de aviso perdidas e correria de última hora porque o PDF do acordo está na caixa de entrada de alguém.

Os problemas que ele deve eliminar

A maioria das equipes esbarra nos mesmos modos de falha:

• Renovações e prazos de aviso perdidos: Muitos contratos exigem cancelamento 30–90 dias antes da renovação. Se essa data passa, você fica preso.
• Cláusulas de renovação automática: Acordos são renovados silenciosamente por outro período, às vezes com aumento de preço.
• Arquivos espalhados e termos pouco claros: A versão assinada é difícil de localizar, emendas estão armazenadas em outro lugar e ninguém tem certeza de quais datas são vinculantes.

Quem realmente usa (e por quê)

Um rastreador útil dá suporte a papéis diferentes sem forçar todos a virarem especialistas em contratos:

• Procurement precisa visibilidade de renovações para negociar cedo e gerenciar gastos com fornecedores.
• Jurídico precisa acesso ao acordo executado mais recente, cláusulas-chave e emendas.
• Financeiro precisa de previsibilidade e confirmação dos termos de pagamento.
• Donos de área (TI, Marketing, RH, etc.) precisam de lembretes e contexto para decidir: renovar, renegociar ou cancelar.

Resultados a serem buscados

Quando o rastreador funciona, ele gera:

• Menos surpresas (sem renovações silenciosas).
• Melhor timing para negociação (inicie discussões antes dos prazos de aviso).
• Propriedade clara (cada contrato tem uma pessoa responsável e um backup).

Métricas de sucesso desde o primeiro dia

Escolha sinais mensuráveis que mostrem adoção e confiabilidade:

• % de contratos com dono atribuído (e departamento).
• Taxa de entrega de lembretes (enviados vs. bounce/falha) em email e Slack.
• Decisões de renovação no prazo (decisões registradas antes da data de aviso).
• % de contratos com datas-chave preenchidas (data de término, prazo de aviso, período de renovação).

Se seu MVP resolver consistentemente isso, você evitará os erros de contrato mais caros antes de adicionar recursos avançados.

Escopo do MVP e checklist de recursos

Um MVP de rastreador de expiração de contratos deve responder instantaneamente a uma pergunta: “O que está vencendo em breve, quem é o dono e o que acontece depois?” Mantenha a v1 pequena o suficiente para lançar rápido e depois expanda com base no uso real.

Se quiser avançar rápido sem construir uma stack personalizada completa no dia 1, uma plataforma de prototipagem como Koder.ai pode ajudar a prototipar as telas principais e o fluxo de lembretes a partir de uma especificação por chat — produzindo código-fonte exportável quando estiver pronto para operacionalizar.

Recursos essenciais do MVP (obrigatórios)

• Lista de contratos com nome do fornecedor, nome/ID do contrato, data de início, data de expiração e status (Ativo/Expirado).
• Campo de responsável (pessoa responsável), mais um responsável backup para cobertura.
• Agendamento de lembretes ligado à data de expiração (ex.: 90/60/30/7 dias), com indicador claro do “próximo lembrete”.
• Busca e filtros básicos: fornecedor, responsável, “vencendo em X dias” e status.
• Página de detalhe simples do contrato: datas-chave, tipo de renovação (automática/manual), notas e link para o documento anexado.

Recursos desejáveis (adicionar após v1)

• Marcação de cláusulas e metadados estruturados (ex.: “rescisão”, “aumento de preço”, “tratamento de dados”).
• Assinatura eletrônica e links de origem (DocuSign/Dropbox/Drive) para que equipes acessem o fluxo original.
• Scorecards de fornecedor (risco de renovação, notas de desempenho) para suportar decisões de renovação.

Explicitamente fora do escopo da v1

Para evitar que o projeto vire um sistema completo de lifecycle de contratos, mantenha fora da v1:

• Workflows multi-etapa de aprovação e revisão jurídica
• Ferramentas de redline para negociação
• Gestão complexa de obrigações (entregáveis, SLAs) além de notas simples

Histórias de usuário simples por papel

Dono do contrato: “Consigo ver meus contratos que vencem em breve e receber lembretes com antecedência suficiente para negociar.”

Procurement/Admin: “Consigo adicionar/editar contratos e atribuir responsáveis para que nada fique sem dono.”

Financeiro/Liderança (somente leitura): “Consigo ver renovações próximas para prever gastos e evitar renovações automáticas surpresa.”

Se você entregar essas histórias com telas limpas e lembretes confiáveis, tem um MVP sólido.

Modelo de dados: Fornecedores, Contratos, Termos e Datas

Um rastreador de contratos vence ou falha pelos dados que captura. Se o modelo for raso, lembretes ficam pouco confiáveis. Se for muito complexo, as pessoas param de inserir informações. Mire num “registro central + alguns campos estruturados” que cubra 90% dos casos.

As entidades centrais

Fornecedor é a empresa que você paga. Armazene o básico que será pesquisado e reportado: nome legal, nome de exibição, tipo de fornecedor (software, facilities, agência) e um ID interno se houver.

Contrato é o acordo que você rastreia. Um fornecedor pode ter vários contratos (ex.: licenciamento e suporte), então mantenha Contrato como um registro separado vinculado ao Fornecedor.

Propriedade e contatos

Todo contrato precisa de um responsável pelo contrato claro (quem decide sobre renovação), mais um responsável backup para férias e turnover. Trate esses campos como obrigatórios.

Também capture contatos-chave:

• Nome/email do representante do fornecedor
• Stakeholders internos (opcional)

Termos e as datas que importam

A maioria dos apps armazena “início” e “término” e depois se pergunta por que as renovações são perdidas. Registre várias datas explicitamente:

• Data de início (quando o período começa)
• Data de término (quando o serviço para, salvo renovação)
• Prazo de aviso (último dia para dar aviso de não renovação)
• Data de renovação/próxima vigência (quando o próximo período começa)

Renovação automática e regras mês a mês

Adicione alguns campos estruturados para cobrir padrões comuns de renovação:

• Tipo de renovação: prazo fixo, renovação automática, mês a mês
• Período de renovação: ex.: 12 meses, 1 mês
• Renovação automática ativada: sim/não

Para mês a mês, a “data de término” pode ser desconhecida. Nesse caso, gere lembretes a partir das regras de prazo de aviso (ex.: “notificar 30 dias antes do próximo ciclo de cobrança”).

Regras de status e ciclo de vida para cada contrato

Status são mais que rótulos — são a lógica que dirige contagens do dashboard, cronogramas de lembretes e relatórios. Defina-os cedo, mantenha simples e consistentes entre todos os acordos.

Status principais (mutuamente exclusivos)

Um conjunto prático para um MVP:

• Ativo: Contrato em vigor e não dentro da janela de “vencendo em breve”.
• Vence em breve: Contrato ainda ativo, mas ação de renovação se aproxima.
• Renovado: Novo período foi executado (frequentemente ligado a um novo registro de contrato ou nova versão/termo).
• Rescindido: Contrato terminou antes ou foi encerrado por aviso antes da data natural.
• Arquivado: Registro histórico que não deve mais gerar lembretes (tipicamente após renovação ou muito tempo após rescisão).

Defina “Vence em breve” com limites claros

Escolha janelas fixas para que todos entendam o que “em breve” significa. Opções comuns são 30/60/90 dias antes da data efetiva de término. Torne o limite configurável por organização (ou por tipo de contrato) para adaptar ao ritmo de procurement.

Também decida o que acontece se a data de término mudar: o status deve ser recalculado automaticamente para evitar bandeiras “Vence em breve” obsoletas.

Códigos de motivo para relatórios limpos

Quando um contrato passa para Rescindido ou Arquivado, exija um código de motivo como:

• Cancelado
• Substituído (substituído por outro acordo)
• Fusão do fornecedor (contraparte alterada)
• Não renovado

Esses motivos facilitam relatórios trimestrais e análises de risco de fornecedores.

Registre cada mudança de status (auditável)

Trate status como campo auditável. Registre quem mudou, quando e o que mudou (antigo status → novo status, código de motivo e nota opcional). Isso suporta responsabilidade e explica por que lembretes pararam ou uma renovação foi perdida.

Motor de lembretes e design de notificações

Um rastreador de contratos só é útil se as pessoas agirem a partir dos lembretes. O objetivo não é “mais notificações” — é nudges acionáveis e em tempo certo que combinem com o modo de trabalho da equipe.

Escolha de canais (comece simples)

Comece com email como canal padrão: é universal, fácil de auditar e não requer trabalho administrativo extra. Quando o fluxo estiver estável, adicione entrega opcional por Slack/Teams para times que vivem em chat.

Mantenha preferências de canal por usuário (ou por departamento) para que Finance permaneça no email enquanto Procurement use chat.

Cronograma de lembretes que previne surpresas

Use uma cadência previsível ligada à data de término:

• 90 / 60 / 30 / 7 dias antes da expiração

Adicione também uma classe separada de alerta para o prazo de aviso (por exemplo, “é necessário dar aviso com 45 dias de antecedência”). Trate isso como prioridade maior que a data de expiração, pois perder esse prazo pode prender você a outro período.

Torne os lembretes acionáveis: confirmar e adiar

Cada notificação deve incluir duas ações com um clique:

• Acknowledge: “Vi isso e estou cuidando.” Isso interrompe pings repetidos para aquele passo.
• Snooze: adiar por um pequeno período controlado (ex.: 3 dias, 1 semana) para reduzir ruído sem perder responsabilidade.

Registre ações na trilha de auditoria (quem confirmou, quando e qualquer comentário) para que os follow-ups sejam claros.

Escalonamento quando nada acontece

Se o responsável não confirmar após uma janela definida (ex.: 3 dias úteis), envie uma escalada para um gestor ou responsável backup. Escalações devem ser limitadas e explícitas: “Ainda sem resposta; confirme propriedade ou reatribua.”

Controle de ruído e confiabilidade

Desduplique lembretes (sem repetições para o mesmo contrato/data), respeite horários silenciosos e tente novamente em caso de falhas. Mesmo um ótimo design falha se mensagens chegarem atrasadas ou repetidas.

Fluxo de UX: Dashboard, Busca e Páginas de Detalhe de Contrato

Um rastreador de contratos vence ou falha pela velocidade: alguém consegue encontrar o acordo certo, confirmar a data de renovação e atualizá-la em menos de um minuto? Projete o UX em torno das ações mais frequentes — checar o que vem a seguir, buscar e fazer pequenas alterações.

Páginas principais a incluir

Dashboard deve responder a uma pergunta: “O que precisa de atenção em breve?” Liderar com Renovações Próximas (próximos 30/60/90 dias) e um pequeno conjunto de KPIs (ex.: vence neste mês, renovação automática em breve, documentos faltando). Forneça duas vistas primárias:

• Vista em tabela para varredura e ações em massa (ordenar por expiração, responsável, fornecedor)
• Vista em calendário (“calendário de renovações”) para planejamento e check-ins recorrentes

Detalhe do Contrato é a “fonte única da verdade.” Coloque o essencial no topo: fornecedor, status, data de expiração, termos de renovação, responsável e configurações de notificação. Itens complementares abaixo: notas, tags, documentos vinculados e contatos relacionados.

Detalhe do Fornecedor agrega tudo vinculado a um fornecedor: contratos ativos, históricos, contatos-chave e padrões de renovação. É onde os usuários respondem “O que mais compramos deles?”

Configurações deve ser enxuto: padrões de notificação, papéis, conexões Slack/email e tags/statuses padrão.

Busca, filtros e vistas salvas

Faça a busca sempre disponível. Suporte filtros por fornecedor, responsável, status, intervalo de datas e tag. Adicione “filtros rápidos” no dashboard (ex.: “Renovação automática em 14 dias”, “Falta responsável”, “Rascunho”). Se os usuários repetirem os mesmos filtros, permita vistas salvas como “Minhas renovações” ou “Aprovações Financeiras”.

Projete para atualizações rápidas

A maioria das edições é pequena. Use edição inline para data de expiração, responsável e status diretamente na tabela e no topo da página de detalhe do contrato. Confirme mudanças com feedback sutil e mantenha uma opção “Desfazer” para edições acidentais.

Mantenha a navegação consistente: dashboard → resultados da busca → detalhe do contrato, com caminho de retorno claro e filtros persistentes para que usuários não percam contexto.

Armazenamento de documentos e controle de versões

Um rastreador de contratos não está completo sem a papelada. Armazenar documentos ao lado das datas-chave evita momentos de “não encontramos a cópia assinada” quando a renovação chega.

O que fazer upload (e por quê)

Comece com o mínimo que as pessoas realmente procuram:

• PDF do acordo assinado (fonte da verdade)
• Emendas e aditivos (frequentemente alteram preço, duração ou prazos de aviso)
• Emails/cartas de renovação ou rescisão (prova de aviso e timing)

Mantenha uploads opcionais no MVP, mas torne o estado “documento faltando” óbvio na página de detalhe do contrato.

Abordagem de armazenamento: object storage + links no banco

Para a maioria das equipes, a configuração mais simples e confiável é:

• Armazenar arquivos em object storage (ex.: compatível com S3)
• Salvar apenas metadados no banco: URL/chave do arquivo, nome original, tamanho, content-type, checksum, uploaded_by, uploaded_at e a qual contrato/versão pertence

Isso mantém o banco leve e rápido, enquanto o object storage lida com PDFs grandes com eficiência.

Versionamento: última vs. versões anteriores

Trate documentos como registros imutáveis. Em vez de “substituir” um PDF, faça upload de uma nova versão e marque-a como a mais recente.

Um modelo prático é:

• document_group (ex.: “Acordo Principal”)
• document_version (v1, v2, v3…)

Na página do contrato, mostre a versão mais recente por padrão, com um histórico curto de versões anteriores (quem fez upload, quando e uma nota como “Atualizada cláusula de renovação”).

Permissões para download, substituir e excluir

O acesso a documentos deve seguir controle baseado em papéis:

• Viewers: apenas download
• Editors: fazer upload de novas versões (e opcionalmente adicionar notas)
• Admins: gerenciar permissões; deletar apenas se realmente necessário

Se permitir exclusão, considere “soft delete” (ocultar da UI, manter no storage) e sempre registrar ações no log de auditoria. Para mais controles, vincule isso à sua seção /security-and-audit.

Segurança, permissões e logs de auditoria

Dados de contratos não são só datas — incluem preços, termos negociados e acordos assinados. Trate segurança como recurso central do seu app, mesmo no MVP.

Papéis e níveis de permissão

Comece com um conjunto pequeno de papéis que mapeiem responsabilidades reais:

• Admin: gerencia usuários, papéis, configurações globais e integrações.
• Editor: pode criar/atualizar fornecedores/contratos, enviar arquivos e gerenciar lembretes.
• Viewer: acesso somente leitura (útil para stakeholders que só precisam do calendário de renovações).
• Legal-only: pode ver campos jurídicos e documentos, mas não campos financeiros.
• Finance-only: pode ver preços, termos de cobrança e custos de renovação, mas não notas jurídicas internas.

Mantenha papéis simples e adicione exceções via regras no nível de registro.

Acesso no nível de registro (quem pode ver o quê)

Defina regras por fornecedor e herde para todos os contratos relacionados. Padrões comuns:

• Fornecedor visível para Todos os funcionários, Equipes específicas ou Usuários nomeados.
• Um contrato pode opcionalmente sobrescrever a visibilidade do fornecedor (para acordos especialmente sensíveis).
• Restrinja downloads de documentos a usuários que podem ver o contrato e tenham permissão de “Download files”.

Isso evita exposição acidental e ainda suporta rastreamento de contratos entre equipes.

Autenticação: SSO ou email + MFA

Se a organização tem um provedor de identidade, habilite SSO (SAML/OIDC) para que o acesso esteja ligado ao vínculo empregatício. Caso contrário, use email/senha com MFA (TOTP ou passkeys) e aplique controles de sessão fortes (timeouts, revogação de dispositivos).

Logs de auditoria que você realmente usará

Registre ações relevantes durante revisões e disputas:

• Download, upload e exclusão de arquivos
• Edições de contrato (valor antigo → novo), especialmente datas de renovação e termos de auto-renovação
• Alterações de permissões e papéis

Torne entradas de auditoria pesquisáveis por fornecedor/contrato e exportáveis para conformidade. Essa “trilha de auditoria para contratos” transforma confiança em evidência.

Importação de contratos existentes e integrações

Um rastreador só é útil quando contém seus acordos reais. Planeje dois caminhos: uma importação rápida “coloque lá dentro” para as pessoas começarem a usar, e integrações mais profundas que reduzam trabalho manual com o tempo.

Começo rápido: importação CSV

Uma importação CSV manual é a maneira mais simples de carregar contratos existentes de planilhas ou drives compartilhados. Mantenha a primeira versão tolerante e focada em campos que geram lembretes:

• Nome do fornecedor (e opcionalmente ID do fornecedor)
• Nome/tipo do contrato
• Data de início, data de término/expiração, flag de renovação automática
• Janela de aviso (ex.: 30/60/90 dias)
• Responsável (pessoa ou time)

Inclua um template para download e uma etapa de “mapeamento” para que usuários associem suas colunas aos seus campos. Forneça também uma pré-visualização que destaque erros antes de salvar.

Limpeza de dados que você deve esperar

Importações expõem dados bagunçados. Construa um pequeno fluxo de limpeza para que o primeiro upload não vire um ticket de suporte:

• Fornecedores duplicados: “Acme Inc.” vs “ACME” vs “Acme, LLC.” Ofereça sugestões de merge e uma forma de escolher um registro existente durante a importação.
• Formatos de data inconsistentes: 01/02/2026 pode significar coisas diferentes. Detecte formatos, peça confirmação e mostre o resultado parseado.
• Falta de responsáveis ou datas: Permita que a importação prossiga, mas sinalize linhas incompletas e envie para uma fila “Needs review”.

Integrações opcionais (reduzem re-digitacão)

Depois que o básico funcionar, integrações podem manter fornecedores e datas atualizados:

• Google Workspace / Microsoft 365 contacts: puxe contatos de fornecedores para preencher “Account manager”, email de cobrança e telefone.
• Sincronização de calendário: opcionalmente crie eventos para datas de expiração e prazo de aviso para que equipes vejam renovações em seus fluxos existentes.

Sincronização com sistema de fornecedores (ERP/procurement)

Se a empresa já tem um ERP ou ferramenta de procurement, trate-o como fonte de verdade para registros de fornecedor. Uma sincronização leve pode importar fornecedores e IDs diariamente, enquanto datas específicas de contrato permanecem no seu app. Documente a regra de precedência em conflitos e mostre um “Last synced” claro para ganhar confiança.

Se for adicionar automação depois, linke-a da área de admin (por ex., /settings/integrations) em vez de escondê-la atrás de processos apenas para engenharia.

Lógica de backend para agendamento e confiabilidade

Um rastreador de contratos parece “simples” até que lembretes não disparem, disparem duas vezes ou no horário local errado. Seu backend precisa de uma camada de agendamento confiável, previsível, depurável e segura para reexecução.

Jobs em background para lembretes e escalonamentos

Use uma fila de jobs (ex.: Sidekiq/Celery/BullMQ) em vez de rodar lógica de lembretes dentro de requisições web. Dois padrões de jobs funcionam bem:

• Job agendador diário: roda a cada hora (ou uma vez por dia) e enfileira jobs de lembrete que vencem em breve.
• Jobs de lembrete por contrato: um job por contrato por janela de lembrete (ex.: 90/60/30/7/1 dias) mais jobs de escalonamento se nenhuma ação for registrada.

Escalonamentos devem ser explícitos: “notificar responsável”, depois “notificar gestor”, depois “notificar finance”, com delays entre cada passo para não spammar todo mundo.

Fusos horários e dias úteis

Armazene todos os timestamps em UTC, mas calcule “datas de vencimento” no fuso horário do responsável pelo contrato (ou o padrão da organização). Ex.: “30 dias antes da expiração às 9:00 AM horário local.”

Se suportar prazos em dias úteis, evite lógica feita à mão. Ou:

• Use uma biblioteca de calendário de negócios, ou
• Mantenha uma pequena tabela “calendário da empresa” (fins de semana + feriados) e mova lembretes para o dia útil anterior.

Deixe a regra visível em logs e na página do contrato para que usuários entendam por que um lembrete chegou numa sexta em vez de no fim de semana.

Idempotência: evitar notificações duplicadas

Retries são normais (hiccups de rede, timeouts do provedor de email). Projete o envio de notificações para ser idempotente:

• Crie um registro notification_outbox com uma chave única como contract_id + reminder_type + scheduled_for_date + channel.
• Coloque uma restrição única nessa chave.
• Envie apenas se o insert for bem-sucedido; se já existir, saia com segurança.

Isso garante “no máximo uma vez” a partir do seu app mesmo se jobs rodarem duas vezes.

Templates de mensagem com variáveis

Centralize templates para que usuários de negócio ajustem texto sem código. Suporte variáveis como:

• {{vendor_name}}
• {{contract_title}}
• {{expiration_date}}
• {{days_remaining}}
• {{contract_url}} (link relativo como /contracts/123)

Renderize templates no servidor, salve o texto final renderizado na outbox para auditoria/depuração e envie por email e Slack com o mesmo payload subjacente.

Testes, piloto e checklist de go-live

Testes são onde rastreadores de contratos normalmente falham silenciosamente: uma regra de data com erro de um dia, uma cláusula de auto-renovação mal interpretada ou notificações enviadas mas não entregues. Trate o motor de lembretes como lógica de cobrança — alto impacto, baixa tolerância a surpresas.

O que testar (e como)

Comece com testes automatizados em torno da sua “verdade do contrato”, não só polimento de UI.

• Regras de data: datas de término, interpretação de “válido até”, fusos e lógica inclusiva/exclusiva (ex.: um contrato é válido até 2026-03-31 23:59?).
• Prazos de aviso: teste datas calculadas para janelas de 30/60/90 dias, incluindo fim de semana/feriado se suportado.
• Lógica de auto-renovação: verifique termos de renovação (ex.: “renova por um ano salvo cancelamento 45 dias antes”) e confirme que o próximo ciclo é calculado corretamente.

Adicione um pequeno conjunto de fixtures (contratos realistas) e escreva testes que afirmem o cronograma exato de lembretes para cada um.

Checagens de confiabilidade de notificação

Teste entregabilidade de email em staging com caixas reais (Gmail, Outlook) e verifique:

• SPF/DKIM/DMARC (ou equivalente do provedor)
• Tratamento de bounces e supressão
• Comportamento de unsubscribe/opt-out para alertas não críticos

Se suportar Slack, valide limites de taxa, permissões de canal e o que acontece quando um canal é arquivado.

Piloto: pequeno, real e mensurável

Execute um piloto com um grupo pequeno (procurement + finance é ideal) usando contratos reais. Defina métricas de sucesso: “Nenhuma renovação perdida”, “<5% lembretes incorretos” e “Todos os contratos pesquisáveis em <10s”. Colete feedback semanal e corrija lacunas de regra antes de escalar.

Se você estiver construindo a primeira versão com Koder.ai, um piloto é o momento certo para usar snapshots/rollback e iterar com segurança na lógica de lembretes e regras de permissão sem impactar toda a equipe.

Checklist de prontidão para go-live

Antes do lançamento, confirme:

• Papéis de admin e acessos corretos para cada time
• Teste de backup/restore realizado
• Jobs de lembrete rodando no horário e monitorados
• Caminho de suporte definido (quem triageia imports falhos ou datas erradas)
• Guia interno curto publicado (ex.: /blog/contract-tracker-playbook)

Analytics, relatórios e manutenção contínua

Um rastreador de contratos compensa quando ajuda pessoas a agir cedo — não apenas armazenar acordos. Isso significa relatórios claros, métricas de engajamento leves e um plano simples para manter os dados confiáveis ao longo do tempo.

Relatórios práticos que as pessoas realmente usam

Comece com algumas vistas “sempre ativas” que respondam perguntas comuns:

• Renovações próximas por mês: um calendário de renovações mostrando quantos contratos vencem nos próximos 30/60/90 dias, agrupados por mês.
• Por responsável: quem é responsável por quê, para gestores reequilibrarem carga antes dos prazos.
• Por fornecedor: veja todos os contratos ligados a um fornecedor (incluindo diferentes departamentos) para identificar oportunidades de consolidação.

Se oferecer exports, mantenha simples: CSV para planilhas e um link filtrado compartilhável no app (ex.: /reports/renewals?range=90&group=owner).

Sinais de engajamento: confirmações e avisos perdidos

Para evitar “nunca vimos o lembrete”, acompanhe alguns eventos:

• Acknowledgements: quando um destinatário clica em “Acknowledge” (ou marca “Em progresso”).
• Renovações atrasadas: contratos que passaram da data de decisão sem resultado registrado.
• Avisos perdidos: lembretes que falharam na entrega (bounce, erro Slack) ou nunca foram confirmados.

Isso não precisa ser punitivo. O objetivo é clareza operacional: ver onde follow-ups são necessários e se as configurações de notificação funcionam.

Melhorias contínuas a planejar

Quando o MVP estiver estável, os próximos upgrades que adicionam valor real são:

• Tags (ex.: “renewal-automatic”, “revisão de segurança necessária”) para filtragem e relatórios mais rápidos.
• Templates para termos padrão e cronogramas de lembrete.
• Aprovações de fluxo de trabalho para decisões de renovar/encerrar (leve: solicitante → aprovador → decisão registrada).

Processos de suporte que mantêm dados limpos

Escreva runbooks simples e linke-os em uma página interna como /help/admin:

• Correções de dados: quem pode editar datas-chave e como documentar por que mudaram.
• Solicitações de acesso: como conceder papéis e frequência de revisão de permissões.
• Backups e restores: frequência de backups, onde ficam e como testar restores periodicamente.

Com esses básicos, o app permanece útil após o lançamento — e os relatórios viram uma fonte confiável para planejamento de renovações.