A veces, el ingeniero de soporte técnico se enfrenta a una difícil elección: ¿aplicar el modelo de diálogo “¡Estamos a favor de una alta cultura de servicio!” o “Haz clic en el botón y obtendrás un resultado?”?
…Rompiendo el ala de algodón,
Nos tumbaremos en las nubes, como en criptas.
Nosotros, los poetas, rara vez somos santos,
Nosotros, los poetas, a menudo somos ciegos.
(Oleg Ladyzhensky)
Trabajar en soporte técnico no se trata solo de anécdotas divertidas sobre el tiempo que salta solo y unicornios GPS, ni solo de misterios al estilo de Hercule Poirot.
El soporte técnico es, ante todo, comunicación, y la comunicación implica personas, y entre nuestros clientes hay personajes muy diversos:
- Un alemán trabajando desde un café frente a su oficina en Berlín, poseedor de una verdadera compostura nórdica, perfecta calma, una red cuidadosamente ajustada, un amplio parque servidores y las capacidades cognitivas para configurar y mantener todo al nivel A+. Las solicitudes de él suelen provocar la misma reacción que el último dumpling en un plato en una gran compañía y la luz apagada en el momento equivocado.
- Un británico, que en los últimos 5 años ha cambiado de empresa dos veces, pero no su estilo de trabajo con el soporte. De sus casos, o huyen como de la peste bubónica, o los aceptan, presagiando de antemano toda la “delicia” de trabajar con esta persona, ya que puede quitar el control en una sesión remota (para revisar su correo, a veces personal) sin previo aviso, presionar a los ingenieros y la gerencia por cosas insignificantes y, finalmente, cerrar solicitudes de manera tan repentina con el comentario «DUPLICADO».
- Un indio con un apellido complicado e impronunciable, que refuta todos los mitos sobre IT indio: educado, tranquilo, competente, leyendo la documentación, escuchando los consejos del ingeniero y siempre haciendo todo por sí mismo, portador de un lujoso turbante (sí, lo encontramos en Facebook) y con una pronunciación perfecta de Oxford.
Cada ingeniero puede recordar a cinco de esos clientes «nominados», sin pensarlo mucho. Algunos asustan a nuestros nuevos empleados («si te portas mal en el laboratorio, ¡vendrá el hombre del saco y!..»), otros presumimos («¡ya he cerrado 5 solicitudes con N.! »). Y más a menudo, incluso recordamos y entendemos que los ejemplos positivos y negativos son simplemente nuestra percepción, que surge de la comunicación, la nuestra con los clientes y la de los clientes con nosotros.
Y esa comunicación puede ser muy variada.
Una vez ya escribimos sobre , y ahora quiero mostrar cómo sucede esto con un ejemplo real.
Aquí hay un buen ejemplo de hace dos años: la reacción de un cliente a los pasos "tradicionales" de solución de problemas por parte del ingeniero y la respuesta del ingeniero al estilo de comunicación del cliente.
Caso de fragmentación
Entonces, el caso: un cliente muy experimentado y técnicamente competente abre un ticket con el soporte técnico y formula una pregunta directa, proporcionando muchos detalles para describir la situación.
Me tomé la libertad de reformular la correspondencia en un diálogo, manteniendo las características estilísticas.
Cliente (C): — Buenas tardes, caballero. Me llamo Marco Santino, hemos seguido sus mejores prácticas e implementado la tecnología más reciente que usted recomienda, pero observamos que la operatividad del sistema se vuelve críticamente baja debido a la alta fragmentación. ¿Esto es normal?
Ingeniero (I): — ¡Hola, Marco! Me llamo Ignat y te ayudaré. ¿Siempre ocurre esto? ¿Han intentado desfragmentar?
(C): — Estimado Ignat! Sí, esto ocurre siempre. Hemos intentado desfragmentar, pero, desafortunadamente, lleva demasiado tiempo durante el downtime total del sistema, y por lo tanto, no resulta posible.
(I): — Escucha, no puedo encontrar estas mejores prácticas. ¿Dónde las encontraste? ¿Y, tal vez, deberíamos hacer la desfragmentación?
(C): — Estimado Ignat! Comprendiendo que usted no toma nuestra problema en serio y conteniendo dificultosamente un respuesta directa, intentaremos responderle. No tenemos su experiencia (estamos en TI desde 1960), y le estamos muy agradecidos por su trabajo y esfuerzo en nuestra educación. Las mejores prácticas nos fueron transmitidas por sus Product Managers durante una cena en Barcelona, y le he enviado un enlace a ellas. Lo que le preguntamos directamente, Ivan, es: ¿es esta situación normal? Si no está interesado en hablar con nosotros, por favor, encuentre a alguien que pueda ayudarnos.
(I): — Marco, no he encontrado estas mejores prácticas. Necesito los registros y pasaré el problema a otro ingeniero. Le diré esto: si ven fragmentación y no desfragmentan, es poco inteligente e irresponsable. Y, en general, ¿cómo lograron confundir el noble nombre de “Ignat” y llamarme Ivan?
(K): — ¡Basta! Igna, no soy tu hermano ni tu compañero, así que, por favor, dirígete a mí como Mr. Santino. Si no puedes encontrar el documento y no puedes manejar esta tarea tan simple, entonces o renuncia a la empresa o pregúntale a su autor, quien nos lo entregó. En cuanto a los registros, no podemos proporcionártelos sin un acuerdo especial, ya que trabajamos con documentos confidenciales. Tu indignación por mi error muestra tu ignorancia y falta de educación. Lo siento por ti. Y por último: si decimos que 'hemos intentado desfragmentar' y eso 'no es posible', significa que lo intentamos y es imposible. Igna, por favor, deja de hacer tonterías y ocúpate de tu trabajo: o danos una respuesta o encuentra a alguien que nos la dé.
Después de esto, la solicitud fue escalada, donde murió: el cliente nunca proporcionó los registros, las pruebas a gran escala no dieron resultados y el problema simplemente no pudo ser confirmado.
Pregunta: ¿qué podría haber hecho el ingeniero para evitar el aumento de tensiones y la escalada del conflicto?
(Intenta responder a esta pregunta tú mismo antes de seguir leyendo).
Un pequeño desvío lírico técnico
Para los aficionados a resolver acertijos y a la pregunta '¿quién es el culpable?': el problema resultó ser mucho más grave: la fragmentación de ReFS no solo afectaba las operaciones en disco, sino que en algunos casos aumentaba el consumo de CPU y RAM hasta diez veces, no solo en clientes de Veeam; todos los usuarios de ReFS podían verse afectados.
A Microsoft le llevó más de un año, con el apoyo de muchos proveedores, finalmente corregir este error (en lo cual vemos también nuestra contribución, pues se rompen muchas lanzas defendiendo a este gigante a todos los niveles).
Al responder a la pregunta '¿qué se podía haber hecho?', quiero plantear otra pregunta eterna: '¿y quién es el culpable?'
Por solidaridad profesional, me gustaría decir: 'Es culpa del cliente', y comenzar a defender al ingeniero. Como líder que evalúa constantemente el trabajo de sus ingenieros, veo los errores que Igna cometió. ¿Quién tiene razón?
Desglosamos todo paso a paso
Este caso es muy difícil, hay más preguntas que respuestas.
Formalmente, Igna hizo todo bien:
- siguiendo uno de los valores fundamentales de Veeam: Conversación desde el corazón;
- me dirigí al cliente por su nombre;
- aclaré la situación antes de proponer una solución.
¿Podría haber evitado tal intensidad emocional?
Podría: notar cómo el Sr. Santino se comunica (solo de usted y por apellido), evitar las "preguntas básicas", mostrar interés en el problema y prometer averiguar si este comportamiento es normal.
Pasos mínimos, sin la parte técnica, ya habrían ayudado a "apagar" la situación. Pero incluso si se perdió eso, simplemente "no hacer" también habría ayudado un poco.
Suena obvio: no tomar el error como algo personal, no ofenderse por un cliente sarcástico (incluso si todo indica un ego sobreinflado), no personalizar la conversación, no caer en provocaciones... Cuantos más "no", todos importantes, y todos sobre la comunicación.
¿Y qué pasa con el cliente? Los correos están escritos en un "alto estilo", constantes referencias a sus conexiones más cercanas, insultos velados y resentimiento por lo que parece una falta de respeto? Sí, podemos leerlo exactamente así. Pero por otro lado, ¿realmente está tan equivocado el Sr. Santino en su enfado?
Y aun así, ¿qué se podría haber hecho de ambas partes? Yo lo veo así:
Desde el lado del ingeniero:
- evaluar el grado de formalidad del cliente;
- seguir menos la "aislación básica";
- (será subjetivo) leer los correos con más atención;
- responder a las preguntas, en lugar de eludirlas;
- y, finalmente, no caer en provocaciones y no personalizar la conversación.
Al cliente:
- definir claramente la pregunta en el primer correo, sin esconderla en detalles técnicos (del diálogo, esto no se deduce directamente, pero créanme, la detallación fue asombrosa);
- ser un poco más tolerante con las preguntas: no todos piensan de la misma manera, y a veces hay que preguntar mucho para entender la esencia del problema;
- quizás contener el deseo de mostrar su importancia y conexiones "a niveles muy altos";
- y, al igual que para Ignat, evitar personalizar la conversación.
Reitero, esta es solo mi visión, mi evaluación, que de ninguna manera son recomendaciones o una guía de "cómo vivir y trabajar". Esta es una de las formas de ver la situación, y agradecería si ustedes proponen las suyas.
No estoy defendiendo al ingeniero; él es su propio y maligno Pinocho. No estoy culpando al cliente; tiene todo el derecho de comunicarse como lo considere necesario, aunque esa comunicación esté más oculta en un delicado encaje de casi-ingenio y cortesía ofensiva (una buena imagen de un hidalgo moderno que no se dedica a la mercenaria ni a la guerra, sino a IT - aunque...).
«La guadaña encontró la piedra» — así es como concluyo esta correspondencia, o incluso podría expresarlo de otra manera, en la que sinceramente creo: «en cualquier conflicto, generalmente son culpables dos».
Se podría decir con las palabras de nuestro entrenador de negocios: «la experiencia pasada, los hábitos comunicativos y las diferentes visiones del mundo obstaculizan una comunicación exitosa». También se puede recordar la regla de oro de la ética: «actúa hacia los demás como te gustaría que ellos actuaran hacia ti».
O simplemente se puede decir: en cualquier comunicación siempre participan dos, y al otro lado del teléfono o la pantalla hay una persona viva, que también siente miedo, alegría, tristeza o algo más. Sí, se dice que las emociones y el negocio son incompatibles, pero ¿cómo podemos escapar de las emociones? Han existido, existen y existirán, y aunque nosotros seamos Soporte Técnico y resolvamos tareas muy concretas, nuestro trabajo principal se define precisamente por la segunda palabra: «apoyo».
El apoyo es sobre las personas.
***
¿Recuerdas que ya escribí dos veces que son culpables dos? Pues bien, en realidad, en esta situación son culpables los tres. ¿Por qué? Simplemente porque el ingeniero no es un ser aislado, sino parte del soporte técnico, y es nuestro trabajo y nuestra responsabilidad enseñar a los empleados a manejar situaciones similares. Nos esforzamos por aprender de nuestros errores y ayudar a nuestros empleados a evitarlos.
¿Se pueden evitar siempre este tipo de situaciones? No siempre. Por muy buen ingeniero que sea el hipotético Ignat, puede haber alguien al otro lado que hará todo lo posible para intensificar la situación.
Pero la belleza de trabajar en el Soporte Técnico de Veeam, uno de los valores de los que nos enorgullecemos, es trabajar en equipo. Es muy importante recordar: «no estás solo», y hacemos todo lo posible para que así sea.
¿Se puede enseñar a vivir y trabajar en tales situaciones? Sí, se puede.
Sabemos, amamos y practicamos: por eso hemos construido nuestra formación interna y seguimos afinándola y perfeccionándola. En los dos años y medio que han pasado desde la situación descrita, hemos trabajado seriamente en nuestro programa de formación y ahora utilizamos casos prácticos, modelamos situaciones, acumulamos y siempre regresamos a nuestros errores para analizar los matices de la comunicación.
Creemos que ahora nuestros chicos están muchísimo más preparados para cualquier situación y, si surge algo para lo que no están listos, estamos aquí para ayudar y luego complementar nuestros cursos con nuevos ejemplos.
Y esto da frutos. Aquí, por ejemplo, está el testimonio de uno de nuestros clientes sobre nuestro trabajo:
“Hemos trabajado en la industria de TI durante más de 20 años y todos coincidimos en que ningún proveedor ofrece el nivel de soporte técnico que ofrece Veeam. Es un placer hablar con el personal técnico de Veeam porque son expertos y resuelven los problemas rápidamente. El soporte nunca debe subestimarse. Es un indicador del compromiso y éxito de una empresa. Veeam es el número uno en soporte.”
“Trabajamos en la industria de TI durante más de 20 años y afirmamos que ningún otro proveedor ofrece un nivel de soporte técnico como Veeam. Es muy placentero trabajar con los ingenieros de Veeam, ya que conocen su trabajo y pueden resolver los problemas rápidamente. El soporte técnico nunca debe ser subestimado. Es un indicador de cuán responsable y exitosa es una empresa. Veeam tiene el mejor soporte técnico.”
***
Cualquier comunicación es un campo de experimentos, errores, queramos o no. Y mi opinión es que equivocarse es normal, de hecho, mi llamado sería: ¡equivocarse! No se trata de si te has tropezado, sino de si aprendiste a poner el pie firme después.
A veces es difícil recordar todas las instrucciones y recetas que los 'gurús' de la comunicación con los clientes o compañeros experimentados comparten generosamente. A veces, es mucho más fácil recordarte a ti mismo: “Estoy hablando con una Persona”.
***
No pretendo tener el conocimiento supremo o un estándar especial de calidad en la comunicación con los clientes. Solo la lista de mis errores sería suficiente para un manual completo.
El objetivo que me propuse: mostrar cómo puede ser el soporte técnico y lanzar la discusión sobre lo que puede considerarse aceptable en tales casos y lo que no.
¿Qué opinas?
Fuente: habr.com
