***Habilidad:** Resumir el negocio de la startup en una frase clara que explique qué vende, a quién y a qué precio.* --- ## ¿Por qué importa esta habilidad? Si el founder no puede explicar su negocio en una frase, la startup tiene un problema de claridad comercial. "El trato" es el punto de partida de cualquier conversación comercial y el filtro para decisiones de producto. ## Qué se ve como un buen resultado El equipo puede completar esta frase: "Vendemos \[qué\] a \[quién\] a \[precio / modelo de ingreso\]", sin ambigüedad y sin necesidad de explicaciones adicionales. ## Errores comunes - Describir la tecnología en lugar de la oferta. - Incluir jerga técnica que el comprador no usa. - Escribir el trato en términos de impacto en lugar de en términos comerciales. - Confundir el trato con la propuesta de valor. ## Preguntas que el startup debe responder - ¿Qué compra exactamente el cliente? - ¿Quién es el cliente que paga? - ¿Cuánto paga y cuándo paga? - ¿Puede alguien que no conoce la startup entender el trato en diez segundos? ## Artifact requerido

### 📄 Declaración de El Trato **Propósito:** Capturar en una frase el negocio de la startup desde la perspectiva comercial más básica. **Card vinculada:** El trato #### Instrucciones de desarrollo 1. Completa la frase: "Vendemos \[X\] a \[Y\] por \[Z\]". 2. Valida que X es algo que el cliente puede comprar (no una tecnología abstracta). 3. Valida que Y es un cliente real y específico, no un segmento vago. 4. Valida que Z es un precio o modelo de ingreso concreto. **Estado esperado:** Frase de una a dos líneas, clara y verificable, validada por alguien externo al equipo. #### Criterios de revisión del Artifact - Identifica el objeto de compra de forma específica. - Identifica el tipo de cliente de forma específica. - Incluye un modelo de precio o ingreso. - Puede entenderse sin contexto adicional. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - La declaración de El Trato existe en forma escrita. - Ha sido validada por alguien fuera del equipo. - El equipo la usa para introducir el negocio en conversaciones comerciales. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No existe ninguna descripción del negocio en términos comerciales.
En progreso	Existe una descripción pero es vaga o técnica.
Completo	La frase identifica qué, quién y precio de forma básica.
Revisado	Ha sido validada por personas externas al equipo.
Cumple estándar	El trato es claro, diferenciado y refleja el segmento Beachhead.
Fuerte/Sobresaliente	El trato se actualiza con cada iteración del modelo de negocio.

## Cards relacionadas / siguiente paso - Producto, servicio o híbrido - Qué compra realmente el cliente - Tipo de cliente

***Habilidad:** Clasificar correctamente la naturaleza de la oferta para elegir la lógica financiera y comercial adecuada.* --- ## ¿Por qué importa esta habilidad? Un producto y un servicio tienen estructuras de costo, precio, entrega y escala radicalmente diferentes. Confundir la clasificación lleva a modelos de negocio incoherentes y decisiones de go-to-market equivocadas. ## Qué se ve como un buen resultado El equipo puede clasificar su oferta con claridad (producto, servicio o híbrido) y explicar por qué esa clasificación importa para su modelo de negocio y estrategia de precios. ## Errores comunes - Decir "tenemos un producto" cuando en realidad es principalmente servicios. - No reconocer que muchos cleantech son híbridos hardware-servicio. - Ignorar cómo la clasificación afecta el CAC, el margen y la escala. - Cambiar la clasificación sin ajustar la lógica financiera. ## Preguntas que el startup debe responder - ¿El cliente puede usar la oferta sin la intervención del equipo? - ¿Los costos escalan con el número de clientes o son relativamente fijos? - ¿Hay un componente hardware, software o ambos? - ¿Cómo cambia el margen a medida que aumentan los clientes? ## Artifact requerido

### 📄 Matriz de tipo de oferta **Propósito:** Clasificar la oferta del startup y documentar las implicaciones para precio, costo y escala. **Card vinculada:** Producto, servicio o híbrido #### Instrucciones de desarrollo 1. Define si la oferta es producto, servicio o híbrido, con justificación. 2. Para cada componente de la oferta, identifica si escala de forma lineal o no lineal con el número de clientes. 3. Identifica la implicación más importante de esa clasificación para el modelo de negocio. 4. Valida la clasificación con alguien con experiencia en ese tipo de oferta. **Estado esperado:** Matriz completada con clasificación justificada e implicaciones identificadas. #### Criterios de revisión del Artifact - La clasificación es específica (no "somos un poco de todo"). - Las implicaciones de escala están identificadas. - El equipo entiende cómo la clasificación afecta el pricing. - La clasificación es coherente con el modelo financiero. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - La oferta tiene una clasificación definida y justificada. - El equipo puede explicar las implicaciones de esa clasificación. - La clasificación es coherente con el árbol financiero. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay claridad sobre el tipo de oferta.
En progreso	Hay una clasificación intuitiva pero no documentada.
Completo	La clasificación está documentada con justificación básica.
Revisado	Las implicaciones para precio y costo están identificadas.
Cumple estándar	La clasificación es coherente con el modelo financiero y el go-to-market.
Fuerte/Sobresaliente	La clasificación guía decisiones de producto y escala de forma activa.

## Cards relacionadas / siguiente paso - El trato - Árbol financiero - Precio basado en valor

***Habilidad:** Definir el objeto real de compra desde la perspectiva del cliente, no desde la perspectiva del producto.* --- ## ¿Por qué importa esta habilidad? Los clientes no compran tecnología ni features; compran resultados, seguridad, tiempo ahorrado o riesgo reducido. Entender qué compra realmente el cliente es la base para construir una oferta que venda. ## Qué se ve como un buen resultado El equipo puede describir en términos del cliente —no del producto— qué obtiene el cliente cuando compra. Esto es específico, funcional y vinculado al problema que resuelve. ## Errores comunes - Describir lo que hace el producto en lugar de lo que obtiene el cliente. - Usar el lenguaje de la startup en lugar del lenguaje del comprador. - Confundir el resultado funcional con el beneficio emocional. - No validar esta definición con clientes reales. ## Preguntas que el startup debe responder - ¿Qué resultado concreto obtiene el cliente al comprar? - ¿Cómo describiría el cliente la compra a un colega? - ¿Qué problema deja de tener el cliente después de comprar? - ¿Qué palabra usaría el cliente para describir lo que adquirió? ## Artifact requerido

### 📄 Ficha de oferta comprable **Propósito:** Documentar el objeto real de compra desde la perspectiva del cliente, en su propio lenguaje. **Card vinculada:** Qué compra realmente el cliente #### Instrucciones de desarrollo 1. Escribe: "Cuando el cliente compra, obtiene…" usando lenguaje del cliente, no del producto. 2. Identifica el problema que deja de tener el cliente. 3. Valida estas frases con al menos tres clientes potenciales. 4. Ajusta la ficha con el lenguaje que los clientes usaron en sus respuestas. **Estado esperado:** Ficha validada con lenguaje de cliente, que describe resultado funcional y problema resuelto. #### Criterios de revisión del Artifact - Usa el lenguaje del cliente, no del producto. - Describe un resultado concreto, no una feature. - Ha sido validada con clientes reales o potenciales. - Puede usarse directamente en materiales de venta. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - La ficha describe el objeto de compra en lenguaje de cliente. - Ha sido validada con al menos tres clientes o potenciales. - Es distinguible de la descripción técnica del producto. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay descripción del objeto de compra desde el cliente.
En progreso	Hay una descripción pero está en lenguaje interno del equipo.
Completo	La ficha usa lenguaje de cliente y describe resultados.
Revisado	Ha sido validada con clientes reales.
Cumple estándar	La ficha se usa en materiales de venta y conversaciones comerciales.
Fuerte/Sobresaliente	Se actualiza con cada ronda de discovery y refleja el lenguaje real del mercado Beachhead.

## Cards relacionadas / siguiente paso - El trato - Tipo de cliente - Dolor del cliente

***Habilidad:** Distinguir entre lógica B2B y B2C para elegir el modelo comercial correcto.* --- ## ¿Por qué importa esta habilidad? Las startups que no tienen claridad sobre su lógica de cliente —B2B, B2C o mixta— construyen procesos de venta, pricing y go-to-market completamente equivocados. Un startup cleantech que vende a empresas necesita una lógica radicalmente diferente a una que vende a consumidores. ## Qué se ve como un buen resultado El equipo puede clasificar su modelo con claridad y explicar por qué esa clasificación define el ciclo de venta, quién aprueba la compra y qué tan larga es la decisión. ## Errores comunes - Decir "vendemos a todos" sin especificar si la lógica es B2B o B2C. - Mezclar estrategias B2B y B2C sin una razón clara. - Subestimar la longitud del ciclo de venta en B2B. - Ignorar que en B2B el usuario y el pagador suelen ser personas distintas. ## Preguntas que el startup debe responder - ¿Quién firma el contrato o hace el pago? - ¿Es una decisión individual o institucional? - ¿Cuánto tarda el ciclo de venta típico? - ¿Cuántas personas están involucradas en la decisión de compra? ## Artifact requerido

### 📄 Hoja de lógica de compra **Propósito:** Documentar la lógica de compra del cliente: quién compra, cómo decide y cuánto tarda. **Card vinculada:** Tipo de cliente #### Instrucciones de desarrollo 1. Define si el cliente primario es una organización (B2B) o un individuo (B2C). 2. Describe el proceso de decisión: ¿quién inicia, quién aprueba, quién paga? 3. Estima el ciclo de venta en semanas o meses. 4. Identifica las dos principales diferencias de tu modelo respecto a la lógica estándar de tu tipo. **Estado esperado:** Hoja con clasificación, proceso de decisión y ciclo de venta estimado. #### Criterios de revisión del Artifact - La clasificación B2B/B2C está definida y justificada. - El proceso de decisión tiene al menos dos roles identificados. - El ciclo de venta tiene una estimación con base en conversaciones reales. - El equipo puede usar esta hoja para diseñar su go-to-market. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - La lógica de compra está documentada y validada. - El equipo entiende el ciclo de decisión del cliente. - La hoja es coherente con la estrategia de go-to-market. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay claridad sobre B2B vs B2C.
En progreso	Hay una idea intuitiva pero no documentada.
Completo	La clasificación está definida con proceso de decisión básico.
Revisado	El ciclo de venta tiene evidencia real de clientes.
Cumple estándar	La lógica de compra orienta el diseño del proceso comercial.
Fuerte/Sobresaliente	Se actualiza con el aprendizaje de conversaciones y cierre de ventas.

## Cards relacionadas / siguiente paso - El trato - Comprador vs usuario - Selección del mercado Beachhead

***Habilidad:** Diferenciar entre el usuario final, el comprador y el influenciador en el proceso de adopción.* --- ## ¿Por qué importa esta habilidad? En muchos mercados B2B, quien usa el producto no es quien lo compra. Ignorar esta diferencia lleva a pitchear a la persona equivocada, hacer las preguntas incorrectas en discovery y construir una propuesta de valor que no mueve la decisión de compra. ## Qué se ve como un buen resultado El equipo tiene un mapa claro de los actores de compra en su mercado Beachhead: quién usa, quién decide, quién paga y quién puede bloquear la compra. ## Errores comunes - Asumir que el usuario es siempre el comprador. - Ignorar la figura del influenciador o gatekeeper. - Construir el pitch solo para el usuario final. - No identificar quién tiene autoridad de presupuesto. ## Preguntas que el startup debe responder - ¿Quién usa el producto en el día a día? - ¿Quién aprueba la compra? - ¿Quién tiene autoridad sobre el presupuesto? - ¿Quién puede decir que no aunque no sea el decisor final? ## Artifact requerido

### 📄 Mapa de actores de compra **Propósito:** Identificar y documentar todos los roles involucrados en la decisión de adopción del startup. **Card vinculada:** Comprador vs usuario #### Instrucciones de desarrollo 1. Lista todos los roles que participan en la decisión de compra en tu mercado objetivo. 2. Para cada rol, define: ¿qué quiere?, ¿qué teme?, ¿qué poder tiene en la decisión? 3. Identifica al comprador económico (quien firma y paga). 4. Identifica al bloqueador más probable y piensa cómo abordarlo. **Estado esperado:** Mapa con al menos tres roles identificados, con motivaciones y poder de decisión documentados. #### Criterios de revisión del Artifact - Incluye usuario, comprador y al menos un influenciador o bloqueador. - Cada rol tiene motivación y nivel de poder documentados. - Ha sido validado con conversaciones de discovery. - El equipo usa este mapa para diseñar sus conversaciones de venta. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - El mapa de actores tiene al menos tres roles definidos. - Ha sido validado con potenciales clientes. - El equipo lo usa para preparar conversaciones comerciales. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay distinción entre usuario y comprador.
En progreso	Hay conciencia informal de los roles pero no está documentada.
Completo	El mapa tiene usuario y comprador identificados.
Revisado	Incluye influenciadores y bloqueadores con motivaciones.
Cumple estándar	El mapa guía el diseño de las conversaciones de venta.
Fuerte/Sobresaliente	Se actualiza con el aprendizaje de cada ciclo de ventas.

## Cards relacionadas / siguiente paso - Tipo de cliente - Mercado de dos lados - Lista objetivo de entrevistas

***Habilidad:** Reconocer si el modelo de negocio requiere más de un tipo de cliente para funcionar.* --- ## ¿Por qué importa esta habilidad? Algunos modelos solo funcionan si se capturan dos audiencias simultáneamente. Intentar construir un mercado de dos lados sin reconocerlo explícitamente es una de las trampas más frecuentes en startups cleantech de plataforma. ## Qué se ve como un buen resultado El equipo ha evaluado si su modelo es de un solo lado o de dos lados, y si es de dos lados, tiene claridad sobre cuál audiencia priorizar primero y por qué. ## Errores comunes - No reconocer que el modelo requiere dos tipos de cliente. - Intentar capturar ambos lados del mercado con los mismos recursos desde el inicio. - No definir cuál lado priorizar para alcanzar masa crítica. - Confundir un mercado de dos lados con tener dos segmentos de cliente. ## Preguntas que el startup debe responder - ¿Necesita la startup tener Tipo A de cliente para atraer Tipo B? - ¿El valor para uno aumenta con el número del otro? - ¿Cuál lado necesita más para que el modelo funcione? - ¿Cómo se supera el problema del "huevo y la gallina"? ## Artifact requerido

### 📄 Mapa de mercado de dos lados **Propósito:** Documentar si el modelo es de dos lados, qué audiencias involucra y cómo se resuelve el problema de arranque. **Card vinculada:** Mercado de dos lados #### Instrucciones de desarrollo 1. Determina: ¿necesitas dos tipos distintos de participantes para que el modelo funcione? 2. Si sí: define quiénes son el Lado A y el Lado B y qué valor obtiene cada uno del otro. 3. Identifica cuál lado es la restricción crítica para arrancar. 4. Define la estrategia mínima para superar el problema del arranque. **Estado esperado:** Mapa que confirma si hay dos lados, los describe y define la estrategia de arranque. #### Criterios de revisión del Artifact - La evaluación de si es mercado de dos lados está documentada con justificación. - Si aplica, ambos lados están definidos con el valor que obtienen. - La restricción de arranque está identificada. - Hay una estrategia mínima de arranque definida. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - El equipo tiene claridad sobre si su modelo es de uno o dos lados. - Si es de dos lados, la estrategia de arranque está documentada. - La decisión de prioridad de lado está justificada. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No se ha evaluado si el modelo es de dos lados.
En progreso	Hay conciencia del tema pero no está documentado.
Completo	La evaluación existe con definición de los lados.
Revisado	La estrategia de arranque está definida con lógica.
Cumple estándar	La estrategia de arranque tiene evidencia de validación.
Fuerte/Sobresaliente	El mapa guía las decisiones de crecimiento y partnerships.

## Cards relacionadas / siguiente paso - Tipo de cliente - El trato - Selección del mercado Beachhead

***Habilidad:** Proponer un precio preliminar coherente para comenzar conversaciones comerciales reales.* --- ## ¿Por qué importa esta habilidad? Muchos founders evitan el precio porque temen equivocarse. Pero sin un precio, no hay conversación comercial real. El precio inicial no tiene que ser perfecto: tiene que ser un punto de partida que permita aprender. ## Qué se ve como un buen resultado El equipo tiene un precio inicial propuesto con al menos una justificación básica. Puede ser rango o punto, pero existe y se usa en conversaciones con clientes. ## Errores comunes - Esperar a tener el modelo financiero completo para proponer un precio. - Poner un precio solo basado en el costo sin considerar el valor. - No probar el precio con clientes reales por miedo al rechazo. - Cambiar el precio con cada conversación sin aprender de los patrones. ## Preguntas que el startup debe responder - ¿Cuánto cuesta producir o entregar la oferta? - ¿Qué precio comparable existe en el mercado? - ¿Cuánto vale el resultado para el cliente? - ¿Cuál sería el precio que haría que el cliente dijera "eso es razonable"? ## Artifact requerido

### 📄 Hoja de precio inicial **Propósito:** Documentar el precio propuesto con su justificación y las reacciones del mercado. **Card vinculada:** Precio inicial #### Instrucciones de desarrollo 1. Define el precio o rango de precio inicial con base en costo, mercado y valor percibido. 2. Escribe en una frase por qué ese precio tiene sentido. 3. Prueba el precio en al menos tres conversaciones de discovery. 4. Documenta las reacciones: ¿caro, barato, razonable? ¿Por qué? **Estado esperado:** Hoja con precio propuesto, justificación y primeras reacciones del mercado documentadas. #### Criterios de revisión del Artifact - El precio está definido de forma específica (no solo "asequible"). - La justificación cubre al menos uno de los tres criterios: costo, mercado, valor. - Se probó con al menos tres clientes potenciales. - Las reacciones están documentadas con citas o notas. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - El precio inicial existe y está justificado. - Ha sido probado con potenciales clientes. - Las reacciones están documentadas y se usan para iterar. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay ningún precio definido.
En progreso	Hay un precio intuitivo no documentado.
Completo	El precio está definido con justificación básica.
Revisado	El precio fue probado con clientes y las reacciones están documentadas.
Cumple estándar	El precio refleja aprendizaje de mercado y es coherente con el valor creado.
Fuerte/Sobresaliente	El modelo de precio guía las conversaciones comerciales y se actualiza con cada ciclo.

## Cards relacionadas / siguiente paso - Precio basado en valor - Recurrente o transaccional - Cuantificación del valor

***Habilidad:** Justificar el precio de la oferta desde el valor percibido o creado para el cliente, no solo desde el costo.* --- ## ¿Por qué importa esta habilidad? Las startups que solo calculan el precio desde el costo suelen dejar dinero sobre la mesa o subcobrar. El precio basado en valor conecta lo que el cliente gana con lo que paga, haciendo la conversación comercial más sólida. ## Qué se ve como un buen resultado El equipo puede articular la lógica de valor que justifica el precio: "el cliente paga X porque obtiene Y, y Y vale Z para él". Esta lógica sobrevive una conversación comercial real. ## Errores comunes - Justificar el precio solo con "el mercado cobra eso". - No cuantificar el valor que se crea para el cliente. - Usar lógica de valor sin evidencia de que el cliente lo percibe así. - Dejar el pricing a "lo que el cliente esté dispuesto a pagar" sin un ancla racional. ## Preguntas que el startup debe responder - ¿Cuánto dinero ahorra o gana el cliente con esta solución? - ¿Qué porcentaje del valor creado sería un precio justo? - ¿Qué alternativa tiene el cliente y cuánto le cuesta? - ¿Cómo presenta el equipo la lógica de precio en una conversación de venta? ## Artifact requerido

### 📄 Modelo simple de pricing basado en valor **Propósito:** Construir la lógica de valor que justifica el precio propuesto con números del cliente. **Card vinculada:** Precio basado en valor #### Instrucciones de desarrollo 1. Cuantifica el valor que crea la solución para un cliente típico (ahorro, ingresos nuevos, riesgo evitado). 2. Calcula el precio como porcentaje del valor creado (típicamente 10-30%). 3. Compara el precio resultante con alternativas del mercado. 4. Valida la lógica en conversaciones con al menos dos clientes. **Estado esperado:** Modelo con valor cuantificado, precio derivado y comparación de mercado. #### Criterios de revisión del Artifact - El valor se expresa en términos numéricos del cliente (no de features). - El precio tiene una lógica de captura de valor explícita. - Se compara con alternativas reales del mercado. - Ha sido probado en conversaciones comerciales. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - El modelo de pricing basado en valor está documentado. - El valor creado tiene cuantificación con base en datos del cliente. - La lógica ha sido probada en conversaciones reales. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay ninguna lógica de pricing basada en valor.
En progreso	Hay una intuición de valor pero no está cuantificada.
Completo	El modelo tiene valor estimado y precio derivado.
Revisado	El modelo fue validado con clientes reales.
Cumple estándar	La lógica de valor es el argumento central en las conversaciones de venta.
Fuerte/Sobresaliente	El modelo se actualiza con cada cierre o pérdida de venta.

## Cards relacionadas / siguiente paso - Precio inicial - Cuantificación del valor - Recurrente o transaccional

***Habilidad:** Definir si el ingreso del startup es único, recurrente o mixto, y diseñar la estructura de ingresos inicial.* --- ## ¿Por qué importa esta habilidad? La diferencia entre ingreso transaccional y recurrente define el valor de largo plazo de la empresa, la predictibilidad del flujo de caja y el atractivo para inversores. Esta decisión hay que tomarla conscientemente, no por defecto. ## Qué se ve como un buen resultado El equipo ha definido el modelo de ingresos (pago único, suscripción, consumo, licencia, etc.) con justificación y ha estimado cómo ese modelo impacta en la predictibilidad del negocio. ## Errores comunes - Elegir suscripción porque "las startups hacen eso" sin validar si el cliente acepta ese modelo. - No considerar el impacto del churn en modelos recurrentes. - Mezclar modelos de ingreso sin una lógica clara. - No calcular el impacto del modelo de ingresos en el flujo de caja. ## Preguntas que el startup debe responder - ¿El cliente paga una vez o de forma periódica? - ¿Qué modelo prefiere el cliente según lo que dijo en discovery? - ¿Cómo afecta el modelo de ingreso al flujo de caja en los primeros 12 meses? - ¿El equipo puede asumir el costo de adquisición dado el modelo de ingreso? ## Artifact requerido

### 📄 Estructura de ingresos inicial **Propósito:** Documentar el modelo de ingresos elegido, su justificación y el impacto estimado en el flujo de caja. **Card vinculada:** Recurrente o transaccional #### Instrucciones de desarrollo 1. Define el modelo de ingresos: pago único, recurrente mensual/anual, consumo, licencia u otro. 2. Escribe dos frases justificando por qué ese modelo es el correcto para tu cliente. 3. Estima el ingreso por cliente en los primeros 12 meses bajo ese modelo. 4. Identifica el riesgo principal del modelo (ej. churn en recurrente, cierre largo en transaccional). **Estado esperado:** Estructura documentada con modelo de ingreso, justificación e impacto estimado. #### Criterios de revisión del Artifact - El modelo de ingresos está definido de forma específica. - Tiene justificación vinculada al comportamiento del cliente. - El ingreso por cliente tiene una estimación para 12 meses. - El riesgo principal del modelo está identificado. **Estado:** ☐ No iniciado | ☐ En progreso | ☐ Completo | ☐ Revisado | ☐ Cumple estándar | ☐ Fuerte/Sobresaliente

## Criterios de completitud - La estructura de ingresos está documentada y justificada. - Existe una estimación del ingreso por cliente. - El equipo entiende el impacto del modelo en el flujo de caja. ## Rúbrica de revisión

Nivel	Descripción
No iniciado	No hay ninguna estructura de ingresos definida.
En progreso	El modelo de ingreso es intuitivo pero no está documentado.
Completo	La estructura está definida con justificación básica.
Revisado	Tiene estimación por cliente y análisis de flujo de caja.
Cumple estándar	La estructura está validada con feedback de clientes y modelos financieros.
Fuerte/Sobresaliente	El modelo de ingresos evoluciona con el aprendizaje de ventas y se refleja en el árbol financiero.

## Cards relacionadas / siguiente paso - Precio basado en valor - Árbol financiero - Vida del cliente