Plantilla de precios SaaS: Tiers que venden

La mayoría de problemas de pricing SaaS no son problemas de precios. Son problemas de estructura — demasiados planes, ninguna métrica de valor clara, triggers de upgrade que parecen arbitrarios y una página de precios que lo explica todo excepto por qué alguien debería pagar más.

Esta página te da la estructura. Una plantilla de modelo de precios SaaS de 3 tiers que puedes copiar, adaptar y lanzar — con el razonamiento detrás de cada decisión para que entiendas qué cambiar cuando tu producto no encaje con el default. Para el contexto sobre la gama completa de modelos de precios disponibles, la guía minimalista cubre cada enfoque con ejemplos reales.

La plantilla: modelo de precios SaaS de 3 tiers

Esta es la estructura de pricing mínima viable para la mayoría de productos SaaS self-serve.

Tabla de precios

Plan	Ideal para	Precio	Límite principal	Trigger de upgrade
Starter	Uso individual / evaluación inicial	€19/mes	Tope de volumen bajo	Primer hito de uso alcanzado
Growth	Usuarios activos de pago	€49/mes	Tope de volumen medio	Crecimiento de volumen / más automatización
Scale	Equipos / uso intensivo	€99/mes	Tope de volumen alto	Colaboración / escala avanzada

Destaca Growth como el default. Debería ser visualmente distinto — la mayoría de visitantes que evalúan seriamente aterrizarán aquí. Starter es la entrada de bajo compromiso. Scale es para cuentas que ya encontraron valor y necesitan más.

Cómo deberían sentir los tiers los clientes

Starter: “Puedo obtener valor real de esto antes de decidir pagar más.” No un plan de castigo. No una demo rota. Suficiente para demostrar que el producto funciona.

Growth: “Este es el plan para alguien que realmente usa esto.” El mejor valor por unidad. Claramente la elección correcta para cualquiera que va en serio. La mayoría de tus ingresos vienen de aquí.

Scale: “Para cuando lo uso a máxima capacidad.” Límites más grandes, opcionalmente features de equipo o colaboración. Debería sentirse como un paso natural, no un salto de precio repentino.

¿Te preguntas si tu último cambio de precios realmente movió el ARPU? Mira el desglose de MRR por plan →

El modelo de precios subyacente: cómo rellenar la plantilla

La tabla de arriba es el output. Las elecciones de abajo determinan si realmente convierte.

Paso 1: Elige una métrica de valor

La métrica de valor es la unidad por la que los clientes pagan más conforme obtienen más valor. Impulsa el límite que cambia entre tiers y crea el trigger de upgrade.

Buenos ejemplos de métricas de pricing SaaS por tipo de producto:

Tipo de producto	Opciones fuertes de métrica de valor
Analytics / herramienta de métricas	Cuentas conectadas, ingresos rastreados, fuentes de datos
IA / herramienta de automatización	Workflows completados, ejecuciones de automatización, documentos procesados
API / herramienta para devs	Requests de API, minutos de compute, ejecuciones de pipeline
Email / herramienta de outreach	Contactos, emails enviados por mes
Proyecto / herramienta de ops	Proyectos activos, asientos activos, tableros
Facturación / herramienta financiera	Facturas enviadas, suscripciones gestionadas

El test: ¿puedes completar esta frase? “Cobramos más cuando los clientes [hacen más X], porque [más X significa más valor].” Si no, la métrica no es lo bastante clara.

Para el marco completo sobre cómo elegir una métrica de valor, consulta la guía dedicada a elegir una unidad que lo aclara todo.

Paso 2: Define límites que creen momentos naturales de upgrade

Los límites en cada tier deberían estar calibrados para que:

Starter sea suficiente para alcanzar un primer resultado real (no solo configurar la cuenta)
Growth cubra a un cliente que usa activamente el producto a ritmo normal
Scale sea donde los clientes terminan naturalmente conforme su negocio crece

Una heurística útil: mira tus datos de usuarios activos y encuentra los clusters naturales de uso. Starter debería cubrir el cuartil inferior de uso activo. Growth debería cubrir la mediana. Scale maneja el cuartil superior.

Evita límites que parezcan arbitrarios (¿por qué 1.000 exactamente?) o que creen ansiedad (los clientes cerca del borde dejan de usar el producto para evitar alcanzar el tope en vez de hacer upgrade). La visibilidad dentro del producto — mostrando el uso actual y en qué tier están — elimina la mayor parte de esa ansiedad.

Según los benchmarks de pricing SaaS de OpenView Partners, los productos con medidores de uso visibles dentro del producto ven tasas de upgrade significativamente más altas desde sus planes de entrada.

Paso 3: Decide qué features, si alguna, cambian entre planes

La métrica de valor impulsa la progresión principal. Las diferencias de features deberían ser secundarias. Una página de precios donde la distinción principal entre tiers es una checklist de 20 toggles de features es difícil de leer — los clientes no pueden determinar rápidamente por qué están pagando realmente.

Features que tiene sentido escalonar:

Colaboración / asientos de equipo — si el trabajo en equipo es parte del valor del producto, escalonar asientos es natural
Profundidad de reporting o exports — analytics avanzados, vistas de cohortes o exports de datos pueden vivir en Growth/Scale
Integraciones — si tienes múltiples objetivos de integración, limitar a las principales en Starter es defendible
Nivel de soporte — soporte prioritario en Scale es esperado; no bloquees la ayuda básica

Features que deberían estar en todos los tiers:

Funcionalidad core del producto — bloquear features críticas en Starter entrena a los clientes a no confiar en el producto
Baseline de seguridad — no crees una “versión segura” del producto
Onboarding básico — si ayudas a los usuarios de Starter a tener éxito, hacen upgrade; si no, hacen churn

Paso 4: Define un trigger de upgrade claro por tier

Cada límite de plan debería tener una razón obvia y autoevidente para subir. El upgrade debería sentirse ganado, no forzado.

Starter → Growth: alcanzar el límite de uso, o estar listo para usar el producto en serio. El momento en que un cliente piensa “esto es realmente útil para mi trabajo real,” debería estar a un click de Growth.

Growth → Scale: crecimiento del equipo, mayor volumen o operaciones más complejas. El trigger debería ser algo que el cliente eligió (contratar un colaborador, lanzar un nuevo producto, escalar uso) — no algo arbitrario.

Para la estructura de packaging que hace visibles los triggers de upgrade y reduce la fatiga, la guía del sistema de 3 niveles lo cubre en detalle.

Modelos de precios por suscripción SaaS: eligiendo la estructura correcta

La plantilla de 3 tiers de arriba es packaging. El modelo de precios por suscripción subyacente es una elección separada — determina cómo escalan los ingresos con el crecimiento de clientes.

Pricing escalonado de tarifa plana (lo que la plantilla muestra): precio fijo por tier con límites definidos. Predecible para los clientes, fácil de explicar, bueno para self-serve. El modelo más común para SaaS bootstrapped e indie.

Pricing basado en uso: los clientes pagan por unidad consumida, ya sea con una tarifa base o puro pay-as-you-go. Alinea coste con valor pero puede crear ansiedad de facturación si la métrica es difícil de predecir. Funciona bien para herramientas de API y productos de infraestructura donde el uso es visible y estimable. Las guías de facturación de Stripe Atlas cubren la mecánica de implementación para facturación basada en uso.

Pricing por asiento: el precio escala con el número de usuarios. Natural para herramientas de colaboración y software de equipo. Más débil cuando un power user genera la mayor parte del valor.

Híbrido: una tarifa base de plan que incluye un allowance de uso, más un coste por unidad por encima de ese umbral. Reduce la ansiedad de facturación mientras retiene la alineación con el uso. Común en herramientas de email (base + por envío por encima del límite incluido).

Para la mayoría de productos SaaS de fundador solo y equipo pequeño que apuntan al mercado indie hacker y fase temprana: el pricing escalonado de tarifa plana es el punto de partida con menor fricción. Es predecible, comparable y directo de comunicar.

Plantilla de modelo de ingresos SaaS en JSON

Para builders que quieran documentar el modelo de precios en código o docs internos — algo que pueda realmente conducir una configuración de facturación, página de precios o lógica de onboarding:

{
  "pricing_model": {
    "structure": "tiered_flat_rate",
    "primary_metric": "workflows_completed",
    "billing_intervals": ["monthly", "annual"],
    "annual_discount_pct": 20,
    "plans": [
      {
        "id": "starter",
        "name": "Starter",
        "price_monthly": 19,
        "price_annual_per_month": 15,
        "included_units": 200,
        "best_for": "Fundadores solo / evaluación inicial",
        "upgrade_trigger": "Límite de uso alcanzado o listo para uso serio"
      },
      {
        "id": "growth",
        "name": "Growth",
        "price_monthly": 49,
        "price_annual_per_month": 39,
        "included_units": 2000,
        "best_for": "Usuarios activos de pago",
        "upgrade_trigger": "Crecimiento de volumen o colaboración de equipo necesaria",
        "highlighted": true
      },
      {
        "id": "scale",
        "name": "Scale",
        "price_monthly": 99,
        "price_annual_per_month": 79,
        "included_units": 10000,
        "best_for": "Equipos / operaciones intensivas"
      }
    ],
    "overage_policy": "prompt_to_upgrade",
    "downgrade_policy": "allowed_at_renewal"
  },
  "value_metric": {
    "name": "workflows_completed",
    "visible_in_product": true,
    "usage_warning_threshold_pct": 80
  }
}

El campo usage_warning_threshold_pct importa: mostrar a los clientes que están al 80% de su plan crea un momento natural de upgrade sin presión en vez de un muro repentino.

NoNoiseMetrics como ejemplo real

NoNoiseMetrics usa la misma estructura de 3 tiers descrita arriba, con cuentas de Stripe conectadas como métrica de valor principal:

Plan	Precio	Cuentas Stripe	Para quién
Free	€0/mes	1	Fundadores solo bajo €10K de MRR
Indie	€19/mes	3	Productos SaaS indie activos
Pro	€49/mes	Ilimitado	Portfolios multi-producto y equipos

El trigger de upgrade de Free a Indie es añadir una segunda cuenta de Stripe — natural para fundadores que lanzan un segundo producto o quieren separar entornos. El trigger de Indie a Pro es necesitar más de 3 cuentas — lo que pasa cuando el producto funciona lo bastante bien como para expandirse.

El acceso de por vida a €299 vive fuera de la estructura recurrente y captura una psicología de comprador específica: fundadores que prefieren la propiedad sobre la suscripción y están dispuestos a pagar por adelantado para acceso permanente.

La investigación de pricing de SaaStr confirma que un trigger de upgrade visible y nativo del producto convierte significativamente mejor que comparaciones abstractas de planes — que es exactamente lo que la métrica de cuentas conectadas logra aquí.

Errores comunes del modelo de precios

Demasiados planes. Seis tiers crea parálisis de comparación. Tres tiers cubre el rango completo de clientes — entrada, activo, power — sin pedir a los visitantes que evalúen más opciones de las que pueden manejar en memoria de trabajo.

Sin métrica de valor clara. Si los clientes no pueden decir qué cambia entre Starter y Growth sin leer una tabla de comparación, el modelo de precios carece de columna vertebral. Una unidad clara de progresión lo arregla.

Sopa de features en vez de progresión de límites. Cuarenta checkmarks en una tabla de precios oscurecen la razón principal de hacer upgrade. Lidera con la métrica; añade diferencias de features como contexto secundario.

Hacer de Starter un tier de castigo. Si el plan más bajo no puede demostrar valor real del producto, los clientes no tienen razón para confiar en la ruta de upgrade. Starter debería crear valor. Growth debería expandirlo.

Triggers de upgrade que se sienten punitivos. Un límite que parece arbitrario o injustamente bajo entrena a los clientes a resentir el pricing en vez de esperar crecer hacia él. Los mejores upgrades se sienten ganados.

Sin visibilidad de uso dentro del producto. Los clientes que pueden ver su uso contra el límite de su plan hacen upgrade proactivamente. Los clientes que descubren que alcanzaron un límite inesperadamente se irritan. Esta es una inversión de ingeniería que se devuelve en conversión.

Convirtiendo la plantilla en una página de precios

El modelo conduce la página. Una vez que el modelo está definido, la página en sí es relativamente mecánica.

Titular: para quién es y el beneficio principal. Mantenlo específico del producto, no genérico (“simple” y “potente” no son beneficios).

Grid de precios: nombres de plan, precio mensual, límite principal, 3–5 diferencias de features, opción de facturación anual, un plan default destacado.

Copy de lógica de upgrade: una línea por transición. “Pasa a Growth cuando necesites más de 200 workflows/mes.” No más vago que eso.

FAQ o bloque de confianza: qué cuenta hacia el límite de uso, qué pasa cuando lo alcanzas, si el downgrade está disponible y cuáles son los términos de facturación anual. Estas cuatro preguntas representan la mayoría de tickets de soporte relacionados con pricing en fase temprana.

Copy del CTA en cada plan: verbos, no sustantivos. “Empieza gratis” le gana a “Plan gratuito.” “Empezar” en Growth. “Contáctanos” solo si Scale es realmente enterprise — si es self-serve, dale un CTA real.

FAQ

¿Qué es una plantilla de modelo de precios SaaS?

Una plantilla de modelo de precios SaaS es una estructura repetible de cómo se pone precio a un producto de suscripción — sus planes, la métrica de valor que impulsa la progresión entre tiers, los límites que definen cada plan y la lógica de upgrade. Es la arquitectura económica detrás de la página de precios, no solo el diseño visual.

¿Cuántos tiers de pricing debería tener un producto SaaS?

Tres tiers es el estándar para SaaS self-serve: un tier de entrada de bajo compromiso, un tier de crecimiento por defecto y un tier de mayor uso o equipo. Menos de tres limita la capacidad de capturar diferentes segmentos; más de tres crea fatiga de comparación.

¿Cuál es el mejor modelo de pricing por suscripción para SaaS?

Para la mayoría de productos SaaS bootstrapped e indie, el pricing escalonado de tarifa plana — precio fijo por plan con un límite de uso definido — es el punto de partida con menor fricción. El pricing basado en uso funciona bien para productos de API e infraestructura donde los clientes pueden estimar su consumo. El pricing por asiento funciona mejor cuando la colaboración es el driver de valor principal.

¿Qué debería cambiar entre tiers de pricing?

Principalmente el límite de la métrica de valor (más de aquello por lo que los clientes pagan conforme obtienen más valor), secundariamente un número pequeño de diferencias de features. La razón principal para hacer upgrade debería ser clara en una frase.

¿Qué es una plantilla de modelo de ingresos SaaS?

Una plantilla de modelo de ingresos SaaS documenta cómo se estructuran los ingresos recurrentes — tiers de pricing, la métrica de valor, intervalos de facturación (mensual vs. anual), política de excedentes y triggers de upgrade. Es la lógica subyacente que una página de precios presenta a los clientes y que un sistema de facturación implementa. La estructura JSON en este artículo es un punto de partida práctico.

¿Qué debería evitar en una página de precios?

Nombres de plan vagos (Basic, Pro, Enterprise cuando realmente no vendes enterprise), límites sin explicar, triggers de upgrade que parecen arbitrarios y tablas de precios con demasiados checkmarks que oscurecen la progresión principal. El objetivo es que un visitante nuevo entienda “por qué estoy pagando y cuándo debería pagar más” en menos de 30 segundos.

Después de fijar tu precio, necesitas saber si funciona. NoNoiseMetrics rastrea ARPU y MRR por plan automáticamente. Conecta Stripe →

Free Tool
Try the SaaS Pricing Calculator →
Interactive calculator — no signup required.