Calculadora de plazos SLA (días laborables, fines de semana y festivos públicos)
Por qué los SLA en días laborables generan discusiones, cómo contarlos con equidad entre regiones y cómo la calculadora y la API de plazos SLA de HolidayDB se alinean con calendarios reales.
Cuando «tres días» abre un debate
Alguien abre un ticket a las 16:59 del jueves. El contrato dice «respuesta en tres días laborables».
Media sala cuenta desde el viernes. Otro empieza tras el fin de semana. Un tercero menciona un festivo nacional que nadie había bloqueado en el calendario.
Nadie se está ahorrando trabajo. La redacción simplemente nunca se cruzó con un calendario real.
Esa brecha es lo que teníamos en mente para la calculadora de plazos SLA: no otro selector de fechas, sino un marco compartido: elija un país (y región si lo necesita), elija cómo trabaja realmente su equipo y deje que la herramienta avance en días laborables mientras fines de semana y festivos se excluyen automáticamente.
Lo que los contratos suelen dejar implícito
La mayoría de los SLA se escriben en días laborables porque intentan medir capacidad, no tiempo solar transcurrido. El problema es que «día laborable» no dice:
- si el plazo empieza el día de la recepción o el siguiente día laborable
- qué definición de fin de semana aplica (vie-dom frente a normas regionales)
- qué lista de festivos aplica cuando la gente está en sitios distintos
- qué ocurre cuando el propio «inicio» cae en un día no laborable
Hasta que eso quede fijado, cada hoja de cálculo es una opinión privada.
El modelo de HolidayDB coincide con lo que documentamos en la calculadora: elige un horario laboral (p. ej. lun-vie, lun-sáb, dom-jue u operación siete días que aún excluye festivos) y elige dónde se ancla el trabajo para que los festivos públicos no se adivinen de memoria.
El «día cero» es donde los equipos discrepan en silencio
Un desajuste sutil es si la fecha de la solicitud cuenta como primer día o como día cero antes de contar.
Nuestra calculadora trata la fecha de inicio como día 0 y luego avanza N días laborables a lo largo de días laborables válidos. Así, un SLA de un día laborable desde un jueves laborable suele caer en viernes, no en «saltar el jueves y llegar al lunes» salvo que el jueves no sea laborable en su configuración.
No es la única convención que existe, pero sí es coherente entre la interfaz de la calculadora y el endpoint GET /api/sla-deadline, y eso importa más de lo que parece. Cuando soporte, legal e ingeniería leen el mismo resultado, se gana tiempo reconciliando herramientas.
Las regiones importan aunque la etiqueta del país parezca la misma
Los festivos nacionales son solo parte del cuadro. Las normas subnacionales (estados, cantones, provincias) pueden separar dos escritorios en el «mismo» país en semanas laborables distintas durante el mismo tramo.
Si su SLA está ligado a dónde se hace el trabajo o dónde está el cliente, incorpórelo al cálculo desde el principio. Si no, acabará con una política «global» que favorece en silencio el calendario de una oficina.
Cuando supera el copiar y pegar
La herramienta en página es para personas que necesitan una respuesta rápida. Cuando necesite las mismas reglas en facturación, ticketing o controles de cumplimiento, conecte GET /api/sla-deadline (véase documentación: plazo SLA) con los mismos parámetros que elegiría en la interfaz: país, subdivisión opcional, fecha de inicio, longitud del SLA en días laborables, horario e idioma cuando esté soportado.
Los calendarios de festivos se mantienen alineados con GET /api/holidays, así no mantiene CSV que caducan cada temporada de presupuesto.
Pruébela
Abra la calculadora de plazos SLA y ejecute algunos escenarios que ya le hayan generado discusiones en reuniones: inicios en viernes, fines de semana largos, el «mismo» SLA en dos regiones. Si los resultados coinciden con cómo su equipo pretendía leer el SLA, tiene una referencia a la que apuntar. Si no, habrá detectado una ambigüedad que merece aclararse en el contrato antes de la próxima escalada.