La mayoría de los debates sobre precios en SaaS empiezan en el lugar equivocado.
Los equipos discuten sobre tiers. Se desgastan comparando cantidad de asientos contra límites de uso. Miran a la competencia. Lanzan encuestas para preguntarles a los clientes cuánto pagarían. Después salen al mercado, ven cómo se comprimen los márgenes y se preguntan qué pasó.
Lo que pasó es esto: el modelo de precios se armó sobre estimaciones de costos, no sobre la realidad de esos costos. Y las estimaciones envejecen mal. El secreto incómodo del unit economics en SaaS
Cuando un VP de Producto o un consultor de pricing arma un modelo para un plan nuevo, trabaja hacia atrás desde supuestos. Los costos de infraestructura se aproximan. El consumo de recursos compartidos se promedia. El uso de IA se estima a ojo. La varianza entre clientes se aplana en una sola línea.
El modelo dice que atender a un cliente del plan Growth debería costar $80/mes. El costo real, una vez que lo rastreas por la infraestructura real, se acerca a los $190 en tus cuentas más pesadas y a $12 en las más livianas. El promedio se ve bien. La cola te está matando en silencio.
Esto no es un problema de estrategia de pricing. Es un problema de datos. Más puntualmente, es un problema de dataset faltante.
Por qué existe esta brecha
Las herramientas tradicionales de costos en la nube se diseñaron para equipos de FinOps que administran presupuestos de infraestructura. Leen los billing exports, parsean los logs de CloudTrail y organizan el gasto por cuenta, región o tag. Eso le sirve al equipo de Engineering que quiere hacer right-sizing de instancias EC2.
No le sirve a pricing.
Los equipos de pricing necesitan el costo organizado de otra forma: por cliente, por línea de producto, por feature, por la unidad de uso que efectivamente cobran. Un billing export no sabe qué cliente disparó qué workload. No sabe que una cuenta enterprise corre jobs de scan que consumen 40 veces más compute que cualquier otra del mismo plan. No sabe que tu feature de IA cuesta tres veces más para los power users que para los usuarios ocasionales.
La capa de billing no tiene ese contexto. Nunca lo tuvo. Se diseñó para decirle al proveedor de nube cuánto cobrarte, no para decirte cuánto cuesta operar el workload de cada cliente.
Para responder esa pregunta, hace falta una fuente de datos completamente distinta.
Qué cambia con los datos de runtime
Cuando instrumentas tu infraestructura a partir de datos de runtime —leyendo el tráfico real, las llamadas reales a servicios y el consumo real de recursos a medida que ocurre—, la foto de costos se ve muy distinta.
Puedes ver qué clientes están detrás de qué workloads. Puedes rastrear una query de base de datos hasta el feature que la disparó, y de ahí al cliente que la usó. Puedes observar recursos compartidos como Kafka o Elasticsearch y entender qué tenants están consumiendo cuánto, sin pedirles a los Engineers que taggeen nada.
No es una capacidad teórica. Ya existe, desplegada en producción en compañías que están haciendo exactamente este análisis.
¿Y qué encuentran?
La mayoría descubre que su modelo mental sobre la distribución de costos está equivocado. La brecha entre los consumidores más livianos y los más pesados es más ancha de lo esperado. Un pequeño porcentaje de cuentas —por lo general enterprise, por lo general en el medio del stack de planes— consume a un ritmo que hace que su ARR parezca un descuento.
Una compañía detectó 360 cuentas donde el costo de atención superaba al ingreso. Exposición total: $1,3M en pérdidas anuales, invisibles hasta que la atribución en runtime mapeó el costo hacia los clientes. Las pérdidas no estaban en las cuentas que ya se sabían no rentables. Estaban escondidas en planes que parecían un ARR saludable.
El problema del pricing de IA es un anticipo de lo que viene
Este tipo de compresión de márgenes va a empeorar, no a mejorar.
Las features de IA cambian la estructura de costos de un producto SaaS de maneras que un modelo por asiento —o incluso por uso— muchas veces no alcanza a capturar. Un agente de IA que corre un workflow de varios pasos no consume una cantidad fija de compute. Consume según la complejidad, el tamaño del input, cuántas herramientas invoca y cuántos tokens quema en el camino. Dos clientes que usan la misma feature de IA pueden tener perfiles de costo 10 veces distintos.
Si tu modelo de precios los trata igual, uno le está subsidiando el uso al otro.
Las compañías que van a acertar con el pricing de IA son las que puedan ver el consumo de tokens, las acciones del agente y el volumen de tool calls a nivel de cliente, y construir precios alineados con esa realidad. Ni por asiento. Ni por cada mil requests. Estructuras de precios que reflejen los verdaderos drivers de costo del producto.
Eso requiere datos de runtime. No hay otra forma de conseguirlo con este nivel de granularidad.
Qué habilita esto para los equipos de pricing
Puedes identificar qué segmentos tienen margen negativo antes de que aparezcan en una presentación al board. Puedes ver qué tiers de planes tienen la mayor varianza de costos y diseñar límites de uso o add-ons alineados con el consumo real. Puedes probar el impacto en margen de una nueva capacidad antes de ponerle precio y lanzarla, usando datos reales de baseline en vez de supuestos modelados.
También puedes construir modelos de precios que antes eran imposibles. Los precios por consumo dejan de ser una apuesta cuando sabes exactamente cuánto cuesta entregar cada unidad de consumo. Los precios basados en valor se vuelven defendibles cuando puedes mostrar lo que efectivamente gastas para generar el resultado por el que cobras.
La era agéntica vuelve todo esto más urgente. Si cobras $250 por tarea completada, necesitas saber si esa tarea costó $80 o $380 en ejecutarse. La respuesta lo cambia todo: qué workflows cobrar más caro, cuáles rediseñar, qué clientes son rentables al precio actual. Sin datos de runtime, estás volando a ciegas en tus decisiones de pricing más importantes.
Puedes responder la pregunta que los equipos de pricing siempre necesitaron responder pero rara vez pudieron: ¿cuánto cuesta realmente entregarle este valor a este cliente?
Cuando tienes esa respuesta, la estrategia de precios deja de ser adivinanza. Se convierte en una ventaja competitiva.
La pregunta para tu próximo pricing review
Antes de debatir tiers de empaquetado o gating de features, hazte una pregunta previa: ¿realmente sabemos cuánto cuesta atender a cada cliente, cada plan, cada feature?
Si la respuesta involucra hojas de cálculo y estimaciones, el modelo de precios está parado sobre una base que no va a aguantar cuando el producto escale.
Empieza por la realidad del costo. Todo lo demás viene después.
Attribute™ mapea el costo de infraestructura de nube e IA hacia clientes, productos y features usando datos de runtime, sin tagging. Descubre cómo funciona para los equipos de pricing.