Calculadora de prazo de SLA (dias úteis, fins de semana e feriados públicos)

Quando “três dias” vira discussão

Alguém abre um ticket às 16:59 de quinta. O contrato diz “resposta em até três dias úteis”.
Metade da sala conta a partir de sexta. Outra pessoa começa depois do fim de semana. Um terceiro inclui um feriado nacional que ninguém lembrou de bloquear no calendário.

Ninguém está sendo preguiçoso. O texto simplesmente nunca encontrou um calendário de verdade.

Essa lacuna é o que tínhamos em mente para a calculadora de prazo de SLA - não mais um seletor de data, mas um conjunto de regras compartilhado: escolha o país (e a região se precisar), escolha como sua equipe realmente trabalha e deixe a ferramenta avançar em dias úteis enquanto fins de semana e feriados saem automaticamente.

O que os contratos deixam implícito

A maioria dos SLAs é escrita em dias úteis porque quer medir capacidade, não tempo corrido na parede. O problema é que “dia útil” não diz:

• se o relógio começa no dia do recebimento ou no próximo dia útil
• qual definição de fim de semana vale (sex-dom vs normas regionais)
• qual lista de feriados vale quando as pessoas estão em lugares diferentes
• o que acontece quando o “início” cai em um dia não útil

Até isso estar fixado, toda planilha é uma opinião privada.

O modelo da HolidayDB segue o que documentamos na calculadora: você escolhe uma escala de trabalho (ex.: seg-sex, seg-sáb, dom-qui ou operação sete dias que ainda pula feriados) e onde o trabalho está ancorado para que feriados não sejam adivinhados de memória.

“Dia zero” é onde os times discordam em silêncio

Uma divergência sutil é se a data do pedido conta como o primeiro dia ou como dia zero antes de contar.

Nossa calculadora trata a data de início como dia 0 e avança N dias úteis ao longo de dias válidos. Então um SLA de um dia útil a partir de uma quinta útil costuma cair na sexta, não em “pular quinta e cair na segunda”, a menos que quinta não seja dia útil na sua configuração.

Não é a única convenção por aí, mas é consistente entre a interface da calculadora e o endpoint GET /api/sla-deadline - e isso importa mais do que parece. Quando suporte, jurídico e engenharia leem a mesma saída, vocês gastam menos tempo reconciliando ferramentas.

Região importa mesmo quando o país parece o mesmo

Feriados nacionais são só parte da história. Regras subnacionais - estados, cantões, províncias - podem dividir duas mesas no “mesmo” país em semanas de trabalho diferentes no mesmo intervalo.

Se o SLA está ligado a onde o trabalho é feito ou onde o cliente está, incorpore isso no cálculo desde o início. Caso contrário, você entrega uma política “global” que favorece em silêncio o calendário de um escritório.

Quando copy-paste não basta

A ferramenta na página é para quem precisa de resposta rápida. Quando você precisa das mesmas regras em cobrança, tickets ou checagens de compliance, conecte GET /api/sla-deadline (veja docs: prazo de SLA) com os mesmos parâmetros que escolheria na interface - país, subdivisão opcional, data de início, duração do SLA em dias úteis, escala e idioma quando suportado.

Calendários de feriados permanecem sincronizados com GET /api/holidays para você não manter CSVs que envelhecem a cada temporada de orçamento.

Experimente

Abra a calculadora de prazo de SLA e rode cenários que vocês já discutiram de verdade em reuniões - início na sexta, feriados prolongados, “mesmo” SLA em duas regiões. Se os resultados batem com o que o time pretendia que o SLA dissesse, você tem uma linha de base para apontar. Se não batem, você descobriu uma ambiguidade que vale corrigir no contrato antes da próxima escalação.