{"id":6667,"date":"2026-01-27T10:34:36","date_gmt":"2026-01-27T13:34:36","guid":{"rendered":"https:\/\/minders.io\/?post_type=case-study&p=6667"},"modified":"2026-01-27T10:47:19","modified_gmt":"2026-01-27T13:47:19","slug":"transformacion-producto-buk-amplitude-minders","status":"publish","type":"case-study","link":"https:\/\/minders.io\/es\/case-study\/transformacion-producto-buk-amplitude-minders\/","title":{"rendered":"C\u00f3mo Buk redujo en un 70% el tiempo de solicitud de vacaciones con Amplitude"},"content":{"rendered":"

C\u00f3mo Buk transform\u00f3 un flujo cr\u00edtico y aceler\u00f3 su cultura de producto con Amplitude y Minders<\/h2>\n

Una mejora operativa que se convirti\u00f3 en decisi\u00f3n estrat\u00e9gica<\/h3>\n

Optimizar un flujo puede parecer un cambio menor. Pero cuando ese flujo impacta a m\u00e1s de 1,3 millones de personas cada d\u00eda, deja de ser una mejora puntual. Se convierte en una decisi\u00f3n estrat\u00e9gica. Eso fue lo que ocurri\u00f3 en Buk<\/a>, la plataforma integral de gesti\u00f3n de personas que opera en toda Latinoam\u00e9rica.<\/p>\n

Con el acompa\u00f1amiento de Minders y un uso m\u00e1s profundo de Amplitude<\/a>, Buk protagoniz\u00f3 una transformaci\u00f3n de producto que combin\u00f3 datos, foco estrat\u00e9gico y cambios visibles para sus usuarios. Esta transformaci\u00f3n de producto en Buk con Amplitude y Minders no solo redujo en un 70% el tiempo necesario para solicitar vacaciones.<\/strong> Tambi\u00e9n cambi\u00f3 la forma en que sus equipos entienden el producto, toman decisiones y priorizan lo que se construye.<\/p>\n

Cuando lo b\u00e1sico define toda la experiencia<\/h3>\n

Buk es una suite de gesti\u00f3n de personas. Centraliza procesos como remuneraciones, beneficios, capacitaciones y flujos administrativos. Su modelo es B2B2C: las empresas contratan la plataforma, pero quienes la usan son los colaboradores.<\/p>\n

En ese contexto, acciones como pedir vacaciones o ver una liquidaci\u00f3n son expectativas b\u00e1sicas. No son funcionalidades \u00abnice to have\u00bb. Si esos flujos generan fricci\u00f3n, afectan la percepci\u00f3n de toda la plataforma.<\/p>\n

Por eso, el equipo de producto empez\u00f3 a observar con m\u00e1s atenci\u00f3n esas interacciones cotidianas.<\/p>\n

\"transformaci\u00f3n<\/p>\n

Datos que incomodan, decisiones que desbloquean<\/h3>\n

El primer s\u00edntoma apareci\u00f3 en los datos. El flujo de solicitud de vacaciones mostraba que los usuarios tardaban m\u00e1s de un minuto en encontrar d\u00f3nde iniciar el tr\u00e1mite. No era por complejidad, sino por ubicaci\u00f3n: estaba escondido en la ficha del colaborador, lejos del punto de entrada.<\/p>\n

Ese dato incomod\u00f3. Pero la fricci\u00f3n m\u00e1s limitante estaba en otro lado: el acceso a la informaci\u00f3n. Antes de usar Amplitude de forma estructurada, los Product Managers depend\u00edan de ingenier\u00eda para casi cualquier consulta. Las preguntas requer\u00edan queries SQL y varias iteraciones.<\/p>\n

Ese proceso era lento, consum\u00eda foco t\u00e9cnico y dificultaba sostener ciclos de mejora continua. Aunque Buk ya impulsaba una cultura de Discovery Continuo, la velocidad no era suficiente para acompa\u00f1ar al negocio.<\/p>\n

Datos accesibles para equipos que deciden m\u00e1s r\u00e1pido<\/h3>\n

El objetivo era claro: acompa\u00f1ar el crecimiento con una forma de trabajar que permitiera aprender r\u00e1pido y decidir con evidencia. Para lograrlo, los equipos necesitaban explorar informaci\u00f3n por su cuenta, cruzar datos y validar impacto sin fricciones.<\/p>\n

Amplitude era la herramienta adecuada, pero el desaf\u00edo era su implementaci\u00f3n. Ah\u00ed comenz\u00f3 el trabajo conjunto con Minders.<\/p>\n

La transformaci\u00f3n de producto en Buk con Amplitude y Minders se plante\u00f3 como un camino estrat\u00e9gico, con foco en el cambio cultural antes que en el despliegue t\u00e9cnico.<\/p>\n

Implementaci\u00f3n con foco: menos dashboards, m\u00e1s preguntas<\/h3>\n

La adopci\u00f3n de Amplitude no fue masiva desde el inicio. Junto a Minders, Buk empez\u00f3 por equipos concretos con casos de uso claros: beneficios, experiencia del colaborador y workflows. Todos con preguntas bien definidas y ganas de usar datos.<\/p>\n

Antes de visualizar, se orden\u00f3 la base. Se defini\u00f3 una taxonom\u00eda clara, se establecieron procesos para formular preguntas de negocio y se acordaron criterios sobre qu\u00e9 medir y por qu\u00e9.<\/p>\n

La premisa era simple pero exigente: si no hab\u00eda una pregunta clara, no se marcaba nada. Gracias a eso, Amplitude se transform\u00f3 en una herramienta para pensar el producto.<\/p>\n

Caso vacaciones: cuando un dato impulsa una decisi\u00f3n<\/h3>\n

Con esa base, el equipo volvi\u00f3 a analizar el flujo de vacaciones. El dato segu\u00eda siendo claro: m\u00e1s de un minuto para iniciar el tr\u00e1mite. La pregunta correcta fue: \u00bfD\u00f3nde esperan los usuarios resolver esto?<\/p>\n

El an\u00e1lisis mostr\u00f3 que el portal principal era el punto de entrada para la mayor\u00eda de los colaboradores. Pero el acceso a vacaciones estaba en otra secci\u00f3n. La hip\u00f3tesis fue simple: si se mov\u00eda el flujo al portal principal y se simplificaba el acceso, la fricci\u00f3n deber\u00eda caer.<\/p>\n

Se implementaron accesos directos mediante modales y se redise\u00f1\u00f3 la navegaci\u00f3n. Gracias a Amplitude, la validaci\u00f3n fue inmediata.<\/p>\n

Resultados claros y escalables<\/h3>\n

Los cambios generaron impacto medible:<\/p>\n