---
id: financeiros/sla-esteiras-operacionais
industria: Serviços financeiros
uso: muito usado
esforco: médio
grao: Tarefa x responsável (passagem); evento de espera do cliente (mensagens até a primeira resposta); chamado
---

# SLA das esteiras operacionais

Quanto tempo cada análise, cálculo, sinistro e chamado fica em cada mão, quem está com a fila agora e o que estourou o prazo, em horas úteis e sem tratar devolução como atraso.

## Resumo executivo

**Para quem:** Líderes de operação de crédito, sinistro, cálculo, formalização e suporte que respondem por prazo e produtividade do time.

**O que resolve**

- O líder vê a fila de cada analista agora, com o que entrou hoje, o que sobrou e o que está atrasado.
- O prazo é medido em horas úteis do time, com a meta certa para cada tipo de processo e severidade.
- Devolução e reabertura aparecem como retrabalho, separadas do tempo de execução.

**Por que importa:** Em crédito, seguro e BPO a esteira é regulada por documento e checagem, e o prazo de cada etapa é o principal indicador de gestão: define quanto o cliente espera, quanto o time produz e onde contratar. Medido em horas corridas ou só pela média, o painel culpa o analista errado e esconde o caso que está parado há dias. Com a fila e o SLA na mesma régua, o líder age antes do cliente reclamar.

**Perguntas de negócio que responde**

- Quais tarefas do time de cálculo estão pendentes há mais de 2 dias úteis?
- Qual analista está com a maior fila atrasada agora?
- Quantos sinistros estão sem resposta da operação além do prazo?
- Qual o tempo de triagem típico e o pior caso desta semana?
- Qual etapa da esteira concentra o tempo e o retrabalho?
- Quantos chamados cada parceiro abriu este mês e quantos foram resolvidos no prazo?

**O que você precisa**

- A ferramenta da esteira ou de atendimento conectada na Nekt: Zeev, Pipefy, Zendesk, ClickUp ou a base da plataforma
- A lista do time com papel e período de cada pessoa, e as metas de prazo por processo e severidade
- O calendário do time: jornada, feriados locais e dias especiais

**O que você recebe**

- Uma tabela de fila por analista, atualizada ao longo do dia
- Uma tabela de passagens com tempo útil, prazo e status de SLA
- Mediana, p90 e % no prazo por etapa, severidade e semana
- Alertas de prazo e um agente de IA que responde sobre a fila

## Detalhado

### O problema

A ferramenta da esteira guarda cada tarefa com início, fim e responsável, mas não diz quem está sobrecarregado agora nem quanto tempo útil cada etapa levou. Quem subtrai datas em UTC conta noite, fim de semana e feriado como atraso; quem soma a tarefa devolvida pune o analista pelo erro de outra área. Em sinistro e suporte o relógio é a conversa, e sem separar a mensagem do cliente da resposta da operação não há SLA de resposta.

### Regras de negócio

1. **O time é uma tabela, com período e quem tem zero.** Mantenha a lista de membros por id de usuário da ferramenta, com área, papel e data de entrada e saída. A fila parte dessa lista e mostra com zero quem não tem tarefa. Caixas compartilhadas (a agenda do time, por exemplo) aparecem separadas das pessoas. Nunca derive o time só de quem apareceu nas tarefas. (Evite: Lista de e-mails fixa no código, editada à mão a cada contratação.)
2. **Fila de hoje, remanescente e atrasada.** Considere só tarefas ativas. Iniciada hoje (data em America/Sao_Paulo) é fila de hoje; iniciada antes é remanescente; com prazo previsto pela ferramenta (data de término esperada) menor ou igual a agora é atrasada. Conte processos distintos, não linhas: uma tarefa com dois responsáveis aparece duas vezes na fonte. Separe tarefa principal de subtarefa. (Evite: Contar linhas da tabela de tarefas e comparar o prazo com o relógio em UTC.)
3. **Hora útil se calcula dia a dia.** Percorra cada dia entre início e fim e some só o trecho dentro da jornada (por exemplo, 9h às 18h, ou 8h às 18h no atendimento), pulando fim de semana, feriados nacionais, estaduais e municipais e férias coletivas, com meio expediente onde houver. Mover só o início e o fim para dentro do horário comercial e subtrair ainda conta as noites e o fim de semana no meio. (Evite: Ajustar início e fim para o horário comercial e subtrair os dois.)
4. **Uma régua de tempo por indicador.** Zendesk e outras ferramentas trazem tempo útil e tempo corrido para espera, primeira resposta e resolução. Escolha um por indicador e use o mesmo na meta, no percentual e na média. (Evite: % resolvido em 24h pelo tempo corrido e tempo médio pelo tempo útil no mesmo painel.)
5. **Cada passagem pela área é medida à parte.** Tarefas seguidas da mesma área formam uma passagem, aberta por uma tarefa inicializadora da área. Quando o caso sai para outra área e volta, abre outra passagem. Dentro da passagem, cada troca de responsável abre uma sub-passagem, para medir quem fez cada parte. Marque passagens com conferência (double check). Tarefa da área sem inicializadora antes é órfã e não entra no tempo. (Evite: Somar todo o tempo do caso na área e dividir pelo número de casos.)
6. **SLA de resposta começa na mensagem do cliente.** Ordene as mensagens por processo (sinistro, fiança, chamado). Um evento começa na primeira mensagem do cliente depois de uma resposta da operação, e mensagens seguidas do cliente pertencem ao mesmo evento. O evento termina na primeira mensagem da operação depois do início. Sem resposta é um status próprio, não zero. Quem é operação vem do id ou do papel do remetente (analista de sinistro, administrador da corretora), não do nome. (Evite: Medir do início do sinistro até a última mensagem, ou contar cada mensagem do cliente como um SLA.)
7. **A meta depende do processo e da severidade.** Guarde as metas numa tabela: por processo (por exemplo, sinistro 24 horas úteis e demais processos 48) e por severidade do chamado (por exemplo, crítico 60 minutos, alto 4 horas, médio 8, baixo 16). Mude a meta com data de início, para não reclassificar o passado. (Evite: Uma meta única para sinistro, cadastro e dúvida, escrita dentro do código.)
8. **Devolução e reabertura são retrabalho.** Tarefa encerrada com resultado de devolver a solicitação sai do tempo da etapa e entra na taxa de retrabalho da área que recebeu de volta. Chamado reaberto conta como retrabalho do analista que encerrou. Mostre retrabalho por analista e por severidade nos últimos 30 dias. (Evite: Somar a tarefa devolvida no tempo médio de quem a recebeu.)
9. **Mediana e p90, só entre quem passou.** Tempo de etapa tem cauda longa. Mostre mediana e percentil 90 por semana, além da média. O tempo de uma etapa considera só os casos que passaram por ela; caso que não passou não entra como zero. (Evite: Média de todos os casos, com zero para quem não passou pela etapa.)
10. **Backlog só com o que é do cliente.** Tire da fila de suporte as subtarefas internas de desenvolvimento sem empresa, cards de teste e duplicados. Chamado sem empresa ou parceiro preenchido fica na fila, mas vira indicador próprio (% sem empresa), porque esconde volume por cliente. Quando o parceiro vem no nome do campo como "[código] nome", extraia o código para cruzar com o cadastro. (Evite: Contar subtarefas de dev e testes no backlog do suporte.)

### Metas de prazo usadas na prática

Exemplos de metas que operações reais adotaram. Cada uma vai para a tabela de metas com tipo de tempo e vigência.

- **Sinistro: primeira resposta da operação** → 24 horas úteis (`jornada 8h às 18h`)
- **Demais processos da plataforma** → 48 horas úteis (`jornada 8h às 18h`)
- **Chamado crítico (Sev1)** → Primeira resposta em 60 minutos (`sla_resposta_min = 60`)
- **Chamado alto (Sev2)** → Primeira resposta em 4 horas (`sla_resposta_min = 240`)
- **Chamado médio (Sev3)** → Primeira resposta em 8 horas (`sla_resposta_min = 480`)
- **Chamado baixo (Sev4)** → Primeira resposta em 16 horas (`sla_resposta_min = 960`)
- **Chamado de parceiro no Zendesk** → Resolvido em 24 horas (`first_resolution_time_in_minutes`)
- **Tarefa da esteira (Zeev, Pipefy)** → Prazo previsto da própria tarefa (`expectedEndDateTime`)

### Definições

| Métrica | Definição |
|---|---|
| Fila de hoje | processos distintos com tarefa ativa iniciada hoje (America/Sao_Paulo), por analista |
| Fila remanescente | processos distintos com tarefa ativa iniciada antes de hoje, por analista |
| Fila atrasada | processos distintos com tarefa ativa cujo prazo previsto é menor ou igual a agora, por analista |
| Tempo útil da passagem | soma das horas dentro da jornada, nos dias úteis do calendário do time, entre o início da primeira e o fim da última tarefa da passagem, sem tarefas devolvidas |
| Tempo até a primeira resposta | horas úteis entre a primeira mensagem do cliente no evento e a primeira mensagem da operação depois dela |
| % no prazo | eventos ou tarefas concluídos dentro da meta / eventos ou tarefas concluídos no período, por processo, severidade e analista; sem resposta fica fora do denominador e é mostrado à parte |
| Taxa de retrabalho | passagens ou chamados com devolução ou reabertura / passagens ou chamados concluídos nos últimos 30 dias |
| % sem empresa | chamados sem empresa ou parceiro preenchido / chamados abertos no período |

### Armadilhas

- **Lista do time desatualizada.** A lista de e-mails do time vivia no código; quem entrou não aparecia na fila e quem saiu continuava com zero até alguém editar a transformação. Como evitar: Tabela de membros por id de usuário, com data de entrada e saída.
- **Tarefa trocada no meio do ano.** Uma tarefa da esteira foi substituída por outra a partir de julho e a série histórica da etapa caiu a zero de um mês para o outro. Como evitar: De-para de tarefas para etapas com vigência, atualizado junto com o fluxo.
- **Noite contada como atraso.** Um painel ajustava só o início e o fim para o horário comercial e subtraía; um sinistro aberto na sexta à tarde e respondido na segunda cedo parecia ter levado mais de 60 horas. Como evitar: Some as horas úteis dia a dia no calendário do time.
- **Comentário interno como resposta.** O SLA de primeira resposta usava o primeiro comentário do time no ClickUp, que pode ser uma nota interna; o cliente continuava sem retorno. Como evitar: Use a mensagem enviada ao cliente; quando só houver o proxy, declare isso no painel.
- **Data em UTC.** Tarefas iniciadas depois das 21h caíam na fila do dia seguinte, e o prazo previsto era comparado com um agora em outro fuso. Como evitar: Converta tudo para America/Sao_Paulo antes de comparar com hoje e com agora.
- **Erro de outra área na conta do analista.** Tarefas devolvidas por documento faltante entravam no tempo médio de quem recebeu o caso de volta. Como evitar: Devolução fora do tempo da etapa e dentro da taxa de retrabalho.

### Teste de aceitação

- [ ] Todo membro ativo do time aparece na fila, inclusive com zero tarefas.
- [ ] Para 5 tarefas escolhidas ao acaso, o tempo útil calculado bate com a contagem manual no calendário do time (diferença abaixo de 0,1 hora).
- [ ] Fila de hoje + remanescente = processos distintos com tarefa ativa do analista na ferramenta, no mesmo momento.
- [ ] Nenhuma tarefa com resultado de devolução entra no tempo médio da etapa.
- [ ] Todo evento de SLA de resposta tem status: dentro do SLA, fora do SLA ou sem resposta.

### Context document

```text
SLA das esteiras operacionais
- Fuso: America/Sao_Paulo para hoje, agora e todas as datas exibidas.
- Time: use a tabela <tabela_membros> (id de usuário, área, papel, vigência). Analista sem tarefa aparece com zero.
- Fila: só tarefas ativas. Hoje = iniciada hoje; remanescente = iniciada antes; atrasada = prazo previsto <= agora. Conte processos distintos.
- Tempo útil: horas dentro da jornada <início> às <fim>, em dias úteis, sem feriados nacionais e locais, férias coletivas e com meio expediente onde houver.
- SLA de resposta: evento começa na primeira mensagem do cliente depois de uma resposta da operação e termina na primeira resposta da operação. Sem resposta é status próprio.
- Metas: sinistro <24> horas úteis, demais processos <48>; chamados por severidade conforme <tabela_metas>.
- Tarefa com resultado "devolver solicitação" e chamado reaberto são retrabalho, nunca tempo da etapa.
- Para tempos, informe mediana e p90 além da média, só entre os casos que passaram pela etapa.
- Subtarefas internas de dev, testes e duplicados não estão no backlog.
Exceções por cliente:
- <cliente>: a tarefa <nova> substituiu a <antiga> a partir de <data>; as duas mapeiam para a etapa <etapa>.
- <cliente>: quarta-feira de cinzas útil só a partir das 14h; feriado municipal em <data>.
```

### Variações

- **Estoque comercial:** O mesmo raciocínio para pedidos parados: estoque por SDR e consultor, aging médio e follow-up vencido, em dia ou ausente.
- **Chamados por parceiro:** Imobiliária, correspondente ou escritório extraído do campo do chamado, com volume, reabertura e % resolvido no prazo por parceiro.
- **Assertividade da etapa:** Junte ao SLA a taxa de conferência que achou erro (double check) para ver se o time mais rápido também é o mais certo.