Por qué los tours de producto dejan de funcionar a la semana

Los tours de producto funcionan en la primera visita: le enseñan a un usuario nuevo dónde está cada cosa. Después dejan de funcionar por tres motivos. La interfaz cambia y el tour sigue señalando la anterior. Los usuarios llegan con tareas que no estaban en el guion. Y a la segunda semana nadie quiere aprender la pantalla: quieren que una cosa concreta quede hecha.

Nada de esto significa que los tours no sirvan. Significa que resuelven un problema pequeño, y la mayoría de los equipos pequeños les piden uno mucho más grande: “que los clientes dejen de escribirnos”. Este artículo mira dónde está esa frontera, con los datos que existen, y qué poner del otro lado.

¿Para qué sirve un tour de producto?

Un tour sirve para orientarse. La primera vez que alguien abre tu producto no sabe que los reportes están en el menú de la izquierda ni que las integraciones están en la configuración. Tres tooltips bien colocados le ahorran un minuto dando vueltas, y ese minuto cuenta el primer día.

Además, los tours funcionan mejor de lo que dice su fama cuando es el usuario quien los pide. El informe de benchmarks 2024 de Chameleon, hecho sobre casi 300 millones de interacciones dentro de aplicaciones, encontró que los tours que la gente abría por su cuenta desde una checklist se completaban un 64 % de las veces. Es el mejor dato a favor de los tours, y dice algo útil: un tour ayuda cuando responde a una pregunta que el usuario ya tiene.

Así que, si tienes un tour de bienvenida, consérvalo. Hazlo corto, deja que la gente lo inicie cuando quiera y no le pidas más que eso.

¿Cuántos usuarios terminan un tour de producto?

Más o menos uno de cada tres. El mismo informe da la otra mitad de la historia: la tasa media de finalización de todos los tours fue del 33,5 %. Dos de cada tres personas que ven un tour no llegan al último paso.

La longitud lo empeora. En los datos de Chameleon, los tours de cinco pasos bajaron a un 21,6 % de finalización, y la cifra siguió cayendo con cada paso extra. Los usuarios también los aplazan: el informe cuenta 2,4 millones de tours pospuestos en un solo año.

Un tour que dos tercios de los usuarios cierran antes de tiempo no sirve para quitarte trabajo de soporte. Lo que explique ese tour, la mayoría no lo vio, y te lo va a preguntar a ti.

Primer motivo: la interfaz cambia y el tour no

Un tour es un guion pegado a tu interfaz. Dice “haz clic aquí, luego aquí, luego aquí”, y cada aquí es un elemento de la página. Cuando publicas un rediseño, le cambias el nombre a un menú o mueves un ajuste a otra pestaña, el guion no se entera.

En un equipo de tres personas esto pasa continuamente. Publicas cada semana. Nadie tiene los tours como responsabilidad: los configuró una vez quien tenía una tarde libre. El resultado es un tooltip que señala un botón que ya no está ahí, o un tour que se detiene en el paso tres porque el elemento que espera ya no existe. El usuario ve un producto que parece roto, justo cuando intentaba aprenderlo.

Claro que puedes mantener los tours. Pero eso es una segunda copia de tu interfaz que hay que tener sincronizada, y lo que querías ahorrarte era tiempo.

Segundo motivo: el cliente toma caminos que no previste

Un tour cubre los caminos que imaginaste cuando lo escribiste. Los clientes llegan con los que no imaginaste.

La encuesta de Gartner de 2024 sobre el recorrido de atención al cliente trata del autoservicio en general, no de los tours, pero el patrón es el mismo. Solo el 14 % de los problemas de atención al cliente se resolvió del todo con autoservicio. Incluso en los problemas que los propios clientes llamaban “muy simples”, solo el 36 %. El 45 % de quienes empezaron por el autoservicio dijo que la empresa no entendía lo que intentaban hacer. Y el motivo de fallo más común, en el 43 % de los casos, fue que no encontraban contenido relevante para su problema.

Ese es el hueco que un tour no puede cerrar. Tú escribiste “cómo crear tu primer reporte”. El cliente quiere un reporte filtrado por un equipo, enviado cada lunes, a alguien que todavía no es usuario. Cada parte está en tu producto. Ningún tour recorre exactamente ese camino, y un tour no puede preguntarle al usuario qué quería decir.

Tercer motivo: a la segunda semana nadie quiere aprender

Hay un problema más discreto. Un tour enseña, y la mayoría de los usuarios no quiere que le enseñen. Abrió la app para hacer algo.

Nielsen Norman Group lo estudió en tutoriales de aplicaciones móviles. Quienes leían los tutoriales no completaban las tareas más rápido que quienes los saltaban, y además las valoraban como más difíciles. Una app móvil no es un panel B2B, pero la dirección es conocida: una lección que llega antes de que haga falta no se queda.

A la segunda semana tu usuario ya no está explorando. Intenta invitar a un compañero, cambiar de plan o conectar una integración, casi siempre porque otra cosa depende de eso. Un tour, incluso uno perfecto, responde a “¿qué hay en esta pantalla?”. Su pregunta es otra: “¿me ayudas a hacer esto?”.

Esa pregunta antes acababa en tu bandeja de entrada, o en una llamada donde compartes pantalla y haces los clics por él. Ahí se van las horas; lo que cuesta de verdad que el founder haga el soporte le pone número.

¿Qué conservar de tus tours y qué reemplazar?

Conserva los tours para la primera visita y para las funciones que el usuario explora a propósito; reemplázalos cuando el usuario tiene una pregunta o una tarea. Esta es una forma de ordenar tu ayuda según el momento al que sirve. Úsala como plantilla: haz una lista de lo que tu producto muestra hoy a los usuarios y pon cada pieza en una fila.

Momento	Qué quiere el usuario	Qué funciona	Encaje del tour
Primera visita	Un mapa del producto	Un tour corto, de tres o cuatro pasos	Bueno
Explorar una función	Entender qué hace	Un tour que inicia cuando quiere, o un artículo de ayuda	Bueno, si lo elige él
Una pregunta (“¿tienen X?”)	Una respuesta	La documentación, o un asistente que responde con ella	Malo
Una tarea (“cámbiame el plan”, “añade un monitor”)	Que quede hecha	Algo que abra la pantalla y rellene el formulario	Malo
Una tarea que salió mal	Una persona	Pasar la conversación a tu equipo, con el contexto	Ninguno

En muchos equipos pequeños, los tours cubren las dos primeras filas y la bandeja de soporte se come las tres últimas. En esas tres se va la semana del founder.

Dónde encaja un asistente que actúa

Las filas que un tour no cubre tienen algo en común: el usuario sabe lo que quiere, lo dice con sus palabras, y el trabajo son unos pocos pasos dentro de tu propia app.

Para ese problema está hecho aside. Tu página registra unas pocas acciones, funciones que ya tienes, como invitar a un compañero, cambiar de plan o crear un monitor, cada una con un nombre y una descripción. Cuando un usuario pide algo, aside elige la acción y sus argumentos, y la ejecuta el propio código de tu página: se abre la pantalla y el formulario se rellena delante del usuario. El usuario pulsa el botón que guarda, envía o borra. Si no hay una acción para lo que pide, aside responde con tu documentación, dice cuándo no sabe algo y pasa la conversación a tu equipo.

Esto aguanta mejor que un tour por dos motivos. La acción es tu propio código: si mueves un ajuste, actualizas una función, igual que actualizas cualquier otra parte del código. Y parte de lo que pide el usuario, no de un camino que tú adivinaste. Cómo dejar que un asistente actúe en tu app sin darle las llaves explica cómo escribir esas funciones.

Si estás comparando las opciones una al lado de la otra, la comparación completa está en Chatbot, tour de producto o asistente dentro de la app: cuál te quita trabajo.

Un siguiente paso concreto

Abre tu bandeja de soporte y toma los últimos veinte mensajes de usuarios que ya habían visto tu tour. En cada uno, pregúntate: ¿era una pregunta o una tarea? (aquí tienes un método de 20 minutos)

Si la mayoría son preguntas, a tu documentación le falta trabajo, y un tour tampoco lo va a arreglar. Si la mayoría son tareas, el tour hizo su parte: sabían dónde estaba cada cosa. Lo que necesitaban era alguien que lo hiciera con ellos. Esas tareas, escritas como unas pocas funciones, son el punto donde el trabajo empieza a salir de tu mesa.