Definición
Una demo es la demostración de tu producto a un cliente potencial. Suena inocuo y es donde se pierden muchísimas ventas que estaban ganadas, por un motivo constante: se enseña el producto en lugar de enseñar la solución al problema del cliente.
La diferencia práctica: un recorrido por todas las pantallas es una demo del producto. Enseñar exactamente cómo se resuelve lo que te contó en el discovery es una demo de su problema. La segunda cierra; la primera aburre.
De ahí la regla de oro: nunca hagas una demo sin haber hecho discovery antes. Si no sabes qué le duele, solo puedes enseñarlo todo, y enseñarlo todo es la forma más segura de que no recuerde nada.
Cómo estructurarla
1. Recapitula el problema. Empieza repitiendo lo que te contó, con sus palabras. "Me decías que cada pedido lo pasáis a mano al Excel y que se os cuelan errores." Con eso, todo lo que venga después tiene un motivo.
2. Enseña el final primero. Antes de mostrar cómo se hace, muestra el resultado. La gente se engancha al destino, no al camino.
3. Recorre solo lo que resuelve lo suyo. Tres funciones bien contadas valen más que veinte de pasada. Lo demás se menciona: "hace muchas más cosas, pero esto es lo que a ti te resuelve hoy".
4. Usa sus datos, o algo que se parezca. Una demo con "Cliente de prueba 1" y "Producto ejemplo" obliga a imaginar. Con sus referencias y sus nombres, se ve.
5. Para y pregunta. Cada pocos minutos. Una demo de treinta minutos sin una sola pregunta es una conferencia.
6. Cierra con el siguiente paso. Concreto y con fecha.
Ejemplo práctico
En AE Works, la "demo" no es de un producto estándar: es enseñar algo parecido a lo que va a tener.
Lo que aprendí es que lo que convence no son las funciones, es reconocerse. Enseñar el panel de otro cliente del mismo tipo —con permiso y con los datos tapados— hace más que cualquier lista de características. La reacción que buscas es "eso es justo lo que me pasa a mí".
En el CRM de IMDICA, cuando se enseña una sección nueva a alguien del equipo, el patrón es el mismo. La forma que no funciona es "aquí tienes filtros, aquí exportas, aquí configuras". La que sí: "¿te acuerdas de que no sabías qué presupuestos llevaban semanas parados? Mira" — y se enseña la pantalla con los rojos.
El error que más he visto cometer, y que cometí: enseñar lo que a ti te parece más ingenioso. La parte del sistema que más trabajo costó no suele ser la que al cliente le resuelve el día. Uno enseña la integración compleja que le llevó dos semanas y el cliente solo quiere saber si puede imprimir el albarán.
Errores comunes
- Demo sin discovery. El error de base.
- Enseñarlo todo. Cuanto más enseñas, menos recuerdan.
- Hablar de funciones en vez de resultados. "Tiene informes configurables" no dice nada; "sabrás cada lunes qué clientes han dejado de pedir" sí.
- Datos de ejemplo genéricos.
- No parar a preguntar.
- Enseñar lo que a ti te gusta en vez de lo que a él le duele.
- Improvisar sin probar. Una demo en directo que falla destruye la confianza. Ensáyala.
- Prometer lo que no existe. El "eso está en el roadmap" se convierte en un problema al entregar.
- Acabar sin siguiente paso.
Cuando algo falla en directo
Pasa. Lo que hay que evitar es la reacción de esconderlo: "qué raro, normalmente funciona" suena peor que el fallo. Reconocerlo, seguir y volver a ello después transmite más solvencia que fingir.
Y si el fallo es grande, tener una grabación de respaldo lo salva.
Cuándo hacerla
Después del discovery y antes de la propuesta, cuando el cliente ya ha reconocido el problema y quiere ver si tu solución encaja.
Si te piden una demo antes de contarte nada —cosa habitual—, la respuesta que funciona no es negarse: "claro, y para enseñarte lo que te sirve, cuéntame primero cómo lo lleváis ahora". Con cinco minutos de contexto la demo mejora muchísimo.
