El único indicador SaaS que sobrevive cuando el mercado aprieta
Hay un momento en el ciclo de vida de cualquier empresa de software por suscripción en el que el tablero de métricas empieza a parecer un síntoma y no una herramienta. Usuarios activos diarios, tasa de apertura de funciones, tiempo de sesión, adopción de módulos, NPS trimestral. Todo se mide. Todo se presenta en color verde. Y sin embargo, los contratos no se renuevan.
Ese desajuste entre actividad y valor no es nuevo, pero tampoco está siendo corregido a la velocidad que la presión del mercado exige. En un momento en que los compradores empresariales aplican escrutinio real a cada línea del presupuesto tecnológico, la pregunta que muchos proveedores de software evitan formularse con honestidad es si sus clientes están ganando dinero gracias a su plataforma, o simplemente están usando una herramienta que nadie ha tenido el tiempo de cancelar.
David Pickard, director global de Phonexa, publicó recientemente en Forbes Technology Council una tesis que resume ese desajuste con una pregunta de autoevaluación: si fueras tu propio cliente, ¿usarías tu software? La provocación es efectiva porque el diagnóstico que la sostiene es preciso. El sector SaaS ha construido una cultura de métricas de actividad que funciona bien para los roadmaps internos y las presentaciones a inversores, pero que tiene una correlación cada vez más débil con la experiencia económica del cliente.
Cuando la métrica de éxito es interna
El problema no es medir. Es qué se elige medir y por qué.
Las métricas de vanidad —diarios activos, volumen de logins, número de funciones adoptadas— tienen una función legítima en etapas tempranas de un producto: indican si el software está siendo usado, si el onboarding funciona, si hay engagement suficiente para justificar una ronda de feedback. El error ocurre cuando esas métricas migran al centro del tablero ejecutivo sin haber hecho la transición hacia métricas de resultado económico.
Un cliente puede generar un patrón de uso alto y simultáneamente estar generando menos dinero que antes de implementar la plataforma. El software le consume tiempo de configuración, requiere integraciones que su equipo no domina, produce informes que nadie sabe interpretar correctamente. La tasa de retención aparece sana durante meses porque los procesos de cancelación son lentos y la inercia organizacional es poderosa. Pero el contrato no se renueva, y cuando hay que explicar por qué, la respuesta no está en el tablero de métricas interno.
Esto tiene una consecuencia menos obvia: los equipos de producto empiezan a optimizar para lo que se mide. Si el indicador de éxito es la adopción de funciones, se agregan funciones. Si es el tiempo de sesión, se diseñan flujos que retienen al usuario dentro de la plataforma aunque no sea necesario. Si es el NPS, se gestiona la percepción en el momento de la encuesta. La optimización hacia métricas de actividad produce productos más complejos y clientes con menor retorno real. No por mala intención, sino porque la arquitectura de incentivos apunta en una dirección diferente a la que el cliente necesita.
El argumento de Pickard sobre lo que él llama "vanity development" —construir funciones que no están impulsadas por necesidades de los clientes, sino por tendencias del mercado, presión competitiva o afinidad tecnológica interna— describe exactamente ese mecanismo. El resultado es una plataforma que acumula capas de complejidad sin que ninguna de ellas mueva de manera demostrable los ingresos, la eficiencia o la reducción de costos del cliente.
La estructura de incentivos que nadie audita
Detrás de la proliferación de métricas de vanidad no hay ingenuidad. Hay una estructura de incentivos que las produce de manera sistemática y que opera en al menos tres niveles simultáneos.
El primero es el ciclo de financiación. Las rondas de capital en etapas tempranas y medias de una empresa SaaS históricamente han estado ligadas a métricas de crecimiento de usuarios, tasa de crecimiento de ingresos recurrentes mensuales y proyecciones de expansión de mercado. Esas métricas son capturables con datos de actividad. El retorno económico del cliente, en cambio, es más lento de medir, requiere acceso a datos que el cliente no siempre comparte y no aparece limpiamente en una pitch deck de Serie B. La consecuencia es predecible: los equipos optimizan para los indicadores que mueven el precio de la siguiente ronda, no necesariamente para los que reflejan valor entregado.
El segundo nivel es la estructura de los equipos de Customer Success. Durante años, esta función fue diseñada como soporte técnico-relacional: resolver problemas de implementación, responder tickets, gestionar el onboarding. En ese modelo, el indicador de rendimiento del equipo era la satisfacción del cliente y la tasa de retención, no la expansión de ingresos del cliente. Eso crea un equipo bien posicionado para detectar fricción pero sin herramientas ni mandato para cuantificar el impacto financiero de la plataforma en el negocio del cliente.
El tercer nivel —y el más resistente al cambio— es la distancia entre el equipo de producto y el cliente que opera en el día a día. Las decisiones de roadmap se alimentan de entrevistas de usuario, análisis de comportamiento dentro del producto y benchmarking competitivo. Raramente se alimentan de los estados financieros del cliente, de sus métricas de eficiencia operativa o de una evaluación honesta de si la plataforma redujo su costo por transacción o aumentó su tasa de conversión. La distancia produce features que resuelven problemas percibidos pero no problemas económicos.
Pickard señala como solución a esto lo que describe como "vanillificar" los requerimientos: cuando un cliente pide una funcionalidad específica, el equipo de producto debe generalizar esa solicitud para que escale hacia otros segmentos y sea suficientemente flexible para casos de uso futuros. El principio es correcto, pero hay una condición previa que el argumento no resuelve directamente: para saber si una funcionalidad generalizada crea valor, es necesario tener una definición operativa de qué significa valor para el cliente. Sin esa definición, la generalización puede producir complejidad de la misma forma que la copia de competidores.
El retorno del cliente como indicador financiero de la salud del proveedor
Hay una razón estructural por la que el retorno del cliente termina siendo el mejor indicador adelantado de la salud financiera del proveedor SaaS, y vale la pena hacerla explícita.
Los modelos de negocio por suscripción dependen de dos variables: la retención de ingresos existentes y la expansión dentro de la base de clientes actual. La Retención Neta de Ingresos (NRR), uno de los indicadores más vigilados en la industria, mide precisamente eso: si los ingresos provenientes de clientes activos crecen, se mantienen o se contraen después de incorporar cancelaciones, downgrades y expansiones. Una NRR superior al 100% indica que la base de clientes existente está expandiendo su uso, lo que suele ser el indicador más eficiente de crecimiento porque evita el costo de adquisición de nuevos clientes.
Ese número no se sostiene sin retorno económico demostrable para el cliente. Un cliente que no está generando ingresos incrementales, ahorrando costos o ganando eficiencia operativa a través de la plataforma no tiene una razón económica para expandir su contrato. Puede renovar por inercia durante uno o dos ciclos, pero la lógica de expansión —que es lo que hace que una NRR supere el umbral del 100%— requiere que el cliente haya conectado el software con un resultado de negocio positivo.
La cadena causal es entonces precisa: retorno del cliente → retención de contratos → expansión de gasto → NRR saludable → valoración del proveedor. Medir únicamente los eslabones intermedios de esa cadena —retención y expansión— sin auditar el eslabón inicial produce una ilusión de solidez que el mercado corrige en el siguiente ciclo de renovaciones.
Pickard apunta en la misma dirección cuando señala que en modelos de ingresos basados en uso, el crecimiento del gasto del cliente en la plataforma debería ser un síntoma de que ese cliente está generando más ingresos a través del sistema. Si el cliente duplica su gasto en la plataforma, su ganancia debería crecer en un múltiplo mayor. Si eso no ocurre, el modelo no está entregando valor: está capturando una porción creciente de un ingreso que no está creciendo.
Los servicios gestionados que el artículo menciona funcionan como un acelerador de ese ciclo cuando están bien diseñados: reducen el tiempo entre implementación y retorno demostrable, lo que a su vez acelera la decisión del cliente de expandir uso. El riesgo, que el artículo no tematiza explícitamente pero que es real, es que los servicios gestionados se conviertan en un parche para plataformas que no son suficientemente intuitivas o que requieren demasiada intervención para producir resultados. En ese caso, la capa de servicios subsidia indefinidamente una complejidad que el producto debería haber eliminado.
Lo que precede al número visible
El argumento de centrar todo en el retorno del cliente es correcto en su diagnóstico, pero su implementación enfrenta una condición previa que pocas empresas SaaS han resuelto: cómo medir ese retorno de manera sistemática y no anecdótica.
Los casos de éxito de cliente existen en todas las empresas de software. Son el combustible de las presentaciones de ventas y las páginas de testimonios. El problema es que un caso de éxito narrado después del hecho tiene valor comercial pero poca utilidad operativa. No dice qué produjo el retorno, en qué condiciones se replicaría, ni qué variables lo hicieron posible en ese cliente y no en otros con perfiles similares.
Construir una metodología de medición del retorno del cliente que sea comparable entre segmentos, que se actualice en tiempo real y que alimente decisiones de producto y de Customer Success requiere acceso a datos que el cliente a menudo no comparte por defecto. Requiere que la plataforma esté instrumentada para capturar no solo el comportamiento dentro del sistema, sino sus efectos downstream en los indicadores de negocio del cliente. Y requiere que los equipos de producto y de Customer Success hablen el mismo idioma económico que los compradores ejecutivos que evalúan la renovación.
La fricción que nadie está contando en el debate sobre métricas de vanidad es precisamente esa: el problema no es que las empresas SaaS no quieran medir retorno del cliente. Es que la infraestructura de datos, los acuerdos de intercambio de información con clientes y la capacidad analítica para convertir esos datos en señales de roadmap no están construidas en la mayoría de los proveedores medianos. Cambiar el dashboard ejecutivo es simple. Cambiar la arquitectura de información que alimenta ese dashboard es el trabajo que tarda años.
Eso no invalida la tesis de Pickard. La refuerza. Pero coloca el verdadero problema donde debe estar: no en la elección de qué medir, sino en la capacidad de medir lo que importa de manera sistemática. Las empresas SaaS que logren construir esa capacidad primero —incluyendo los acuerdos con clientes que habilitan la visibilidad sobre sus resultados— tendrán una ventaja que no se replica simplemente cambiando el nombre de un indicador en el reporte trimestral.
El tablero de métricas no cambia si la plataforma no está generando retorno demostrable. Pero la arquitectura que produce ese tablero —y los equipos capaces de interpretarlo con honestidad— es la inversión que separa a los proveedores que sobreviven las renegociaciones presupuestarias de los que no llegan al siguiente ciclo de renovación.
