¿Cómo lidiar con la mesa de ayuda de TI que no reconoce las solicitudes de ayuda?

Cada vez que mis colegas o yo contactamos con la mesa de ayuda de TI, hay una serie de problemas sistémicos, a saber:

  • No acusar recibo de la solicitud
  • No tomar medidas correctivas y cerrar casos unilateralmente sin explicación para el usuario

Esto es lo que he probado antes:

  • Hablando con la mesa de ayuda de TI en persona. Esto ahora es imposible, ya que están ubicados en una oficina diferente a la que es inviable viajar a
  • Hablando con la mesa de ayuda de TI por teléfono. Desafortunadamente, hay un intermediario de triaje en un país extranjero, lo que crea barreras idiomáticas, por lo que esto es impredecible.
  • Escalar el problema a mi gerente. Esto no funciona ya que la mesa de ayuda brinda el mismo nivel de servicio deficiente en toda la empresa.
  • Escalar el problema a su gerente. Esto no funciona ya que la cultura de la función de la mesa de ayuda parece ser proteccionista.

Mi pregunta es ¿cómo puede un usuario final alentar a la mesa de ayuda de TI a reconocer y trabajar con los tickets generados?

Información adicional:

  • Soy un empleado de nivel asociado. La mesa de ayuda está en una estructura organizativa totalmente diferente a la de los usuarios.
  • Esta es una organización masiva con decenas de miles de empleados.
  • La empresa tiene su sede en el Reino Unido.
No esté de acuerdo con su lógica de "Escalar el problema a mi gerente. Esto no funciona ya que la mesa de ayuda brinda el mismo nivel de servicio deficiente en toda la empresa". Si es un problema global, entonces es un problema de gestión. Entiendo que esté frustrado, pero como empleado de nivel asociado solo necesita empujarlo hacia arriba en la cadena.
@Paparazzi tiene que ser empujado a un nivel de director o superior y debe hacerse un caso de amplio impacto. No puede hacerlo solo.
@RichardU No sé a qué nivel debe ir. No tengo una pregunta aquí.
Está presentando un caso en contra de la subcontratación y casi todo el mundo ya está en este barco. Obviamente estás atrapado en uno malo. A menos que documente un manejo mediocre de solicitudes de servicio como esas, no hay nada que su gerencia pueda hacer. Si la empresa subcontratada se monta con cientos de tickets para investigar, de repente comenzará a prestar atención. Mi consejo: documenta y sube en la cadena alimentaria con tu denuncia.
@MelBurslan ¿Dónde te subcontratan?
Si problemas como este no se pueden resolver a nivel de director o ejecutivo, eso indica un colapso total de la responsabilidad organizacional. Realmente no quieres trabajar en un lugar como ese. Lo sé por experiencia y he dejado un trabajo por esta misma razón.
Sería irónico si su pregunta aquí no obtuviera respuestas.
Soy parte de un departamento de TI y me molesta escuchar cosas como esta. Me temo que su gerente no puede poner, no escalará, entonces todo lo que puede hacer es documentar. ¡La mejor de las suertes!
"La empresa tiene su sede en el Reino Unido" Al menos no son solo los clientes humildes entonces
He experimentado esto en el Reino Unido en una gran empresa financiera. Se lo pasé a mi jefe, quien básicamente me dijo que viviera con eso. No ayudó a mis niveles de estrés ni a nuestra relación laboral. Lamento decir esto, pero te recomiendo que te familiarices con la oración de la serenidad .
XKCD obligatorio - xkcd.com/806
Lo más probable es que este escenario esté en juego allí: algunos gerentes patrocinaron la subcontratación de la mesa de ayuda y vendieron con éxito esa idea a sus superiores. Obviamente, estos patrocinadores ahora quieren que este cambio se considere exitoso, por lo que protegen el statu quo minimizando los informes de problemas y frunciendo el ceño ante cualquier comentario no positivo. Está informando problemas y proporcionando comentarios no positivos. Si aún no te han llamado "no positivo", "propenso al conflicto", "no proactivo", etc., es solo cuestión de tiempo. Simplemente pon una sonrisa falsa hasta que encuentres un nuevo trabajo en una empresa adecuada.
@SantiBailors y MelBurslan; la función no está subcontratada
¿Cómo estás abriendo o escalando tickets? En trabajos anteriores, tuvimos una disputa de clientes que "sabían más que nosotros" y no aceptaban nuestras soluciones, y en el trabajo actual, a menudo, la mesa de ayuda escala al tercer o cuarto nivel directamente con tickets como "Internet no funciona". o "las cosas van lentas", que obviamente les son devueltas...

Respuestas (7)

Como siempre, documenta todo. Si puede lograr que otros empleados colaboren, hágalo. Pregúntele a su gerente si puede hacer lo mismo con otros gerentes y haga que escalen.

Lo que debe hacer es demostrarles a los superiores que esto les está costando dinero. ESO siempre les llama la atención. "X horas perdidas debido a la inacción de la mesa de ayuda" frente a alguien que escribe los cheques obtendrá resultados.

O... desde una perspectiva de TI, el OP presenta constantemente tickets frívolos que no son problemas para que los solucione el departamento de TI ("¡este sitio web es lento para mí!"... "mi impresora no imprimió el tamaño correcto" ... "¿puedes desatascar mi impresora?"... "¡mi celular personal no se conecta al WIFI!"). Parece poco probable que un departamento de TI en una organización de tamaño tan grande esté desechando insensiblemente las multas reales.
@SnakeDoc Lo siento, yo mismo estoy en TI y he experimentado el mismo tipo de cosas. Nada más agravante que tener que caminar por el escritorio indefenso a través de su propio trabajo. Consideraría una posibilidad si hubiera comentarios en los tickets, pero cerrar tickets sin comentarios no es profesional y, en mi opinión, prueba que no es un PEBKAC.
Eso puede ser justo, pero cerrar boletos sin comentarios también podría indicar "No hay problema". También podría ser que el OP no esté siguiendo un procedimiento, como "¿probó todas estas cosas primero?" o "¿obtuvo la aprobación de la gerencia para presentar este ticket?", en un intento de eliminar los tickets frívolos. Los departamentos de TI se ven abrumados con toneladas de solicitudes de soporte falsas, por lo que no es del todo sorprendente para mí si simplemente eligen cerrar tickets frívolos sin ninguna ceremonia. Si el OP involucró tanto a la administración de TI como a la administración de OP, y no resultó nada ... parece probable que no haya ningún problema.
@SnakeDoc He acumulado muchas llamadas que fueron errores de PEBKAC y NPI a lo largo de los años, y también la infame llamada "portavasos". Eso no es lo que parece en este caso.
@SnakeDoc: Poniéndome en el lugar del servicio de asistencia de TI, puedo entender que hay tickets de spam. En mi caso, estoy siguiendo el proceso y proporcionando muchos detalles (trabajo en la administración de bases de datos, por lo que soy bastante experto en tecnología)
@WorkerWithoutACause Pensé que ese podría haber sido el caso. No sonabas como el tipo "mi teléfono no funciona, LO ARREGLAS".
@WorkerWithoutACause Solo estoy haciendo de abogado del diablo, ya que en Workplace recibimos muchos reclamos unilaterales. Para ese esfuerzo, ¿es posible que estos sean boletos de los que sientan que debería ocuparse, si están relacionados con su base de datos? Todavía me resulta difícil aceptar que un departamento de TI en una empresa del tamaño que afirmas (múltiples decenas de miles de empleados) esté total y deliberadamente arruinando tus boletos. Especialmente después de que afirmaste involucrar tanto a su gerencia como a la tuya, y no salió nada de eso. ¿Quizás podría dar un problema de boleto de muestra?
@SnakeDoc Experimenté algo similar con una corporación alemana. Una ENORME corporación alemana que existe desde el siglo XIX. No eran mejores. Tuve que guiar a su servicio de asistencia técnica hasta el último paso de lo que debía hacer. Como yo mismo he brindado soporte, nunca llamaría con un problema trivial, como resultado, estaban fuera de su alcance cada vez que les hablaba. Sucede. Por difícil que sea de creer, sucede.
¿Error de @RichardU NPI? Nunca había visto este antes, y mis resultados de Google están llenos de definiciones que no son sarcásticas.
¿Error de @RichardU NPI? Nunca había oído hablar de ese término. Escuché sobre PEBKAC, ID10T, interfaz biológica, capa 8, software húmedo, ... Toneladas de cosas que dicen "error de usuario" ofuscado, pero aún no error NPI.
Error @DanNeely NPI = No conectado. Además: un error de ID diez tee explicó que es ID10T, y muchos otros (l) errores de usuario. Muchas otras cosas como "mantenimiento de percusión" y "resolución de conflictos no verbal". PITA = Dolor en el a.. tantos términos, tan poco tiempo.
Como alguien que trabaja en una mesa de ayuda, me aseguro de documentar minuciosamente y enviar actualizaciones sobre los casos en los que no existe un problema real. Es muy común que las personas que informan que no hay problemas intenten culpar a TI por algo que olvidaron o que estropearon. Si escribo tres párrafos sobre cómo revisé todos los aspectos del sistema de correo y no encontré ningún problema a pesar de que el usuario informó que "faltaba" un correo electrónico, que estuvo en sus elementos eliminados todo el tiempo, entonces sé que el supervisor del usuario no lo hará. No intentes culparnos cuando un cliente nos deja porque el usuario eliminó su correo electrónico.
@SnakeDoc Si ​​en realidad se trata de un montón de problemas, entonces documentar todo también lo mostrará.
Una razón común por la que las personas suelen ser muy propensas a culpar al departamento de TI es sin duda la estupidez, la incompetencia o la pereza de dichas personas (el sitio web es lento, el tamaño de impresión incorrecto, etc.). Otra razón común por la que las personas suelen ser muy propensas a culpar a la mesa de TI es sin duda que muchas mesas de ayuda rutinariamente hacen todo lo posible para descartar las solicitudes de ayuda para trabajar menos / no meterse en "problemas" / evitar admitir fallas, etc. harto de eso y comienza a esperar un comportamiento tan sórdido de las mesas de ayuda por defecto.
@SantiBailors En mi última posición, la mesa de ayuda fue calificada por la cantidad de tickets que cerraron en la primera llamada. Debido a eso, los problemas que deberían haberse escalado no lo fueron y las personas que administraban las aplicaciones no fueron alertadas de los errores. Moraleja de la historia: Lo que calificas es lo que obtienes.
@RichardU: además, o tal vez solo desde un ángulo diferente sobre el costo, documente el impacto comercial del trabajo que no se hizo o se retrasó. por ejemplo, no pude proporcionarle X a Sally en contabilidad porque el ticket Y estaba cerrado. Y Sally, en el lado comercial, también puede escalar. Coordina el ataque al problema con Sally, escalando múltiples cadenas.
@RichardU, no caiga en la trampa de asumir que una organización es competente solo porque es grande y ha existido durante mucho tiempo (no necesito mencionar los ejemplos más conocidos).
"X hours lost due to inaction of help desk" in front of someone who writes the checks is going to get results.Sí, eso agregará combustible al fuego, haciéndolo aún más caliente y más doloroso. Solo asegúrate de que el fuego arda donde crees que lo hará. Si la mesa de ayuda está operando de alguna manera de acuerdo con la política oficial (tal vez hay una política que se supone que debe seguir en un ticket cerrado), entonces esas horas desperdiciadas pueden perjudicarlo si/cuando la investigación determina que usted fue el incompetente. Por lo tanto, tenga cuidado antes de hacer esto. Asegúrate de estar haciendo tu propio trabajo.
He trabajado en TI antes. Incluso yo sé que cerrar un ticket sin un comentario NUNCA es una buena idea. Enfada a los usuarios. Lo que lleva a una conversación no tan buena del gerente.

He observado este comportamiento de HelpDesk en un sistema que cerraba automáticamente los tickets tan pronto como se archivaban. (Lo más difícil de detectar es una falla en el formulario "informar un problema".) Por "sistema", me refiero al software de seguimiento de problemas en línea y múltiples operadores de HelpDesk con un operador de HelpDesk que presionó el botón "cerrar" en cada problema después de abrir y sin hacer ningún trabajo. Esto no se resolvió hasta que comencé lo siguiente:

  • Realice un seguimiento de todos los problemas para los que crea un ticket.
  • Cada vez que cualquier ticket en línea que cree se cierre sin resolución, haga dos llamadas telefónicas al HelpDesk: La primera llamada es para reabrir el problema ya que no se ha resuelto. La segunda llamada es para reportar un error en el sistema HelpDesk ya que el asunto fue claramente cerrado erróneamente y sin comentarios ni resolución. (Estos son, de hecho, dos errores que vale la pena informar).
  • Cada vez que un ticket telefónico que creaste se cierre sin resolución, haz dos tickets online con el HelpDesk: El primero es para reabrir el asunto ya que no se ha resuelto. La segunda es para reportar un error en el sistema HelpDesk del teléfono ya que el tema fue claramente cerrado erróneamente y sin comentarios ni resolución. (Estos son, de hecho, dos errores que vale la pena informar).
  • Recurso.

Esto creó unos cientos de tickets en un período de dos días, durante los cuales el problema que estaba planteando me detuvo y no pude lograr nada más. (Administrar esto con una base de datos puede ser útil). Esto tuvo una serie de efectos interesantes:

  • El manejo de tickets ganó un nuevo paso "su problema realmente se resolvió" (con una fecha límite de aceptación automática de unos pocos días).
  • Se volvió a capacitar al personal de HelpDesk para que no cerrara los tickets hasta que realmente se resolvieran.
  • La persona de HelpDesk que había estado cerrando tickets para aumentar su tasa de cierre sin hacer ningún trabajo en realidad se volvió excepcionalmente visible.
  • Se quitó énfasis a la tasa de cierre como métrica. (Con lo cual estoy bien: es una métrica en gran medida inútil ya que los trabajadores no pueden controlar las entradas y supone falsamente que la distribución de "tamaños de tareas" sigue una distribución unimodal).

Su experiencia puede ser diferente.

Parece mucho trabajo, pero si funcionó podría valer la pena el esfuerzo. Tiendo a una resolución más directa, pero +1 por encontrar algo en una situación difícil.
De alguna manera me recuerda a la redención de Shawshank. El personaje principal envía una carta todos los días para obtener una subvención para la biblioteca de la prisión, hasta que recibe una y dice "Así que comencé a enviar 2 cartas todos los días".
Tendría cuidado aquí. La gerencia del OP parecía ser muy indulgente con su departamento de TI. Por eso, la gerencia puede ver el comportamiento que usted describe como una interrupción del trabajo del departamento de TI. No abogo por esta opinión, pero sé muy cauteloso con tu gestión.
¡Me gusta como piensas! Me recuerdas a alguien... hum, quién podría ser... ¡oh, sí! ¡YO! ¡¡Salud!!
Esto es hilarante, pero soy escéptico de que terminaría bien en la mayoría de los casos.

Registre todos los contactos con la mesa de ayuda, en una hoja de cálculo compartida o incluso en una hoja de tiempo (lo que lo hace muy visible). Conserve todos los números de boleto; si no obtiene uno, comuníquese nuevamente con la mesa de ayuda para obtener el número de boleto.

En la hoja de cálculo, registre el progreso del ticket, por ejemplo, Resuelto, Cerrado por soporte, Sin respuesta, y también registre la respuesta de los usuarios, por ejemplo, Resuelto, Cerrado pero no resuelto, etc.

Después de aproximadamente una semana, podrá mostrar a sus gerentes el impacto real de una función de soporte que no brinda soporte.

Esta es una buena forma de hacerlo. TI debe documentar de forma transparente porque la documentación gana cuando se produce un desacuerdo sobre algo importante. Si los usuarios documentan los problemas de TI, tendrán la información que necesitan cuando algo sale muy mal.

La respuesta sigue siendo escalar el problema a su gerente.

Necesitan abordar este problema hablando con su gerente. Debería ser posible construir un caso de que x no se hizo o se hizo mal, o que y superó el presupuesto debido a fallas repetidas de la función de TI.

Claramente no hay acuerdos de nivel de servicio (SLA) o, si existen, a nadie le importa que no se cumplan. Parece que la cultura del bajo rendimiento ya se ha establecido, se acepta tácitamente y será difícil de cambiar. La solución más rápida que le brindará un buen servicio desde su mesa de ayuda es reemplazarlos.

Cuantifique el problema como dinero: mantenga un registro del tiempo perdido en su equipo (o más amplio si puede) para que pueda mostrar el costo monetario del mal desempeño del servicio de asistencia actual.

Investigue la subcontratación de la función de la mesa de ayuda de TI a una parte externa, cuyo contrato puede tener SLA que deberán cumplir. Obtener citas.

Calcule el costo total de usar un servicio de asistencia subcontratado, incluidos los ahorros obtenidos al despedir a todo el personal del servicio de asistencia (calcule su salario y al menos duplíquelo para obtener el costo real de un empleado para la empresa).

Suponiendo que el costo real de la subcontratación es un ahorro , propóngalo a la gerencia mostrando todas sus suposiciones y cálculos. Demostrará que tienes una gran iniciativa y eres proactivo.

Si no es un ahorro, entonces aún muéstrele su trabajo a la gerencia, pero solo para mostrarle que investigue alternativas y que no se acumulen. Pero aun así mostrará que el servicio de asistencia necesita un SLA y deben cumplirlo y cuál es el costo de no cumplirlo.

¿Qué es "SLA", específicamente?
@donjuedo "SLA" significa Acuerdo de nivel de servicio , que es básicamente el rendimiento mínimo aceptable para algo. En el caso de un servicio de asistencia, podría ser algo así como "Todos los tickets se resolvieron en 3 días, el 80 % en 1 día, el 50 % en 3 horas. Todas las respuestas a los correos electrónicos en 1 hora".
Diría que sí, por supuesto, hay SLA , y este servicio de asistencia técnica está haciendo servilmente exactamente lo que necesita para cumplir con ellos. ¿El personal del servicio de asistencia maneja más de x tickets por hora? Controlar. ¿Los boletos se cierran en menos de y horas? Controlar. Por supuesto, los SLA probablemente deberían redactarse mejor, pero por lo general no lo están.

La respuesta ideal es hacer que su mesa de ayuda tenga un sistema de seguimiento de tickets adecuado, con visibilidad para sus clientes y métricas de seguimiento de latencia, rendimiento y calidad/satisfacción.

Pero eso es algo que su gerencia debe implementar, por lo que es algo que su gerente debe pasar por alto en la buena cadena.

Mientras tanto, como han dicho otros, implemente una solución de seguimiento ad-hoc para su contacto con ellos, registrando todos los contactos y qué información se transmitió de un lado a otro. Hacer solicitudes por correo electrónico es una forma de capturar esto fácilmente, aunque algunas personas de soporte dan mayor prioridad a las preguntas que llegan por teléfono.

Si fuera yo, me convertiría en el reemplazo local de la mesa de ayuda de su unidad de negocios. Si puede adquirir la habilidad, tiene la capacidad de exponerse a su gerencia local y convertirse en un empleado realmente valioso.

Ese tipo de cosas tienden a conducir a cosas realmente buenas, como promociones y salarios más altos.

Dado su nivel declarado de asociado, esa es la mejor manera de lograr un cambio positivo en su unidad de negocios.

Una buena sugerencia, y odio presentar más obstáculos, pero mi empleador ha bloqueado las computadoras, por ejemplo, no puedo instalar ni modificar nada porque no tengo privilegios de administrador.
Por supuesto que lo hicieron. No hay mucho que puedas hacer en ese momento. ¿Es posible pasar a otra empresa?
¿Quién sueña con convertirse en mesa de ayuda? ughh Para muchos de nosotros es una degradación, no una mejora. Necesito que mi Helpdesk arregle la rutina diaria para que yo pueda concentrarme en problemas mayores.