Volver al blog
Guías

Onboarding segmentado: rutas distintas para administradores, usuarios finales y viewers

Un administrador, un usuario final invitado y un viewer de solo lectura se registran para trabajos muy distintos. Cómo diseñar rutas de onboarding por rol que lleven a cada uno al valor antes.

NudgePath Team14 de mayo de 20269 min de lectura

Puntos clave

  • El onboarding genérico es onboarding para administradores disfrazado, y en los productos de equipo los administradores son una minoría de los usuarios.
  • Antes de diseñar ningún flujo, mapea rol, trabajo, momento de primer valor y atasco más probable para administradores, usuarios finales y viewers: de esa tabla sale cada decisión sobre las rutas.
  • Segmenta primero con los datos del producto y el contexto de la invitación, después con una encuesta de una sola pregunta, y deja el comportamiento como corrección continua.
  • Ramifica en la entrada y converge pronto: empieza por creador frente a invitado y añade rutas solo con pruebas de activación, o la matriz se comerá el programa.
  • Mide la activación por rol, con embudos por segmento y experimentos dentro de cada segmento: una cifra de activación mezclada esconde justo los fallos que la segmentación existe para resolver.

Hay una aritmética incómoda detrás de casi todo el onboarding B2B: se diseñó para quien se registra y, en un producto de equipo, esa persona es una minoría de tus usuarios. Por cada creador de cuenta hay compañeros invitados y, detrás de ellos, viewers que no van a crear nada nunca. Y aun así los tres suelen aterrizar en el mismo recorrido de bienvenida, la misma lista de tareas y el mismo estado vacío del tipo «conecta tus datos»: una experiencia pensada para el administrador y servida a todo el mundo.

El desenlace es predecible. Al usuario final invitado se le pide configurar integraciones que ya están configuradas. Al viewer de solo lectura se le pasea por funcionalidades de creación que ni siquiera tiene permiso para tocar. Ambos aprenden, en sus primeros cinco minutos, que la guía del producto no sabe quiénes son; y una guía que no te conoce es una guía que dejas de leer. El onboarding segmentado corrige esto con un solo movimiento: deja de incorporar a «el usuario» y empieza a incorporar a las tres o cuatro personas que de verdad aparecen.

Los tres roles por defecto y qué significa el valor para cada uno

Los nombres cambian de un producto a otro, pero el trío de fondo es notablemente estable:

  • El administrador (creador de la cuenta, dueño de la configuración). Su trabajo es hacer que el producto funcione para un equipo: conectar datos, configurar el espacio de trabajo, definir permisos, invitar gente. Su primer valor no es personal; llega en el momento en que el sistema funciona para el equipo que él mismo ha traído. Tolera más fricción de configuración que nadie, pero también carga con la decisión de compra, así que sus atascos son los más caros que tienes.
  • El usuario final (operador invitado). Su trabajo es el verbo diario de tu producto: crear la tarea, registrar la llamada, publicar el contenido. No eligió la herramienta y no comparte la motivación del administrador; su primer valor es completar un trozo real de su propio trabajo, más rápido o mejor que antes. Cada paso de configuración que le enseñas es fricción pura, porque la configuración ya la hizo otro.
  • El viewer (consumidor del resultado). Directivos que echan un ojo a un panel, responsables que leen informes. Su trabajo es encontrar la información y entenderla. Su primer valor es un vistazo a un informe que responde a una pregunta que le importa. Su onboarding entero puede consistir, con toda legitimidad, en dos tooltips y una navegación bien etiquetada.

Escribe esta tabla para tu propio producto antes de construir nada: rol, trabajo, momento de primer valor y el mayor obstáculo que podría dejarlo atascado. De ahí sale cada decisión sobre las rutas.

De dónde sale la señal de segmento

Ramificar exige saber con quién hablas, y las fuentes de señal se ordenan por fiabilidad:

  1. Datos del producto. Nivel de permisos, rol en el espacio de trabajo, plan contratado. Si el producto ya sabe que este usuario es de solo lectura, sobra la encuesta: la segmentación más fiable es la que el usuario no puede declarar mal.
  2. Contexto de llegada. Registro orgánico frente a enlace de invitación es la división más valiosa en los productos de equipo, y encima sale gratis. Quien llega invitado se encuentra un espacio de trabajo que ya existe, y ese hecho por sí solo debería redirigir toda su primera sesión.
  3. Una encuesta de bienvenida de una sola pregunta. Donde se acaban los datos, pregunta: una vez, con tres o cuatro opciones formuladas como trabajos («configurar esto para mi equipo» / «hacer aquí mi trabajo diario» / «revisar informes»). La intención declarada es imperfecta, pero una pregunta corta y honesta rinde más que una suposición larga, y además queda como dato declarado para todos los flujos posteriores. En NudgePath, las respuestas de la encuesta caen en el mismo modelo de segmentos que los atributos del producto, así que «lo que dicen» y «lo que son» alimentan la misma lógica de ramificación.
  4. Comportamiento en la primera sesión. Donde hasta una pregunta sobra, observa qué toca primero y adapta a partir de la segunda sesión. El comportamiento va corrigiendo con el tiempo a los usuarios mal etiquetados: quien se declara administrador y jamás abre los ajustes te está diciendo algo.

Cómo diseñar las tres rutas

Con la tabla y la señal en la mano, cada ruta casi se escribe sola; la disciplina está en lo que dejas fuera de cada una.

La ruta del administrador lleva el arco completo de configuración, pero ordenado para generar impulso: una lista de tareas que va de conectar los datos a ver el primer resultado y de ahí a invitar al equipo, con la invitación planteada por su recompensa («tu equipo verá este panel, no uno vacío»). Los asuntos exclusivos del administrador, permisos y facturación, aparecen en las pantallas donde vienen a cuento, no en el flujo de bienvenida.

La ruta del usuario final se salta la configuración por completo. Ni pasos de integración ni ajustes del espacio de trabajo: su lista de tareas son dos o tres acciones de hacer, completar su primera tarea, localizar el espacio de su equipo y aprender el atajo que le ahorra tiempo cada día. Su recorrido, si lo hay, es el de la tarea, disparado en la pantalla donde ocurre su trabajo.

La ruta del viewer apenas es una ruta: una indicación hacia el informe para el que le invitaron, un tooltip que descifre los dos tecnicismos que aparecen en él y, después, silencio. Aquí la contención es una funcionalidad más: cada paso innecesario que le enseñas a un viewer le entrena para ignorar la guía, y los viewers pesan en más conversaciones de renovación de lo que los equipos suponen.

Evita que la ramificación explote

El fallo clásico del onboarding segmentado no es segmentar poco, sino montar una matriz. Tres roles por cuatro planes por tres sectores son treinta y seis rutas, y treinta y seis rutas significan treinta y cinco que no vas a mantener. Los topes de seguridad:

  • Empieza con dos ramas, creador de la cuenta frente a usuario invitado, y añade la tercera solo cuando la primera división demuestre su valor en las cifras de activación.
  • Ramifica en la entrada y converge pronto. Primeras sesiones distintas y después una única experiencia de producto con momentos conscientes del rol; no universos paralelos que mantener para siempre.
  • Añade una dimensión solo con pruebas. Cuando los datos muestren que un segmento se activa de otra forma por un motivo que una rama nueva resolvería, no porque la web de marketing tenga cinco perfiles de cliente.

Trata los casos sucios a propósito

Las cuentas reales no respetan roles limpios, y esos bordes merecen diseño: el administrador que además es usuario final (en equipos pequeños, casi siempre) debería recorrer primero la ruta de administrador, con un puente explícito hacia la del trabajo diario en cuanto termine la configuración. El rol que cambia a mitad del ciclo de vida, un usuario final ascendido a administrador meses después, necesita que la guía de configuración reaparezca en ese ascenso en lugar de perderse porque «el onboarding ya se ejecutó». Y el usuario invitado que llega antes de que la configuración esté lista necesita un estado vacío elegante («tu espacio de trabajo todavía se está preparando») en vez de un recorrido roto que apunta a datos que aún no existen.

Mide cada ruta con su propia definición de valor

El onboarding segmentado exige medición segmentada, y aquí es donde más equipos tiran por tierra su propio trabajo: una única cifra de activación mezclada esconde una ruta que falla detrás de otra que funciona. Define la activación por rol, la del administrador es el equipo operando con datos reales, la del usuario final su primera tarea completada y la del viewer quizá una segunda visita voluntaria, y lee el embudo de cada segmento por separado. Después experimenta dentro de los segmentos: un test A/B sobre la lista de tareas del usuario final solo entre usuarios finales, con un grupo de control que confirme que la rama supera al flujo genérico al que sustituye. Esa última comparación es la que justifica todo el programa, y ejecutarla segmento a segmento es justo lo que una plataforma como NudgePath está hecha para volver rutinario en vez de heroico.

Un onboarding que sabe con quién habla no es un onboarding de categoría superior: es lo que la versión genérica siempre fingió ser. Empieza por la división en dos que puedas publicar este mes, mide cada ruta con honestidad y deja que las pruebas te digan dónde compensa abrir una tercera rama.

Compartir este artículo

X / TwitterLinkedIn

Preguntas frecuentes

Es el onboarding que encamina a distintos tipos de usuario por primeras experiencias distintas, en lugar de servir a todos un único flujo genérico. En el SaaS de equipo la división canónica es por rol: el administrador que configura el producto, el usuario final invitado que hace en él su trabajo diario y el viewer que consume su resultado. Cada uno recibe una ruta ajustada a su trabajo y a su propia definición de primer valor.

Porque está diseñado, de forma implícita, para el creador de la cuenta, que es una minoría de los usuarios. A los usuarios finales invitados se les pide configurar cosas que ya están configuradas, y a los viewers de solo lectura se les pasea por funcionalidades que no pueden tocar. Ambos aprenden en sus primeros minutos que tu guía no sabe quiénes son; y una guía que no te conoce es una guía que los usuarios dejan de leer.

Por orden de fiabilidad: los datos del producto (nivel de permisos, rol en el espacio de trabajo, plan), el contexto de llegada (registro orgánico frente a enlace de invitación, la señal gratuita más valiosa en los productos de equipo), una encuesta de bienvenida de una sola pregunta formulada como trabajos por hacer y el comportamiento de la primera sesión para ir corrigiendo con el tiempo a los usuarios mal etiquetados. Usa los datos donde existan y pregunta solo donde se acaben.

Sáltate la configuración por completo, porque ya la hizo otra persona. Su lista de tareas son dos o tres acciones de hacer: completar una primera tarea real, localizar el espacio de trabajo del equipo y aprender un atajo que le ahorre tiempo. Su recorrido, si lo hay, es un recorrido corto de la tarea, disparado en la pantalla donde ocurre su trabajo, y no un repaso del producto en el primer inicio de sesión.

Con dos: creador de la cuenta frente a usuario invitado. Esa única división elimina el desajuste más grave y sale barata de publicar. Añade una ruta de viewer u otra dimensión solo cuando los datos de activación por segmento muestren que un grupo falla por un motivo que una rama nueva resolvería: tres roles por cuatro planes por tres sectores son treinta y seis rutas, y treinta y cinco de ellas no se mantendrán jamás.

Define la activación por rol —el equipo del administrador operando con datos reales, la primera tarea completada del usuario final, la vuelta voluntaria del viewer— y lee el embudo de cada segmento por separado, porque una cifra mezclada esconde una ruta que falla detrás de otra que funciona. Después haz tests A/B dentro de cada segmento y mantén un grupo de control en el flujo genérico para confirmar que cada rama supera de verdad a lo que sustituyó.

¿Listo para poner la IA a trabajar en tu soporte?

14 días gratis. Plataforma completa. Movemos tus datos por ti.