¿Te ayudamos a aplicar esta guía?Pregunta al equipo de DripTell
Un panel de soporte puede mejorar mientras un cliente sigue esperando. Bajan los casos abiertos y mejora la mediana, pero el problema más antiguo apenas se mueve.
El tamaño del backlog no basta. Mida la antigüedad desde una captura diaria completa. Muestre el tiempo del cliente y el accionable, lea la distribución y asigne dueño y decisión a cada caso viejo. De otro modo, el panel mejora mientras la experiencia empeora.
Empiece con todos los problemas pendientes
Defina primero la población. Incluya todo el trabajo del cliente que no se ha resuelto, no solo la cola ya asignada. El informe de backlog de Microsoft define la antigüedad como los días desde que se creó el caso o registro y la muestra junto a cola, estado, agente, número único, hora de creación y prioridad. Una edad sin identidad estable ni contexto operativo no permite decidir.
- 1Capture todo el trabajo abiertoIncluya casos asignados, libres, en espera y bloqueados en una sola captura.
- 2Inicie dos relojesConserve el tiempo total del cliente y el tiempo separado en que el equipo puede actuar.
- 3Exponga la cola antiguaLea juntos la mediana, un percentil alto y el caso accionable más antiguo.
- 4Revise la consecuenciaCombine antigüedad con prioridad, compromiso, tipo de problema y bloqueo.
- 5Acepte el siguiente pasoNombre responsable, acción y revisión sin reiniciar el tiempo original.
Tome la captura a la misma hora cada día. Cuente problemas, no mensajes. Un hilo largo de WhatsApp es un problema mientras el cliente busque un resultado; dos asuntos independientes son dos casos. Así los canales activos no inflan el backlog.
Use un inicio estable, normalmente cuando el negocio conoció el problema. No lo reinicie al cambiar de canal, cola, prioridad o agente. Una transferencia cambia el dueño, no el tiempo del cliente. Un diseño claro de cola según el SLA y una identidad fiable conservan ese contexto.
Mantenga dos relojes honestos
Un solo reloj no puede describir a la vez la espera del cliente y el retraso que el equipo puede controlar.
El reloj total del cliente corre desde el inicio original hasta la resolución verificada. Responde una pregunta humana: ¿desde cuándo existe este problema para el cliente?
El reloj accionable corre mientras su equipo puede dar el siguiente paso útil. Puede pausarse por una prueba del cliente, una decisión externa o un evento previsto. La pausa requiere motivo, responsable y revisión, y nunca oculta el caso.
Esta separación evita dos errores. Mantener todos los relojes activos atribuye a un agente tiempo que no controla. Pausar el único reloj oculta la espera total del cliente. Conserve ambos.
La guía de Microsoft sobre tiempo de gestión distingue cinco horas de trabajo activo de una resolución cinco días después de crear el caso. Los dos relojes propuestos no son esos campos, pero el ejemplo muestra por qué una duración no basta. Escriba reglas de inicio, pausa y cierre.
| Señal del backlog | Qué puede significar | Decisión útil |
|---|---|---|
| Crece el volumen y la edad sigue baja | La demanda supera la capacidad | Revise el tipo de demanda y proteja capacidad |
| Baja la mediana y envejece la cola | Avanza lo fácil y se atasca lo difícil | Revise los bloqueos más antiguos |
| La edad total es alta y la accionable baja | Domina la espera | Confirme dueño, aviso y revisión |
| La edad se concentra por tipo | Falta habilidad, autoridad, ruta o conocimiento | Corrija la restricción |
| Los casos viejos cambian de agente | La propiedad se mueve sin progreso | Exija aceptación y acción |
Lea la cola antigua junto con el centro
Unos pocos casos extremos pueden arrastrar el promedio. La mediana puede ocultar esos mismos casos. Use un conjunto pequeño de vistas:
- problemas pendientes totales
- antigüedad mediana
- un percentil alto como el noventa
- caso accionable más antiguo
- bandas de antigüedad por prioridad, tipo, estado, cola y propietario
Construya las bandas desde sus compromisos e historia operativa. Busque movimiento y consecuencias, no un indicador verde universal.
El tiempo de primera respuesta y la antigüedad responden preguntas distintas. Un acuse rápido mejora el tiempo de primera respuesta mientras el problema envejece. El tiempo de resolución describe trabajo terminado; la antigüedad expone el riesgo abierto. Necesita ambas vistas.
Convierta la antigüedad en una decisión
El informe solo sirve si cambia el trabajo. Revise con frecuencia los casos accionables más antiguos. Registre resultado pendiente, responsable, bloqueo, próxima acción y revisión.
No cierre registros antiguos en bloque para mejorar el gráfico. Algunos serán duplicados u obsoletos, pero cada cierre requiere una razón y, cuando proceda, un aviso al cliente. La recuperación del backlog busca resolución verificada o decisión honesta, no limpieza cosmética.
Escale según consecuencia y antigüedad. Una duda vieja sobre contraseña y un fallo de pago antiguo no tienen el mismo riesgo. Prioridad, compromiso e impacto cambian la acción mientras la edad mantiene visible la espera.
Mantenga una medición justa entre canales
Mida el problema, no la bandeja. Si un cliente empieza en Instagram, sigue por WhatsApp y luego llama, unir los registros no debe crear tres casos jóvenes que oculten un problema viejo. Use un identificador estable y conserve la hora original durante el enrutamiento y el traspaso.
También importa lo contrario. No agrupe asuntos independientes solo porque vienen de la misma persona. La identidad conecta el contexto, pero no borra resultados separados.
Si un problema resuelto vuelve porque el resultado no se sostuvo, aplique una regla escrita de reapertura. Un método justo para medir reaperturas evita presentar un cierre prematuro como un éxito nuevo.
Use la antigüedad como señal del sistema, no como clasificación de agentes. El trabajo viejo revela falta de autoridad, defectos, propiedad confusa, dependencias o mal enrutamiento. Una vista compartida como el flujo de soporte de DripTell debe hacer esas condiciones accionables.
La pregunta diaria es sencilla: ¿qué cliente espera algo que podemos hacer ahora y quién aceptó el siguiente paso?
Preguntas frecuentes
Cómo se calcula la antigüedad del backlog
Para cada problema pendiente, reste su hora de inicio original y estable a la hora de la captura. Guarde por separado el tiempo total del cliente y el tiempo accionable del equipo, y analice la distribución en lugar de mostrar un solo promedio.
Debe detenerse el reloj mientras se espera al cliente
Puede pausar el reloj accionable cuando una respuesta real del cliente sea necesaria. No detenga ni borre el tiempo total. Mantenga el caso visible con motivo de espera, responsable y fecha de revisión.
Es suficiente la antigüedad mediana
No. Combínela con un percentil alto, el caso accionable más antiguo, todo el trabajo abierto y cortes por prioridad, tipo, estado, cola y propietario.
Con qué frecuencia debe revisarse
Tome una captura diaria y revise los casos accionables más antiguos. Los compromisos críticos deben activar atención antes de la revisión programada.
DripTell Editorial
Guías prácticas revisadas por el equipo de producto y flujos de cliente de DripTell.
Consulta cómo DripTell verifica el producto, utiliza fuentes primarias y corrige errores.
Política editorial y de fuentes