El tiempo corre.
Alguien está respondiendo.

Primera causa: no hay un SLA definido. “Lo revisaremos lo antes posible” no es un compromiso; es buena voluntad imposible de medir. Como el cliente no sabe cuándo recibirá respuesta, entra en una espiral de preocupación, empiezan a llover los correos de seguimiento y la energía del equipo se va en explicar cuándo se resolverá el problema en lugar de resolverlo. Si no hay objetivos de respuesta y resolución por escrito para las prioridades crítica, alta, media y baja, todos los tickets son igual de urgentes; es decir, ninguno lo es.

Segunda causa: los tickets se pierden. Cuando el soporte todavía llega a una dirección genérica “info@”, tres personas distintas responden el mismo correo electrónico o no responde nadie; las cadenas de CC se ramifican, los adjuntos desaparecen y ya no queda claro qué conversación corresponde a qué cliente. Los canales de WhatsApp, teléfono, formulario y chat no saben nada unos de otros. El cliente tiene que volver a contar su historia cada vez. Además de restar profesionalidad, este es el mayor obstáculo para construir una operación medible.

Tercera causa: no hay escalamiento. Cuando el agente de L1 no puede resolver el problema, no está claro a quién debe pasarlo. “Se lo preguntaré al CTO” se convierte en un canal improvisado que despierta a la alta dirección a las 23:00. El equipo sénior de ingeniería, obligado a explicar el mismo problema por quinta vez, se tensa; bajan la velocidad de resolución, la calidad y la moral del equipo. Sin una ruta de escalamiento escrita L1 → L2 → L3 → equipo de arquitectura → dirección, las crisis se resuelven siempre con pánico, no con un sistema.

Cuarta causa: no hay rotación de guardias. Si una sola persona concentra todo el conocimiento, el sistema queda expuesto cuando está de vacaciones; si durante un incidente crítico en plena noche tiene el teléfono apagado, a todos los demás solo les queda esperar hasta la mañana. Sin herramientas como PagerDuty u Opsgenie, sin planes semanales de turnos y sin transparencia sobre quién está de guardia en cada momento, la guardia se convierte en heroísmo voluntario: insostenible, agotador para el equipo y fuente de decisiones equivocadas.

Quinta causa: no hay base de conocimiento (KB) y las preguntas repetidas nunca se documentan. La misma pregunta “¿cómo restablezco mi contraseña?” puede llegar 40 veces al mes, y cada vez un especialista de soporte le dedica 8 minutos. La solución es escribir un artículo de la KB la primera vez y hacer que el sistema sugiera “¿ya leyó este artículo?” en cuanto el cliente abre un ticket. Cada artículo sin escribir es una experiencia lenta para el cliente y un impuesto de tiempo que su equipo paga cada mes. En el paquete de soporte con SLA de Partnerfy, la producción de la KB no es opcional: es la base de la operación.