Los niveles de soporte no existen para que el cliente hable con más gente, sino para lo contrario: que cada caso llegue a la persona adecuada en el menor número de pasos, y que quien corrige el código no tenga que explicar cómo se restablece una contraseña.

Se suelen llamar N1, N2 y N3. Estos nombres cambian de empresa a empresa, pero la idea es siempre la misma.

Los tres niveles: N1 atiende y resuelve lo conocido, N2 diagnostica y N3 corrige

N1: atender y resolver lo conocido

Es la primera línea, donde debería resolverse la mayor parte de los casos.

  • Qué hace: recibe, identifica al usuario, entiende el problema y lo resuelve siguiendo guías.
  • Casos típicos: accesos, dudas de uso, configuración, cobros, cómo hacer algo.
  • Qué necesita: una base de conocimiento y permisos básicos.
  • Qué entrega si no puede resolver: un caso bien documentado, nunca un "te transfiero".

N2: diagnosticar

Toma lo que no tiene una respuesta conocida y averigua qué está pasando.

  • Qué hace: reproduce la falla, revisa registros y datos, y distingue entre error del usuario, de configuración o del sistema.
  • Casos típicos: "solo me pasa en este Android", un cobro que no se reflejó, una integración que dejó de funcionar.
  • Qué necesita: acceso de lectura a registros y herramientas, ambiente de pruebas y conocimiento técnico.
  • Qué entrega: la solución, si está a su alcance, o un reporte completo para N3.

Este nivel es el que más tiempo le ahorra a tu equipo, y el que más empresas pequeñas se saltan.

N3: corregir

Son quienes pueden cambiar el producto: desarrollo e infraestructura.

  • Qué hace: corrige la causa en el código o en la infraestructura.
  • Casos típicos: errores reales, fallas de servidores, problemas de datos.
  • Qué necesita: que los casos le lleguen ya diagnosticados.
  • Qué entrega: la corrección, y una nota para que los demás niveles sepan qué responder.

Algunas empresas añaden un N4 para proveedores externos, como cuando la falla está en una pasarela de pago o en un servicio de terceros.

Un ejemplo: la app que se cierra al pagar

Usuario: "La app se cierra cuando intento pagar."

N1 confirma la versión y el teléfono, y comprueba en la guía que no sea un problema conocido. Le pide que actualice. Sigue fallando. Registra el caso con los datos y lo escala.

N2 intenta reproducirlo. Encuentra que solo ocurre en cierta versión de Android con una tarjeta guardada, y los registros muestran un error concreto. Le da al usuario una solución temporal: pagar con la tarjeta capturada a mano.

N3 recibe un reporte con los pasos, la versión y el registro. Corrige y publica una nueva versión.

N1 le avisa al usuario y, si dejó una reseña, también responde allí.

Con buenos reportes, el desarrollador no ha tenido que preguntar nada.

Qué debe traer un caso escalado

Un buen escalamiento responde a todo esto:

QUÉ PASA:        La app se cierra al confirmar el pago
QUÉ DEBERÍA:     Mostrar la confirmación
PASOS:           1. Abrir carrito 2. Pagar con tarjeta guardada
ENTORNO:         App 2.4.1, Android 14, Galaxy A15
FRECUENCIA:      Siempre con tarjeta guardada; 3 usuarios afectados
IMPACTO:         No pueden pagar; hay solución temporal
INTENTADO:       Actualizar, reinstalar, otra red
EVIDENCIA:       Registro y video adjuntos

Cómo evitar que los casos reboten

  • Define criterios de escalamiento por escrito: qué sube a cada nivel y cuándo.
  • Un caso, un responsable. Siempre debe tener dueño visible.
  • Que el cliente no se repita. Lo explicamos en omnicanal.
  • Lo que vuelve baja. Cuando se resuelve algo nuevo, se documenta para que la próxima vez lo resuelva un nivel más bajo.
  • Separa la urgencia del nivel. Una caída total pasa directo a quien la puede resolver, sin escalones.

Cuántos niveles necesitas

  • Equipo de 2 a 5 personas: puede bastar con un responsable de N1 y un turno rotatorio de quien programa. Documenta desde ya.
  • Con usuarios creciendo: separa N1 de desarrollo. Es el primer cambio con mejores resultados.
  • Producto más complejo: agrega N2 para proteger el tiempo de tus desarrolladores.

Ese primer nivel no necesariamente debe estar en tu nómina. Con nuestro soporte técnico externo puedes tercerizar N1 y N2, y conservar N3 en tu equipo, recibiendo solo los casos que lo necesiten. Si no sabes si te conviene, lee cuándo tercerizar.

#soporte técnico #mesa de ayuda #tercerizar #escalamiento #atención al cliente

Sebastián Espinoza

Fundador · Espacio Rojo

Espacio Rojo es una empresa de tecnología basada en Chihuahua, México. Construimos software, hardware y SaaS para empresas mexicanas que quieren competir con las mejores del mundo.