Cuándo debe soporte pausar un SLA por el cliente

Una bicicleta eléctrica llega al taller con una avería, pero el cargador extraíble sigue en casa del cliente. El técnico no puede realizar la prueba acordada hasta que el cliente lo entregue. Esta sí es una razón válida para pausar el reloj de servicio correspondiente.

Pause un SLA solo cuando el cliente sea responsable de una acción siguiente, concreta y necesaria. No lo pause porque otro equipo se retrasa, un proveedor no responde, falta una aprobación o el responsable está ausente. Esas demoras siguen perteneciendo a la empresa.

Pause solo por una acción del cliente

Un SLA es una promesa de servicio, no un simple temporizador del sistema de tickets. La pausa excluye tiempo de esa promesa, así que necesita una prueba mejor que un cambio de estado conveniente.

Nombre el dato pendiente con palabras claras. Puede ser una foto del daño, la confirmación de una dirección, la elección entre dos soluciones válidas o un permiso para entrar en una cuenta. La petición debe ser necesaria, proporcional y posible. Si el equipo puede avanzar sin ella, el caso no está esperando realmente al cliente.

Microsoft documenta condiciones configurables para pausar SLA en la entidad, el KPI y cada elemento. Una condición específica puede sustituir una configuración general. La flexibilidad es útil, pero también permite que un estado pendiente genérico afecte a varios relojes de forma inesperada. Vincule la pausa con la medida y el estado exactos.

Separe la espera del cliente de la demora interna

La prueba más limpia consiste en identificar al dueño de la siguiente acción útil. Si es el cliente, la pausa puede ser justa. Si es la empresa o una dependencia, el reloj normalmente debe seguir.

La guía de Microsoft sobre el temporizador SLA muestra que un caso en espera pausa la instancia del KPI y conserva la duración de la espera, mientras que el tiempo activo y el transcurrido siguen en campos separados. No copie una configuración predeterminada. Decida primero qué promesa está midiendo.

La distinción evita penalizar al agente por el tiempo que controla el cliente y evita que la empresa oculte sus propias colas o dependencias.

Registre la pausa como un evento auditable

Un estado no basta. Guarde la información solicitada, el mensaje al cliente, el responsable durante la espera, el inicio, la fecha de revisión y el evento que reanudará el trabajo. Conserve también la llegada original y la duración pausada. De lo contrario, el caso vuelve a la cola como si fuera nuevo.

El mensaje debe explicar qué hace falta y qué ocurrirá después. El taller puede pedir el cargador, indicar que el diagnóstico no continúa sin él y confirmar que el caso se reanudará al recibirlo. Evite frases como “envíe más información”. No permiten saber si el cliente completó la acción.

Fije una revisión cercana aunque no haya un plazo final. El caso sigue necesitando dueño mientras espera. Esa persona puede enviar un recordatorio razonable, ofrecer otro canal o decidir que la petición era innecesaria. Una pausa nunca debe ser un estante invisible para trabajo incómodo.

Reanude sin perder la antigüedad original

Reanude el reloj cuando llegue la prueba por cualquier canal conectado. El cliente puede contestar en WhatsApp a una petición enviada por correo o dar el dato por teléfono. Vincular el evento al mismo cliente y caso importa más que recibirlo en el canal inicial.

Conserve el tiempo anterior, la pausa y el tiempo posterior. No reinicie el caso desde cero. La espera total del cliente debe seguir disponible aunque el SLA excluya una parte. Así se mantiene una medición justa de la siguiente respuesta sin permitir que un estado borre la historia.

Si el cliente nunca responde, use la regla transparente de inactividad de la política de cierre de casos. Cierre solo si comunicó el plazo y la empresa no debe ninguna acción. El silencio no demuestra que el problema terminó.

Mida la espera sin ocultarla

Informe por separado del trabajo activo, la espera del cliente y las dependencias internas. Revise la mediana y la cola lenta, pausas sin una petición concreta, casos reanudados sin dueño y cierres directos desde espera. Examine conversaciones reales porque una historia de estados limpia puede ocultar una mala pregunta.

En DripTell, un flujo de soporte mantiene visible la acción siguiente y el inbox compartido conserva dueño e historial. La automatización puede reaccionar a un evento del cliente, pero la política necesita un responsable humano y condiciones probadas. Limite quién cambia las reglas con controles de seguridad.

La regla es sencilla. Pause solo cuando el cliente posea el siguiente movimiento necesario. Mantenga honesto el reloj de la empresa en cualquier otro caso.

Preguntas frecuentes

Cuándo debe pausarse un SLA de soporte?

Cuando se pide al cliente un dato o una decisión concreta y necesaria, y el trabajo no puede continuar sin ella. Registre la petición, el responsable, el inicio, la revisión y el evento de reanudación.

Debe pausarse el SLA al esperar a otro equipo?

Normalmente no. Un equipo interno, proveedor, transportista o aprobación forma parte de la entrega empresarial. Mantenga el reloj activo y haga visibles la dependencia y la persona que actualizará al cliente.

Qué debe ocurrir cuando responde el cliente?

Reanude el reloj relevante de inmediato, devuelva el caso a un dueño responsable y conserve su antigüedad original junto con la pausa. Vincule de forma fiable las respuestas de otros canales.

Puede una automatización pausar un SLA?

Sí, cuando detecta una condición precisa y comprobada. No debe inferir responsabilidad del cliente a partir de un estado pendiente genérico. Pruebe datos ausentes, respuestas cruzadas, eventos duplicados, tiempos agotados y recuperación manual.