Commercial Esta Collection cubre la claridad comercial básica: qué vendemos, a quién, bajo qué lógica y cómo se justifica el precio. Offer Clarity Definir con precisión qué ofrece la startup. El trato 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 Completa la frase: "Vendemos [X] a [Y] por [Z]". Valida que X es algo que el cliente puede comprar (no una tecnología abstracta). Valida que Y es un cliente real y específico, no un segmento vago. 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 Producto, servicio o híbrido 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 Define si la oferta es producto, servicio o híbrido, con justificación. Para cada componente de la oferta, identifica si escala de forma lineal o no lineal con el número de clientes. Identifica la implicación más importante de esa clasificación para el modelo de negocio. 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 Qué compra realmente el cliente 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 Escribe: "Cuando el cliente compra, obtiene…" usando lenguaje del cliente, no del producto. Identifica el problema que deja de tener el cliente. Valida estas frases con al menos tres clientes potenciales. 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 Buyer Logic Entender quién compra y por qué compra. Tipo de 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 Define si el cliente primario es una organización (B2B) o un individuo (B2C). Describe el proceso de decisión: ¿quién inicia, quién aprueba, quién paga? Estima el ciclo de venta en semanas o meses. 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 Comprador vs usuario 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 Lista todos los roles que participan en la decisión de compra en tu mercado objetivo. Para cada rol, define: ¿qué quiere?, ¿qué teme?, ¿qué poder tiene en la decisión? Identifica al comprador económico (quien firma y paga). 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 Mercado de dos lados 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 Determina: ¿necesitas dos tipos distintos de participantes para que el modelo funcione? Si sí: define quiénes son el Lado A y el Lado B y qué valor obtiene cada uno del otro. Identifica cuál lado es la restricción crítica para arrancar. 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 Pricing Logic Construir la primera lógica de precio. Precio inicial 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 Define el precio o rango de precio inicial con base en costo, mercado y valor percibido. Escribe en una frase por qué ese precio tiene sentido. Prueba el precio en al menos tres conversaciones de discovery. 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 Precio basado en 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 Cuantifica el valor que crea la solución para un cliente típico (ahorro, ingresos nuevos, riesgo evitado). Calcula el precio como porcentaje del valor creado (típicamente 10-30%). Compara el precio resultante con alternativas del mercado. 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 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 Define el modelo de ingresos: pago único, recurrente mensual/anual, consumo, licencia u otro. Escribe dos frases justificando por qué ese modelo es el correcto para tu cliente. Estima el ingreso por cliente en los primeros 12 meses bajo ese modelo. 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 Portada — Commercial 💼 Commercial Define el modelo de negocio, la estructura de precios y la naturaleza del trato con el cliente. Tarjetas de esta colección El trato Producto, servicio o híbrido Qué compra realmente el cliente Tipo de cliente Comprador vs usuario Mercado de dos lados Precio inicial Precio basado en valor Recurrente o transaccional