SLA, calendario y escalados

Los plazos se configuran en «Settings → SLA». La propia página te avisa arriba cuando no hay ninguna directiva activa. Una directiva tiene tres partes: un nombre, las condiciones y los objetivos. Las directivas nuevas se crean a propósito inactivas, para que puedas terminar de configurarlas antes de que hagan nada.

Las condiciones son «Team», «Priority», «Main category» y «Subcategory». Vacío significa «cualquiera», es decir, «se aplica a todo», y no «no se aplica a nada». Si coinciden varias directivas, gana la que tenga el número más bajo en «Order»; por eso la directiva estrecha va arriba y la general debajo.

Los dos campos de categoría están agrupados por equipo, porque las categorías pertenecen a un equipo, pero se te ofrecen todas, también las de otros equipos. Es intencionado: en un traspaso se mueve el ticket, no la categoría. Un ticket que el helpdesk pasó al equipo de red sigue llevando la clasificación del helpdesk, y una directiva puede apuntar justo a eso. Cuando eliges una categoría principal, el campo de debajo solo ofrece las subcategorías enlazadas con ella; una pareja que no puede existir en un ticket se rechaza al guardar.

Cada directiva tiene dos objetivos. «Time to first response» termina con la primera respuesta pública de un agente; un acuse de recibo automático y una nota interna, expresamente, no cuentan. «Time to resolution» termina en cuanto el ticket alcanza un estado que cuenta como resuelto (cuál es, lo defines en «Settings → General → Status»). Ambos objetivos tienen sus propios minutos, su propio calendario y su propia reacción ante un incumplimiento.

En el ticket, los plazos están a la derecha, en la tarjeta «Details», y debajo está «Show deadline history»: un registro que anota cada paso —iniciado, pausado, reanudado, cumplido, incumplido— con su motivo y el tiempo laborable consumido. Solo lo ven agentes y administradores; para los clientes no se puede consultar.

Si alguien cambia después la prioridad o el equipo, el reloj pasa a la directiva que coincida entonces: el tiempo laborable consumido hasta ese momento se liquida con el calendario antiguo y, a partir de ahí, valen los valores nuevos. Si ya no coincide ninguna directiva, el reloj termina sin veredicto: no cuenta ni como cumplido ni como incumplido.

Si ninguna directiva coincidía al crear el ticket, el reloj arranca la primera vez que una directiva coincide tras un cambio, por ejemplo una prioridad más alta. Cuenta desde ese momento. El reloj de la primera respuesta solo arranca si nadie ha respondido todavía.

Solo nacen relojes nuevos cuando se reabre un ticket. Los demás cambios de estado no crean relojes nuevos.

Un calendario dice cuándo corre el reloj. Tiene un nombre, su propia zona horaria y cualquier número de franjas por día de la semana; una pausa de comida es sencillamente un día con dos franjas. Una franja puede pasar de la medianoche, y entonces aparece «ends next day» al lado.

Qué calendario se aplica a un equipo se define en el equipo («Settings → Teams»). En el objetivo concreto de una directiva puedes sobrescribirlo: «From the team» toma el del equipo, o eliges otro. Justo eso produce el caso habitual: las averías cuentan a todas horas y todo lo demás solo en horario de oficina.

Se cuenta el tiempo que transcurre realmente dentro de la franja, no la diferencia entre las horas del reloj. En el cambio de hora eso marca la diferencia: un día 24/7 de octubre tiene 25 horas, y un turno de noche de 22:00 a 06:00 tiene en primavera siete en lugar de ocho. Una franja de oficina de 09:00 a 17:00 no se ve afectada nunca, porque en la UE el cambio ocurre de noche.

Si no se encuentra ningún calendario con horas de apertura, no se crea ningún plazo: mejor ninguno que uno adivinado. En el ticket aparece entonces una nota en lugar de una fecha.

Debajo de cada calendario está la lista «Closed days». Un clic en «Import holidays (.ics)» toma un archivo de calendario y después informa de cuatro cifras: cuántos días se han incorporado, cuántos se han sustituido, cuántos eran ilegibles y cuántos ya estaban. También puedes introducir días sueltos a mano.

El símbolo ↻ que sigue a un día significa «se repite cada año». Solo es correcto en fechas fijas: el 3 de octubre cae cada año en la misma fecha, mientras que el Viernes Santo y el Lunes de Pentecostés cuelgan de la fecha de la Pascua y se mueven. Los festivos móviles aparecen por eso en la lista con su fecha concreta de cada año; en la imagen, «Good Friday» sin el símbolo.

Un día cerrado se traga toda la franja de ese día, incluida la parte que se prolonga al día siguiente. Y cuando un calendario no conoce ningún día cerrado en los próximos doce meses, la página lo dice expresamente; de lo contrario, el sistema contaría en silencio a través de los festivos y produciría plazos equivocados.

La discusión más habitual sobre los plazos es esta: el ticket lleva tres días esperando la respuesta del cliente y el reloj sigue corriendo igualmente. Por eso cada objetivo tiene el interruptor «Pause while waiting for the requester», por separado y no para toda la directiva.

Si se está esperando o no lo decide el estado: en «Settings → General → Status», cada estado lleva una marca que indica si cuenta como «esperando a quien solicitó». Con el interruptor activado, el plazo descansa mientras el ticket esté en un estado así. El reloj de pared sigue corriendo, y por eso la lista muestra «Paused» en lugar de un tiempo restante, y el historial de plazos contiene «Paused» y «Resumed» con sus horas. El tiempo de espera tampoco cuenta si el ticket se resuelve directamente desde un estado así.

Para la primera respuesta se suele dejar el interruptor desactivado: la primera respuesta la debes tú, se esté esperando lo que se esté esperando. Para la resolución suele estar activado. La imagen muestra exactamente ese ajuste.

En cuanto hay una directiva activa, la lista de tickets recibe la columna «Deadline». Muestra el tiempo restante del siguiente plazo abierto («14h 53m»). Cuando ya no corre ningún plazo del ticket, ahí queda el veredicto: la marca «In time» si se cumplió, y el rojo «Breached» si se incumplió. Un ticket sin ningún reloj recibe un guion neutro, y es a propósito: un ticket anterior a la directiva no es un fracaso.

Si no hay ninguna directiva activa, la columna no aparece en absoluto: no se queda ahí vacía. Lo mismo vale para el filtro: en «Filter», la casilla «Breached only» solo aparece cuando hay plazos.

Un ticket tiene dos relojes, pero la columna solo tiene un hueco: muestra el plazo ABIERTO más urgente. Si la primera respuesta se incumplió y la resolución sigue corriendo, la columna muestra el tiempo restante de la resolución con una «!» roja al lado. Esa marca dice que un plazo de este ticket ya se ha incumplido, y así es exactamente como lo encuentra el filtro «Breached only», porque pregunta por cualquier plazo incumplido, incluso por uno terminado hace tiempo. Cuál de los dos fue está escrito en el propio ticket.

También puedes ordenar por ella: bajo ese mismo encabezado «Deadline» hay un campo con «Due soonest first» y «Due latest first». Los tickets sin reloj en marcha quedan siempre al final: no son los menos urgentes, sencillamente no están afectados. Ordenar por plazo tiene preferencia sobre ordenar por «Updated at»: ninguna lista puede satisfacer dos ordenaciones a la vez.

Por objetivo defines en «When breached» qué ocurre al incumplirse: «Record only» solo lo registra, «Notify assignee and observers» envía un correo a la persona asignada y a los observadores (no a todo el equipo), y «Hand over to another team» traspasa el ticket. Para el traspaso tienes que elegir un equipo de destino; una directiva sin él se rechaza al guardar, porque parecería configurada y no haría nada.

La acción se ejecuta exactamente una vez por reloj. Sin ese cerrojo, un reinicio del servidor volvería a enviar el mismo correo. La marca de «ya hecho» se pone incluso cuando el envío falló: un correo que no llegó es mejor que un bucle que envía uno nuevo cada minuto.

El incumplimiento se fecha en el momento en que venció, no en la pasada de comprobación; de lo contrario, los informes dependerían del ritmo del servicio de comprobación. Y se mide contra el tiempo laborable consumido: un reloj en pausa no puede incumplirse, aunque la fecha de vencimiento haya pasado hace mucho.

El traspaso vuelve a poner el estado en «Open». Las filas del historial sobre ello son internas; el cliente solo ve en el ticket el nuevo estado y el nuevo equipo.

En «Reports» eliges el periodo y pulsas «Generate report»; sin ese clic la página se queda vacía. El informe contiene entonces el bloque «Service level agreements» con una fila por objetivo: cumplidos, incumplidos, todavía en marcha, tasa alcanzada y tiempo medio consumido.

El recuento se hace por objetivo, no por ticket, y así se indica también bajo la tabla. Un ticket con ambos objetivos aparece por tanto dos veces, una en cada fila.

La tasa alcanzada cuenta solo los relojes ya decididos. Los que siguen en marcha no pertenecen al denominador; de lo contrario, cada SLA recién activado parecería catastrófico al principio y mejoraría solo. Si todavía no hay ni un reloj decidido, aparece un guion, no un «0 %».

Si trabajas con incidencias colectivas, hay además una línea «Achieved without group incidents»: una sola incidencia colectiva con cien tickets enganchados distorsionaría si no la tasa en ambos sentidos. Deja fuera todos los tickets vinculados a una incidencia colectiva.

En este bloque los agentes solo ven sus propios equipos. Sin Professional, el bloque solo aparece si hay datos de plazos de antes; entonces sigue siendo legible.