El número que importa no es la factura, es el coste por cliente
Una factura cloud que crece con los ingresos está bien. Una que crece más rápido es un problema de negocio escondido dentro de un informe de infraestructura. Elige la unidad, atribuye el coste compartido, y la conversación con el consejo cambia.
Un equipo de plataforma presenta el coste cloud del mes. Subió un once por ciento. La sala reacciona como si algo hubiera ido mal, se encarga un proyecto de optimización, y tres ingenieros pasan un mes buscando ahorros.
Nadie preguntó qué hicieron los ingresos en el mismo periodo. Subieron un diecinueve por ciento. El coste por cliente bajó, la plataforma se volvió más eficiente, y la empresa acaba de gastar un mes de ingeniería en optimizar un número que ya estaba mejorando.
La factura absoluta, por sí sola, no significa casi nada. Es un coste de entrada de un negocio que presumiblemente crece. La pregunta que merece hacerse es si cada unidad de lo que vendes es cada vez más barata o más cara de servir.
Elegir la unidad
La unidad tiene que ser algo que el negocio ya cuente, o nadie fuera de ingeniería la va a usar.
Para la mayoría del software por suscripción es coste por cliente o por cuenta, a veces desglosado por plan. Para productos con precio por uso es coste por transacción, por llamada a la API, por documento procesado. Para un marketplace es por pedido o por anuncio. Para una funcionalidad de IA es coste por consulta o por conversación, que es la forma de lo que cuesta de verdad una automatización por ejecución.
Dos reglas. Elige una unidad que aparezca en una presentación de consejo, para que los dos números puedan ponerse uno al lado del otro. Y elige una, no cinco. Un solo número seguido durante un año vale más que un panel con seis en los que nadie confía.
Y después calcula la cifra derivada que de verdad mueve decisiones: el coste de infraestructura como porcentaje de los ingresos, o el margen bruto por cliente. Esa es la versión sobre la que puede actuar una dirección financiera.
Atribución y el problema del coste compartido
Los costes directos son la parte fácil: el cómputo que sirve las peticiones de un inquilino, su almacenamiento, su base de datos.
La parte difícil es que la mayor parte de la factura es compartida. El plano de control, el balanceador, la pila de observabilidad, el pipeline de integración continua, los entornos de no producción, las herramientas del propio equipo de plataforma. Si lo repartes, la aritmética es discutible; si lo dejas fuera, el número está mal de una forma que te favorece.
Tres enfoques, en el orden en que los usamos:
- Proporcional al coste directo. Simple, defendible, suficiente para casi todo el mundo.
- Por un motor de uso como el número de peticiones o el volumen de datos, cuando un motor domina claramente.
- Mantenido como una línea de coste de plataforma aparte, reportada al lado pero no distribuida. Honesto, y hace visible el coste fijo de estar en el negocio, que a menudo es la conclusión más útil.
Elijas lo que elijas, muestra la parte directa y la asignada por separado. Un equipo o un directivo que ve el desglose acepta el total; quien ve una única cifra mezclada lo discute.
El requisito técnico es el mismo que sostiene todo lo demás en esta área: un etiquetado lo bastante bueno como para que el coste se resuelva a una carga de trabajo y, en un clúster compartido, un reparto por namespace que funcione, como se describe en repartir la factura de un clúster compartido.
Dónde están los hallazgos interesantes
Una vez tienes el coste por cliente, la media es el resultado menos interesante. Donde está el trabajo es en la distribución.
La cola larga de clientes caros. En casi todos los entornos que hemos medido, un número pequeño de cuentas consume una proporción desmedida de la infraestructura. Normalmente es legítimo: son grandes. A veces no lo es, y un solo cliente con tarifa plana está ejecutando un patrón de consultas que cuesta más de lo que paga. Eso no se puede encontrar sin atribución por cliente, y una vez encontrado el arreglo suele ser una decisión de producto y no de ingeniería.
Margen por plan. Se espera que el plan gratuito pierda dinero. La pregunta es cuánto, y si el plan de pago de entrada cubre de verdad su coste de servicio. A los equipos les sorprende con regularidad descubrir que un plan barato con límites generosos es el que destruye el margen.
Coste por cliente en el tiempo. La tendencia es la métrica de salud. Plana mientras crece el número de clientes significa que la plataforma escala de forma sublineal, que es lo que quieres. Creciente significa que algo escala de forma superlineal, y la causa suele ser un coste fijo por inquilino: una base de datos por cliente, una cola dedicada, un namespace con sus propias cargas base.
Coste por funcionalidad. Si una funcionalidad se puede atribuir, aprendes cuáles valen su coste de servicio. Una funcionalidad de IA con coste de inferencia alto y poca adopción es candidata a un modelo más barato o a desaparecer, y ninguna de las dos conversaciones es posible sin el número.
La conversación que esto habilita
Este es el objetivo real. Cambia lo que ingeniería puede decirle al resto de la empresa.
"Nuestra factura cloud subió un once por ciento" invita a una respuesta de recorte. "El coste por cliente bajó un siete por ciento mientras incorporábamos cuarenta cuentas nuevas" es el informe de un sistema funcionando. Los mismos datos de debajo, una reunión completamente distinta.
También cambia cómo se prioriza el trabajo de optimización. No "reduce la factura" sino "este plan tiene margen negativo" o "este segmento de clientes cuesta tres veces la media servirlo". Esas son afirmaciones que conectan con decisiones de precio, empaquetado y producto, que es donde están las palancas grandes.
Y vuelve honesta la planificación de capacidad. Si el coste por unidad es estable, prever el coste de infraestructura del año que viene es aritmética sobre la previsión de ventas en vez de una conjetura.
Llegar a un primer número
No construyas un almacén de datos. La primera versión debería llevar una semana.
Exporta los últimos tres meses de datos de facturación con etiquetas. Agrupa por las etiquetas que identifican carga y entorno. Separa lo directo de lo compartido. Saca el número de clientes o de transacciones de esos mismos meses de la base de datos del producto. Divide. Ponlo en una hoja de cálculo y enséñaselo a alguien de finanzas para validar el denominador.
El primer número estará mal en el tercer decimal y será correcto en dirección, que es todo lo que necesita. Refínalo cuando se esté usando, porque un número que nadie mira no merece precisión.
Después automatízalo en un informe mensual que llegue sin que nadie lo ejecute, y sigue la tendencia en vez del nivel.
Lo que se olvida
- El denominador hay que definirlo. Clientes activos, clientes de pago y cuentas creadas son tres números distintos y la gente los va a usar indistintamente.
- Los descuentos cambian el numerador. Usa tarifas efectivas después de compromisos, no precio de catálogo, o la proporción sale inflada.
- La no producción es un coste real de hacer negocio. Inclúyela, en la línea compartida.
- Los costes puntuales de migración distorsionan un mes. Anótalos en vez de dejar que parezcan una tendencia.
- Más barato por unidad no siempre es mejor. Recortar el coste por consulta degradando la latencia puede costar más en abandono de lo que ahorra.
Qué hacer esta semana
Coge la factura cloud del mes pasado, coge el número de clientes activos de ese mismo mes y divide. Después hazlo con el mismo mes del año pasado. Esos dos números, en una línea, son más útiles que cualquier panel de coste que pudieras construir este trimestre, y llevan una hora. Lo producimos en la primera semana de la fase de costes de un proyecto cloud.