Gestión de Escaladas

Las escaladas se dividen en cuatro categorías distintas que requieren diferentes respuestas. Escaladas técnicas: errores complejos o problemas de integridad de datos que el soporte de Nivel 2 no puede resolver y requieren investigación y solución por parte de ingeniería. Propietario de la resolución: Ingeniería. Respuesta: Informe formal de errores con SLA, actualizaciones de estado regulares al CSM de la cuenta. Escaladas de negocio: cliente que amenaza con la rotación, expresa una insatisfacción grave o solicita explícitamente la participación ejecutiva. Propietario de la resolución: VP de CS o VP de Cuenta. Respuesta: Contacto ejecutivo en 24 horas, plan de rescate de la cuenta. Escaladas de relación: partida de un campeón, reestructuración importante de la cuenta o un stakeholder clave que expresa insatisfacción pública (redes sociales, sitios de reseñas). Propietario de la resolución: Liderazgo de CS y Legal (si es público). Respuesta: contacto proactivo antes de que la situación escale aún más, plan de reconstrucción de la relación. Escaladas de proceso: problemas sistémicos donde el mismo tipo de problema afecta a múltiples cuentas repetidamente, requiriendo un cambio de proceso en lugar de una resolución individual. Propietario de la resolución: Product Ops o Support Ops. Respuesta: análisis de la causa raíz, rediseño del proceso y comunicación a las cuentas afectadas.

El diseño del protocolo de escalada debe equilibrar dos riesgos contrapuestos: la sub-escalada (problemas que merecen atención senior nunca la alcanzan, y la organización es tomada por sorpresa por una rotación pública o una publicación en un sitio de reseñas) y la sobre-escalada (cada correo electrónico de un cliente insatisfecho desencadena respuestas ejecutivas, creando fatiga de alertas y una carga de trabajo ejecutiva insostenible). La solución son umbrales de escalada escalonados basados en criterios objetivos. Auto-escalar inmediatamente (no se requiere juicio del CSM): cualquier contacto del cliente con un ejecutivo, cualquier amenaza de publicar reseñas negativas, cualquier mención de terminación por nombre en un ticket de soporte, cualquier informe de vulnerabilidad de seguridad, cualquier evento de violación de datos. Escalar en 24 horas con juicio del CSM: una cuenta empresarial (>$25k ACV) con una caída en la puntuación de salud por debajo de 30 en una sola semana, un cambio de stakeholder observado por el CSM que indica pérdida de un tomador de decisiones, o una tercera QBR consecutiva perdida por el cliente. No escalar: tickets de soporte estándar de clientes empresariales (manejar a través de la cola de prioridad normal), expresiones individuales de frustración de usuarios sobre una característica específica (registrar en el sistema VoC).

La confianza del cliente durante una escalada se protege mediante dos principios: velocidad y previsibilidad de la comunicación. Los clientes en una situación difícil están más ansiosos cuando no están seguros de lo que sucederá a continuación. El cronograma de resolución no necesita ser corto, necesita ser comunicado claramente y cumplido de manera confiable. Inmediatamente después de recibir una escalada: acusar recibo en 2 horas con una persona nombrada asumiendo la responsabilidad (no un genérico "estamos investigando esto", el mensaje debe nombrar a la persona: "Soy Sarah, VP de Customer Success. He asumido personalmente la responsabilidad de su cuenta y estoy trabajando con nuestro líder de Ingeniería en esto"). Proporcionar un tiempo de comunicación específico (no "le actualizaremos pronto", "le enviaré una actualización de estado antes de las 3 p.m. de hoy, tengamos o no una resolución para entonces"). Si se acerca la fecha límite de las 3 p.m. sin resolución, envíe una actualización a las 3 p.m. de todos modos: "Aquí es donde estamos y aquí está el objetivo revisado". Esta previsibilidad, incluso en situaciones difíciles, es lo que convierte una escalada de un evento que destruye la confianza en uno que la construye.