Define los criterios de escalado, el proceso de handoff entre niveles y la comunicación con el cliente durante una escalada que transforma una crisis en una demostración de compromiso. Con las plantillas de comunicación y el proceso de retrospectiva.
Cuándo usarlo: Escalado de tickets, proceso de soporte, handoff, customer support
Herramienta recomendada: Claude
Eres un Director of Customer Support con experiencia diseñando procesos de escalado en equipos de soporte de 5 a 50 agentes en productos SaaS y plataformas digitales. Contexto: - Canales de soporte: [chat en vivo / email / teléfono / todos] - Herramienta de soporte: [Intercom / Zendesk / Freshdesk / Help Scout / otra] - Tamaño del equipo: [N agentes de L1 / N agentes de L2 / N técnicos L3] - Mayor problema actual: [los escalados tardan demasiado / el cliente tiene que explicar el problema de nuevo / no hay criterios claros para escalar / todo se escala sin criterio / otro] ## Protocolo de Escalado de Tickets — [Empresa] ### 🏗️ Los niveles de soporte y qué resuelve cada uno **L1 — Soporte general:** - Responde el 70-80% de los tickets - Problemas: configuración básica, preguntas sobre features, contraseña olvidada, errores conocidos con solución documentada - Criterio para escalar: no puede resolver en <[N] minutos o el ticket requiere acceso técnico al backend **L2 — Soporte especializado:** - Problemas más complejos que requieren conocimiento profundo del producto - Diagnóstico de bugs, integraciones, configuraciones avanzadas - Criterio para escalar: necesita cambio en el código o involucra pérdida de datos **L3 — Ingeniería:** - Bugs confirmados, pérdida de datos, problemas de infraestructura - Solo recibe tickets que L2 no puede resolver con las herramientas disponibles - Criterio para escalar: incidente de severidad alta que afecta a múltiples clientes ### ⚡ Los criterios de escalado inmediato (sin esperar) Estos tickets se escalan a L2 en <15 minutos sin importar la cola: - Pérdida de datos reportada - Acceso a la cuenta bloqueado para un cliente de alto valor - Fallo de pagos o transacciones - Posible brecha de seguridad (datos visibles, acceso no autorizado) - Cliente que menciona explícitamente que va a cancelar ### 🔄 El handoff que no frustra al cliente **El mayor error en los escalados:** el cliente tiene que explicar el problema de nuevo. **El handoff correcto:** ``` [L1 al L2, en notas internas del ticket]: RESUMEN DEL PROBLEMA: El cliente [nombre] reporta [descripción exacta del problema] desde [fecha/hora]. Ha intentado: [pasos ya probados]. Ya verificado: [lo que se ha descartado]. CONTEXTO DEL CLIENTE: Plan: [plan] | Desde: [fecha] | CSAT histórico: [X] Nivel de urgencia percibido: [alto / medio / bajo] Tono de la conversación: [frustrado / tranquilo / urgente] SIGUIENTE PASO ESPERADO: El cliente espera que [expectativa concreta]. ``` **Comunicación con el cliente durante el escalado:** ``` Asunto: Tu consulta ha sido asignada a nuestro equipo especializado Hola [nombre], He escalado tu caso a [nombre del agente L2], quien es especialista en [área]. Te contactará en [plazo comprometido] con las primeras novedades. No necesitarás explicar el problema de nuevo — le he pasado todos los detalles. Si mientras tanto el problema empeora o hay algún cambio, escríbeme directamente. [Nombre del agente L1] ``` ### 📊 Métricas de los escalados | Métrica | Objetivo | Cómo calcular | |---------|---------|---------------| | Tasa de escalado | <20% de tickets totales | Tickets escalados / total | | First-contact resolution de L1 | >75% | Tickets resueltos por L1 / total L1 | | Tiempo de primer contacto post-escalado | <2h (L2), <4h (L3) | Promedio del tiempo entre escalado y primera respuesta | | CSAT en tickets escalados | >4.0/5.0 | Encuesta post-cierre | ### 🔍 La retrospectiva post-escalado El proceso de 10 minutos que convierte cada escalado en conocimiento para reducir el siguiente.