Tiempo Medio de Resolución (MTTR)

Fórmula del MTTR: MTTR = Suma de (Marca de tiempo de resolución - Marca de tiempo de creación para todos los tickets en el período) / Número de tickets resueltos en el período. La media bruta es altamente susceptible a la distorsión por un pequeño número de tickets de duración extremadamente larga — un solo error sin resolver abierto durante 90 días puede distorsionar la media drásticamente, mientras que la mediana refleja con precisión la experiencia típica del cliente. Support Ops debe informar tanto la media como la mediana del MTTR, y también segmentar el MTTR por: prioridad del ticket (el MTTR P1 debería ser de 2 a 4 horas para SaaS empresarial; el MTTR P4 puede ser de más de 10 días hábiles y es aceptable); tipo de ticket (los tickets de facturación se cierran en horas; las escaladas de ingeniería pueden tardar semanas); canal (el MTTR de chat debería ser inferior a 15 minutos; el MTTR de correo electrónico se mide en horas); y nivel de cliente (empresa vs. SMB pueden tener objetivos de MTTR muy diferentes). El MTTR informado como un único número combinado mezcla todas estas dimensiones en una cifra difícil de actuar y fácil de manipular.

La reducción del MTTR requiere identificar dónde se gasta el tiempo — el proceso de resolución tiene fases distintas donde es posible mejorar. Tiempo de evaluación del agente (primer contacto hasta el diagnóstico completo): reducido por flujos de trabajo de diagnóstico estructurados en la base de conocimientos ("para [síntoma], verifica estas 5 cosas en orden"), contexto de cuenta auto-poblado desde la integración de CRM y soluciones sugeridas por IA basadas en el texto del ticket. Tiempo de espera de ingeniería (escalada de Nivel 2 esperando una respuesta de ingeniería): reducido al definir los SLA de escalada de Ingeniería y monitorear el cumplimiento; construir herramientas de diagnóstico de Nivel 2 que permitan al Nivel 2 resolver problemas que antes requerían ingeniería; y construir una biblioteca de resolución para patrones comunes de escalada de ingeniería. Tiempo de espera del cliente (agente esperando que el cliente proporcione información adicional): reducido por agentes que solicitan toda la información necesaria en un solo mensaje en lugar de seguimientos secuenciales; reapertura automática basada en el estado de "esperando al cliente" para que los tickets no se marquen como resueltos mientras se espera; y temporizadores de seguimiento proactivo (recordatorio automático enviado al cliente y al agente si no hay respuesta en 24 horas). Retención post-diagnóstico (solución conocida pero bloqueada por el proceso): reducida por la autoridad claramente definida del agente para implementar soluciones comunes sin aprobación.

La relación MTTR-CSAT es no lineal y contraintuitiva. Reducir el MTTR generalmente mejora el CSAT — los clientes aprecian una resolución más rápida. Pero la reducción del MTTR lograda a través de resoluciones apresuradas, cierre prematuro de tickets o soluciones superficiales daña activamente el CSAT: un ticket cerrado en 2 horas sin resolver realmente el problema generará una puntuación CSAT muy baja y probablemente una reapertura (medida como una "tasa de recontacto"). El punto de tensión: cuando la gerencia incentiva la reducción del MTTR como un KPI sin salvaguardas de CSAT, los agentes optimizan la velocidad de cierre sobre la calidad de la resolución — tomando atajos, marcando tickets como resueltos antes de una verificación exhaustiva y desviando problemas complejos a la base de conocimientos sin ayuda genuina. Support Ops mitiga esto al: informar el MTTR junto con el CSAT y la tasa de recontacto en cada panel operativo (haciendo obvia la manipulación a través de la señal de recontacto); decir explícitamente a los agentes que un MTTR largo en un problema complejo manejado con cuidado es más valorado que un MTTR rápido logrado mediante la desviación; y establecer objetivos de MTTR por tipo de ticket que reflejen plazos realistas de calidad de resolución en lugar de objetivos de velocidad aspiracionales.