¿Cuál es la estrategia más útil cuando su aplicación arroja una excepción en el medio de la demostración, en términos de mantener el estado de ánimo del cliente aún positivo?¿Cuál es el mejor engaño cuando su aplicación arroja una excepción en el medio de la demostración?
Si su cliente no confía en usted, no hay nada que realmente pueda hacer. Creo confianza con mis clientes, así que cuando sucede algo como esto, me creen cuando les doy una explicación. Y cuando les digo lo que voy a hacer para evitar problemas en el futuro, me aseguro de cumplir.
Según si se trata de una demostración "final" o si es una demostración a mitad de proyecto también afectará si realmente puede aliviar las preocupaciones de los clientes. Hay muy poco que puede hacer para alegrar al cliente si es el final del contrato y no hay más presupuesto para las pruebas y las correcciones de errores.
Una estrategia genérica que he utilizado: si alguien en la sala documenta la excepción/problema frente al cliente y les hace saber que va al sistema de seguimiento de fallos para su investigación y prueba, eso demostrará a ellos debida diligencia y aliviar algo de preocupación. Usted, por supuesto, necesita seguir y asegurarse de solucionar el problema.
Simplemente diga la verdad, pero con humor, como diciendo aparentemente nuestro software aún no es perfecto, y lo estamos haciendo perfecto.
no mienta ni intente taparlo. los clientes no son tontos.
honestidad +1 es la mejor política sin dudas. Se ve peor cuando tratas de mentirle al cliente, hace que parezcas indigno de confianza, lo que también podría reflejar en tu aplicación. –
+1 de acuerdo, sé sincero al respecto. –
+1 estoy de acuerdo con "nunca mientas o trato de ocultarlo", pero no estoy tan seguro de que "los clientes no son tontos" –
Diría que depende del escenario en el que se encuentre. Si está vendiendo algo, mi experiencia es que siempre es preferible llevar material estático para la demostración. Los Powerpoints están bien, pero las capturas de pantalla impresas que los clientes pueden lanzar alrededor de la mesa son inmejorables. Le permite mostrar exactamente lo que quiere, de una manera muy controlada, sin dejar de verse muy profesional.
Si el cliente ya ha comprado el proyecto, y la demostración está relacionada, por ejemplo, con un lanzamiento que se inicia, lo mejor que puede hacer es sonreír y decir "como puede ver, aún estamos trabajando" algunos caprichos "
Creo que personalmente depende de su relación con el cliente y de cuán satisfechos están con su producto hasta el momento.
Normalmente les digo que fueron datos malos de las pruebas o, en broma, dicen que fue una prueba para ver cómo la aplicación maneja los errores (si tiene un mensaje/página de error genérico). También puede usar el tiempo para reiterar la importancia de la prueba/aceptación del usuario.
Normalmente, dejo al cliente saber por adelantado que me estoy escapando de un entorno de desarrollo en vivo, por lo que podríamos ver algunas rarezas. Si soy consciente de las partes que tienen problemas (bloqueos incoherentes ...) informo al cliente sobre ellas antes de mostrarle esa sección (junto con el hecho de que la producción no lo hará y ya estoy trabajando en ello).
Actualización: en base a otras respuestas, acepto que las primeras demostraciones con material estático son mejores para generar discusión.
+1 Es difícil mostrar las demostraciones del cliente cuando todavía está desarrollando el software. Estoy de acuerdo, sé sincero y hazle saber que aún no todo está unido todavía. Bajo promesa y entregar más. –
@ J.Hendrix Debe conocer a mi gerente, dice eso mucho (dice lo mismo sobre mis estimaciones también ...) –
¿Este producto de envío está aún en desarrollo?
Suponiendo que es un producto de envío, simplemente recupere y continúe. Trabaja en la habitación mientras te recuperas (reiniciando, reiniciando la aplicación, etc.) y no pienses demasiado en lo que sucedió. Los clientes entienden que sucede algo.
Yo era ingeniero de aplicaciones y esto sucedía con frecuencia. OMI, la clave para recuperarse de esto comienza al principio de la relación/proceso de ventas/demostración, no es un evento en particular.Establezca confianza y genere credibilidad con su audiencia lo antes posible. Si tiene esto y se emite una excepción, la audiencia probablemente confiará en usted lo suficiente como para no pensar en nada sobre la falla del software y simplemente pasará de largo. Sí, tendrás a la persona ocasional buscando crucificarte, independientemente de lo que hagas, pero eso viene con el territorio.
Sea honesto si alguien pregunta (probablemente no) y nunca hable negativamente sobre su producto. También me di cuenta cuando me preguntaron sobre un error fatal, es útil, y son muy cuidadosos, si puedes explicar lo que sucedió en términos que la audiencia entienda. Demuestra su conocimiento del proceso de software y vuelve a la confianza.
estrategias posibles:
diciendo a la audiencia "todos vamos a quedar aquí hasta el que lo hizo hasta que posee".
Quejándose de la prevalencia de los monos malvados.
En serio, estoy principalmente en contra de las demostraciones públicas de productos. No intente demos hasta que esté 99.99999% seguro de que las malditas cosas funcionan. E incluso entonces es una mala idea, te estás preparando para fallar con todas las variables que pueden salir mal, que ni siquiera puede ser con tu software. Si debe hacerlo, tratar de impresionar a los clientes con una interfaz de usuario llamativa es mejor hacerlo uno a uno. Esa es la forma en que siempre lo hemos hecho.
+0 No estoy seguro de que estoy de acuerdo en que las demos son una mala idea. He encontrado que las demos ayudan a establecer las expectativas adecuadas, obtener retroalimentación temprana sobre la usabilidad y, a menudo, pueden comenzar las discusiones sobre el trabajo de seguimiento.Pero para hacer demostraciones de forma segura, debe tener PM que se mantendrán firmes en lo que respecta al alcance no pagado. –
No estoy en contra de las demos (las hacemos cara a cara con las computadoras portátiles), estoy en contra de las demostraciones * public *, donde algunos pobres schmo de las ventas se levantan frente a una multitud en una conferencia de la industria. En mi experiencia, la probabilidad de que todo funcione, incluso con el software * production *, es baja. Los locales tienen una red escamosa, pueden no tener instalaciones de UPS, las personas pasan de largo las máquinas y comienzan a jugar con ellas ... usted se da cuenta. Simplemente no hay suficiente * control *. –
Ah - tiene sentido. De acuerdo: la demostración "pública" puede ser realmente mala. –
La última vez que presenté un proyecto a una conferencia, planifiqué una demostración en vivo, pero en realidad tenía un conjunto de diapositivas titulado "¡Si puede ver esto, la demostración en vivo no funcionó!" con grandes capturas de pantalla. Inevitablemente, la demostración en vivo no funcionó (se necesitaba una dirección IP enrutable globalmente y no estaba disponible) y se solicitaron las diapositivas.
Ahora que lo pienso, las diapositivas están aquí: http://www.slideshare.net/TYR/tracking-international-arms-dealers-with-python-and-bits-of-string – user106514
Nunca he hecho una demostración en la que no haya establecido las expectativas de antemano. Si este es un trabajo en progreso, asegúrese de que lo sepan por adelantado. Esto va un largo camino para mantenerlos positivos. TODOS tienen problemas durante las demostraciones. Solo sonría, diga la verdad y continúe.
Probablemente la mejor manera de ayudar a mantener a su cliente positivo es proyectar la positividad y la confianza usted mismo. Si parece inseguro de sí mismo, se mostrará como si no estuviera seguro de su aplicación.
Escriba la excepción y por qué/cómo se produjo INMEDIATAMENTE. Entonces verán que lo arreglarás.
¿Por qué no intentar evitar la excepción en primer lugar? –
Lo intentas ... Pero sucede algunas veces; ¿no lo hace? – pencilCake
@James G .-- un objetivo admirable, pero incluso los mejores de nosotros cometeremos errores. –