Una herramienta no se adopta porque funcione bien, se adopta porque ahorra más trabajo del que exige aprenderla. Si usarla es más lenta que el método anterior, aunque sea unos días, el equipo vuelve a lo de siempre. La adopción real depende de la fricción del primer uso, no de cuántas funciones tenga la herramienta.
Que algo funcione técnicamente y que el equipo lo use son dos cosas distintas. Una herramienta puede procesar bien la información, no tener errores, y cumplir exactamente lo que se pidió al construirla, y aun así terminar sin uso real semanas después. El equipo no adopta una herramienta nueva porque funcione bien, la adopta porque le ahorra más trabajo del que le exige aprenderla.
El equipo no adopta una herramienta nueva porque funcione bien, la adopta porque le ahorra más trabajo del que le exige aprenderla.
La razón casi siempre es la misma: el equipo ya tenía una forma de hacer ese trabajo, aunque fuera manual o incómoda. Cambiar esa forma de trabajar tiene un costo, y ese costo se paga antes de ver cualquier beneficio. Mientras el beneficio no sea evidente de inmediato, el costo de cambiar pesa más que la promesa de que después será mejor.
Esto explica por qué construir la herramienta correcta no basta. También hay que construir el momento en que el equipo decide que vale la pena pagar ese costo de cambio.
La diferencia no está en cuántas funciones tiene, está en qué tan rápido el equipo siente que le ahorró algo. Una herramienta que resuelve una sola cosa, pero lo hace más rápido que el método anterior desde el primer uso, se adopta con más facilidad. Una herramienta completa que exige aprender varios pasos antes de ver el beneficio, no.
Hay una tentación natural a agregar más funciones antes de lanzar algo nuevo, pensando que así se justifica mejor el esfuerzo de cambiar. El efecto suele ser el contrario. Más funciones significan más que aprender antes del primer beneficio percibido, y eso empuja la decisión de adopción hacia el lado equivocado.
Lo que sí ayuda es que la herramienta se parezca, en su primer uso, a lo que el equipo ya sabe hacer. Cuanto más cerca esté del hábito existente, menos fricción hay que superar para empezar a usarla.
La primera vez que alguien usa una herramienta nueva es la más importante de todas. Si esa primera experiencia es más lenta o más confusa que el método anterior, la persona saca una conclusión rápida: esto no vale el esfuerzo. Esa conclusión es difícil de revertir después, aunque la herramienta mejore con el uso.
El equipo no evalúa la herramienta en abstracto. La evalúa contra lo que ya sabe hacer, en el momento exacto en que decide si sigue con el método conocido o prueba el nuevo. Cualquier fricción en ese momento específico pesa más que todas las ventajas que la herramienta pueda tener a largo plazo.
Por eso reducir pasos, evitar configuración inicial larga, y hacer que el primer resultado útil aparezca rápido importa más que pulir funciones que el equipo va a descubrir mucho después, si es que llega a descubrirlas.
No lo mide que exista una cuenta creada para cada persona del equipo. Eso mide acceso, no uso. La adopción real se mide por si el equipo sigue usando la herramienta semanas después, sin que nadie se lo recuerde, para el trabajo real y no solo para una demo inicial.
Esta es la prueba más honesta: si hay que insistir para que alguien la use, todavía no fue adoptada, sin importar cuántas cuentas se crearon el primer día.
En Progresus, de más de 4.600 tickets de soporte entre 2020 y 2026, solo 15 mencionan IA, Breeze o Copilot. No hay todavía un dato propio que mida adopción de herramientas internas de forma directa, pero esa ausencia de tráfico es coherente con un patrón de bajo uso sostenido: muchas herramientas construidas rápido nunca llegan a un uso lo bastante constante como para generar una duda de soporte.
En Progresus, de más de 4.600 tickets de soporte entre 2020 y 2026, solo 15 mencionan IA, Breeze o Copilot.
Antes de mejorar la herramienta, pregunta directamente a dos o tres personas del equipo qué paso concreto les resulta más lento con ella que con el método anterior. Casi siempre ahí está la razón real del abandono, y casi nunca es la razón que se había asumido al construirla.
Imponer el uso de la herramienta resuelve el síntoma, no la causa. El equipo la usará mientras lo vigilen, y volverá al método anterior en cuanto la presión baje, porque el problema de fondo de fricción sigue sin resolverse. Forzar la adopción sin resolver esa fricción solo pospone la conversación incómoda.
El camino más efectivo suele ser reducir la herramienta a lo mínimo que ya supera al método anterior desde el primer uso, y agregar el resto después, una vez que el equipo ya sintió el beneficio inicial. Es más fácil pedirle a alguien que use algo un poco más, que convencerlo de empezar a usar algo desde cero. Ese primer paso pequeño, bien elegido, suele ser lo que decide todo lo que viene después.
Casi siempre porque usarla exige más esfuerzo del que ahorra, al menos en el primer uso. El equipo compara el costo de aprender algo nuevo contra el costo de seguir con el método conocido, y elige el que le cuesta menos hoy.
Si quieres evaluar si vale la pena seguir invirtiendo en adoptarla, puedes usar una checklist para entender por qué tu equipo no adopta la app nueva. También puedes revisar por qué el equipo no usa la nueva herramienta interna, dentro de la guía completa de Progresus Apps sobre apps con IA sin método.