Primera demo de un SaaS B2B: cómo hacerla como founder y qué dejar acordado al final

En la primera demo de un SaaS B2B, yo dedicaría la primera mitad a preguntar y la segunda a mostrar solo lo que resuelve lo que la persona te acaba de contar. Al final, antes de cortar, dejaría acordado un próximo paso con fecha y con quién. Una demo que termina en "te mando info" suele enfriarse.

La demo es una de las etapas del pipeline. Cómo ordenarlas está en el pipeline de founder-led sales. Acá voy a la reunión en sí.

Antes de la reunión

Diez minutos de preparación alcanzan:

1. Qué sabés de la empresa. Industria, tamaño aproximado, país, y por qué aceptó la reunión. Si vino por un mensaje de outbound, releería qué le escribiste.
2. Quién va a estar. No es lo mismo el que usa la herramienta que el que la paga. Si no sabés quién decide, eso es una de las preguntas.
3. Una hipótesis del problema. Una línea. "Creo que hoy concilian a mano y cierran tarde." La vas a confirmar o tirar en los primeros minutos.
4. El entorno de demo listo. Datos de ejemplo que se parezcan a su negocio, sin datos de otros clientes. Probaría el recorrido una vez antes, porque lo que falla en vivo se recuerda más que lo que funciona.

Los primeros 15 minutos: preguntar

No arrancaría compartiendo pantalla. Arrancaría con algo así: "Antes de mostrarte, contame cómo lo resuelven hoy, así te muestro lo que te sirve y no todo."

Preguntas que haría:

• Cómo lo hacen hoy, paso a paso, y quién lo hace.
• Cuándo fue la última vez que salió mal, y qué pasó.
• Qué probaron antes y por qué lo dejaron.
• Qué tendría que pasar para que valga la pena cambiar.
• Quién más participa en la decisión y cómo compran este tipo de cosas.

Si en estas preguntas aparece que el problema no le duele, lo diría. Te ahorrás a vos y a él una demo de 40 minutos. Muchas de estas preguntas salen de las entrevistas de validación del problema, con la diferencia de que acá ya estás vendiendo.

Mostrar: poco y conectado

Mostraría dos o tres cosas, cada una atada a algo que dijo:

• "Me dijiste que el cierre se atrasa por la conciliación. Esto es lo que vería tu equipo el día 1 del mes."
• "Contaste que el error estaba en las planillas que llegan por mail. Acá se cargan así."

Lo que no tocó, no lo mostraría. Si pregunta por una función que no existe, diría que no existe. Si está en el roadmap con fecha, diría la fecha. Si no hay fecha, no la inventaría para salvar la reunión, porque esa promesa la vas a tener que cumplir en el onboarding.

Los últimos 10 minutos: el próximo paso

Reservaría tiempo para esto. Opciones según cómo vino la reunión:

• Prueba o piloto, con qué datos, por cuánto tiempo y qué resultado lo da por bueno.
• Propuesta con precio, con fecha para revisarla juntos.
• Reunión con quien decide, con nombre y fecha.
• No avanzar, si quedó claro que no es para ellos. También es un resultado, y te limpia el pipeline.

Lo pediría en voz alta: "Te parece si agendamos el jueves para revisar la propuesta con vos y con quien firma?" Y mandaría la invitación ese mismo día, con un resumen corto de lo que entendiste del problema. Si el resumen está mal, te lo van a corregir, y eso también te sirve.

Ejemplo hipotético

Un SaaS para gestionar órdenes de compra en empresas con varias sedes. El founder llega con la hipótesis de que el problema es aprobar rápido. En las preguntas aparece otra cosa: cada sede compra al mismo proveedor a precios distintos y nadie lo ve hasta fin de mes. En la demo muestra solo el reporte de precios por proveedor y cómo se carga una orden. Cierra con un piloto de un mes en dos sedes, con la gerente de compras y el CFO en la reunión de cierre del piloto.

El caso es inventado para el ejemplo. El orden es el mismo que arriba: preguntar, mostrar lo que conecta y acordar el siguiente paso.

Sin revenue y con revenue

Sin revenue, cada demo es también una entrevista. Anotaría qué objeciones se repiten y qué partes del producto nadie pidió ver. Si después de varias demos nadie acepta un próximo paso concreto, revisaría el problema o el segmento antes que el pitch.

Con revenue, ya tenés casos parecidos para contar y una demo que funciona. Lo que cuidaría es no saltear las preguntas por costumbre. Una demo armada para el cliente típico puede no servirle al que tenés enfrente. Si estás por sumar a alguien que haga demos, la parte de pasarle esto está en el primer vendedor con revenue.

Dónde entra GTM OS

En GTM OS, el contexto de tu empresa, con el ICP, las personas y la propuesta de valor, lo armás con Claude, y las campañas que generan las reuniones salen de ahí. Cuando una reunión queda agendada, GTM OS la detecta, arma el resumen con la transcripción y te pide el próximo paso. El pipeline lo seguís desde la App.

La demo la hacés vos. GTM OS no la presenta ni decide qué mostrarle a cada cuenta.

Los 15 días gratis son del plan de GTM OS, sin tarjeta. Hace falta un plan pago de Claude (Pro, Max, Team o Enterprise) y una cuenta gratis de Supabase. Smartlead, HeyReach o una herramienta de datos se pagan aparte desde el primer día. Si seguís, el plan pasa a USD 400 por mes. Cancelás cuando quieras desde la App.

Lo operás vos. Que el equipo de ZalesMachine opere tus campañas es el servicio de la agencia.

Preguntas frecuentes

Cuánto tiene que durar una primera demo?

Entre 30 y 45 minutos me parece razonable para una primera reunión B2B, con la mitad para preguntas. Si en 15 minutos queda claro que no hay problema, cortaría antes.

Mando la grabación o un video de la demo después?

Mandaría un resumen escrito del problema y del próximo paso acordado. Si la persona tiene que mostrarle el producto a alguien más, ahí sí un video corto de lo que viste juntos puede ayudar.

Puedo probar el seguimiento de reuniones en los 15 días gratis?

Sí, es parte del plan de GTM OS durante la prueba. Las herramientas de envío y de datos se pagan aparte desde el primer día. Creá tu cuenta, o agendá una reunión si preferís verlo antes con el equipo.