Reducir horas de soporte en un MSP sin perder SLA: rediseño operativo y automatización

¿Se puede cuadrar el círculo? ¿Es posible reducir horas en un proveedor de servicios gestionados (MSP) sin degradar los acuerdos de servicio con los clientes (SLA)? Sí, pero comienza por aceptar una verdad incómoda que solemos ignorar, a ver si así se va: Que la mayoría de MSP no escalan, engordan.
La canción la conocemos, conseguimos clientes nuevos y, para mantener los SLA del contrato engordamos en personal y licencias de herramientas. Es una ecuación lineal que aceptamos como dogma de fe: Si captamos 10 clientes, necesitamos X técnicos más y Z licencias adicionales.
Pero eso no mejora nuestros márgenes de beneficio, de hecho, los empeora, más temprano que tarde, mientras quemamos la mecha de nuestra vela. O mejor dicho, a nuestro talento técnico.
Pero en vez de engordar, gracias a la tecnología actual, podemos optimizar, quemar grasa y añadir músculo para hacer más con menos.
Eso sí, el primer mandamiento es que reducir las horas de soporte en un MSP nunca consiste en recortar calidad, ni dejar al cliente escuchando música de espera otro minuto adicional.
La esencia es mucho más fundamental: Admitir que el problema no es el volumen de tickets que nos llega al techo, sino el diseño operativo defectuoso, que permite que esos tickets existan en primer lugar… y crezcan sin medida.
Si soporte pasa el 80 % del tiempo reaccionando a incidencias ya sucedidas, en lugar de anticiparse a las que ocurrirán, no gestionamos infraestructuras, sino pánico. Un mal modelo de negocio.

Por qué la carga de soporte limita la escalabilidad del MSP

El cliente paga a un MSP para que «las cosas funcionen» y la tecnología le ayude, en lugar de obstaculizar. Pero la ecuación lineal de antes no se puede aplicar a las personas y el caos diario, como no se puede aplicar a un modelo de negocio.
Así que esa carga de soporte va envenenando al MSP de 3 formas principales:

• Reduciendo el margen operativo: Cada hora que un ingeniero senior dedica a tareas repetitivas, o a apagar fuegos evitables en lugar de implementar mejoras proactivas, es una hora que se come nuestra rentabilidad.
• Rotación por burnout: A los mejores les gustan los retos, no vivir el Día de la Marmota. Si la jornada está hecha de reiniciar servicios, limpiar discos al 99 % y explicarle a «ese» usuario cómo configurar la VPN otra vez, se irán donde puedan construir cosas, no solo repararlas. Y reemplazar a un técnico que conoce la infraestructura de nuestros clientes sale mucho más caro que mantenerlo.
• Riesgo de incumplimiento del SLA: Cuantos más tickets gestionemos a mano, más riesgo corremos de incumplir el Service Level Agreement, porque de nuevo las ecuaciones lineales no sirven aquí. El volumen satura la capacidad de atención y la calidad de respuesta, los tiempos de resolución se alargan y, de pronto, un incidente crítico se pierde en la marea de alertas irrelevantes, porque llevamos cuatro horas con la vista en la pantalla, pero la cabeza en Bali.

Dónde se va el tiempo: anatomía del soporte reactivo

Cualquier acción duradera e importante debe ser estratégica, incluyendo reducir tiempos de soporte como MSP. Así que, antes aplicar RPA a ciegas o instalar un modelo de lenguaje que nadie usará (y tampoco encaja en nuestro flujo de trabajo), toda acción estratégica debe comenzar por un análisis de lo que está ocurriendo.
Lo contrario pondrá vendas donde no hay herida, dejando otras cada vez más abiertas.
Ese análisis no debe ser superficial, porque si no, la conclusión siempre será «falta de tiempo» cuando quizá es «falta de filtro». O que en lugar de prevenir nos pasemos los días reaccionando… Y esa no es manera de vivir.
En el colegio probablemente nos dijeron que éramos especiales y todo eso, pero cuando analicemos nuestras operaciones, encontraremos ciertos sospechosos habituales que se repiten en casi todo MSP desbordado por el volumen de soporte.

Demasiadas alertas, que son malas para el corazón

El tiempo en un MSP se escapa por las costuras de un sistema mal diseñado, y el primer culpable suelen ser alertas pobremente definidas.
No hay nada más destructivo para la productividad que el ruido. Si nuestro sistema de monitoreo envía una alerta crítica cada vez que una CPU llega al 90 % durante dos segundos, nuestros técnicos aprenden a ignorar el panel. Es el cuento de Pedro y el Lobo versión IT y, cuando llega el fallo real, nadie está mirando.
Este suele ser uno de los elementos comunes a optimizar, pero no el único.

Las cosas a mano no son mejores

El segundo sumidero de horas que podemos taponar son los diagnósticos y tareas manuales de bajo valor.
Así, entra un ticket típico de usuario: «El servidor va lento», sin más.
El técnico se conecta entonces por escritorio remoto, abre el administrador de tareas, revisa los logs, mira el espacio en disco… Han pasado veinte minutos solo para saber qué pasa.
Ahora multipliquemos eso por cincuenta tickets al día… Aquí es donde un buen Modelo de Lenguaje y scripts estratégicos pueden ayudar, pero no nos anticipemos.

Procesos diferentes según la persona

La ausencia de estandarización suele ser otro factor en nuestra experiencia, con procesos y buenas prácticas poco (o nada) definidas.
Así, en muchos MSP la solución a un problema depende de quién coja el teléfono. Si es Laura, lo soluciona en cinco minutos con un script que se hizo ella y no quiere compartir. Si lo coge Javier, tarda media hora a mano, porque no sabe priorizar ni tiene un flujo de acción óptimo que consultar en la base de conocimiento.
Esa sabiduría tribal, no aglutinada en ninguna parte ni estandarizada, es ineficiente y poco rentable.

SLA ≠ urgencia permanente

Cuando se trata de reducir horas de soporte, hay otro tema importante que no pasa solamente por fustigarnos debido a nuestra falta de eficiencia, sino por fustigar también un poco al cliente.
Aquí entra la pedagogía, tanto interna como con el usuario de nuestro servicio.
El pobre Javier tarda media hora a mano y, además, no prioriza porque, como siempre, se confunde lo urgente con lo importante.
Pero el cliente también hace eso y viviremos con demasiado estrés si equiparamos el SLA (un contrato legal sobre disponibilidad y tiempos de respuesta) con la urgencia subjetiva del usuario.
No todo es prioritario y, si todo es urgente, nada lo es.
Está claro que el cliente siempre percibirá su problema como el fin del mundo, pero un MSP maduro debe tener la capacidad para distinguir entre la criticidad técnica y la urgencia percibida.
Un servidor de email caído es crítico, pero que a un usuario no le cargue la firma del correo es molesto, pero no debería despertar a nadie a las tres de la mañana.
Aquí viene la clave, para reducir horas habremos de hacer un rediseño operativo. Este implica configurar nuestras herramientas para que esa distinción entre urgente e importante sea automática, sin depender de que el terapeuta de Javier le enseñe por fin a decir que no.
Del mismo modo, los SLA se cumplen garantizando disponibilidad y resolviendo enseguida lo importante, no respondiendo cada correo en tres minutos para decir: «Lo estamos mirando».
La inmediatez vacía no aporta valor, la resolución efectiva, sí.
Vale, ya conocemos qué nos encontraremos muchas veces en nuestro análisis y qué principio fundamental nos debe guiar. Vayamos ahora con el cómo, detallando ese rediseño que reduzca horas de soporte en el MSP.

Diseño de un modelo operativo con menor carga reactiva

Para escapar de la rueda de hámster y reducir horas de soporte hemos de cambiar el enfoque, dejar de ser bomberos para convertirnos en arquitectos que construyan un edificio ignífugo.
Este se debe levantar sobre tres pilares técnicos:

• Monitorización proactiva real.
• Automatización inteligente.
• Estandarización.

Que coincide con el antídoto a muchos de esos sospechosos habituales anteriores.

Monitorización proactiva basada en condiciones técnicas reales

Olvidémonos de monitorizar si el servidor «hace ping», eso es volver a los 90. La monitorización proactiva real implica observar tendencias y comportamientos.
No queremos que el sistema de monitorización avise cuando el disco está lleno, queremos que lo haga cuando, basándose en el ritmo de crecimiento de los últimos meses, prevea que se llenará en 48 horas. Esa capacidad de predicción permite planificar la solución, no correr para aplicarla.
Así, debemos tener una herramienta que sea capaz de lo anterior, así como de configurar umbrales inteligentes y alertas personalizadas para cada infraestructura. Como Pandora FMS e ITSM, pero de nuevo, no nos anticipemos.
Un pico de memoria puede ser normal en un proceso de backup, no precisamos una alerta ahí. Pero si el servicio web deja de responder transacciones, aunque el servidor diga que está online, eso sí debe dar la alarma.
Hay que medir la experiencia real, no solamente bits, metal y procesos ciegos.

Automatización con impacto medible y controlado

La automatización es la única forma de escalar de manera consistente, punto.
Pero no hablo de grandes proyectos de orquestación complejos, sino de automatizar esos mil pequeños cortes de bajo valor que nos desangran.
¿Cómo? Con herramientas como:

• Modelos de lenguaje e IA: Adaptados al proceso y probadas a fondo. Por ejemplo, aplicándolos en la primera línea de soporte, de modo que ese LLM pueda dar las respuestas más sencillas al usuario sin intervención humana o discrimine la gravedad del problema y el responsable al que escalar de manera inteligente el ticket.
• Autocuración (Self-healing): Si sabemos que cuando el servicio de cola de impresión se atasca, la solución es reiniciarlo, ¿por qué lo hace un humano? El sistema de monitorización debe detectar el atasco, reiniciar el servicio, verificar que funciona y cerrar la incidencia. Así, el cliente no se entera, el técnico no pierde tiempo y el SLA se mantiene inmaculado.
• Despliegues y parches: Hacer esto a mano hoy debería estar tipificado como delito, pero ojo a backups y procesos de reversión al punto anterior en caso de problemas. Soy un pesado, pero las automatizaciones no deben ser ciegas.
• Limpieza: Con scripts recurrentes que borren archivos temporales, vacíen papeleras y roten logs sin necesidad de que el CTO esté haciendo de conserje.

Estandarización de respuestas y reutilización de conocimiento

Si tenemos clientes con infraestructuras similares (y deberíamos intentar que así fuera para ayudarnos a escalar y reducir cargas de soporte como MSP), lo que aprendemos en uno se aplica al otro.
La estandarización implica que las configuraciones de alertas, los scripts de respuesta y los procedimientos sean plantillas reutilizables en la medida de lo posible.
No hay premios a reinventar la rueda y deberíamos aspirar a desplegar nuestro propio: «Paquete estándar de monitorización y automatización™», para luego afinarlo y personalizarlo según las características del cliente.
Del mismo modo, el conocimiento interno en el MSP debería ser común para todos y no estar aislado en silos, dependiendo así de la sabiduría particular del técnico que toque.
Esto implica bases de conocimiento de fácil acceso, comunes y actualizadas. De hecho, aquí podría ser útil otro modelo de lenguaje, un agente entrenado o, al menos, afinado (con un buen fine-tuning) con nuestra base de conocimiento, manuales técnicos de nuestras herramientas de soporte y monitorización, etc.
Por supuesto, esto no sustituye a otro elemento clave: Una buena formación interna en procesos y conocimiento.
Con todo esto, reduciremos la curva de aprendizaje de nuestros técnicos, asegurando una calidad homogénea.

Cómo medir la reducción de soporte sin degradar los SLA

Voy a ser lo que más odio, un tópico, pero lo de que no se puede mejorar lo que no se puede medir es cierto.
Ahora, el enemigo aquí son las métricas de vanidad.
Si queremos cuantificar realmente reducciones de carga de soporte en el MSP y otras mejoras, necesitamos comparar el antes y el después con KPIs honestos como:

• Volumen de tickets reactivos por endpoint: Esta es la clave. ¿Cuántos tickets genera cada dispositivo al mes? Si bajamos de 0.5 a 0.2, vamos ganando.
• Ruido de alertas: Cuántas alertas se generan vs. cuántas requieren acción real. Aquí buscamos minimizar el ratio de falsos positivos.
• MTTR (Mean Time To Resolution): El clásico intemporal en este negocio. Este tiempo debería disminuir siempre y la automatización es clave. Un script tarda segundos en arreglar lo que un humano tarda minutos.
• Carga por técnico: ¿Cuántos endpoints o clientes puede gestionar un técnico sin perder la cordura como en La llamada de Cthulhu? Si aumentamos este número manteniendo la satisfacción del cliente, escalamos sin engordar.
• Cumplimiento contractual: La vara de medir que no debe alterarse nunca, por mucho que mejoremos los indicadores anteriores.

Caso aplicado en entornos MSP con Pandora FMS

Es obvio que hoy, las herramientas marcan la diferencia para obtener el grial de escalar a la vez que reducimos carga de soporte en nuestro MSP.
En Pandora nos encontramos a menudo con clientes que tienen mil herramientas haciendo la guerra por su cuenta (un monitor de redes, otro de servidores, otro para logs y, por supuesto, el incombustible Excel), en lugar de un solo cerebro unificado que no solo aglutine, sino que sea capaz de pensar con esos datos y ayudarnos a gestionar.
Pandora FMS se diseñó entendiendo (y sufriendo) este dolor del proveedor de servicios.
Por eso, levanta la carga de soporte en un MSP mediante:

Reducción de tickets reactivos gracias a alertas inteligentes

Obviamente, la solución técnica se adapta a esas mejores prácticas definidas antes. Así, con Pandora FMS la monitorización es realmente inteligente gracias a la correlación de eventos.
Ejemplo: Si el servidor A pierde conexión, pero el B y el C (que están en el mismo switch) también, no me mandes tres alertas de servidor caído, sino una de switch caído.
Esto limpia la bandeja de entrada y va aún más allá, gracias a la capacidad de predicción de Pandora, que permite actuar en muchos puntos antes de que el SLA se vea comprometido.

Segmentación multicliente con trazabilidad total

Diferenciar entre clientes a los que damos soporte y entre los usuarios dentro de esos clientes, con sus permisos correspondientes de acceso, es una buena práctica integrada en el corazón de Pandora.
La gestión de tickets con filtros por empresa, usuarios dentro de esas empresas y permisos granulares (para definir quién puede acceder al cliente o al conocimiento) es una de las claves en Pandora ITSM.
Lo mismo se aplica a informes, con flexibilidad y personalización total, también para la creación de dashboards que permitan tener los paneles de control que precisemos para saber cómo va la cosa de un vistazo, en lugar de estar buceando entre logs de mil clientes.

Automatización de tickets, monitorización con IA y capacidad de predicción

Pandora FMS es capaz de realizar monitorización predictiva gracias a su motor MADE, indispensable para reducir carga de soporte en un MSP.
Pero no solo eso, en Pandora ITSM encontramos esa automatización en el uso de Chatbots e IA aplicados tanto a soporte, como a las bases de conocimiento, con modelos de lenguaje e inteligencia artificial conversacional basada en conocimiento específico sobre procesos, herramientas en infraestructuras de clientes, no solamente en lo que dijo un tipo en Reddit.
Los mejores procesos y, sobre todo, tecnología que los implemente, como la de Pandora FMS y Pandora ITSM son lo único que conseguirá el aparente milagro de hacer más con menos y que la vida de nuestros técnicos y nuestro negocio sea larga y próspera.
Si logramos que esos técnicos se aburran por no tener incidencias triviales, habremos ganado. Porque entonces se dedicarán a lo importante: ayudar a nuestros clientes a usar la tecnología para crecer, no solo para que no se les apague la pantalla.
Ahí está el margen, tanto el de mejora, como el económico.