¿Qué es un Service Desk y para qué sirve?

Larra, el genial escritor español, publicó en 1833 «Vuelva usted mañana», la historia de un monsieur francés que llega a Madrid para resolver un asunto de dos semanas… y quema seis meses rebotando de ventanilla en ventanilla. Casi 200 años después, podría ser la historia IT del usuario que no puede conectar a la VPN y no sabe si eso es cosa de redes, sistemas o quien hizo la app. Para demostrar que algunas cosas sí cambian, está el Service Desk, la «ventanilla única» que conecta usuarios con equipo técnico.
Así, un Service Desk es el punto de contacto unificado en el que el proveedor de servicios IT, o el personal encargado de tecnología en una organización, recibe todas las incidencias, consultas o solicitudes relacionadas con los servicios tecnológicos que presta y/o mantiene.
El usuario ya no tiene que adivinar, ni peregrinar como el Monsieur Sans-délai de Larra viendo cómo su vida se pierde en un laberinto de términos técnicos incomprensibles y ese «vuelva usted mañana». El usuario solo debe saber que, para todo lo relacionado «con eso de la tecnología», ha de acudir a un único sitio, el Service Desk, y él se encarga del resto.

¿Qué es un Service Desk? La función, el equipo y la herramienta

Para definir Service Desk debemos comprender primero que dicho término se utiliza para denominar tres cosas distintas: la función de gestión IT unificada, el sufrido personal que realiza dicha función y también las herramientas con las que desarrolla su trabajo.
Pero lo fundamental es empezar comprendiendo la esencia de que Service Desk actúa como «Punto Único de Contacto» (o SPOC, single point of contact, por sus siglas en inglés). Así lo define IBM: un mecanismo de entrega que proporciona un punto único de contacto entre la organización IT y sus usuarios.
Con él, dicho usuario no tiene que saber de tecnología o de cómo se organiza esta en cuanto a departamentos, funciones u organigrama. Él escribe a un sitio con su habitual descripción de: «Esto se ha roto, yo no he hecho nada», y los siguientes pasos corren a cuenta de quien sí conoce el mapa del laberinto IT.
Pero además, hemos de volver sobre esos tres aspectos del principio y remachar que un Service Desk es:

• La función. Es decir, el papel dentro de la organización, consistente en recoger, gestionar y responder lo relacionado con los usuarios de IT. Como veremos, lo hace en sentido amplio, no solo cuando se trate de un problema o avería.
• El equipo. Que hace la labor anterior, con sus perfiles, turnos interminables y niveles de soporte.
• Las herramientas. Con las que el equipo anterior desarrolla su labor. Normalmente, un Service Desk usa una plataforma de ticketing, mantiene una base de conocimiento y un portal de usuario, emite informes…

Para los lectores en diagonal voy a recalcar que el error más común es reducir Service Desk a software de tickets o a Helpdesk (algo bastante habitual, que desarrollaré con epígrafe propio).
Recordemos, el concepto Service Desk es todo lo anterior y no se reduce a una sola cosa. De hecho, puedes tener una magnífica herramienta de tickets o gestión, pero sin la función bien definida detrás, no sirve de nada.
Y hablando de eso…

¿Para qué sirve un Service Desk?

Para no perder. En concreto, no perder ninguna interacción con el usuario relacionada con IT, ya sea porque se presentó en la ventanilla equivocada como con Larra, o porque se perdió en la memoria de alguien, en lugar de estar recogida y centralizada en una herramienta.
Esa es la función en un párrafo que, desglosado, hace que un Service Desk sirva para:

• Recibir y registrar desde un único sitio todo lo que tenga que ver con IT: incidencias, consultas, solicitudes… que quedan registradas de acuerdo a un proceso y no al capricho de quien esté de guardia.
• Clasificar y priorizar. Urgente e importante no son lo mismo y alguien tiene que recordarlo, poniendo orden a esas peticiones con un criterio explicable.
• Asignar y escalar. Lo que significa que cada petición debe ir a quien corresponda. Y si esa petición sobrepasa la asignación inicial, debe escalar a quien pueda resolverla.
• Comunicar con el usuario, manteniéndolo informado. Pocas cosas hacen perder más paciencia (y confianza) que el silencio… y esta parte se desatiende demasiado.
• Controlar los SLA (service level agreements). Porque si no, vienen las consecuencias y, cuando el SLA es contractual, son monetarias. El Service Desk debe medir tiempos respecto a lo especificado en los niveles de servicio acordados, avisando con antelación de su posible incumplimiento.
• Facilitar el autoservicio del usuario y el conocimiento de la tecnología. Una quimera eso de que el usuario busque y arregle su problema pero, al menos, lo resuelto una vez debe quedar resuelto para siempre. O bien que «el problema de siempre» tenga la solución actualizada en una entrada de la base de conocimiento.
• Controlar. Recogiendo indicadores clave y datos con los que debatir en reuniones, en lugar de gritarnos sobre percepciones subjetivas.

¿Cómo funciona un Service Desk?

Ya hemos visto el qué, ahora toca el cómo y la respuesta es que funciona como un circuito con una única entrada y una trazabilidad total hasta la resolución.
Cada proceso de funcionamiento diferirá según la organización (habrá quien tenga más requisitos de compliance, por ejemplo) pero, siento ser yo el de la mala noticia, no somos tan especiales como nos decían en el colegio, así que hay una serie de pasos comunes.

• El usuario contacta con el Service Desk por el canal que hemos dispuesto y que haría que Larra estuviera orgulloso.
• La interacción se registra como caso en el sistema, con un identificador.
• Se analiza el tipo de necesidad: avería, petición, consulta…
• De acuerdo a lo anterior, se categoriza y prioriza dependiendo del impacto y la urgencia.
• Si el Dios Máquina nos está mirando con cariño, se resuelve en primer nivel. Si no, se asigna al equipo correspondiente.
• Si el nivel asignado es insuficiente para resolver, se escala.
• Durante todo el proceso, el usuario recibe información sin que tenga que perseguirla.
• Se solventa la incidencia o, en caso de ser otra cosa, se completa la solicitud.
• No cantemos victoria, no hemos terminado. Ahora se documenta lo realizado. Si es pertinente, lo aprendido se convierte en artículo de conocimiento.
• Ahora sí, se cierra el caso y queda registrado para informes, auditorías o análisis posteriores.

Funciones principales de un Service Desk

Pongámonos las «gafas de cerca» para examinar más a fondo las funciones de un Service Desk. Este tiene multitud de capacidades, porque las peticiones y lo que se rompe en tecnología tiende al infinito.
La función primordial es gestionar incidencias y solicitudes relacionadas con IT. Son los dos flujos principales que tienen ciclos de vida muy distintos, pero entran por la misma puerta.
Para lo anterior, registra en tickets, categoriza y prioriza como hemos visto. Y cuando algo se atasca, escala al pobre técnico de siempre cuya maldición es que le preocupa su trabajo y es el único «que se entera».
Otra función clave es el control del SLA. Su cálculo, los tiempos, cómo vamos…
Service Desk no sirve de nada haciendo de forense de nuestros niveles de servicio, la clave es controlar y prevenir si empezamos a descarrilar.
Gestiona flujos de trabajo y aprobaciones, automatizando estados, asignaciones, notificaciones… Y si es necesario visar algo en una solicitud, también es su función.
En esa línea, define además reglas de automatización que ahorran trabajo repetitivo, como informes.
El mantenimiento del portal de autoservicio y la base de conocimiento también es su prerrogativa. No podemos perder la esperanza de que el usuario mire alguna vez ese portal, en vez de llamarnos cabreado, o que alguien consulte la base de conocimiento antes de preguntar al técnico de al lado.
Además, monitoriza la satisfacción del usuario mediante encuestas y consultas posteriores que se ignoran (todos somos culpables, confesemos).
Por último, se integra con otras prácticas ITSM, como cambios, mantenimiento de activos, seguridad, monitorización…
Lo que separa un Service Desk de élite es aglutinar estas piezas, ya que gestionarlas de forma integrada nos da una máquina mucho más valiosa que cada engranaje por separado.

Incidente, solicitud, problema y cambio

¿Qué diferencia hay entre estos cuatro términos?
A ojos de los usuarios que escriban al Service Desk, parece que ninguna. Pero la mirada de un técnico perdió su inocencia hace mucho a cambio de perspicacia, y comprenderlas permite entender qué llega a dicho Service Desk y hacia dónde debe continuar el viaje.

• Incidente: es una interrupción o degradación de un servicio, como que no se envíen correos o que la app de CRM tarde 10 segundos en cargar.
• Solicitud de servicio: esta es una petición prevista y habitual, como un alta en el sistema, suministrar un equipo nuevo o ajustar permisos de usuario.
• Problema: ojo, porque no es el incidente del principio, sino su causa o posible causa, la que hay detrás de uno o varios incidentes. Se aborda investigando esos incidentes hasta dar con el origen.
• Cambio: cuando añadimos, modificamos o retiramos un servicio o componente de nuestra infraestructura IT (de manera controlada), habiendo evaluado el riesgo y la ventana de cambio.

Los días de un Service Desk están hechos, principalmente, de recibir los dos primeros y derivar los dos últimos a quien los gestiona (idealmente, detectándolos con antelación).

Service Desk vs Helpdesk

En la obra maestra El Gran Lebowski, «El Nota» es confundido por unos ladrones con un millonario que se llama igual. A mí nunca me confunden con un rico, pero Service Desk y Help Desk sufren lo mismo que «El Nota», aunque no son lo mismo.
Help Desk (o Helpdesk, la forma más usada cuando nos referimos solo al software) se enfoca en resolver incidencias y dar soporte técnico, mientras que Service Desk, como hemos visto, establece una relación mucho más amplia entre IT y los usuarios.
Es la típica confusión de «la parte por el todo», que tendremos más clara con esta tabla.

	Helpdesk	Service Desk
Objetivo	Resolver incidencias y solicitudes de soporte	Gestionar la relación del usuario con los servicios IT en sentido amplio
Alcance	Soporte al usuario	Prestación y gestión del servicio IT al usuario
Marco de trabajo	Puede operar sin marco formal de gestión de servicios	Encaja habitualmente como práctica dentro de ITSM
Procesos principales	Incidencias, solicitudes, escalados	Los anteriores, más catálogo, aprobaciones, comunicación de cambios
Métricas clave	Tiempos, resolución en primer contacto, volumen	Las anteriores, más cumplimiento de SLA y satisfacción

Me han llamado muchas veces rígido y aquí voy a demostrar que solo tienen razón en parte, porque lo cierto es que en la vida real las fronteras son borrosas entre estos dos términos, de ahí esa confusión habitual.
Hay organizaciones que llaman Helpdesk a algo que hace catálogo, aprobaciones y gestión de SLA, y otras que denominan Service Desk a algo que es poco más que una bandeja de entrada compartida y ya.
Pero lo que los distingue es el alcance real que hay detrás y no lo que ponga el cartel.

Service Desk vs Ticketing

En este caso, la diferencia entre los términos es la que hay entre lo que se hace, es decir, la función (Service Desk), y el mecanismo con el que desarrollamos dicha función en nuestro día a día (Ticketing).
El ticketing se realiza con una herramienta que registra y sigue los casos que debe gestionar un Service Desk. Suele ser su herramienta principal, aunque no la única.
Con el ticketing respondemos a las preguntas clave, como la de en qué estado concreto se encuentra un caso y, más importante aún, a quién le echamos la culpa en la reunión de que siga abierto.

Service Desk vs ITSM

Estos términos también se solapan a veces, porque de nuevo se confunde «la parte por el todo», solo que ahora el Service Desk es la parte, una función dentro de la gestión TI y, en concreto, de la gestión de servicios IT (ITSM, por sus siglas en inglés).
Por ejemplo, la seguridad es parte fundamental de ITSM, pero muchas veces no requiere interacción con el usuario (como en parcheos, hardening, etc.). De ese modo es ITSM, pero no Service Desk, que no abarca esto.
Si ponemos a los cuatro términos anteriores en una rueda de reconocimiento de sospechosos habituales (y ordenados por función, desde la más específica a la más amplia), veremos mejor las diferencias.

Concepto	Función
Ticketing	Registrar y seguir casos
Helpdesk	Resolver incidencias y solicitudes
Service Desk	Gestionar el punto de contacto y la interacción con los servicios
ITSM	Gestionar los servicios IT de forma integral

Service Desk e ITIL

ITIL (Information Technology Infrastructure Library o Biblioteca de Infraestructura de Tecnologías de la Información) es un marco de buenas prácticas para la gestión de servicios IT y, en su versión 4, Service Desk es una práctica con entidad propia.
PeopleCert, la entidad que la administra, dispone de una certificación específica, ITIL 4 Practitioner: Service Desk, centrada en conceptos, procesos, roles y métricas, así como en la relación con otras prácticas.
Pero como Service Desk es solo una pieza de la gestión global, no vive solo y aparece dentro del módulo ITIL 4 Specialist: Monitor, Support and Fulfil, junto a: Incident Management, Monitoring and Event Management, Service Request Management y Problem Management.
Dicha agrupación implica quién atiende al usuario, quién detecta los eventos y quién investiga las causas, funciones que trabajan en el mismo territorio.
Más allá de ITIL, la norma de referencia es ISO/IEC 20000-1, pero ojo, porque no son mandamientos grabados en piedra y ninguna obliga a montar un Service Desk de una manera concreta.
A lo que nos ayudan es a no improvisar de cualquier manera y, para quien necesite pasar de la teoría a la práctica, he aquí una guía sobre cómo implementar ITIL en IT.

Canales de atención y experiencia del usuario

Tron, en aquella segunda parte a ritmo de Daft Punk (vamos a obviar que hay otra película posterior), lo dejaba claro: «Yo lucho por el usuario». En términos menos épicos, el Service Desk está también para satisfacer sus necesidades y lo primero que hace falta es un buen canal de atención.
Los habituales son el portal, el email, el teléfono, el chat, los asistentes conversacionales de IA y las integraciones con otras herramientas.
Pero eso es un catálogo y la trampa está en creer que más canales implican mejor servicio.
Si abrimos uno nuevo, pero no lo integramos con el proceso, ya hemos fragmentado el historial y multiplicado las grietas por las que se pierden peticiones. O si ponemos una ventanilla, pero nadie atendiendo en ella, multiplicamos la frustración.
No importa por dónde entre la petición, todo debe converger a un único caso trazable.
En ese campo nos jugamos la experiencia de usuario y la clave es la comunicación, porque en este mundo enfocado en lo externo, la percepción es la realidad.
Un caso que tarda tres días en resolverse, pero informa todo el tiempo, hace que el usuario perciba movimiento. Mucho mejor que una petición resuelta en día y medio, que ha mantenido 36 horas de silencio absoluto.
Trabajamos con máquinas, pero para servir a personas, con emociones y gatillo fácil para mandar quejas. Y el Service Desk debe gestionar esas emociones tanto como los ceros y unos.

Autoservicio, base de conocimiento y shift-left

El Service Desk se preguntó un día:
«¿Y si el usuario pudiera resolver por su cuenta lo que le ocurre?».
Y guiado por ese sueño, tiene una parte de autoservicio que permite eso, al menos en teoría.
En la práctica, esto cristaliza en portales de usuario y bases de conocimiento con buscador de soluciones, preguntas frecuentes, artículos, consulta de sus casos sin tener que llamarnos o incluso automatizaciones para lo más sencillo.
Es lo que sostiene la filosofía shift-left: desplazar la resolución hacia el punto más cercano al usuario que pueda solventarla mejor.
Del especialista pasa al primer nivel, de ese primer nivel pasa al conocimiento publicado en forma de FAQ o artículos y del conocimiento pasa a la automatización.
¿Para qué? Para que perfiles técnicos con 10 años de experiencia no estén configurando el correo de un móvil… otra vez.
Eso sí, el cambio es lo único que existe en la vida y, especialmente, en tecnología. Así, el portal y la base deben estar actualizados o aumentaremos la frustración del usuario y nuestra carga de trabajo.

Automatización e IA en el Service Desk

En Fantasía, un Mickey Mouse aprendiz de mago da vida a una escoba para que acarree agua por él, pero se le descontrola y, al partirla con un hacha, consigue el doble de escobas sembrando el caos.
Eso es lo que ocurre cuando automatizamos un proceso que no entendemos.
Mientras no olvidemos ese cuento de advertencia, lo cierto es que la IA y la automatización se aplican hoy a clasificar, dirigir, resolver y documentar casos en el Service Desk.
Bien aplicadas ayudan a:

• Clasificar casos automáticamente según su contenido, el servicio afectado o el usuario al que atender.
• Calcular la prioridad partiendo del impacto y la urgencia declarados en la petición.
• Resumir casos largos para el técnico, por ejemplo, tras un escalado.
• Buscar conocimiento y sugerir respuestas a dicho técnico, que debe decidir si sirven y le ahorran tiempo.
• Que el usuario tenga asistentes conversacionales que atiendan las solicitudes más frecuentes, cotejando con la base de conocimiento.
• Aplicar workflows, enviar notificaciones y realizar escalados, que se disparen por eventos en lugar de por frustración humana.

Eso sí, ahora que está tan de moda el concepto, sigue siendo necesario un humano en el bucle (human in the loop) para no repetir la escena de Fantasía.

Métricas de un Service Desk

En mecánica cuántica, la onda no colapsa hasta que la medimos, del mismo modo que un Service Desk también es un brindis al sol mientras no calibremos su desempeño real con indicadores clave.
Los más habituales son:

• Tiempo hasta la primera respuesta (First Response Time). O cuánto tarda el usuario en sentir que se le escucha, recibiendo la primera contestación útil. Fundamental por aquello de la necesaria gestión de emociones.
• Tiempo de resolución (Resolution Time). Que es lo que tarda en cerrarse el caso. Ojo, porque se puede reabrir si el arreglo no ha sido satisfactorio.
• Resolución en primer contacto (First Contact Resolution, FCR). Mide los casos que solucionamos a la primera, sin que se reabran o escalen.
• Cumplimiento de SLA. Fundamental, ya que lo contrario implica incumplimientos que, en contratos con clientes, se traducen en penalizaciones.
• Backlog. La torre de casos pendientes acumulados que amenaza con aplastarnos. Este es el indicador que avisa de tormenta en el horizonte antes de que descarguen los relámpagos.
• Tasa de reaperturas (Reopen Rate). O los cierres que eran en falso. Que sea elevada implica una gran ineficiencia.
• Satisfacción del usuario (CSAT). Medida por encuestas y calificaciones del usuario al final de la interacción. Nuestra particular vuelta al colegio del que siempre quisimos escapar.
• Volumen de casos por categoría. Muy interesante porque nos dice de dónde viene la demanda principalmente y en qué tenemos que incidir para reducir eso desde el origen.
• Tiempo medio operativo (Average Handle Time, AHT), si resulta relevante. Esto es importante y precisa aclaración.

Cerrar rápidamente una interacción no implica haberlo hecho bien porque, como hemos visto, puede reabrirse.
Los indicadores pueden mentir en solitario y por eso un AHT bajo puede indicar eficiencia, pero también que clausuramos prematuramente los casos.
De ahí que, para saber la verdadera historia que nos cuenta el número, debamos combinarlo con otros indicadores como CSAT o reaperturas.

Beneficios de un Service Desk

Leyendo lo anterior queda claro que este tema puede darnos bastantes beneficios potenciales. Pero estos no emanan de tener un Service Desk y ya está, sino de que desarrolle las capacidades que hemos visto y no sea una bonita cáscara vacía que se convierta en punto único de frustración y no de servicio.
Entre esos beneficios potenciales están:

• Centralización. Adiós a la cacofonía de voces y que el caos ataque por todos los flancos. Ahora hay un único punto de entrada y cualquier canal desemboca en el mismo registro.
• Trazabilidad. Gracias a que ahora tenemos un rastro de cada solicitud, de principio a fin, y un único lugar en el que buscarlo.
• Mejor experiencia de usuario. Gracias a una comunicación coherente, la capacidad de que siga el estado de su petición, notificaciones de lo importante y un lugar al que acudir para ello (el portal de usuario).
• Mejor organización. Ya que prioridades y escalados, por ejemplo, se asignan con un criterio que va más allá de la proximidad, o de ser el sufrido técnico «que lo sabe todo».
• Mayor control del servicio IT. Gracias a una medición y comprobación de los acuerdos de nivel de servicio, con avisos que llegan antes de incumplirlos.
• Mayor conocimiento. Gracias a una base viva y actualizada, que permite la reutilización de soluciones, sin empezar siempre desde cero.
• Menor carga de trabajo. Pudiendo solucionar lo sencillo sin intervención, mediante posibles automatizaciones que se encarguen en primera línea de las peticiones triviales, o bien que el portal sirva por fin y el usuario lo consulte sin preguntar a nadie.
• Una mejora continua. Haciendo realidad la leyenda que persigue toda organización, gracias a disponer de datos para localizar tendencias y problemas de fondo.

Buenas prácticas para un Service Desk que funcione

He comenzado el apartado anterior con el gran riesgo de un Service Desk, que al final sea herramienta y nada más. Un decorado sin vida, una cáscara vacía.
Eso nos sucederá siempre que no haya detrás unas buenas prácticas implantadas.
He aquí algunas que, por la experiencia de más de 20 años en esto, aplicamos en Pandora.

• Definir bien los servicios, su ámbito y sus responsables a todos los niveles. Puro diseño, el imprescindible plano de la casa antes de levantarla, para no repartir casos a ciegas y tener claros los cauces del río de peticiones.
• Reducir niveles y escalados todo lo posible. Queremos una casa sólida y no un palacio bonito sobre el papel, cuya complejidad se va a estrellar contra la realidad al primer minuto.
• Usar un lenguaje que el usuario entienda. Especialmente para categorías y también en el portal de usuario. Esta es una comunicación en dos direcciones y queremos la colaboración de ese usuario. Jerga que parezca un hechizo arcano solo le confundirá y desincentivará el uso.
• Actualización constante. Implantar y olvidar hará que la base de conocimiento sea un museo de la nostalgia. La queremos viva y al día para que resuelva problemas.
• Automatizar solo lo que entendemos. Recordemos la escoba de Disney y que, antes de automatizar hay que estandarizar.
• Comunicación fluida. Lo que implica informar incluso cuando no hay novedades. El usuario debe sentir que se le hace caso.
• Seguimiento de indicadores. Especialmente los relacionados con el SLA, pero también con el funcionamiento interno si queremos ese mirlo blanco de la mejora continua.

Retos habituales en un Service Desk

«Falla mejor», dijo Samuel Beckett. Y tiene razón, fallar es inevitable y solo podemos aspirar a hacerlo de una forma que, al final, nos haga crecer.
El primer paso para ello es dejar de repetir los errores comunes, porque los hemos visto en demasiadas organizaciones y se repiten con una regularidad casi cómica.
Estas son algunas pieles de plátano en las que resbalan demasiados Service Desk.
La primera suele ser la incapacidad para escalar las operaciones. Todo va bien con cien usuarios, pero conseguimos un buen cliente, pasamos a trescientos y se masca la tragedia con una degradación del servicio.
Y hablando de escalar (pero ahora en lo referido a elevar casos a otros equipos), el gatillo fácil es demasiado tentador y, sin políticas claras, los equipos de siempre (que trabajan más y se quejan menos) acaban con todos los casos.
Se nos llena la boca con portales de usuario y bases de conocimiento, pero actualizarlos es un dolor, la verdad. Alguien debe estar designado para ello y soportar esa cruz, o enseguida tendremos conocimiento disperso y obsoleto.
Canales mal definidos hacen que el chat de grupo se convierta en ventanilla de Service Desk cuando no debe serlo. Automatizaciones hechas de cualquier manera disparan errores a velocidad luz y workflows complejos se olvidan, quedando muchos casos varados para siempre en una playa perdida.
En ese museo de los horrores también hemos visto a menudo SLA irreales porque el vendedor nos vendió a nosotros además de a la herramienta. Y para rematar, falta de integración con monitorización o inventario, duplicando el trabajo de cada caso que llega a ventanilla.
La clave a entender es que todo esto nace del mismo manantial: un mal diseño inicial del Service Desk.
Por eso este epígrafe es el reverso tenebroso del anterior sobre buenas prácticas.

Qué valorar en un software de Service Desk

Seamos honestos, hacer un ranking de opciones no tiene mucho sentido. Cada organización es un mundo y, si queremos evitar el campo de minas anterior, debemos diseñar el proceso adecuado para nosotros y luego elegir el software que mejor se adapta a él.
No el más caro, ni el de más lucecitas o el número 1 en una lista web llena de enlaces de afiliados.
Nos toca examinar a fondo y nuestra lupa debe enfocarse en:

• Ciclos de vida diferenciados a la hora de gestionar incidencias y solicitudes. Ventanilla única sí, cauce posterior único no.
• Ticketing flexible y personalizable a cómo trabajamos.
• Buen seguimiento de SLA, con capacidad de gestionar horarios y notificaciones para cuando no vamos bien.
• Portal y base de conocimiento que no sean un añadido de última hora porque la competencia también los tiene.
• Capacidad de automatizaciones y workflows.
• Informes robustos y dashboards útiles adaptados a nuestra forma de trabajar.
• Evaluación por parte de los usuarios, con encuestas, calificación de interacciones…
• Integración y API, también con conexión a inventario para ver con qué activos están conectados los casos, porque otra isla remota en nuestra infraestructura IT nos descarrilará.
• Buenos permisos, roles y auditoría, especialmente si trabajamos con varias entidades y clientes.
• Capacidad de escalar para no tener que multiplicar recursos cuando multipliquemos usuarios.

La realidad es que muchas herramientas marcan bien estas casillas y las demos siempre son preciosas, pero la diferencia la marca probar con nuestro flujo de trabajo.

Cómo encaja Pandora ITSM con Service Desk

«El primer deber de todo oficial de la Flota Estelar es hacia la verdad», le dice el capitán Picard a Wesley Crusher. Ética que parece para otros tiempos, pero nada más lejos.
En Pandora tenemos nuestro propio enfoque de Service Desk a través de Pandora ITSM aplicando esas buenas prácticas que he comentado y esquivando las minas habituales. Pero no decimos que sea el «mejor», por ese deber hacia la verdad.
Creemos que lo es para muchos, claro, pero te invitamos a probarlo y probarnos, por si la llave de nuestro enfoque encaja en la cerradura de tus procesos de trabajo.
Pandora ITSM aborda la ayuda al usuario como parte de una plataforma de gestión de servicios IT más amplia y alineada con procesos ITIL.
Así, la gestión de incidencias se realiza mediante la creación de tickets a través de web o correo. Después, su seguimiento muestra tiempos de respuesta y solución, workflows personalizados con reglas, escalado a varios niveles y notificaciones por evento.
A eso se une la capacidad de gestionar diversas entidades con la misma herramienta y un sistema de roles robusto.
Además, tiene portal de autoservicio, una wiki y base de conocimiento, junto a un sistema integrado de satisfacción del cliente.
Como gestionar a ciegas es imposible, también se pueden configurar informes personalizados con SQL y envío periódico.
Y por supuesto, implementamos IA, con chatbot y smart ticketing para descargar peso en la primera línea de batalla, resolviendo lo sencillo cuando es posible.
Pero lo que nos diferencia es hacer caso a Hemingway, que dijo que no somos islas.
Yo no sé si las personas lo somos o no, pero IT jamás debe convertirse en una, de ahí nuestra integración nativa con Pandora FMS, para que toda la operación funcione como un reloj y no como muchos con horas diferentes.
Inventario de activos o monitorización de los mismos quedan vinculados al ITSM, terminando con el festival de clics y pestañas para averiguar qué máquina ha causado el ticket de: «Esto va lento».
Eso sí, volviendo a la verdad y el deber. Si tu equipo son dos personas y veinte casos al mes, nuestra solución es desproporcionada y mejor que examines otras opciones.
Sí, en serio.
Y si lo que lees suena bien, recuerda lo que decía más arriba y tampoco nos compres. Pruébanos primero con tu flujo de trabajo, que para eso nuestra trial tiene las prestaciones completas y un tiempo generoso.
Porque, al final, en Pandora no somos más que un puñado de fans de Star Trek.

Preguntas frecuentes sobre el Service Desk

Recapitulemos viendo lo anterior desde otra perspectiva, la de las preguntas frecuentes.

¿Qué es un Service Desk?

Un Service Desk es una «ventanilla única», el punto central de contacto entre usuarios y servicios IT, para gestionar todo desde el mismo sitio.
Así, al Service Desk le llegan incidencias, solicitudes y/o consultas relacionadas con tecnología. Luego las registra y clasifica, para resolverlas adecuadamente.
Importante destacar que el término Service Desk sirve para designar esa función de gestión unificada, al equipo que la realiza y a las herramientas y software que utiliza para ello.

¿Para qué sirve un Service Desk?

Para centralizar la relación entre los usuarios y el servicio IT. Así no se depende del canal por el que entró la petición, de que el usuario sepa dónde dirigirse o la memoria del técnico de turno.
Todo se registra, clasifica, prioriza y resuelve desde un mismo punto, comunicando cómo va la petición y controlando los SLA y la prestación de servicio en general.

¿Cómo funciona un Service Desk?

Este es el flujo típico. Un usuario tiene una petición o incidencia, la envía por los canales habilitados, llega al mismo sitio centralizado donde se prioriza y asigna a quien corresponda. Luego, procede a la resolución informando al usuario, documenta lo hecho y cierra el caso.

¿Qué significa SPOC en un Service Desk?

SPOC (Single Point of Contact) no es el primo de Spock, sino el punto único de contacto del Service Desk. Es decir, la puerta de entrada para toda necesidad IT, sea del tipo que sea.
Enviar al lugar correcto una vez cruzado ese SPOC es tarea del Service Desk.

¿Cuál es la diferencia entre Service Desk y Helpdesk?

Que Helpdesk se centra sobre todo en resolver incidencias y peticiones de soporte, pero Service Desk es más amplio, abarcando, por ejemplo: aprobaciones, control de SLA, catálogo…
La frontera es borrosa en el día a día, no lo negaré y, aunque no son lo mismo, no pocas organizaciones usan los términos como si fueran intercambiables.
Pero no lo son.

¿Cuál es la diferencia entre Service Desk y Ticketing?

Que Service Desk es la función, el servicio, como dice su nombre, mientras que ticketing es el mecanismo por el que desarrolla dicho servicio.
El registro y asignación de casos se hace mediante tickets, que se cierran una vez resueltos.

¿Cuál es la diferencia entre Service Desk e ITSM?

Que Service Desk es una parte de ITSM, la que se encarga de relaciones con usuarios y sus peticiones de todo tipo.
Sin embargo, ITSM es la gestión IT amplia, de modo que abarca Service Desk y más cosas que no tienen que ver con el usuario, como estrategia tecnológica, procesos, seguridad…

¿Qué gestiona un Service Desk?

Aunque son peticiones de todo tipo, como posibles cambios de permisos, altas, asignaciones de equipos al usuario… la mayoría de veces serán incidencias (de ahí que a veces se confunda o solape con el término Help Desk).
También actúa como detector de problemas, que deriva a quien los investiga.

¿Qué funciones tiene un software de Service Desk?

Multitud, entre las que destacan: gestión de solicitudes de usuario, incidencias, ticketing con categorización, prioridad y asignación, control de SLA, escalado de casos si no se resuelven, workflows y aprobaciones.
También mantiene el portal de autoservicio, la base de conocimiento, encuestas de satisfacción, implementa automatización, informes y dashboards.
Por último, mantiene registro de auditoría y se encarga de API e integraciones, además de inventario o CMDB.

¿Qué métricas utiliza un Service Desk?

De nuevo son multitud, pero dependen de la organización y lo que sea prioritario controlar en ella.
No obstante, casi todos comparten: tiempo hasta la primera respuesta, tiempo de resolución, el cumplimiento de SLA, tamaño del backlog, tasa de reaperturas, el CSAT y el volumen por categoría.
Eso sí, no hay métrica aislada que represente bien la calidad del servicio y por eso se interpretan en conjunto.

¿Qué es shift-left en un Service Desk?

La filosofía de desplazar la resolución de casos hacia el punto de solución que esté más cerca del usuario.
Del especialista vamos al nivel 1, de ese nivel a la información publicada en la base de conocimiento y de ahí a la automatización.
Eso sí, se aplica cuando el caso lo permita, pero no por sistema.

¿Cómo se utiliza la IA en un Service Desk?

De varias formas, tratando de levantar el peso de las tareas más mecánicas o pesadas, como clasificar, asignar casos y definir prioridades según el contenido de la petición.
También puede buscar en la base de conocimiento y chivarle al oído respuestas al técnico implicado.
Del mismo modo, ejecuta workflows y escalados. De cara al usuario, puede atender solicitudes habituales sencillas.
Eso sí, no elimina la necesidad de «humanos en el bucle», ese término tan de moda.

¿Qué relación existe entre Service Desk e ITIL?

En la versión ITIL 4, el Service Desk es una práctica con identidad propia y certificación específica dentro del esquema PeopleCert.
Ahí aparece agrupado dentro del módulo Specialist: Monitor, Support and Fulfil junto a:

• Incident Management.
• Service Request Management.
• Monitoring and Event Management.
• Problem Management.
• Problem Management.