Cómo manejar las críticas agresivas, negativas e incorrectas de una manera positiva [cerrado]

La empresa para la que trabajo tiene un cliente al que proporcionamos varias soluciones de software. Ejecutan varios eventos y les proporcionamos un sistema de administración para que ejecuten sus eventos y una aplicación de Windows para que puedan realizar un seguimiento de las cosas a medida que suceden en sus eventos.

Mientras trabajaba con ellos, me di cuenta de que son extremadamente hostiles. Ejemplos de esto son:

  • Echar la culpa sin intentar identificar una causa raíz de la falla del software exclusiva de su entorno, y
  • Aprobar requisitos incompletos e inexactos que luego provocan fallas en el sistema.

El foco de la crítica de los temas anteriores parece estar dirigido a mí, que incluye a muchos altos directivos. Mi jefe me está apoyando, pero hay otros en la empresa que se centran más en las experiencias negativas de los clientes.

¿Cuáles son algunas estrategias para manejar las críticas negativas basadas en información inexacta? Mi deseo inmediato es devolver su agresión en especie, pero agradecería si alguien pudiera sugerir una estrategia más constructiva.

Si le escribieron un correo electrónico cortés explicando que tenían problemas pero nuevamente no pudieron reproducirlo, ¿cuál es su compromiso con el cliente? ¿Estás comprometido a ayudar al cliente en esta situación o no?
Haga una lista de todo lo necesario para que su software funcione (conectividad de red, conectividad de base de datos, JVM o versiones .Net) y cree un programa que verifique todo esto y proporcione un mensaje significativo "No puedo alcanzar el puerto X de la máquina Y". "La versión .Net debe ser al menos 4", etc.

Respuestas (4)

Sea Zen al respecto y envíeles un correo electrónico indicando que después de x horas de desarrollador e y horas de prueba de intentarlo, ustedes como grupo no pudieron reproducir el problema. Tenga en cuenta que esta queja es el primer incidente de este tipo que se notifica al grupo, después de que el software del cliente se haya implementado y esté en producción durante seis meses. cc: su gerencia y las mismas personas que el cliente cc'ed. Si no está de cara al cliente, pídale a su gerente que envíe el correo electrónico.

La pelota está en su campo y la carga de la prueba recae sobre ellos. Su historia me recuerda a un administrador de sistemas particularmente ignorante que llamó a nuestro soporte técnico y dijo que nuestro software de equilibrio de carga ya no funcionaba en una de sus máquinas. El ingeniero de campo que enviamos estableció que el administrador del sistema había movido la máquina a una ubicación diferente dentro de la oficina, sin tomar nota de que la nueva máquina ahora estaba en una subred de IP diferente y sin prestar atención al hecho de que a la máquina se le había asignado una IP estática.

Hasta que aparezca nueva información, creo que su cliente hizo algo estúpido ese día. Mi segunda mejor conjetura es que hubo una falla en la red ese día. La tercera posibilidad es que algunos de los datos que su software estaba procesando estuvieran corruptos.

Tenga en cuenta antes de ir a la guerra que los idiotas del mundo nos superan significativamente en número y que nos sobrevivirán a usted y a mí. Si bien los idiotas pueden irritarnos de vez en cuando, tienen que vivir con su idiotez 7x24. Para ellos, así es como se ve el infierno :) No hay mucho que puedas hacerles que sea peor que lo que se están haciendo a sí mismos y entre ellos.

@jcm comenta que "puede parecerle al cliente que 'Funciona en mi máquina', lo que nunca es aceptable para los clientes o los jefes. Podría ser útil incluir en el correo electrónico una solicitud de detalles del cliente para ayudarlo a reproducir el problema . De esa manera, se lo ve como cooperativo mientras demuestra que el problema no está en su lado".

¡Esa NO es una buena sugerencia! Supongo que el OP tuvo el buen sentido de solicitar estos detalles de antemano al cliente cuando intentaron reproducir el problema. No tiene ningún sentido tratar de reproducir CUALQUIER problema sin datos: esto es tan fundamental como la diligencia debida que su sugerencia me resultaría entre poco divertida y extremadamente frustrante si yo fuera el objetivo de esa sugerencia.

No podría importarme menos ser visto como cooperativo. Lo único que me importa es reproducir el problema. No estoy en ingeniería de percepción.

Como decía, el equipo de OP, a pesar de sus esfuerzos, no pudo reproducir el problema, y ​​la pelota está en el tejado del cliente. Especialmente cuando "Funciona en mi máquina", funciona en la máquina de todos los demás clientes, ha funcionado en la del cliente durante los últimos seis meses y la única vez que no funcionó fue en UNA instancia.

Venga a mí con una historia tal que mi software falló, y si no solo yo, sino todo mi equipo no puede reproducir el problema con los datos que me dio, me encogeré de hombros ante su historia. Si usted o mis jefes no estaban contentos con nuestros esfuerzos y saben algo que nosotros no sabemos y sienten que pueden hacer nuestro trabajo mejor que nosotros, son más que bienvenidos a reproducir el problema por ustedes mismos y mostrarnos hasta.

Aclaración de OP: "Somos responsables de que el software funcione, pero se ejecuta en la infraestructura de TI que son responsables de configurar y mantener en cada evento. Literalmente, no tienen a nadie calificado para hacer esto. Tenían un ingeniero de redes calificado que despedido porque solía sentarse sin hacer nada porque nunca tuvieron problemas de red..."

Podrían haber tenido el ingeniero de red calificado configurado para cada evento. No salieron exactamente adelante cuando las cosas no salieron según lo planeado en esa última presentación.

Esto puede parecerle al cliente "Funciona en mi máquina", lo que nunca es aceptable para los clientes o jefes. Puede ser útil incluir en el correo electrónico una solicitud de detalles del cliente para ayudarlo a reproducir el problema. De esa manera, se lo ve como cooperativo mientras demuestra que el problema no está en su lado.
@jcm Edité mi respuesta para responder a tu comentario.
No hago suposiciones. El OP no lo puso en la pregunta, por lo tanto, mi comentario. Además, no hay necesidad de ofenderse cuando alguien se te acerca con una sugerencia, sin importar cuán fundamental pueda parecer. El objetivo es la resolución de problemas, no la preservación del ego.
Además, estoy de acuerdo en que no tiene sentido intentar replicar fallas sin datos, de ahí el comentario.
@jcm Estoy ofendido. No voy por ahí diciéndole a la gente que conoce su trabajo cómo hacer su trabajo. El OP no es tonto. Estoy bastante seguro de que recopilaron todos los datos que pudieron antes de intentar replicar el problema. No podrían haber mantenido sus trabajos por más de 5 minutos si no lo hubieran hecho.
Solo somos diferentes entonces. Siento que la vida es demasiado corta para ofenderse por esas cosas.
@VietnhiPhuvan: a mí también me gustaría darle a la operación el beneficio de la duda, pero no cuando hay muchas críticas hacia el cliente. Cuando una aplicación funciona en estaciones de trabajo 9/10, "algunos" desarrolladores se niegan a culpar a su aplicación. Tal vez los clientes no paguen lo suficiente por un acuerdo de servicio para compensar su falta de capacidad técnica. Si la aplicación no puede enviar datos a través de la red, no podría afirmar que fue creada por un experto hasta que se resuelva el problema.
@JeffO Este es un cliente desagradable y técnicamente analfabeto que grita sobre esa instancia en la que el software no estaba enviando datos a través de la red. ¿Cómo sabes que no hubo una falla en la red? ¿O el cliente metiéndose la pata? El OP y su equipo ya gastaron una tonelada de recursos tratando de duplicar el problema. ¿Cuánto más tiempo y dinero quieres gastar a expensas de todo lo demás que están haciendo? ¿Ha regresado el cliente con nuevas quejas desde el incidente? ¿Algún otro cliente ha presentado la misma queja desde ese incidente? ¿Qué te dice eso?
@VietnhiPhuva Somos responsables de que el software funcione, pero se ejecuta en la infraestructura de TI que ellos son responsables de configurar y mantener en cada evento. Literalmente no tienen a nadie que esté calificado para hacer esto. Tenían un ingeniero de redes calificado que despidieron porque solía sentarse sin hacer nada porque nunca tuvieron problemas de red...
@ user1450877 El cliente es desagradable. Analfabetos técnicos. Toma decisiones gerenciales miopes. Tienes un cliente del infierno :) Si quieres, podemos charlar sobre tu solución de problemas, pero tendrás que configurar el chat :)
@VietnhiPhuvan: no conozco los problemas del cliente, pero buscar una conexión a Internet es bastante fácil. O tienes puesto o no. Parece una explicación simple para la alta gerencia que aparentemente no está comprando la explicación del OP. Cualquiera puede recrear un error por falta de conexión a Internet.
@Vietnh: Puede culpar al cliente por ser "técnicamente analfabeto", pero cuanto más "releo", más me pongo del lado del cliente. Si el cliente no tiene una persona "calificada" para configurar e instalar la aplicación, se le deberían haber proporcionado instrucciones detalladas paso a paso. Además, la empresa del OP entregó un proyecto de acuerdo con las especificaciones pero no con lo que el cliente necesitaba hacer. Suena como un problema con la empresa del OP. Deberían haber identificado al cliente como "técnicamente analfabeto" y haber tomado las medidas correspondientes para garantizar que el cliente obtuviera lo que necesitaba antes de decir "aquí está".
@JeffO ¿Y cómo es que el cliente pierde su conexión a Internet, el problema y la responsabilidad del OP? ¿Puede pensar en un escenario hipotético en el que el software del OP haya causado la interrupción de la conexión a Internet?
@Dunk Nadie tiene ningún problema con las instrucciones, excepto ese cliente. Qué casualidad. Y no, el mundo no te debe una mano, por mucho que te sientas con derecho a ello.
@Viet: ¿Qué le hace pensar que el cliente perdió la conexión a Internet? Además, ¿qué parte de este software personalizado para este cliente específico no estás leyendo? Entonces, en realidad, TODOS LOS CLIENTES de esta aplicación de software tienen problemas con las instrucciones. Tomarse de la mano tal vez no sea un "derecho", pero un mal servicio al cliente causará la pérdida de clientes. Si perder clientes es parte de su modelo de negocio, que así sea. Finalmente, podría pensar en docenas de escenarios hipotéticos en los que el sw del OP puede hacer que una conexión a Internet se apague, pero eso no es parte de la conversación.
@Dunk Soy ingeniero de sistemas. También solía hacer programación de sistemas en la escuela de posgrado. Tú y otros me están haciendo perder el tiempo discutiendo cosas de las que no sabes nada.
@Vietnhi: Y demuestra su falta de conocimiento al insistir en que los demás no saben de lo que están hablando cuando el HECHO ES que lo saben. Wow, programando mientras estás en la escuela de posgrado, debes ser un verdadero experto. No permita que perdamos su tiempo educándolo cuando obviamente sabe todo lo que hay que saber sobre todo.
No digo que el software del OP sea responsable de la pérdida de una conexión a Internet. Todo lo que digo es que si ese es el caso, el software puede "indicar" muy fácilmente que ese es el problema. Dígale al cliente que arregle su conexión. Es muy sencillo.

Mi deseo inmediato es volver a ser igual de agresivo y beligerante y señalar las muchas fallas en su organización que conducen a este tipo de problemas.

Necesitas suprimir este deseo inmediato; nada bueno puede salir de él.

¿Ha hablado con su jefe sobre cómo manejar este tipo de problemas con los clientes?

En general, "el cliente siempre tiene la razón" (incluso cuando no la tiene). Es poco probable que estar a la defensiva ayude en algo; en su lugar, trata de ser útil. Ponte en su lugar e imagina cómo se sentiría si el software del que dependes para ayudarte con tu evento falla por completo. Recuerda que sin clientes felices, no tienes trabajo.

Recuerde también que, a menos que sea el propietario de la empresa, no puede decidir qué clientes se pueden descartar/despedir.

Trate de pensar en formas adicionales de depurar su sistema. Tal vez una vez que resuelva sus problemas, podrá mostrarles que los problemas no tienen nada que ver con el software que escribió. Si eso sucede, los habrá convertido de un cliente negativo y culpable a un cliente agradecido y feliz. Eso puede dar sus frutos a lo grande.

Trabaje con su jefe para determinar qué hacer a continuación. Cree estrategias para evitar o poder diagnosticar rápidamente este problema para que no le suceda a otro cliente valioso. Pregúntele a su jefe cómo debe reaccionar si se presenta una situación similar en el futuro. Podrías superar su negatividad y ser el héroe aquí.

el cliente siempre tiene la razón : si eres un aficionado a la tecnología y el cliente no es experto en tecnología, en mi opinión, esa regla no es apropiada. Según el contrato, puede causarle grandes problemas: intente hacer una lluvia de ideas... depure su sistema : OP dice que no pueden reproducir el problema y que el sistema estuvo funcionando durante mucho tiempo. El 99,9% de las veces significa que algo en el entorno del cliente causó la falla. ¿Quién paga por arreglar su sistema? ¿Gratis? Te abres a que se aprovechen de ti. ¿Cargar? El cliente se enfada. Es mejor simplemente explicar que no es tu problema y tal vez perder un cliente. El hecho es que no necesitas un cliente así...
@Vector: El OP dijo "el software que le proporcionaron al cliente". Lo que implica que es personalizado para el cliente. En cuyo caso, no importa si el cliente es experto en tecnología o no, me inclino a ponerme del lado del cliente si está usando el software en el entorno previsto. Si el cliente no es experto en tecnología, el software debe construirse para adaptarse a eso. De alguna manera, no creo que este sea un evento único y el software realmente no ha estado "sin problemas durante 6 meses", por lo que el cliente puede estar un poco irritable. Si es un tipo de entorno completamente diferente entonces eso es otro asunto.

Aparte de molestarte, hasta ahora nadie te ha castigado; podría ser peor. El cliente pagó para que el software funcione y no funciona, ¿qué espera que haga? Si el programador se da por vencido y no puede resolver el problema, le pasarán por encima de la cabeza. No hay nada que puedan cambiar para solucionar el problema. Otras fallas en la comunicación de su parte en otros proyectos es irrelevante. Están pagando tu salario.

Según lo que ha publicado, hay algún problema con la instalación de este cliente en particular. Puede culpar a Windows o a los Dioses de Internet, pero debe solucionarlo de todos modos.

  • Remoto a su sistema y observe cómo falla de su lado.
  • Aumente el registro y la captura de errores en la aplicación, para que pueda obtener más información.
  • Súbete a un avión y ve directamente a su sitio y arréglalo.

No tiene nada que ver con la culpa. Eres el único que puede ayudarlos. Sugiera todo a los Seniors a cargo y vea hasta dónde lo dejarán llegar para resolver este problema específico.

EDITAR: si este cliente consume una cantidad desproporcionada de tiempo de soporte en comparación con otros clientes, la alta dirección necesita estos datos. Independientemente de su experiencia técnica, no van a querer tirar más dinero a este cliente si no están pagando lo suficiente a cambio. Si no tienen habilidades técnicas, comerciales o contables, son una causa perdida.

there is something wrong with this particular customer's installation. [...] but you need to fix it regardless. En general, no. Usted proporciona un software que funciona con una configuración definida, y no en todas las configuraciones que pueda tener un cliente. ¿Por qué si dicha empresa está usando, digamos, Token Ring? ¿Se supone que debes actualizarlos a Ethernet? Dicho esto, se necesita documentar y verificar defensivamente el entorno (si necesita acceder al puerto X de la máquina Y, documente que lo necesita y proporcione, mediante el propio SW o una herramienta de diagnóstico separada, un mensaje que diga "No puedo alcanzar el puerto X de Y", en lugar de simplemente no hacer nada).
@ SJuan76: estoy de acuerdo si estamos hablando de software estándar, pero el OP indicó "proyectos" que puede asumir alguna personalización. En el caso de token-ring, la aplicación nunca hubiera funcionado y arrojado algún tipo de error que indica que no había conexión de ethernet. Cualquiera puede simular eso en las pruebas desconectando su cable de red o apagando su wifi.
@ Slaun76: el OP admitió que personalizó el software. El papel de un desarrollador no es proporcionar una pieza de software que funcione en el punto en que lo entregó y luego lavarse las manos del proceso. ¿Adónde más se imaginaría que llevaría la investigación inicial además del desarrollador que personalizó el proceso?
  1. Respira hondo antes de leer cualquiera de sus correos electrónicos o contestar el teléfono. No se gana absolutamente nada entrando en una pelea.

  2. Registra todo. Cada solicitud, cada llamada, cada correo electrónico y cada acción del sistema. Cuando llamen preguntando por qué las cosas no funcionan como ellos quieren, mencione cortésmente el requisito de unos meses antes exigiendo que funcione como lo hace. Luego, cortésmente , pregúnteles cómo quieren realmente que funcione. Si dudan más de 2 veces en un artículo en particular, comience a aumentar el costo del cambio.
    Tuve un cliente que cambiaba de opinión sobre una función en particular cada tres meses. Cada vez que hicieron la solicitud, mencioné que la habían cambiado antes. Finalmente, comencé a escalar el costo del cambio y llegó a un punto en el que intervino su alta gerencia, tomaron una última decisión y esas solicitudes cesaron.

  3. Si faltan algunos datos y están furiosos por eso, bríndeles una captura de pantalla del registro que muestre quién lo hizo y cuándo. Esto es fundamental para registrar todas las acciones del sistema. Si no puede decirles quién, cuándo y qué, entonces su aplicación siempre tendrá la culpa .

  4. Asegúrate de que tu aplicación funcione. Pruébelo de todas las formas que pueda y arréglelo rápidamente. Sepa cómo puede fallar y asegúrese de que esté documentado. La aplicación también debe ser bastante verbal con el usuario sobre exactamente lo que no funciona bien; y debe tener un sistema de registro sólido como una roca. No poder transferir datos a través de la red debería ser fácil de identificar la causa raíz. Si no puede, entonces, como un tercero que nunca vio su aplicación, mi primer pensamiento es que lo está haciendo mal.

  5. Programe llamadas periódicas con ellos. En nuestro caso, si no hemos tenido noticias de un cliente en 30 días, el representante de la cuenta lo llama. Sabemos muy bien qué clientes necesitan más comunicación y cuáles necesitan menos. Unos como este necesitan más. Es posible que incluso debas hacerlo semanalmente hasta que comiencen a sentirse cómodos.