Resumo
Plataforma analítica demonstrativa que transforma um conjunto sintético de tickets em indicadores de SLA, backlog, MTTR, riscos e causa raiz.
Case de projeto
- Projeto demonstrativo
- Dados sintéticos
- Sem integração com ITSM real
Support SLA Intelligence Hub
BI operacional para SLA, backlog e incidentes.
Código-fonte privadoAs evidências técnicas verificáveis estão documentadas neste case.
Visão geral
Problema
Operações de suporte podem enfrentar dados dispersos, pouca visibilidade sobre violações de SLA e dificuldade para priorizar tickets críticos.
Meu papel
Definição dos indicadores, modelagem do cenário, desenvolvimento da interface, implementação das visualizações e documentação técnica.
- tickets com SLA em horário útil
- 780
- Página inicial publicada / cálculo sobre 780 tickets sintéticos / 13 out. 2026
- SLA cumprido
- 29,0%
- Página inicial publicada / cálculo sobre 780 tickets sintéticos / 13 out. 2026
- Tickets no backlog
- 90
- Página inicial publicada / cálculo sobre 780 tickets sintéticos / 13 out. 2026
- MTTR médio
- 16h 44m
- Página inicial publicada / cálculo sobre 780 tickets sintéticos / 13 out. 2026
Dados e premissas
Os 780 tickets são sintéticos, determinísticos e não contêm dados pessoais reais. O seed pode persistir os mesmos registros em PostgreSQL sem alterar sua natureza simulada; não há integração ativa com uma plataforma ITSM.
- Volume
- 780 tickets sintéticos
- Granularidade
- Um registro por ticket
- Persistência
- Mock local ou seed em PostgreSQL
Estrutura dos dados
Entidades modeladas
- Ticket: protocolo, datas, unidade, região, categoria, causa raiz, técnico, prioridade, impacto, urgência e status.
- SLA: metas de primeira resposta e resolução, tempos calculados e flags de cumprimento.
- Operação: canal, equipe responsável, dependência de fornecedor, reabertura, reatribuição e recorrência.
- Organização: tenant demonstrativo usado para isolar a massa persistida quando o banco está ativo.
Arquitetura da solução
O fluxo mantém dados, contratos, regras e visualização separados para que a fonte demonstrativa possa ser substituída sem reescrever os indicadores ou os componentes.
Dados sintéticos determinísticos
Catálogos, políticas de SLA e o gerador em src/data produzem uma massa reproduzível; o seed pode copiar os mesmos registros para PostgreSQL.
Contrato e acesso aos dados
O tipo Ticket padroniza cada registro, enquanto a camada de repositório seleciona mock ou banco e normaliza ambos para o mesmo contrato.
Transformação e regras
Funções puras em src/lib aplicam filtros, agrupamentos, SLA, backlog, MTTR, recorrência, tendências e score de risco.
Agregação e distribuição
Routers tRPC e Route Handlers reutilizam as mesmas funções para entregar resumos e séries às diferentes visões do produto.
Dashboard executivo e operacional
Componentes Next.js e Recharts organizam KPIs, gráficos, filtros, tabelas e exportações nas visões executiva, operacional, SLA e causa raiz.
Indicadores e regras de negócio
As definições abaixo correspondem às funções e regras documentadas no repositório. Nenhuma fórmula foi adicionada apenas para o portfólio.
| Definição | Unidade | Regra de cálculo | Uso | Limitação |
|---|---|---|---|---|
| SLA cumpridoPercentual de tickets com SLA de resolução aplicável marcado como cumprido. | % | Tickets com resolutionSlaMet = true ÷ tickets com resolutionSlaMet não nulo. | Monitorar conformidade do prazo de resolução no cenário. | A leitura histórica usa as metas e tempos sintéticos; o Analytics v2 oferece uma visão complementar em horário útil. |
| BacklogTickets em status aberto, em atendimento, pendente ou aguardando fornecedor. | Tickets | Contagem dos registros pertencentes aos quatro status abertos. | Avaliar carga pendente e distribuição do aging. | Representa uma fotografia do relógio fixo do conjunto demonstrativo. |
| MTTRTempo médio de resolução dos tickets resolvidos ou fechados. | Minutos ou horas | Média de resolutionTimeMinutes para tickets com resolução registrada. | Comparar eficiência de resolução entre filtros e dimensões. | Os tempos são gerados pelo cenário sintético, não medidos em uma operação real. |
| Tickets em riscoTickets abertos com consumo do prazo de resolução entre 75% e 100%. | Tickets | Minutos decorridos ÷ resolutionSlaMinutes, considerando apenas consumo maior ou igual a 75% e menor que 100%. | Demonstrar priorização preventiva antes da violação. | A regra histórica usa minutos corridos; a camada v2 calcula também risco em horário útil. |
| Severidade operacionalRecorte de tickets críticos pelas prioridades P1 e P2. | Tickets | Contagem de tickets com priority igual a P1 ou P2. | Destacar chamados de maior impacto potencial. | A prioridade é atribuída pelo gerador sintético e não por triagem humana real. |
| ProdutividadePerfil operacional por técnico com tickets abertos, fechados, vencidos, SLA e reatribuições. | Contagens e percentual | Agrupamentos por technician; não existe um score único de produtividade. | Analisar distribuição de carga sem reduzir o desempenho a uma única métrica. | Os técnicos e a distribuição de carga são inteiramente sintéticos. |
| RecorrênciaTicket com ocorrência anterior da mesma unidade, categoria e causa raiz dentro de 30 dias. | % e tickets | Tickets recorrentes na janela ÷ total de tickets filtrados. | Identificar padrões repetidos que merecem investigação de causa raiz. | A regra depende das três dimensões disponíveis e da janela configurada. |
| Causa raizDistribuição de tickets pelo campo consolidado rootCause. | Tickets | Contagem agrupada pelo valor de rootCause. | Localizar concentrações e orientar investigação no cenário. | As causas são categorias sintéticas e não conclusões de uma análise real. |
SLA cumprido
Percentual de tickets com SLA de resolução aplicável marcado como cumprido.
- Unidade
- %
- Regra de cálculo
- Tickets com resolutionSlaMet = true ÷ tickets com resolutionSlaMet não nulo.
- Uso
- Monitorar conformidade do prazo de resolução no cenário.
- Limitação
- A leitura histórica usa as metas e tempos sintéticos; o Analytics v2 oferece uma visão complementar em horário útil.
Backlog
Tickets em status aberto, em atendimento, pendente ou aguardando fornecedor.
- Unidade
- Tickets
- Regra de cálculo
- Contagem dos registros pertencentes aos quatro status abertos.
- Uso
- Avaliar carga pendente e distribuição do aging.
- Limitação
- Representa uma fotografia do relógio fixo do conjunto demonstrativo.
MTTR
Tempo médio de resolução dos tickets resolvidos ou fechados.
- Unidade
- Minutos ou horas
- Regra de cálculo
- Média de resolutionTimeMinutes para tickets com resolução registrada.
- Uso
- Comparar eficiência de resolução entre filtros e dimensões.
- Limitação
- Os tempos são gerados pelo cenário sintético, não medidos em uma operação real.
Tickets em risco
Tickets abertos com consumo do prazo de resolução entre 75% e 100%.
- Unidade
- Tickets
- Regra de cálculo
- Minutos decorridos ÷ resolutionSlaMinutes, considerando apenas consumo maior ou igual a 75% e menor que 100%.
- Uso
- Demonstrar priorização preventiva antes da violação.
- Limitação
- A regra histórica usa minutos corridos; a camada v2 calcula também risco em horário útil.
Severidade operacional
Recorte de tickets críticos pelas prioridades P1 e P2.
- Unidade
- Tickets
- Regra de cálculo
- Contagem de tickets com priority igual a P1 ou P2.
- Uso
- Destacar chamados de maior impacto potencial.
- Limitação
- A prioridade é atribuída pelo gerador sintético e não por triagem humana real.
Produtividade
Perfil operacional por técnico com tickets abertos, fechados, vencidos, SLA e reatribuições.
- Unidade
- Contagens e percentual
- Regra de cálculo
- Agrupamentos por technician; não existe um score único de produtividade.
- Uso
- Analisar distribuição de carga sem reduzir o desempenho a uma única métrica.
- Limitação
- Os técnicos e a distribuição de carga são inteiramente sintéticos.
Recorrência
Ticket com ocorrência anterior da mesma unidade, categoria e causa raiz dentro de 30 dias.
- Unidade
- % e tickets
- Regra de cálculo
- Tickets recorrentes na janela ÷ total de tickets filtrados.
- Uso
- Identificar padrões repetidos que merecem investigação de causa raiz.
- Limitação
- A regra depende das três dimensões disponíveis e da janela configurada.
Causa raiz
Distribuição de tickets pelo campo consolidado rootCause.
- Unidade
- Tickets
- Regra de cálculo
- Contagem agrupada pelo valor de rootCause.
- Uso
- Localizar concentrações e orientar investigação no cenário.
- Limitação
- As causas são categorias sintéticas e não conclusões de uma análise real.
Decisões técnicas
Dados tipados e determinísticos
- Motivo
- Unificar mock, seed e PostgreSQL sob um contrato TypeScript reproduzível.
- Consequência / trade-off
- Mudanças no contrato exigem atualização coordenada de geração, persistência e métricas.
Modelagem dos indicadores operacionais
- Motivo
- Centralizar SLA, backlog, MTTR, recorrência e risco em funções testáveis.
- Consequência / trade-off
- Novas métricas exigem documentação e testes alinhados.
Separação entre dados, cálculos e visualizações
- Motivo
- Reutilizar as mesmas regras em APIs, tRPC e componentes sem acoplá-las à interface.
- Consequência / trade-off
- A arquitetura ganha camadas que precisam manter contratos consistentes.
Outras decisões técnicas
Fonte configurável entre mock e banco
- Motivo
- Manter o modo demonstrativo independente e permitir persistência com Prisma.
- Consequência / trade-off
- A origem técnica e a natureza sintética dos registros precisam permanecer explícitas.
SLA legado e SLA em horário útil
- Motivo
- Preservar KPIs iniciais e oferecer uma leitura de segunda a sexta, das 08h às 18h.
- Consequência / trade-off
- As duas leituras não devem ser comparadas sem identificar qual calendário foi utilizado.
Visões analíticas separadas
- Motivo
- Separar visão executiva, fila operacional, SLA e causa raiz.
- Consequência / trade-off
- A navegação ganha clareza, mas exige consistência de filtros e métricas entre rotas.
Recharts isolado em componentes cliente
- Motivo
- Usar gráficos interativos mantendo regras e acesso a dados fora da camada visual.
- Consequência / trade-off
- As visualizações adicionam JavaScript ao cliente e precisam de fallbacks textuais e tabelas.
Evidências técnicas
Aplicação, endpoints e contratos confirmados são apresentados conforme seu nível real de acesso.
Aplicação pública
Aplicação publicada
Deploy funcional na Vercel com landing page, dashboards, APIs e massa demonstrativa.
Abrir evidênciaEndpoint público
API de saúde
Endpoint público para verificar o estado do serviço e da fonte configurada.
Abrir evidênciaEndpoint público
API de métricas
Endpoint público com os agregados da base atual do app publicado. Ela muda com o uso, então os números não coincidem com o recorte de 780 tickets analisado neste case.
Abrir evidênciaCódigo-fonte privado
Código-fonte privado
As evidências técnicas verificáveis estão documentadas neste case.
Referência de código
Contrato tipado dos tickets
Campos, enums e estruturas usados por dados, persistência e visualizações.
Referência de códigosrc/types/ticket.ts
Referências de implementação
Referência de código
README e documentação de execução
Escopo demonstrativo, comandos, stack, dados, arquitetura, limitações e deploy.
Referência de códigoREADME.md
Referência de código
Fonte dos dados sintéticos
Gerador determinístico e seed que reproduzem os 780 tickets demonstrativos.
Referência de códigosrc/data/tickets.ts · prisma/seed.ts
Referência de código
Regras dos indicadores
Funções de SLA, backlog, MTTR, agrupamentos, recorrência e risco.
Referência de códigosrc/lib/metrics.ts · src/lib/analytics-v2.ts
Referência de código
Componentes de indicadores e gráficos
Composição do dashboard, cards de KPI, gráficos Recharts, filtros e tabela operacional.
Referência de códigosrc/components/dashboard/dashboard-client.tsx · kpi-card.tsx · chart-card.tsx
Referência de código
Documentação de KPIs
Definições, fórmulas, calendários, faixas de risco e limitações das métricas.
Referência de códigodocs/kpi-rules.md · docs/analytics-v2.md
Indicadores do cenário demonstrativo
- Dados simulados
- 29,0%
- SLA de resolução
- SLA de resolução na regra histórica em minutos corridos.
- Dados simulados
- 90
- Backlog aberto
- Tickets em status aberto no conjunto demonstrativo.
- Dados simulados
- 16h 44m
- MTTR médio
- Conversão de 1.004,4 minutos médios de resolução.
Indicadores calculados sobre o conjunto sintético de 780 tickets. Eles não representam resultados obtidos em uma operação real.
Competências demonstradas
- Modelagem de indicadores operacionais.
- Estruturação de dados tipados.
- Cálculo de SLA, backlog e MTTR.
- Visualização de risco e causa raiz.
- Desenvolvimento de produto analítico responsivo.
- Documentação de premissas e limitações.
Limitações e próximos passos
Limitações
- Dados e resultados exclusivamente sintéticos.
- Sem integração ativa com plataforma ITSM.
- Escopo demonstrativo, sem atualização operacional em tempo real; os dashboards exigem login (Clerk), e a página inicial e a API de métricas são públicas.
- A persistência opcional reproduz o seed; não cria dados reais.
Próximas evoluções
- Integração com uma fonte ITSM autorizada.
- Persistência incremental e histórico.
- Autenticação e controle de acesso.
- Alertas configuráveis de risco e SLA.
- Expansão dos testes automatizados.
- Observabilidade e qualidade da fonte.
Galeria
As imagens registram a direção visual do produto. Os valores exibidos nos mockups não substituem os indicadores auditados do seed atual.
Detalhes técnicos opcionais
Como executar
- Acesse o dashboard publicado na Vercel.
- Explore os KPIs executivos, gráficos, heatmap, radar e tabela de tickets em risco.
- Use os indicadores para simular uma rotina de priorização de filas, análise de SLA e investigação de causa raiz.
Próximo projeto
Python Automation: Operational Intelligence
Central de automações corporativas que simula limpeza de planilhas, consolidação de arquivos, geração de relatórios, logs operacionais e comparação antes/depois para demonstrar ganhos de eficiência.
Ver case completo