SLA e Performance
Voce nao melhora o que nao mede. O Levy Service rastreia aderencia ao SLA, MTTR (mean time to resolve), utilizacao do tecnico e custo por veiculo para que voce identifique os padroes que movem as metricas.
Como SLAs sao calculados
Toda task recebe um timestamp sla_due_at no momento de criacao. A conta e:
sla_due_at = created_at + DEFAULT_SLA_SECONDS[priority]
SLAs default por priority (em segundos):
| Priority | SLA default |
|---|---|
critical | 4 horas (14400s) |
high | 24 horas (86400s) |
medium | 72 horas (259200s) |
low | 7 dias (604800s) |
Esses defaults vivem em src/lib/tasks/sla.ts como DEFAULT_SLA_SECONDS. Sobrescreva por regra setando sla_seconds na linha da regra.
O cron de deteccao de breach
O cron /api/cron/task-sla-check roda a cada 15 minutos. Para cada task aberta onde sla_due_at < NOW():
- Escreve uma linha em
task_sla_breachesse ainda nao houver - Seta
tasks.sla_breached_at = NOW() - Push-notify o assignee e o
ops_manager - Slack-webhook do breach se uma webhook URL estiver configurada
- (Fase 4) Auto-escalacao para vendor se a regra mandar
Uma task so pode entrar em breach uma vez. A linha de breach e o registro de audit.
Lendo a pagina de analytics
A pagina de analytics em /dashboard/tasks/analytics tem tres superficies principais:
MTTR no tempo
Um grafico de linha mostrando mean time to resolve, quebrado por task type, dos ultimos 90 dias. A linha de meta e o limite do SLA. Se sua linha esta sempre abaixo do limite, seus SLAs estao frouxos demais. Se esta sempre acima, seu time esta sobrecarregado ou seus SLAs apertados demais.
Vem de GET /api/tasks/analytics/mttr.
Leaderboard de tecnicos
Uma tabela ordenavel com uma linha por tecnico, mostrando:
- Tasks concluidas (ultimos 90 dias)
- Tempo medio de resolve
- Contagem de breach de SLA
- Custo total (parts + labor)
- Utilizacao (% de horas batidas com task ativa)
Vem da materialized view technician_performance, atualizada todas as noites as 03:30 por /api/cron/refresh-tech-performance. Ou seja, o leaderboard fica ate ~24h atrasado - bom para tendencia, nao para staffing em tempo real.
Heatmap de custo por veiculo
Um heatmap em grid onde cada celula e um veiculo e a intensidade de cor e o custo lifetime de manutencao. Ordene por zona, modelo ou idade do veiculo para achar padroes. Veiculos vermelho escuro sao os limoes que vale aposentar.
Vem de GET /api/tasks/analytics/cost-per-vehicle.
Os KPIs da spec
| Metrica | Meta | Fonte |
|---|---|---|
| MTTR - tasks criticas | < 24h | tasks.closed_at - tasks.created_at onde priority='critical' |
| MTTR - scheduled maintenance | < 72h | mesma |
% veiculos em maintenance a qualquer momento | < 8% da frota ativa | rollup de vehicles.status |
| Utilizacao do tecnico | > 60% das horas batidas com task ativa | task_assignments × logs de turno |
| Tasks concluidas por tecnico-dia | > 6 | tasks group by assignee_id, day |
| % tasks auto-criadas pelo rule engine | > 50% | tasks.created_by_rule_id IS NOT NULL |
| Taxa de breach de SLA | < 5% | contagem task_sla_breaches / contagem tasks |
| % tasks com before+after photos | > 90% | join em task_photos |
Se voce esta acima da meta em mais de duas, fale com seu CSM Levy - normalmente tem um ajuste de config que fecha o gap.
Customizando SLAs por frota
Os SLAs default valem para todas as frotas mas podem ser sobrescritos por subaccount pela pagina Settings -> SLA Config (Fase 5). Ate essa pagina sair, SLAs customizados sao setados editando linhas de regra diretamente:
- Abra a regra em
/dashboard/task-rules/[id] - Defina
sla_secondsno valor desejado - Salve
O novo SLA passa a valer para tasks criadas por essa regra dali em diante, nao retroativamente.
Fadiga de notificacao
Se voce tiver 50 tasks criticas em breach ao mesmo tempo (foi um dia ruim), Expo Push agrupa as notificacoes em um digest em vez de fazer spam de 50 pushes individuais. O limite e 5 breaches em 10 minutos - acima disso, voce recebe um push que diz "12 breaches de SLA nos ultimos 10 minutos, toque para ver".
Notificacoes de Slack nao sao agrupadas; cada breach e um webhook separado. Se isso ficar barulhento, configure action_config.notify_slack: false nas regras de baixa priority.
Diagnosticando MTTR lento
Tres causas comuns quando o MTTR sobe:
- Falta de tecnico - utilizacao acima de 80%. Contrate ou terceirize.
- Triagem ruim - tasks demais como
criticalquando deveriam sermedium. Ajuste as priorities das regras. - Tasks
blockedtravadas - tecnicos tocando em Block e ninguem desbloqueando. Filtre o Kanban porblockeddiariamente.
A meta que mais importa
MTTR para tasks criticas abaixo de 24 horas. Toda outra metrica flui dessa. Se voce acerta ela, sua frota esta saudavel.