La actividad central dentro de un Service Desk es la atención de tickets (solicitudes e incidentes) que realizan los usuarios del área de TI. Para ello y siguiendo una práctica que se ha implementado en la mayoría de las organizaciones, dichas actividades se vinculan directamente con un número de atención que dentro del ambiente interno se denomina número de “ticket”, en este artículo te ayudamos a comprender cómo se hace la optimización de tickets de Service Desk.

El manejo de estas atenciones por medio de tickets facilita su correcta administración y organización en distintas formas; sea por área de atención, sea por el personal que atenderá un grupo en particular de solicitudes, entre otras opciones. Pero más allá de esto, su importancia radica en que nos brindan una serie de estadísticas que nos dan la oportunidad de medir y cuantificar el trabajo que se realiza en el área de sistemas y de esta forma medir el impacto que ésta área tiene en toda la organización.

Los riesgos de no generar bien un ticket

La generación de tickets en Service Desk es una actividad que se realiza de manera tan rutinaria que a veces se descuidan detalles que pueden afectar en determinado momento a que una solicitud realizada por alguno de los usuarios de la empresa no se atienda en el tiempo o las formas adecuadas y por ende no hay una optimización. Esto conlleva repercusiones que en el ámbito laboral pueden ir desde un impacto casi nulo hasta un impacto crítico para la entidad de manera global.

Imaginemos por un instante que somos médicos y que estamos a punto de realizar una autopsia.

Cualquier disciplina o ciencia a pesar de las obvias diferencias que presenta en función al área a la cual está enfocada tiene como base fundamental el método científico, en el cual los procesos de observación y análisis tienen una importancia fundamental para aprender de fallas pasadas y evitarlas en el futuro, garantizando así la creación de hábitos correctos.

También lee: Los clientes y usuarios esperan recibir servicios extraordinarios de TI

Un ticket vencido = un cadáver

Hagamos entonces a partir de este paso, un ejercicio de discernimiento que nos ayudará a encontrar puntos que siendo muy comunes pueden generar en nosotros hábitos correctos al momento de trabajar con las solicitudes que se reciben en el día a día.

En este ejercicio el supuesto “cadáver “estará representado por medio de los tickets, tickets de Service Desk que se “vencieron”, en este caso, el ticket no fue atendido dentro de los parámetros previamente establecidos para una situación específica y se busca su optimización. Dicho ejercicio consistirá en que se nos encomendará revisar el ticket, dividirlo y analizarlo con la intención de conocer las causas que originaron su vencimiento.

Desde luego existen muchas situaciones que podrían analizarse, algunas más complejas que otras, pero en esta ocasión nos encontramos con un ticket que a simple vista nos parece muy común y que seguramente todas aquellas personas que hemos trabajado brindando servicio dentro del área de TI hemos visto; un reporte indicando que un usuario no puede ingresar a internet.

En nuestra hoja de análisis tomamos nota del nombre o título del ticket;

“Sin acceso a Internet”

Es un título simple, común, cotidiano y que a pesar de que en un primer momento nos brinda una clara idea de la situación que se nos presenta (no se tiene acceso a Internet).

Surgimiento de preguntas

Después de unos instantes el panorama deja de ser tan claro y surgen algunas cuestiones básicas relativas a este primer punto:

1. ¿En este equipo ya se había ingresado con anterioridad a Internet o sería la primera vez que se está intentando ingresar?
2. ¿Al intentar ingresar a internet le aparece un mensaje de error?
3. ¿No se tiene acceso a ninguna página o solo es a alguna página en específico?

En realidad, éstas son solo tres preguntas dentro de una amplia gama de cuestionamientos que cualquier analista de ServiceDesk se podría hacer cuando un usuario reporta esta situación. La idea principal consiste en mostrar que el “nombre” bajo el cual se mostró a nuestro “paciente” no es lo suficientemente claro y descriptivo.

Después de este primer punto de reflexión, centramos nuestra atención en el “cuerpo” del ticket. El cuerpo del ticket correspondería con la descripción de la falla o situación que se presenta con la finalidad de que se pueda ahondar en la información colocada en el título (que como ya vimos, no brinda demasiada información al respecto).

Dentro del cuerpo del título encontramos la siguiente información;

“Usuario reporta vía telefónica que no puede acceder a Internet en su laptop. Solicita que se revise su equipo por la tarde ya que necesita entrar a Internet”

Para este punto, la esperanza que teníamos de obtener de primera mano una pieza de información más precisa de lo acontecido se desvanece. Parece ser que este “cadáver” no nos facilitará nuestra labor.

Indagación

Como primer detalle detectamos que la descripción en realidad es casi una repetición del título sin brindar un aporte sustancial, aunque sí permite obtener dos datos adicionales que podemos destacar; se trata de una laptop y la atención se brindó a través del teléfono. Sin embargo, al contar con estos datos, se agregan más preguntas que respuestas al análisis que estamos realizando.

Algunas de las cuales serían:

• ¿La laptop se conecta a la red a través de un cable, de señal inalámbrica (Wireless) o a través de algún dispositivo de Internet móvil como sería una BAM?
• ¿Si se conecta a través de una señal inalámbrica, ya se verificó que el adaptador de red estuviera encendido?

En estricto sentido, estoy seguro que cualquier persona involucrada en el ámbito de sistemas podría notar que hace falta una descripción más clara y precisa de la situación, así como una mayor información relativa a la solicitud que se nos está presentando.

En este momento esa falta de información parece algo muy evidente, que de inmediato salta a la vista y que sin embargo, la gran mayoría de los analistas de ServiceDesk hemos omitido colocar en alguna ocasión. Y no es solo eso, después de leer nuevamente la descripción notamos un pequeño pero importante detalle; no se le pidió al usuario que nos indicara un número telefónico de contacto. ¿Alguna vez nos hemos encontrado con alguna situación similar?

El momento de adentrarse en las entrañas del ticket

Una vez que se terminaron de revisar los puntos anteriores ha llegado el momento de adentrarnos en las entrañas del ticket para saber la razón de su vencimiento. Sin duda, pueden ser muchas las causas de que esto haya sucedido, por lo cual trataremos de hacer un análisis imparcial y obtener conclusiones positivas al respecto.

Al dividir el ticket, llegamos al historial de seguimiento. Aquí cabe aclarar que los procesos establecidos para dar seguimiento a una solicitud pueden variar mucho entre cada uno de ellos, pero para este caso en particular nos encontramos con la siguiente información:

Sin poder contactar al usuario

“No se pudo contactar al usuario vía telefónica debido a que no se tenía su número de extensión, se marcó al área de recepción solicitando información de contacto. Se marcó a la extensión proporcionada varias veces sin éxito alguno”

No se facilita el equipo para su revisión

“Al día siguiente se intenta contactar a usuario nuevamente vía telefónica sin éxito alguno. Por la tarde se logra contactar a usuario quien comenta que ha tenido varias reuniones por lo cual no se encontraba disponible y que debido a su carga de trabajo no puede facilitar su equipo para revisión en este momento por lo cual solicita que se revise al otro día por la mañana”

Verificación de acceso a Internet

“Se contacta a usuario en el tiempo indicado el día anterior vía remota al equipo de cómputo y se verifica si cuenta con acceso a Internet. Elusuario necesita ingresar a una página de transferencia de archivos, ya que necesita enviar un documento a un colaborador».

Detección de página está bloqueada

«No se puede ingresar a dicha página debido a que está bloqueada desde el firewall de la organización por motivos de seguridad. El archivo a enviar se revisa y se detecta que debido a su tamaño no puede enviarse por correo electrónico. Se informa a usuario que dicho acceso a la página debe validarse con el área correspondiente y que dicha solicitud será canalizada a dicha área.”

Escalamiento

“Se escala ticket al área correspondiente para que se permita el acceso a la página solicitada”

El análisis del ticket

En este punto del análisis, cada quien puede opinar si lo descrito en el historial es lo suficientemente preciso o no. Lo que sí resulta más evidente es que ahora ya tenemos una idea clara de la solicitud inicial realizada por el usuario:

1. No podía ingresar a una página de Internet en particular y además, esto no era resultado de un error
2. Para ingresar a dicha página se necesitaba de una configuración realizada por otro nivel dentro del área de sistemas

Desafortunadamente, para el momento en que la situación se clarificó ya habían pasado dos días de que la solicitud había sido creada y por lo tanto, ya había sobrepasado el tiempo en el cual este tipo de solicitudes se deben atender, es decir, ahora ya sabíamos porque el ticket que teníamos ante nuestros ojos se había “vencido”.

En nuestra hoja de anotaciones y para finalizar el ejercicio, colocamos la siguiente descripción;

“Causa principal que originó el vencimiento; definición inadecuada de la solicitud originalmente recibida.”

Conclusiones

En estricto sentido, sabemos que un ticket que se “venció” continúa en proceso de atención y de ninguna manera significa que se abandone o que no se siga revisando por el área correspondiente. Sin embargo, esto no es lo primordial, ya que debemos tener presente que muchas veces una atención brindada fuera de tiempo es equivalente a una atención que no se brindó y la razón es que el tiempo de respuesta es un factor clave tanto en la percepción del usuario como en los estándares de calidad que existen para los servicios de TI.

En el ejemplo anterior, queda de manifiesto que una correcta definición inicial de la solicitud del usuario nos hubiera evitado perder un factor que no se puede recuperar; el tiempo.

Más allá de buscar culpables en la «deficiente» resolución de tickets, el área de TI como una entidad que evoluciona de manera constante debe ser capaz de retroalimentarse a sí misma y de esta forma aprender de lo sucedido para evitar en la medida de lo posible que se vuelva a presentar en el futuro, es decir, buscar la optimización y mejora continua del Service Desk.

Esta percepción, puede hacer toda la diferencia entre el éxito y el fracaso de un departamento de TI. Finalmente, si miramos a través de un cristal claro, el principal objetivo que todo departamento de Ti debería tener es la satisfacción del cliente y para ello, la optimización de tickets de Service Desk puede ayudar.

“Nosotros vemos a nuestros clientes como los invitados de una fiesta en la que nosotros somos los anfitriones. Nuestro trabajo es hacer que la experiencia del cliente sea un poco mejor cada día”.

Jeff Bezos – CEO de Amzon