Los líderes se enfrentan a diversos retos al momento de identificar un único indicador clave de rendimiento (KPI) que unifique el comportamiento dentro de un grupo importante de atención al cliente y que logre resultados efectivos para las organizaciones.
Las métricas de rendimiento se encuentran entre las herramientas más poderosas de los gerentes: establecer los objetivos correctos y realizar un seguimiento preciso del progreso puede ayudarlo a llevar su negocio a donde quiere que vaya. Sin embargo, para ser efectivos, los objetivos y las métricas deben ser claros y simples, y cuanto menos, mejor.
En nuestra empresa en crecimiento, hemos aprendido que la simplicidad aumenta nuestras probabilidades de lograr lo que queremos. Cuando nuestras metas eran demasiado numerosas y demasiado complejas, las decisiones de los colaboradores no se sincronizaban dentro de los equipos o entre ellos, lo que significaba que los grupos y las personas tiraban en varias direcciones y no lograban producir los resultados deseados a escala.
Por lo tanto, nos propusimos identificar un único indicador clave de rendimiento (KPI) que unificaría el comportamiento dentro de un grupo importante de atención al cliente, la unidad que diseña, crea y administra nuestra tienda en línea, y también podría servir como moneda compartida entre equipos, permitiéndonos hacer inversiones más inteligentes en el negocio.
Por qué los KPI incorrectos condenan la transformación digital de los líderes
Pero nos dimos cuenta de que apostar por un KPI sin ponerle algún tipo de verificación podría tener graves consecuencias no deseadas. Sabíamos que cualquier objetivo principal tenía que estar limitado por una restricción, como en “Maximizar X sin reducir Y”.
Esta es la historia de cómo Agoda, la subsidiaria con sede en Asia del grupo de viajes en línea Booking Holdings, se abrió camino hacia un enfoque único de “KPI + restricción” que nos ayuda a administrar una buena parte de nuestro negocio.1
Error para llegar allí; los KPI que desarrollamos y probamos a lo largo del camino promovieron comportamientos y resultados tanto positivos como contraproducentes.
Sin embargo, gradualmente encontramos nuestros principios rectores, los implementamos, mejoramos nuestros resultados comerciales y fomentamos una cultura de aprendizaje y cooperación en el proceso.
Como creemos que nuestras experiencias y conocimientos pueden ser útiles para otras empresas, tanto dentro como fuera del comercio electrónico, los compartimos aquí.
Desde los primeros días de la empresa, Agoda se ha centrado en mejorar continuamente su interfaz o escaparate, el sitio web y las aplicaciones móviles a través de los cuales los clientes buscan, seleccionan y compran productos de viaje, para convertir las visitas al sitio web en ventas.
Al aumentar su tasa de conversión, una empresa digital puede orientar su marketing de manera más efectiva, porque los clientes existentes son más fáciles de atraer que los nuevos. Los ingresos de los clientes convertidos se pueden implementar para hacer que el marketing sea cada vez más eficiente, lo que se traduce en más conversiones.
A la luz de estos beneficios, la tasa de conversión puede parecer el KPI primario perfecto para nuestro negocio, con el retorno de la inversión como una restricción obvia. (Después de todo, ¿por qué perseguir conversiones que son extremadamente difíciles de obtener y que probablemente no valdrán la pena más tarde?) Para calcular la tasa de conversión, normalmente divide los números de tráfico por las ventas.
Desafortunadamente, medir el tráfico no es tan sencillo como parece; es complicado por numerosos factores, incluidos los bots difíciles de manejar, el marketing agresivo y las muchas formas indirectas en que los clientes pueden acceder al sitio.
Aun así, sabíamos que queríamos cosechar los beneficios del aumento de las conversiones y hacerlo más rápido que la competencia. Pero, ¿cómo lo haríamos y seguiríamos nuestro progreso con precisión, dado lo imprecisos que podrían ser esos números de tráfico? Para resolver eso, comenzamos a realizar pequeños experimentos, uno tras otro, para probar los cambios de plataforma que teníamos razones para creer que aumentarían las conversiones.
Utilizamos pruebas A/B, que consistían en cambiar un solo elemento (como un color, un botón, una imagen o un mensaje, como “¡Las habitaciones son limitadas!” o “¡Buena elección!”) para un subconjunto de nuestros usuarios y comparar los resultados con los de un grupo de control. Los experimentos “ganadores” (aquellos que generaron más reservas que el control) se incorporaron a nuestra codificación y se extendieron a los clientes de manera más amplia.
Encontrar esos ganadores fue difícil. A menudo, nuestras hipótesis sobre lo que mejoraría las ventas resultaron ser incorrectas. Alrededor del 80% al 90% de nuestros experimentos fueron buenas ideas de personas inteligentes, pero no mejoraron nuestro negocio; muchos en realidad empeoraron los resultados.
Por ejemplo, si les decimos a los clientes: “¡Reserve ahora o esta habitación desaparecerá!” podemos motivarlos a comprar la habitación, o podemos molestarlos y hacer que abandonen el proceso de reserva. Además, hacer un cambio de software podría introducir un error del que no estábamos al tanto, ese tipo de fallas fueron parte del proceso.
La experimentación nos ayudó a determinar qué iba a funcionar y qué no. Inicialmente, realizamos experimentos únicos, pero para aprender de ellos de manera más efectiva, creamos un sistema centralizado que nos permitía registrar y analizar los resultados de las pruebas en detalle y luego realizar y medir cambios en el sitio web.
Este “motor” de experimentos nos brindó una forma consistente y escalable de tomar decisiones y evaluar su impacto en la conversión, y nos brindó una métrica primaria temprana con la que trabajar: la velocidad de experimentación.
Dada la importancia de los experimentos para nuestras decisiones iniciales, nos dimos cuenta bastante pronto de que necesitábamos aumentar la velocidad de nuestro motor de experimentos.
Así que establecimos la velocidad como un KPI principal para enfocar nuestros esfuerzos de conversión, definiéndola como la cantidad de experimentos que realizamos cada trimestre. Sabíamos que no había forma de que pudiéramos crecer a un ritmo significativo si ejecutábamos muy pocos de ellos, sin importar cuán positivos fueran los resultados para cada uno.
Al dividir nuestros experimentos con mayor precisión, probando un elemento a la vez para que pudiéramos aislar y solucionar problemas más rápido, traer gerentes expertos en ingeniería y gestión de procesos para simplificar las cosas, pasamos de unas pocas docenas de experimentos iniciales por cuarto a más de 1,000 solo unos pocos trimestres después.
Si bien este enfoque nos ayudó a identificar muchas formas de aumentar nuestra tasa de conversión, también provocó que el código de programación de nuestro sitio se deteriorara debido a la frecuencia con la que se realizaban los cambios.
En resumen, la cantidad de errores explotó. Como resultado, introdujimos una restricción en el KPI: la calidad del código, medida por el número y la gravedad de los errores.
Potenciar una cultura de datos desde adentro hacia afuera
El impulso de la velocidad, con la restricción de calidad, cambió la forma en que operamos. Nos llevó a revisar nuestra arquitectura de implementación para ver cómo podíamos implementar cambios más rápido, pero no tan rápido como para causar daños.
Creamos herramientas de software para unificar, automatizar, acelerar la implementación y el monitoreo de código en cientos de miles de servidores en nuestros centros de datos en todo el mundo.
Muchas empresas implementan código nuevo solo semanalmente o incluso con menos frecuencia; lo hacemos cuatro o cinco veces al día. Para apoyar ese ritmo, repensamos nuestros sistemas, personal y estructura organizacional.
A medida que aumentaba la cantidad de errores, tuvimos que desarrollar mejores técnicas de control de calidad. Invertimos mucho en nuestro centro de operaciones de red, que realiza un seguimiento del rendimiento de nuestra plataforma para alertarnos cuando se producen desviaciones significativas del comportamiento normal del sitio web.
Siempre hay desviaciones, que pueden ser causadas por cambios internos o por factores externos; solo un buen dominio de las estadísticas puede ayudarlo a determinar qué desviaciones son relativamente normales y cuáles son indicaciones de problemas reales.
Así que desarrollamos sistemas para encontrar cambios estadísticamente significativos, incluso en patrones menores. También construimos herramientas de monitoreo para mapear cambios de código a patrones de rendimiento para que pudiéramos analizar las causas raíz y resolver problemas más rápido. E invertimos en sistemas de datos para rastrear el tráfico en cada mercado, identificar anomalías significativas y alertar al centro de operaciones de la red, ayudándonos a ver cosas que de otro modo no hubiéramos visto y responder rápidamente.
Centrarse en aumentar la velocidad cumplió un propósito fundamental: nos ayudó a realizar muchos más experimentos que impulsaron las reservas hasta cierto punto.
Pero a veces creó los incentivos equivocados. Los equipos podían obtener una puntuación alta en velocidad (y ser recompensados por ello) ejecutando muchos experimentos pequeños, independientemente de si estos experimentos se correlacionaban con aumentos significativos en la tasa de conversión de la plataforma.
Para determinar qué cambios brindaron las mayores oportunidades de conversión, creamos herramientas de análisis de datos más sólidas.2 Gradualmente, quedó claro que para fomentar esas oportunidades más grandes, necesitábamos cambiar nuestro KPI principal.
Aquí nueve conclusiones para su negocio:
Así que pasamos a una métrica que llamamos reservas incrementales por día o IBPD. Mantuvimos la misma restricción: minimizar la cantidad y la gravedad de los errores.
Nuestro nuevo KPI era bastante simple: si una prueba A/B tenía n1 reservas en la variante A (el grupo de control, sin cambios con respecto a las prácticas anteriores) y n2 reservas en la variante B (donde se realizó el cambio), el impacto de IBPD podría ser calculado de la siguiente manera:
Es probable que tanto la versión A como la B produzcan reservas; queríamos seleccionar la variante más productiva.
Este KPI fue diseñado para recompensar a los equipos de acuerdo con el valor generado por sus experimentos. Establecimos equipos ágiles de scrum y les dimos un objetivo para los IBPD. Esperábamos que este enfoque empujara a los equipos a realizar experimentos más grandes y ambiciosos en lugar de simplemente más experimentos.
Estábamos buscando los experimentos que generarían la mayor cantidad de conversiones. Para contrarrestar el miedo al fracaso, que puede llevar a las personas a hacer apuestas seguras y crear menos valor, alentamos activamente a los equipos a probar cosas grandes incluso si eran riesgosas y ajustamos los objetivos para aquellos que lo hicieron, dándoles espacio para fallar sin penalización.
Seis formas en que los líderes pueden adaptarse al lugar de trabajo de 2022
De hecho, el enfoque IBPD generó beneficios. Como era de esperar, los equipos cambiaron su enfoque de la cantidad a la calidad. También comenzaron a desarrollar y compartir mejores prácticas.
Estos conocimientos fueron más fáciles de identificar una vez que nuestros experimentos fueron más precisos y los equipos estaban ansiosos por intercambiar historias de éxito, ya que todos buscaban buenas ideas sobre las cuales construir.
Por ejemplo, aprendieron que era fundamental brindar a los clientes la cantidad correcta de opciones: con muy pocas o demasiadas opciones, las personas no seleccionarían una habitación.
Después de extraer este principio de nuestro sistema centralizado para registrar y analizar los resultados, los equipos comenzaron a aplicarlo a decisiones sobre numerosas características del sitio web: calcular cuántos hoteles mostrar en respuesta a una búsqueda, la cantidad correcta de fotos para mostrar en el galería, etc.
El nuevo KPI también tuvo importantes implicaciones de gestión. Para empezar, nos permitió comparar las tasas de conversión generadas por diferentes equipos para que pudiéramos determinar dónde invertir más y dónde retroceder o cambiar de táctica.
Si bien este enfoque hizo que los equipos fueran más competitivos, también los hizo más cooperativos: descubrieron que si compartían lo que aprendieron, otros equipos compartirían ideas con ellos, lo que ayudó a todos a alcanzar sus objetivos.
Pasar a los IBPD para el escaparate también nos ayudó a ver cómo el KPI podría ayudar en la toma de decisiones en toda la empresa. Tome el marketing, por ejemplo. Allí, la métrica principal fue inicialmente la cantidad de visitantes del sitio que las campañas generaron durante un período específico y el ROI (nuestro rendimiento de visitantes para nuestros costos de marketing) fue la restricción.
Esa forma de medir el éxito tenía sus límites, porque un aumento en el tráfico no necesariamente aumentaba las conversiones. A medida que el equipo de marketing comenzó a realizar experimentos con IBPD, los resultados de conversión mejoraron.
Si una campaña promocional para un mercado específico en un momento específico atrajo visitantes, las pruebas A/B de diferentes enfoques dentro de ese mismo mercado y período de tiempo mostraron qué tipos de campañas realmente produjeron más reservas. Si bien los factores externos podrían ayudar o dificultar una campaña en particular, en general, el enfoque A/B nos ayudó a determinar con mayor precisión qué campañas funcionaron. Luego podríamos probarlos también en otros mercados.
En todos los grupos, la métrica IBPD permitió a la gerencia realizar compensaciones más inteligentes (por ejemplo, recuento de ingenieros frente a gastos de marketing), por lo tanto, optimizar las inversiones de la empresa.
Pudimos determinar no solo cuánta conversión habíamos agregado en cada trimestre y cómo se comparaba con el trimestre anterior, sino también qué factores habían contribuido a ese éxito.
Compartir un KPI entre varios grupos también nos permitió agregar resultados en el tablero de nuestra empresa. Tener esa visión impulsó aún más la toma de decisiones sobre inversiones internas.
Además de utilizar los IBPD para comparar las contribuciones de los equipos y asignar recursos, podríamos evaluar el desempeño de los gerentes de productos.
Cuando no alcanzaron sus metas, nuestra primera respuesta fue moverlos a un área más productiva para ver si su desempeño mejoraba. Efectivamente, hicimos pruebas A/B a nuestros gerentes de producto.
Si bien cambiar a reservas incrementales por día como nuestro KPI principal fue un importante paso adelante, debatimos constantemente si íbamos en la dirección correcta: ¿Qué pasaría si, como con la velocidad, la nueva métrica causara algunos comportamientos que no queríamos? ¿Deberíamos estar midiendo algo más? ¿Qué nos faltaba?
En cualquier caso, sabíamos que los IBPD no resolvían todos los problemas de una vez por todas. Por ejemplo, el problema de los errores nunca había desaparecido por completo. Éramos buenos solucionando errores grandes que eran bastante visibles.
Pero abordar los errores pequeños no era atractivo para los equipos, porque eran más difíciles de encontrar y corregirlos no producía un aumento significativo en las reservas. Sin embargo, con suficientes errores pequeños, el sitio sufriría la muerte por miles de cortes, ya que el impacto agregado fue significativo: casi todos los usuarios encontrarían un error.
Eventualmente nos dimos cuenta de que teníamos que establecer un umbral claro incluso para errores pequeños; toleraríamos sólo un cierto número en un momento dado. Si el número aumentara más allá del límite, los equipos tendrían que corregir los errores para obtener sus bonos de KPI completos, incluso si el impacto de IBPD de los errores individuales fuera pequeño.
Más polémico, y más difícil, fue el debate sobre cómo usar las estadísticas para promover un comportamiento que fuera verdaderamente beneficioso para nuestro negocio.
En una plataforma bien optimizada, la gran mayoría de los experimentos ganadores producen IBPD de menos del 1 %. (Cuanto más optimizábamos el programa, más difícil se volvía identificar los cambios que lo mejorarían aún más).
Y era difícil detectar si estos pequeños efectos eran de hecho logros reales o simplemente ruido estadístico. Necesitábamos abordar este problema para asegurarnos de que los gerentes de producto estuvieran tomando las decisiones correctas.
Una vez más, los incentivos demostraron ser problemáticos: queríamos que los equipos validaran que las ganancias aparentes estaban directamente relacionadas con el valor comercial real, pero descubrimos que cuando las bonificaciones estaban vinculadas a los IBPD, los equipos estaban sesgados a tratar cualquier experimento con resultados positivos como una ganancia, independientemente de si el impacto fue significativo o simplemente ruido. Esta fue una respuesta de comportamiento natural, y no produjo resultados que beneficiaran a la empresa en su conjunto.
Así que refinamos aún más nuestro KPI, llamándolo IBPD imparcial o UBI. Así es como funciona: cada vez que marcamos un experimento como ganador, antes de implementar el cambio, ejecutamos el mismo experimento nuevamente durante un período determinado (generalmente una semana).
Los resultados de esa ejecución de evaluación posterior se tienen en cuenta en el desempeño del equipo. Si la primera ejecución parece positiva como resultado del ruido estadístico, es igualmente probable que la ejecución de evaluación parezca negativa, por lo que con una muestra lo suficientemente grande, la varianza se anula. Cuando esto sucede, los UBI son cero y el equipo no avanza hacia el logro de sus objetivos de KPI (o su bonificación).
Reconociendo el riesgo de que sus experimentos puedan producir UBI cero o incluso negativos, los equipos ahora tienen un incentivo para tratar solo aquellos experimentos que producen resultados verdaderamente positivos como victorias.
En lugar de seguir adelante con todos los experimentos que parecen positivos, los equipos ahora observan mucho más de cerca sus experimentos para determinar si los cambios que están realizando en el sitio realmente alteran el comportamiento del cliente.
Incluso este enfoque no es una solución perfecta. A escala, en varios equipos, las UBI funcionan bien. Pero si un equipo individual ejecuta solo 10 o 20 experimentos por trimestre, puede encontrar mucho ruido, ya que este equipo no tiene suficientes pruebas para cancelar la varianza de manera efectiva. (Nuestra regla general: se necesitan al menos 50 experimentos para eliminar la varianza).
Además, los equipos pueden ser reacios a aceptar resultados que no son claros, ejecutando experimentos una y otra vez para obtener mejores estadísticas. Esto reduce la velocidad, llevándonos de vuelta a donde empezamos. Al igual que con la elección de nuestros clientes, hay una cantidad adecuada de pruebas: muy pocas producen resultados inexactos, mientras que demasiadas nos ralentizan e impiden el crecimiento.
Todo esto es para decir que nuestro KPI principal sigue siendo un trabajo en progreso. Sin embargo, a pesar de sus limitaciones, hemos encontrado que el sistema UBI es bastante útil en general.
Los comportamientos de los equipos ahora están más alineados con la creación de valor comercial a través de las conversiones, sin afectar significativamente la velocidad.
Los UBI nos permiten medir cuánto contribuyen los equipos y las personas a los ingresos de la empresa trimestre a trimestre, ya que a cada reserva incremental se le puede dar un valor en dólares. Los gerentes ahora pueden tomar decisiones basadas en datos sobre el desempeño de quién recompensar y dónde invertir más recursos en el negocio.
Nuestro trabajo para definir un KPI principal + restricción en el front-end y en marketing ha calado en la empresa. Hoy en día, este enfoque para la toma de decisiones se puede encontrar en cada parte de Agoda, incluso en áreas que tradicionalmente no se centran en la experimentación.
En nuestra organización de compra de inventario, por ejemplo, asignamos tareas a miembros del personal en 35 países, y el impacto de cada tarea en los resultados comerciales se estima en puntos de margen (un indicador indirecto de UBI en una parte del negocio que no se mueve). la aguja en las reservas).
La restricción que hemos impuesto es reducir el comportamiento adverso de la pareja. (Queremos que nuestro equipo de compras de inventario sea agresivo para que podamos reducir los costos y aumentar los márgenes de ganancias, pero si presionamos demasiado, los socios hoteleros podrían dejar de trabajar con nosotros por completo).
Realizamos experimentos para evaluar qué estrategias se correlacionan con las mejores aumenta el margen manteniendo relaciones fructíferas con los socios.
Un resultado cultural predecible de nuestro enfoque en los KPI es que dedicamos mucho tiempo a hablar sobre la medición al comienzo de cada proyecto, y luego nunca dejamos de hablar de ello para responsabilizar a los equipos.
Otro resultado es un poco más sorprendente: la jerarquía ahora importa menos en nuestra toma de decisiones. Discutir sobre cómo medir el éxito se basa mucho menos en el ego que discutir sobre las decisiones en sí mismas, y las pruebas continuas demuestran que incluso las personas más experimentadas y de mayor rango se equivocan la mayor parte del tiempo.
Es difícil para los líderes ser arrogantes y usar su rango cuando a menudo encontramos que las ideas de otras personas funcionan mejor que las nuestras. La habilidad de persuasión tampoco importa tanto como antes, ya que aplazamos los resultados de los experimentos.
Quizás uno de los mayores beneficios culturales de unificar y refinar continuamente nuestros KPI y restricciones es un sentido de propósito compartido.
En lugar de tener cientos de KPI y la confusión y los silos que generan, luchar por métricas optimizadas hace que las personas se muevan en la misma dirección.
Debido a que eso ayuda a los empleados a comprender cómo su trabajo contribuye al éxito general de la empresa, también fomenta la cooperación, la colaboración y el aprendizaje. Los empleados reconocen que se benefician de lo que hacen los demás y del conocimiento que producen y comparten.
Por estos motivos, creemos que nuestra obsesión por establecer y realizar un seguimiento de los KPI y las restricciones correctas ha sido nuestra arma más eficaz en un mercado difícil. Este enfoque nos define y definirá nuestro futuro, y creemos que también puede funcionar para otros.
– – –
REFERENCIAS
1. Agoda, de gestión independiente, tiene oficinas en más de 35 países. Brinda soporte de operaciones y marketing a otras empresas de Booking Holdings a nivel mundial.
2. Una es Canary, una herramienta de análisis frontal que funciona de manera similar a Google Analytics pero está diseñada específicamente para nuestros sistemas. Canary resume la actividad de los clientes, permitiéndonos ver cuántas personas visitan, interactúan, hacen clic, reservan y abandonan cada elemento de la página de nuestro hotel (imágenes, mapas, calificaciones, etc.). Cuando un elemento se convierte bien, encontramos formas de enfatizarlo y aumentar su efectividad a través de opciones de diseño como el tamaño, el color y la posición. Canary también aprende automáticamente cuando se agregan nuevos elementos al front-end.
Así puedes mejorar la gestión de emociones de tus trabajadores