Una demo comercial útil permite entender qué resuelve el producto, qué necesita para funcionar y dónde termina su alcance. Si solo deja pulsar el camino que sale bien, puede parecer convincente y preparar una conversación equivocada. Diseñarla exige decidir qué experiencia representa y qué parte está simulada.

La pregunta no es cuánto puede tocar el visitante. Es qué decisión podrá tomar después. Una persona que descubre una limitación relevante y descarta la herramienta ha obtenido una respuesta útil; su salida no demuestra por sí sola que la demo haya fracasado.

Empieza por una pregunta que cambie la compra

Antes de dibujar pantallas, escribe una duda concreta: «¿Podemos revisar solicitudes incompletas sin perder quién debe resolverlas?». Es más fértil que «mostrar nuestro software», porque obliga a representar una tarea, un estado problemático y una salida.

Elige una pregunta que comercial escuche y producto pueda responder. Si nadie confirma esa necesidad, trátala como una hipótesis de trabajo. No atribuyas al mercado un problema que solo has imaginado para justificar una interfaz vistosa.

La demo comercial debe permitir comparar el proceso actual con una alternativa comprensible. No tiene que representar todos los módulos. Una escena bien delimitada puede explicar mejor una capacidad que un escritorio lleno de iconos inaccesibles.

Separa capacidad disponible y representación

Hay una diferencia entre ejecutar una operación y reproducir su aspecto. Un prototipo puede mostrar cómo se asignaría una incidencia sin guardar datos, enviar avisos ni comprobar permisos. Esa representación es válida si su límite se comunica antes de usarla.

  • Identifica los datos ficticios y evita información real de clientes.
  • Señala las acciones simuladas junto al control correspondiente.
  • Describe los requisitos de las funciones que sí existen.
  • Distingue una posibilidad de configuración de una función contratada.

No escondas todo en una nota al final. Si «Enviar al responsable» no envía nada, el estado posterior debe indicarlo. Si la integración requiere un sistema externo, no presentes su resultado como una capacidad autónoma del producto.

Interacción que se entiende sin adivinar

El patrón de botón de W3C explica cómo representar acciones y operarlas mediante teclado. Esa referencia respalda la base de interacción; no certifica que tu demo sea accesible ni que describa correctamente el negocio. Hay que comprobar ambos planos.

Deja explorar un problema, no solo un éxito

Introduce una variación significativa: falta un dato, aparece una solicitud duplicada o la persona asignada no tiene permiso. El visitante debería entender qué hace el sistema y qué sigue requiriendo intervención humana.

No conviertas la escena en un examen. Ofrece una entrada guiada para quien solo quiere orientarse y una forma clara de reiniciar. Mostrar límites no significa llenar la pantalla de avisos técnicos que impidan ver el valor.

Puede bastar con dos escenarios: una solicitud completa y otra incompleta. Lo importante es que la diferencia cambie el comportamiento de verdad. Cambiar colores sin modificar ninguna decisión añade movimiento, pero no explica capacidad.

Recurso práctico: ficha de evidencia de la demo

Propongo una ficha de evidencia por escenario. Reúne seis campos: pregunta del comprador, condición inicial, acción disponible, resultado observable, límite y siguiente pregunta para comercial. Su función es conectar cada escena con una decisión verificable.

Por ejemplo: pregunta «¿se puede corregir una solicitud?», condición «falta el destino», acción «devolver para completar», resultado «queda identificada como pendiente», límite «el aviso mostrado es simulado», siguiente pregunta «¿quién debe recibirlo en vuestro proceso?». No promete una integración que aún no se ha evaluado.

Revisa la ficha con quienes conocen producto y operaciones. Si una escena carece de resultado observable, simplifícala. Si el límite cambia la compra, debe ser visible. Si comercial no sabe qué preguntar después, falta continuidad entre demostración y contacto.

Caso hipotético: un gestor de mantenimiento

Una empresa ficticia ofrece un gestor de intervenciones. Su demo inicial muestra cómo una solicitud pasa de abierta a resuelta. El recorrido parece limpio, pero no explica qué ocurre cuando la reparación requiere una pieza sin fecha confirmada.

El equipo prepara una segunda escena. La intervención permanece pendiente, se muestra quién debe actualizarla y se distingue una previsión de una fecha comprometida. Así el comprador puede reconocer su problema cotidiano y preguntar por responsabilidades, en lugar de asumir que todo se resuelve automáticamente.

El caso es hipotético: no acredita mejoras de conversión. Para evaluarlo habría que observar si las conversaciones posteriores describen mejor el proceso y si disminuyen las expectativas incorrectas, manteniendo comparables la oferta y el origen de las consultas.

Lo que podría importar cuando las demos sean fáciles de generar

Mi hipótesis es que, si producir demostraciones visuales resulta cada vez más sencillo, la diferenciación dependerá más de mostrar condiciones y excepciones comprobables. Una pantalla elegante será menos informativa que una escena que permita reconocer un problema propio.

La apoyarían compradores que pregunten por límites después de explorar y equipos comerciales que puedan continuar desde una escena concreta. La debilitaría comprobar que el público solo necesita una explicación breve y que la exploración añade confusión sin mejorar la comprensión.

No tomes esa hipótesis como obligación de construir una demo. Para servicios difíciles de representar, una explicación del proceso con entregables y decisiones puede ser más útil. El formato se elige por la tarea, no por su apariencia de modernidad.

Una demostración que prepara una conversación mejor

Escoge una duda, muestra una situación representativa y declara lo que está simulado. Después pregunta qué condición cambia en la empresa del comprador. Esa continuidad convierte una interacción vistosa en una base concreta para valorar un proyecto, sin ampliar promesas por accidente.

Para completar esta decisión, consulta Cuando la IA resume tu vídeo B2B: ¿sobrevive la prueba de lo que vendes?.