Qué es un service desk y en qué se diferencia de un help desk

Service desk es el punto único de contacto entre los usuarios y el área de TI, responsable de registrar, priorizar y resolver solicitudes e incidentes dentro de plazos acordados. A diferencia del help desk, que atiende el pedido puntual, el service desk gestiona el catálogo de servicios completo, con procesos, indicadores y responsables.

Cuando una empresa crece, el área de TI suele recorrer el mismo camino. Primero hay una persona que «sabe de computadoras»; después, un correo compartido o un grupo de chat donde llegan los pedidos; luego, un help desk con algún sistema de tickets. Y en algún momento aparece la pregunta: ¿hace falta un service desk?

La diferencia entre los dos términos no es de tamaño ni de presupuesto, sino de alcance: qué se gestiona, con qué procesos y cómo se mide el resultado. En este artículo explicamos en qué se diferencian, qué hace un service desk en el día a día, cuáles son las señales de que el help desk ya no alcanza y cómo define ITIL esta práctica.

Service desk y help desk: tabla comparativa

Los dos términos se usan muchas veces como sinónimos, y la traducción también cambia según el país: en Colombia se habla más de mesa de ayuda, y en México de mesa de servicios cuando el alcance es más amplio. La tabla resume las diferencias que importan a la hora de decidir.

Dicho de forma simple: el help desk apaga incendios; el service desk organiza la relación entre TI y el resto de la empresa para que haya menos incendios y, cuando ocurran, todos sepan quién los atiende y en qué plazo.

Un help desk no es una versión «peor» del service desk. Muchas organizaciones lo necesitan exactamente así, y agregar procesos sin el volumen que los justifique solo suma burocracia. La pregunta correcta no es cuál es mejor, sino cuál corresponde al momento de la empresa.

Qué gestiona un service desk en el día a día

El trabajo diario de un service desk se organiza alrededor de unas pocas prácticas. No todas tienen que estar maduras desde el primer día, pero conviene conocerlas para ordenar la implementación.

Incidentes. Cualquier interrupción o degradación de un servicio: el ERP que no responde, una impresora de planta fuera de línea, la VPN que se corta. El service desk registra el incidente, lo clasifica, le asigna prioridad según impacto y urgencia, y lo resuelve o lo deriva al grupo que corresponde. El objetivo es restablecer el servicio lo antes posible, no necesariamente encontrar la causa de fondo.

Solicitudes de servicio. Pedidos que no son fallas: el alta de un usuario nuevo, el acceso a una carpeta, una licencia de software, el equipo para quien ingresa el lunes. Son predecibles y repetibles, por eso conviene publicarlas en un catálogo con formularios, aprobaciones y plazos conocidos.

Problemas. Cuando el mismo incidente se repite, el service desk lo detecta y abre un problema para que el equipo técnico investigue la causa raíz. Sin este paso, la mesa resuelve diez veces la misma falla y nadie la elimina.

Cambios. El service desk no siempre ejecuta los cambios, pero sí comunica a los usuarios las ventanas de mantenimiento y registra los pedidos que terminan en un cambio. Así evita que una actualización planificada se viva como un incidente.

Conocimiento. Cada ticket resuelto puede alimentar un artículo de la base de conocimiento, para los técnicos o para el portal de autoservicio. Es lo que permite que la resolución en primer contacto mejore con el tiempo y que algunos pedidos ni siquiera lleguen a la mesa.

Niveles de servicio. El service desk mide los tiempos de respuesta y de resolución contra lo acordado, avisa antes de que un plazo venza y reporta el cumplimiento a las áreas de negocio. Sin SLA, el service desk no tiene contra qué medirse.

Comunicación con el usuario. Confirmar que el pedido llegó, informar el avance, avisar el cierre y preguntar si quedó resuelto. Parece un detalle, pero es la diferencia entre un usuario que espera tranquilo y otro que llama cada media hora.

Para sostener todo esto hace falta una herramienta que reúna los canales (correo, portal, teléfono, chat) en un solo registro, con reglas de asignación, plazos y reportes. Esa es la base de cualquier plataforma de gestión de servicios de TI.

Cuándo el help desk deja de alcanzar

No hay un número mágico de tickets ni de empleados que marque el cambio. Lo que sí aparece son señales que se repiten. Si reconoces tres o más en tu organización, probablemente sea momento de pensar en un service desk:

• Los pedidos llegan por demasiados canales (correo, teléfono, chat, pasillo) y algunos se pierden.
• Nadie puede decir con datos cuánto tarda TI en resolver; solo hay impresiones.
• Las mismas fallas vuelven cada semana y nadie tiene la tarea de eliminarlas.
• Hay varias áreas resolutoras (infraestructura, aplicaciones, redes, proveedores externos) y los tickets rebotan entre ellas.
• El negocio pide compromisos de plazo, o un cliente los exige por contrato.
• Una auditoría o una certificación pide evidencia de cómo se gestionan los incidentes y los cambios.
• Las altas y bajas de personal dependen de que alguien se acuerde de pedir o quitar los accesos.
• La dirección pregunta en qué se va el tiempo de TI y no hay un reporte para mostrar.

El paso de help desk a service desk no tiene que ser de golpe. Un camino habitual es empezar por reunir los canales en un único sistema de tickets, definir prioridades y plazos para los incidentes y publicar un catálogo corto con las cinco o diez solicitudes más frecuentes. Recién después se suman la gestión de problemas, la de cambios y una CMDB que registre los activos y sus relaciones.

Lo que no funciona es lo contrario: comprar una plataforma completa, configurar todos los procesos a la vez y esperar que el equipo los adopte. El service desk se construye sobre hábitos, y los hábitos se instalan de a uno.

También conviene definir desde el inicio quién es el responsable del service desk. No hace falta un área nueva: en muchas empresas medianas es un coordinador que, además de resolver, revisa cada semana los tickets vencidos, las fallas repetidas y los pedidos que no tienen dueño. Sin esa figura, los procesos quedan escritos pero nadie los sostiene, y el equipo vuelve en pocos meses a trabajar como un help desk.

Cómo lo define ITIL

ITIL, el marco de buenas prácticas de gestión de servicios de TI más difundido, trata al service desk como una práctica de gestión de servicios y como el punto único de contacto entre el proveedor de servicios y sus usuarios. En ITIL 4, su propósito es captar la demanda de resolución de incidentes y de solicitudes de servicio, y ser el canal de entrada y de comunicación con todos los usuarios.

Tres ideas de ITIL ayudan a entender por qué el service desk es más que una mesa de ayuda:

1. Punto único de contacto. El usuario no tiene que saber a qué equipo técnico le corresponde su problema. Lo informa en un solo lugar, y el service desk se encarga de que llegue a quien lo resuelve.
2. Foco en el valor, no en el ticket. ITIL 4 pone el acento en la experiencia del usuario y en el resultado para el negocio. Cerrar rápido un ticket que se reabre al día siguiente no suma.
3. Integración con otras prácticas. El service desk se apoya en la gestión de incidentes, de solicitudes, de problemas, de cambios, de niveles de servicio y de conocimiento. Por eso la herramienta que lo soporta necesita conectar esos procesos entre sí.

La norma ISO/IEC 20000-1, que certifica sistemas de gestión de servicios, no exige un área llamada service desk, pero sí pide procesos documentados para incidentes, solicitudes, cambios y niveles de servicio. En la práctica, un service desk bien implementado es la forma más directa de cumplirlos.

Para ponerlo en marcha, la herramienta necesita como mínimo un sistema de tickets con varios canales de entrada, colas por equipo, prioridades y SLA configurables, un portal de autoservicio con catálogo, base de conocimiento y reportes. A medida que madura, suma gestión de cambios, CMDB y automatizaciones. OTRS es una de las plataformas de gestión de servicios pensadas para este fin, con procesos alineados a ITIL. En Aufiero acompañamos a equipos de TI de Latinoamérica en la elección, la licencia y la puesta en marcha: conoce más en la página de OTRS.

Preguntas frecuentes