El 80% de los SaaS Define Sus Precios Sin Mirar Sus Propios Datos. Luego se Preguntan Por Qué No Convierten.

Crees que el pricing de tu SaaS es un problema de matemáticas. Costes más margen igual a precio. O peor aún: miras a tu competidor, le restas un 10%, y ya tienes tus tiers.

Te has equivocado de diagnóstico.

El 80% de los SaaS estructura sus planes de precios sin usar datos reales de uso del producto. Luego se preguntan por qué no convierten, por qué el plan gratuito canibaliza al de pago, por qué los usuarios se van antes de upgrade.

No es culpa del producto. Es culpa de cómo defines el valor.

La realidad es que el pricing no es un problema de finanzas. Es un problema de psicología del producto y análisis de comportamiento. No sabes cuánto vale tu producto hasta que observas cómo lo usan tus clientes reales. La información que necesitas no está en una hoja de cálculo de costes — está en tus logs de producto.

---

Por Qué los Métodos Tradicionales de Pricing Fracasan Sistemáticamente

Dos enfoques dominan el mercado. Los dos están rotos.

❌ Cost-Plus Pricing: Calculas costes de infraestructura, desarrollo y soporte. Les aplicas un margen. Lo etiquetas como "plan Pro". El problema: el coste de servir a un usuario rara vez se correlaciona con el valor que ese usuario percibe. Un usuario que almacena 10 GB de datos puede generar 10x más valor emocional que uno que almacena 100 GB, si el primero usa tu feature core y el segundo solo guarda ficheros muertos.

❌ Competitor-Based Pricing: Miras los precios de tu competidor directo. Te posicionas un 10-20% por debajo para robar cuota. El problema: asumes que tu competidor ya ha optimizado su pricing. Probablemente ellos también están adivinando. Y además ignoras la elasticidad de precio de tu propio segmento de clientes. Dos productos aparentemente idénticos pueden tener disposiciones a pagar radicalmente diferentes si su UX, integración o soporte se perciben como superiores.

✅ Value-Based Pricing desde Datos de Uso: Construyes los precios alrededor de lo que tus usuarios realmente usan, cómo lo usan, y en qué momento perciben más valor. No miras a los competidores. Miras tus propios logs.

El 80% falla porque mide lo fácil (costes, benchmarks) en lugar de lo correcto (patrones de uso, disposición a pagar).

---

El Sesgo de Medir lo Fácil

Los equipos de producto miden consumo de API calls, almacenamiento o usuarios activos porque son datos que ya tienen en sus dashboards. Son métricas cómodas. Vienen con el stack.

El problema: la disposición a pagar de un cliente no se correlaciona con el volumen de uso. Se correlaciona con el valor que percibe en momentos específicos.

Llamamos a ese momento el aha moment. Es el instante en que el usuario entiende: "esto resuelve mi puto problema". Y ese momento no tiene nada que ver con cuántas API calls ha hecho ese día.

Un equipo que solo mide uso bruto termina:

Infravalorando features de alto valor emocional (un dashboard que ahorra 3 horas de trabajo semanal).
Sobrevolarando features commodity (un export a CSV que todo el mundo da por hecho).

El reto no es tener datos. El reto es saber qué datos mirar.

---

El Peligro de Copiar Benchmarks de Competidores

Es el método más común del mercado. Y el más peligroso.

Cuando copias los precios de un competidor, asumes tres cosas que probablemente son falsas:

Que tu competidor ha optimizado su pricing (cuando probablemente ellos también están improvisando).
Que tu producto y el suyo generan el mismo valor percibido.
Que tu segmento de clientes tiene la misma disposición a pagar que el suyo.

Esto es particularmente dañino en mercados competitivos. La respuesta corta cuando te dicen "no podemos subir precios, el mercado es muy competitivo" es: la disposición a pagar no es un número fijo en el mercado, sino una distribución. Siempre hay un segmento dispuesto a pagar más por una propuesta de valor específica. El error es tratar de capturar a todo el mercado con un solo precio. La segmentación en tiers bien diseñada permite capturar tanto al cliente price-sensitive como al que valora features premium — sin tener que competir en precio con todos.

---

El Framework: Mapeo de Valor por Uso (MVU)

No te voy a dar teoría. Te voy a dar el proceso que uso con mis productos. Lo llamo Mapeo de Valor por Uso. Son cinco pasos. Ninguno requiere machine learning ni un data scientist. Requieren acceso a tu base de datos y ganas de hacer preguntas incómodas.

1. Auditar los Datos de Uso Actuales

Extrae de tu base de datos qué features se usan realmente, con qué frecuencia y por qué segmento de cliente. No mires promedios. Míralo por cohortes.

La mayoría descubre que el 20% de las features genera el 80% del valor percibido. El resto es ruido. El primer paso es identificar ese 20%.

Hazte estas preguntas:

¿Qué feature tiene la tasa de retención más alta a los 30 días?
¿Qué feature correlaciona con invitaciones a otros usuarios?
¿Qué feature usan los usuarios que nunca hacen churn?

Los patrones no están en el promedio. Están en los extremos.

2. Identificar Clusters de Comportamiento

Agrupa usuarios según patrones de uso reales. No según el plan que eligieron (eso es autoselección, no comportamiento).

Tres clusters típicos:

Power users: usan 5+ features a diario. Invitan a otros. Son tus evangelistas.
Usuarios medios: usan 2-3 features clave semanalmente. Obtienen valor, pero no profundizan.
Usuarios ligeros: usan 1 feature de forma esporádica. Probablemente llegaron por una necesidad puntual.

Ahora correlaciona cada cluster con su disposición a pagar. Usa métodos como Van Westendorp o Gabor-Granger para encuestar a cada grupo por separado. No preguntes "¿cuánto pagarías?" en abstracto. Pregunta: "Si esta feature específica dejara de estar disponible, ¿cuánto estarías dispuesto a pagar para recuperarla?" El dolor por la pérdida es un predictor más fiable que el deseo por una ganancia.

3. Diseñar Tiers Alrededor de Bloques de Valor Naturales

Aquí viene lo contraintuitivo: no tienes por qué tener 3 planes.

La industria asume que el pricing perfecto tiene 3 tiers (Basic, Pro, Enterprise). Esto funciona para algunos modelos, pero no hay evidencia de que sea universalmente óptimo. Slack tiene 4 planes. Empresas de infraestructura como Twilio usan precios por unidad sin tiers.

La estructura correcta emerge del análisis de clusters de comportamiento de tus propios usuarios — no de una plantilla copiada.

Diseña los tiers alrededor de los límites de uso que separan los clusters de comportamiento que identificaste en el paso 2. Si el 60% de tus power users usa más de 500 unidades de tu feature core al mes, ese es tu límite natural entre el plan medio y el premium.

No fuerces 3 planes porque "todo el mundo tiene 3 planes". Emerge del dato.

4. Aplicar Anclaje Estratégico

El anclaje es un sesgo cognitivo clásico: el primer precio que ve un usuario se convierte en el punto de referencia contra el que compara todos los demás.

Para explotarlo:

Sitúa el plan más popular (target) entre un plan básico de entrada y un plan premium con features aspiracionales.
El plan premium no necesita muchas ventas. Su función es anclar el valor percibido del plan medio.
Si vendes el plan medio a una cifra, el premium debería estar muy por encima (2x-3x). Esto hace que el medio parezca una ganga.

Es la misma lógica que usa la carta de vinos en un restaurante caro: la botella de 200€ no está ahí para que la compres. Está ahí para que la de 80€ te parezca razonable.

5. Testear e Iterar con Feature Gating Progresivo

El error más común es bloquear features de golpe en la pantalla de "upgrade ahora". Esto genera fricción y abandono.

El enfoque correcto: soft gates progresivos.

Permite que el usuario gratuito use una feature premium un número limitado de veces (5, por ejemplo). Mide el aumento de engagement durante esas 5 veces. Entonces presenta la actualización no como una restricción, sino como una forma de "desbloquear el potencial" que el usuario ya ha descubierto y valora.

El usuario paga por lo que ya ha probado y valora. No paga por lo que no entiende.

---

Tres Objeciones Que Te Van a Poner (y Cómo Responderlas)

"Nosotros ya miramos los datos de uso y no encontramos patrones claros"

Es la objeción más común. Y la razón es casi siempre la misma: estás analizando datos agregados en lugar de segmentar por cohortes de comportamiento.

Si miras la media de uso de todos tus usuarios, no verás nada. Las señales se diluyen en el promedio. Pero si separas a los que se quedan vs. los que hacen churn, los que invitan a otros vs. los que usan en solitario, los patrones emergen.

El problema no es la ausencia de datos. Es la granularidad del análisis.

"No podemos cambiar los precios porque los clientes existentes se quejarán"

Confundes cambiar precios con cambiar la estructura de tiers. No necesitas tocar los planes de los clientes actuales.

Estrategias que funcionan:

Grandfathering: los clientes legacy conservan su plan actual con precios antiguos. Solo los nuevos clientes ven la nueva estructura.
Nuevos tiers: introduces un plan intermedio o premium que no existía antes. Los clientes actuales no pierden nada.
Feature gating del plan gratuito: lo que antes era gratis ahora es de pago, pero los usuarios legacy lo conservan.

Los ingresos incrementales de nuevos clientes con mejor estructura de precios compensan el riesgo de queja de usuarios existentes. Tu base actual decrece si no optimizas. No te puedes permitir el lujo de no cambiar.

"Nuestro mercado es muy competitivo, no podemos subir precios"

Falso dilema. Ya lo hemos visto: la disposición a pagar es una distribución, no un número fijo.

Si tu producto tiene una integración mejor, un soporte más rápido o una UX más limpia que tu competidor, hay un segmento dispuesto a pagar más por eso. No necesitas ganar a todo el mercado. Necesitas ganar a tu segmento.

Diseña tiers que capturen tanto al cliente price-sensitive como al que valora features premium. Y deja de competir en precio con todos.

---

Lo Que Pasa Cuando Aplicas el MVU

El pricing basado en datos de uso real no es más complicado que el pricing basado en competidores. Es diferente. Requiere que mires hacia dentro en lugar de hacia fuera. Que confíes en tus logs en lugar de en tus hojas de cálculo.

Y requiere una cosa que la mayoría de los founders evita: preguntar a tus usuarios qué valoran realmente, no qué pagarían.

La diferencia entre esas dos preguntas es la diferencia entre un pricing que funciona y uno que deja dinero sobre la mesa.

El 80% de los SaaS estructura sus precios sin mirar sus propios datos. El otro 20% construye negocio sobre el que el 80% deja escapar.

Tú decides en qué grupo quieres estar.

El 80% de los SaaS Define Sus Precios Sin Mirar Sus Propios Datos. Luego se Preguntan Por Qué No Convierten.