ES 
EN 
¿Alguna vez ha oído (o dicho):
"Lo siento, no tengo un ejemplo así en nuestro sistema de demostración...".
"No, no podemos mostrar ese flujo de trabajo - se trata de una base de datos de demostración..."
"Nuestro entorno de demostración no está actualizado - por eso esta función no funciona..."
"No, no tengo buenos datos para mostrar en este informe - ningún dato, de hecho - ¡lo siento...!".
"Ese informe no se ha creado para nuestro sistema de demostración, pero créeme, es estupendo".
En sus demostraciones, ¿con qué frecuencia se disculpa por su incapacidad para demostrar capacidades, completar flujos de trabajo o presentar resultados e informes convincentes? Demasiado a menudo, en muchos casos.
Un entorno de demostración perfecto le permite mostrar lo que tiene que mostrar, de forma clara y convincente. Sin disculpas ni excusas. Por eso, aquí tienes algunas recomendaciones para que tus demostraciones sean lo más nítidas, convincentes y exitosas posible.
No lo llames "Demo
Uno de nuestros objetivos en una demostración de software es "suspender la incredulidad". Cualquier cosa que parezca real ayuda a nuestra causa; cualquier cosa que parezca falsa nos perjudicará.
¡A pesar de que enseñamos técnicas de "demostración" en nuestros talleres Great Demo! y a pesar de que el cliente tiene la oportunidad de preguntó para una "demo", recomiendo evitar el uso de la palabra "demo" en, bueno, demos... Y, en particular, en entornos de demostración.
¿Por qué? Porque los clientes traducen inconscientemente la palabra "demo" por "falso". Si se trata de una demo no es real desde el punto de vista del cliente. Todo lo que se haga en un entorno así es sospechoso.
Así que no lo llames sistema "demo", entorno "demo" o similar. En su lugar, dale el nombre de un cliente ficticio pero plausible u otra opción que suene realista. ("Apex" es un ejemplo que utilizamos hace tiempo...)
Y no etiquetes las cosas como "Demo
Del mismo modo, cualquier cosa etiquetada como "demo" en su (ejem) entorno provoca el mismo resultado.
Nombres de archivos, etiquetas de módulos, nombres de inicio de sesión, formularios, cuadros de mando... Los he visto todos adornados con "demo" de una forma u otra. Todo ello grita sutilmente "falso" a nuestros clientes.
De nuevo, utilice un nombre neutro o una convención de nomenclatura que se parezca a la de un cliente real. Mucho mejor.
Sin nombres obviamente ficticios
Del mismo modo, cuando un cliente ve los nombres de personajes famosos en su entorno de demostración, esto también dice: "¡Esto es falso!" a los clientes.
Hace poco vi a un vendedor que utilizaba los nombres de los actores de la serie completa de películas Océanos XX -incluidos George Clooney, Brad Pitt y Julia Roberts (el reparto original) además de Sandra Bullock, Cate Blanchett y Anne Hathaway-, todos estos nombres estaban en la base de datos de demostración del vendedor. También he visto figuras del deporte, científicos importantes, autores y mucho más.
Quizá sea fácil recordar los nombres, pero comunican "¡Esto es falso!" a los clientes.
En su lugar, utilice nombres, direcciones y otros datos realistas. Una solución sencilla es utilizar los nombres reales de su organización: eso es una mejora.
Una buena fuente de datos ficticios convincentes son las bases y fuentes de datos creadas y utilizadas por el equipo de control de calidad de su propia organización. Al fin y al cabo, su personal de control de calidad necesita datos realistas suficientes para explorar una amplia gama de escenarios de pruebas (¡hmmm - escenarios potencialmente muy similares a los que usted necesita demostrar!). Algunos ejemplos de fuentes son Generador de datos MDT, Generador de datos SQLy Mockaroo.
Incluir problemas, excepciones y oportunidades
Situación actual es aburrido.
He visto innumerables demostraciones que presentan un cuadro de mandos o un informe que muestra que todo "va bien", que todo está "en verde", sin problemas ni preocupaciones. Esto no tiene sentido. Tienes que demostrar que tus herramientas pueden encuentre los problemas del cliente y que su software puede abordar directamente esos problemas o permitir soluciones.
Las demostraciones más convincentes muestran ejemplos de cómo los clientes pueden resolver sus problemas empresariales, abordar los valores atípicos y las excepciones, y sacar a la luz y explotar las oportunidades. Esto significa que su entorno de demostración debe incluir buenas instancias de estos elementos con buenos datos de ejemplo.
Los problemas deben descubrirse y presentarse con claridad, y ofrecer la posibilidad de generar y enviar alertas desde su sistema (tal y como lo utilizaría un cliente).
Las excepciones deben ser igualmente detectables, con los datos adecuados para explorar y determinar cómo abordarlas (igual que investigaría un cliente).
Las oportunidades deben ser fácilmente visibles y explotables (tal y como las buscaría un cliente).
¡Cuanto más realista, mejor...!
EE.UU. vs. Internacional
Cuando me desterraron al extranjero (a Suiza, tarea difícil), me di cuenta de que nuestro entorno de demostración estaba totalmente centrado en Estados Unidos. Esto puede ser un gran "fallo" para los clientes no estadounidenses.
Las empresas con sede en EE.UU. suelen utilizar entornos de demostración que muestran mapas de EE.UU., enumeran ciudades y direcciones de EE.UU., números de teléfono de EE.UU., moneda de EE.UU., códigos postales de EE.UU. (¡incluso el uso del término "código postal" es un ejemplo!), nombres de productos de EE.UU. y mucho más. Esto puede resultar medio insultante para el público no estadounidense, y no ayudará a su causa.
Si quiere vender en Europa, asegúrese de disponer de euros, direcciones y códigos postales europeos, prefijos telefónicos y todas las demás unidades y medidas que se utilizan en los países y mercados de destino. (Furlongs per fortnight es una de mis unidades arcanas favoritas...).
¿Quiere vender en el Reino Unido o en otros países de habla inglesa (pero no estadounidenses)? Es posible que también tenga que utilizar su versión local de la ortografía y el vocabulario ingleses. Ahora que casilla está marcada...
¿Lanzamiento en Asia-Pacífico? Las mismas directrices.
¿No soporta las lenguas locales en estas regiones? ¡Quizá deba replantearse su estrategia...!
En pocas palabras, necesitamos datos específicos de cada región (según proceda) si queremos ofrecer a los clientes una visión de la utilización de nuestras herramientas en la región o regiones en las que se utilizan. ellos funcionar. [Y, para ser justos, si usted es una empresa de software no estadounidense que quiere entrar en el mercado estadounidense, ¡también se le aplican las mismas directrices...!]
Alineación de mercados
¿Ha visto alguna vez una demostración presentada a una gran empresa de construcción que utilizaba datos de ejemplo del sector bancario? (Yo sí, pero fracasé...)
El mejor de los casos: sus datos, vocabulario, casos de uso y ejemplos de demostración coinciden con el mercado o vertical específico del cliente.
Siguiente mejor: sus datos, etc. son lo suficientemente cerca al mercado específico del cliente que éste pueda realizar la conexión. Nota: es el cliente quién decide si sus datos son "lo suficientemente cercanos"...
Generalmente insuficiente: sus datos, etc., no se parecen en nada al mercado de su cliente, les está pidiendo que den un salto demasiado grande. (La incredulidad ya no se suspende...)
Muy malos: datos obviamente falsos y ¡no tiene nada que ver con el mercado objetivo...!
Uno de los métodos más eficaces que he visto es disponer de un conjunto de datos bastante neutral, pero también tienen la posibilidad de configurar o personalizar las etiquetas de las pantallas, los cuadros de mando, los formularios y los nombres de los campos para asignarlos a mercados específicos. Esto puede requerir cierto nivel de configuración o programación, pero la recompensa puede ser alta.
Una nota adicional a tener en cuenta: Las directrices de éxito del cliente sugieren que cuanto más alejados estén sus clientes potenciales de sus mercados objetivo actuales y exitosos, peor será el ajuste, y probablemente representen el mayor riesgo de implementaciones fallidas o insatisfechas.
Madurez del mercado
Curiosamente, los clientes que se encuentran en distintas fases de la curva de adopción de la tecnología reaccionarán de forma muy diferente a los datos de demostración. Los "Adoptantes de tecnología" y los "Adoptantes tempranos" suelen ser muy indulgentes con los datos que se utilizan. Los clientes de la "Mayoría Temprana" pueden ser razonablemente indulgentes, pero cuanto más se avanza hacia la derecha, hacia la "Mayoría Tardía", más necesitan ver sus propios datos (o lo que parecen ser sus propios datos).
¿Quién soy?
Iniciar sesión como "Administrador" es otra forma de gritar "¡Falso!" a tu audiencia...
En la vida real, los únicos que inician sesión como "Admin" son, bueno, ¡los administradores del sistema...! Esto es aún más problemático cuando los vendedores empiezan a hablar de cómo "el sistema puede configurarse por roles para usuarios finales, gerentes, ejecutivos", etc.
En la misma línea, intente evitar nombres obviamente falsos, como:
- Stanley Staffer
- Mary Manager
- Ernie Ejecutivo
- Adeline Admin
(Nota: he visto las cuatro en demostraciones...) ¿Parecen reales? No. ¡Suspéndase a la incredulidad!
Sea cliente
En serio, en cierto sentido. Algunos de los mejores entornos de demostración son instancias "cliente", creadas y mantenidas exactamente del mismo modo que los entornos de los clientes reales.
Para las organizaciones SaaS, esto puede ser enormemente ventajoso: su "cliente" de demostración recibe el mismo trato que todos los demás clientes y recibe actualizaciones, mejoras, etc. exactamente en el mismo plazo.
Sabrá que su entorno de demostración estará actualizado y será coherente con lo que utilizan los demás clientes. Sin sorpresas... (O menos sorpresas, al menos...)
Manténgalo al día
Hace poco vi una "alerta" de flujo de trabajo que mostraba una tarea perdida que era 5 años¡! ¡Santa vaca vieja! Algún directivo va a ser muy enfadado, si esto fuera la vida real.
Las fechas de los flujos de trabajo deben parecer actuales (o razonablemente actuales). Cuanto más antigua sea la información, menos creíble será.
En muchos sistemas, esto plantea algunos retos y sugiere que tiene que haber una forma de "refrescar" los entornos de demostración.
Actualizar o reiniciar
Quizá una de las tareas más difíciles para quienes mantienen entornos de demostración sea mantenerlos al día y actualizados (para evitar problemas embarazosos como el anterior). Se pueden emplear varias estrategias:
- Revisar y actualizar los datos: para ello es necesario que alguien revise periódicamente los datos/flujos de trabajo/alertas/etc. pertinentes para limpiar los elementos obsoletos y actualizarlos cuando sea necesario. Es trabajo, pero hay que hacerlo para que el entorno de la demo sea lo más realista y creíble posible.
- Reinicio: ¿no sería estupendo pulsar un botón y que todo volviera a un estado prístino de "cero"? Hay una serie de proveedores que, en teoría, proporcionan estas capacidades - Cloudshare, Skytap, Quali, Qloudable, VMware Workstation, Microsoft Dynamics' Test Drive, y otras herramientas pueden proporcionar las capacidades para permitir esto. ¡Compruébelo si no está familiarizado...!
- También puede crear scripts en su propio entorno para lograr el mismo objetivo.
Disponibilidad
En algunas organizaciones, los entornos de demostración deben reservarse con antelación (por diversas razones). En algunos casos, estas reservas pueden tener que hacerse con un día o más de antelación.
Esto puede suponer un reto para las demostraciones que deban realizarse en un plazo más corto o en un plazo más corto. ad hoc base. He oído decir que estos entornos han sido implantados por el "¡Equipo de Prevención de Ventas...!".
En otros casos, puede llevar tiempo "poner en marcha" un entorno de demostración, lo cual puede ser inevitable, pero igualmente problemático, y habrá que planificarlo con antelación.
Y, por supuesto, ¿alguna vez ha intentado acceder a su entorno de demostración y lo ha encontrado "caído" o simplemente no disponible? ¡No es bueno, sobre todo si ha cruzado el país (o el océano) para la demostración más importante del año...!
En una demostración que vi hace poco, el software anunciaba "No habilitado para esta cuenta de demostración" cuando el presentador intentaba mostrar un caso de uso específico. Peor aún, el caso de uso fue introducido por el presentador. vendedor como "aquí hay algo muy chulo...", ¡no en respuesta a una pregunta de un cliente...!
Fundamentalmente, su entorno de demostración tiene que estar siempre disponible: tiene que poder contar con él.
Rendimiento
"...El sistema de demostración va lento hoy porque..." ¿Alguna vez has oído esto en una reunión de demostración? ¿Lo has dicho tú alguna vez?
Los clientes sólo recordarán una palabra: "lento".
Los clientes dan por sentado que el entorno que utilices para la demostración será mejor que el suyo. mucho mejor. Nunca he oído a un cliente decir: "¡Nuestra red es rapidísima...!".
En algunos casos, es posible que pueda precargar, almacenar en caché o flanquear de otro modo las áreas con posibles problemas de rendimiento. Para saber cómo prepararte, deberás caracterizar completamente tu entorno de demostración y familiarizarte con él.
¿En el mejor de los casos? Tu entorno de demostración es realmente "rapidísimo" y no presenta problemas de rendimiento visibles.
Sorpresa: ¡no hay Internet!
¿Te has encontrado alguna vez en una situación en la que necesitabas acceder a la web para ejecutar tu software y no tenías conectividad?
¿O alguna vez te han pedido que hagas una demostración en una organización gubernamental que no permitía el acceso a través de su red?
[Esto me recuerda al sketch de la tienda de quesos de los Monty Python - "Lo siento, recién salido..."]
Puede que necesites tener planes de respaldo para estas situaciones, que podrían incluir:
- La posibilidad de ejecutar todo el software desde el portátil, sin conexión a Internet.
- O la posibilidad de utilizar su propio entorno "myfi" o "mifi", si está permitido.
- O bien (lo menos atractivo, aunque no deja de ser una especie de auto-rescate) has capturado un conjunto saludable de las pantallas clave de tu software en PowerPoint, que puedes compartir sin conexión a la red para dar al cliente una idea de lo que tu sistema puede hacer...
"Confía en mí..."
Con demasiada frecuencia, veo demostraciones que muestran informes con datos incompletos, ¡o sin datos en absoluto...! Esto es aún peor cuando los informes son las pantallas finales para casos de uso importantes... (Suspenso.)
Los flujos de trabajo deben funcionar, los informes deben rellenarse razonablemente (o en su totalidad), los gráficos deben mostrarse correctamente, las alertas deben responder a acciones realistas, etcétera. En la medida de lo posible, el software debe funcionar como lo haría para el cliente.
Es inaceptable escuchar al vendedor decir: "¡Oh, confía en mí, estos informes son estupendos...!".
Problemas con el proyector
¿Alguna vez has conectado un proyector (o "proyector") en una sala de reuniones y te ha sorprendido lo que le ha pasado a tu pantalla? Muchas salas de conferencias tienen proyectores antiguos de baja resolución que simplemente son insuficientes para demostraciones desde portátiles de alta resolución, lo que da lugar a botones invisibles, partes perdidas de la pantalla y barras de desplazamiento inesperadas.
Como mínimo, caracterice el proyector que debe utilizar para reducir las sorpresas y estar preparado: practique las partes clave de su demostración. in situantes de que empiece la reunión.
Mejor aún, considere la posibilidad de comprar y llevar consigo un proyector que permita mostrar su software de la mejor manera posible (sin coste alguno por este juego de palabras). ¡Una inversión de unos cientos de dólares o euros podría ahorrar miles de euros en tiempo perdido y gastos de viaje...!
Mini ratón
Por último, tenga en cuenta el cursor del ratón: al fin y al cabo, es probable que su público intente observar sus movimientos durante una hora o más. ¿Es visible?
Puede que quieras considerar aumentar su tamaño y/o relleno. La mayoría de los ajustes predeterminados del ratón en los portátiles Windows y Macintosh son demasiado pequeño para demostraciones. Explore las opciones y vea qué se adapta mejor a su software y a los escenarios típicos de las demostraciones.
Lista de control de infraestructuras
Éste es un artículo largo: mucha información. Hemos explorado algunos aspectos de tus entornos de demostración de hardware y software, pero la situación de cada persona es única.
En los talleres ¡Gran Demo! le sugerimos que elabore (y utilice) una lista de comprobación de la infraestructura para reducir el riesgo de que le ocurran cosas malas en sus demostraciones: "¡Nunca debería pasarte más de una vez la misma cosa mala, si está bajo tu control...!".
Un entorno de demostración perfecto
Es probable que no exista (todavía) un entorno de demostración realmente perfecto, pero si sigue las directrices anteriores, sin duda mejorará la probabilidad de éxito de sus demostraciones. Unos pocos cambios pueden marcar la diferencia entre una "falsificación" evidente y el éxito en la suspensión de la incredulidad.
Copyright © 2019 El segundo derivado - Todos los derechos reservados.
Si desea consultar más artículos sobre técnicas y métodos para demostrar la eficacia, visite nuestra página web https://greatdemo.com/. ¡Para obtener consejos sobre demostraciones, mejores prácticas, herramientas y técnicas, únase al grupo de LinkedIn Great Demo! o explore nuestro blog en https://greatdemo.com/blog/.