Evitar que el soporte reactivo consuma el margen del MSP

El margen de beneficio en un Managed Service Provider (MSP) es un animal delicado. No suele esfumarse por un gran desastre, una brecha de seguridad o perder a ese cliente importante, sino que suele morir por mil cortes invisibles que lo van desangrando sin remedio. Una erosión constante que suele estar provocada por un soporte reactivo que, si no se vigila, convierte un negocio que podría ser escalable en una odisea para salvar el Titanic.
Para ello, los directores de operaciones y CTOs se centran a menudo en el volumen: «Tenemos demasiados tickets» suele ser el soniquete en las reuniones, pero el volumen es el síntoma. El problema que se esconde tras eso y se enciende los puros con nuestros billetes, es la variabilidad incontrolada y la normalización del caos en el día a día.
Si nuestro equipo hace cada uno la guerra por su cuenta y pasa las jornadas achicando agua, nadie tiene tiempo de arreglar las grietas del casco.
Y en la gestión IT, la entropía siempre tiene las de ganar, así que analicemos el tema a fondo para conocer las mejores prácticas que mantengan márgenes de beneficio sanos en nuestro MSP.

Qué significa realmente el «soporte reactivo» en un MSP

Para proteger nuestros márgenes, primero debemos hacer caso a Sun Tzu y su Arte de la guerra y conocer al enemigo, desarrollando una estrategia general contra él antes de lanzarnos con tácticas y técnicas.
El soporte reactivo se encarna sobre todo en tres jinetes del apocalipsis operativo:

• Incidencias reales con impacto: Como el servidor que decide dejar de respirar a las tres de la mañana o la base de datos que se corrompe. Estos problemas son inevitables porque así es la vida en IT, pero su frecuencia y duración determinan nuestra supervivencia.
• El ruido de fondo: Que es información que molesta en lugar de ayudar, como alertas mal diseñadas, sin contexto o directamente inútiles. Es el equivalente a que el ordenador de la Enterprise active la alerta roja cada vez que detecta una nave. Si todo es crítico, nada lo es y el tiempo de los técnicos se consume descartando basura.
• Peticiones de usuario disfrazadas de incidentes: «No me funciona el correo» suele traducirse en «he olvidado la contraseña por cuarta vez». Tratar estas incidencias con el mismo flujo de trabajo que una caída de red es un suicidio económico.

Si no gestionamos óptimamente estas categorías, será imposible detener la sangría de nuestros márgenes. Estaremos lanzando horas de técnicos senior a reinicios o recuperaciones de contraseñas, y esa es la forma más rápida de que las cuentas dejen de cuadrar.

Dónde se va el margen: la mecánica económica del desastre

Sigamos analizando al adversario, haciendo zoom ahora desde lo general a aspectos concretos sobre los que tendremos que actuar.
El margen no desaparece por arte de magia, se consume en procesos físicos y cognitivos que rara vez aparecen en los informes mensuales si no sabemos buscarlos.
Algunos de estos procesos habituales en un MSP son:

1. Horas no planificadas y el desplazamiento del valor

Cada vez que un técnico debe abandonar una tarea de mejora o un despliegue planificado para atender un fuego reactivo, el coste no es solo la hora pagada por eso y debemos metérnoslo en la cabeza para cuantificar bien las pérdidas.
Como gestores, también hemos de considerar el coste de oportunidad, concepto económico que me trae flashes de Vietnam y de las viejas clases de mi primera carrera.
Esto significa que las cosas no solamente cuestan lo que pagamos a nuestros técnicos del MSP, sino también lo que estamos dejando de ingresar o el ahorro que tendríamos si, en lugar de ser bomberos, dichos técnicos estuvieran construyendo una infraestructura proactiva y predictiva (que evitaría muchas de esas incidencias en primer lugar).
Esa manera de trabajar ahorra miles de euros al mes en incidencias que no llegan a producirse, además de proporcionar ganancias de productividad y, por tanto, márgenes cada vez más amplios.
Pero si nuestro MSP se parece a ese parque de bomberos, el trabajo productivo se desplaza, los plazos se estiran y la eficiencia operativa se desploma.

2. La senioridad mal asignada

Este es el pecado original de muchos MSP, usar el Ferrari para ir a Mercadona. O dicho de otro modo, ingenieros L3 (caros, escasos y con una capacidad estratégica importante) que pasan sus días resolviendo incidencias que deberían estar automatizadas o gestionadas por «el becario» y una buena base de conocimiento.
Cada vez que un senior hace un trabajo de un junior, el margen de ese contrato se evapora.

3. El veneno del context switching

Un técnico que salta entre diez clientes distintos y cinco tipos de tecnologías en una mañana no está siendo productivo, solo tratando de que su cabeza no explote.
Multipliquemos eso por el número de tickets reactivos y localizaremos otro sumidero importante por el que se nos va el margen.

4. El «re-trabajo» por ausencia de estándares

Si cada cliente es un «copo de nieve especial» con su propia configuración artesanal y scripts personalizados, el soporte reactivo se vuelve exponencialmente caro.
Sin estándares robustos, cada diagnóstico es un proceso de investigación desde cero y ese «re-trabajo» es la antítesis de la rentabilidad.

Las principales señales de que el soporte está devorando nuestra rentabilidad

Yo soy el primero que no reconoce sus problemas y todos los humanos tenemos ese punto ciego, pero cuando se trata de perder margen de beneficio en el MSP tenemos la suerte de poder detectarlos sin tener que esperar el informe trimestral.
Algunos síntomas demasiado habituales son:

• Tickets repetitivos sin análisis de su causa raíz: Si el mismo error en el mismo cliente aparece tres veces por semana y la solución es siempre «reiniciar el servicio», no estamos dando soporte, sino siendo un parche humano.
• Picos de carga impredecibles: Si el lunes tenemos la caldera a punto de reventar y el jueves cruzan por el servidor esos matojos rodantes de las pelis de vaqueros, nuestra capacidad de planificación es nula. La variabilidad es el enemigo de la escala.
• Modo urgencia permanente: Si el cortisol del equipo está siempre rebosando, la moral cae y la rotación aumenta. El coste de reclutamiento y onboarding de un nuevo técnico es un golpe bajo al margen que pocos cuentan en sus hojas de cálculo.

El patrón más peligroso: El SLA cumplido con sobreesfuerzo

Este es el espejismo que engaña a muchos gerentes. Miran los informes y ven que los SLA de respuesta y resolución están en verde. Todo parece ir bien y el cliente está contento.
Sin embargo, si ese cumplimiento se logra con horas extras no facturables, estrés crónico y seniors haciendo guardia para atajar problemas básicos, nuestra rentabilidad económica está rota.
Cumplir el servicio de cara al cliente es obligatorio para que no nos den con el contrato en la cabeza, pero si no es sostenible operativamente, estamos comprando la satisfacción del cliente con nuestro margen de supervivencia.
Es el equivalente a mantener el soporte vital de la nave desviando la energía de los escudos: tarde o temprano, algo nos va a golpear y no estaremos preparados porque nos pilló corriendo y parcheando.

Qué debe cambiar un MSP para proteger su margen: Palancas de alto impacto

Pocas cosas más irritantes (y habituales) que señalar los problemas sin aportar soluciones, así que vamos con ellas.
Proteger el margen no se consigue diciendo a los técnicos que tecleen más rápido, sino rediseñando la arquitectura de trabajo.
Para ello, y siguiendo con aquellas clases de economía, debemos pensar en términos del Principio de Pareto y trabajar los aspectos fundamentales que producen mayor impacto, como estos 5:

1. Reducción de ruido y priorización real

Mientras no sepamos distinguir lo urgente de lo crítico, dará un poco igual lo que hagamos.
El usuario que escribe con mayúsculas los tickets no es necesariamente el primero a atender y, sobre todo, no todas las alertas son iguales.
Por eso, implementar una monitorización inteligente que correlacione eventos permite ignorar el ruido y centrarse en lo que de verdad impacta en el servicio.
Menos alertas falsas significan más tiempo para trabajar en lo importante. Esto se complementa con una automatización para lo trivial, como veremos enseguida.

2. Estandarización de base

La monitorización para MSP debe partir de una base común.
Si estandarizamos el stack tecnológico y las políticas de gestión, el soporte deja de ser un constante CSI forense investigando qué ha pasado, para convertirse en un proceso metódico que sí podremos escalar.

3. La detección temprana como objetivo operativo

Hemos de olvidarnos de cerrar tickets más rápido para centrarnos en reducir la altura de la torre de incidencias, aumentando el único tipo bueno de ticket, el que no llega a abrirse.
Eso nos permite el gran cambio necesario, de soporte reactivo a proactivo y predictivo.
Usar herramientas que detecten patrones de degradación antes de que el servicio caiga, por ejemplo, permite una intervención planificada, que siempre es más barata que actuar de urgencia.

4. Automatización controlada

Todo lo anterior son los cimientos que permiten automatizar, algo imprescindible para aumentar márgenes, pero que no debemos hacer de golpe ni de cualquier manera.
La forma adecuada empieza por identificar esas tareas repetitivas de bajo valor que consumen minutos preciosos: Reinicios de servicios, limpieza de archivos temporales, chequeos de salud…
Si una máquina puede hacerlo con garantías, un humano no debería tocarlo.
Lo mismo ocurre con la implementación de Grandes Modelos de Lenguaje en soporte. Pueden ayudar a aliviar una primera línea de incidencias sencillas para que el ticket no se eleve a un técnico humano y discriminar cuáles sí deben ser trasladadas al equipo técnico.

5. Routing claro y límites de escalado

Hablando del escalado, este debe ser sagrado y ordenado. Con buena preparación, una automatización en primera línea y una buena formación y base de conocimiento, un técnico L1 debe tener herramientas y documentación necesarias para resolver gran parte de las incidencias.
El escalado a técnicos L2 o L3 debe ser la excepción, no la norma por pereza o falta de formación.
Igualmente, esos ingenieros deben aprender a priorizar y no microgestionar, porque esta ineficiencia suele discurrir en dos direcciones y hay técnicos que no son capaces de dejar ir ni un milímetro de su parcela, por nocivo que sea.

Cómo medir si estamos recuperando el margen en el MSP

«Todo el mundo tiene un plan hasta que recibe un puñetazo en la boca». Pocas frases más ciertas que esta del filósofo Mike Tyson. Por eso, todo lo anterior debe ser medido para averiguar si las buenas intenciones se están convirtiendo en realidad o recibieron ese puñetazo nada más tocarla.
Y como aquí hablamos de márgenes, debemos olvidarnos de métricas de vanidad para centrarnos en indicadores que tienen una conexión directa con el dinero:
Aunque esos KPI concretos dependerán de la naturaleza de cada actividad, he aquí algunos que conviene considerar:

• Número de tickets por endpoint: Si baja, la proactividad está funcionando.
• Porcentaje de tickets repetitivos: Un indicador claro de si estamos atacando causas raíz o solo poniendo tiritas al síntoma.
• Porcentaje de escalados a L2/L3: Si baja, estamos aprovechando mejor nuestra estructura de costes, al no tener a los técnicos mejor pagados enchufando y desenchufando.
• Tiempo Medio de Resolución (o MTTR por sus siglas en inglés) por tipo de ticket: Si bien el MTTR global es una métrica útil a alto nivel, aquí precisamos un análisis más profundo, como el MTTR por tipo de ticket, para saber cuánto cuesta resolver lo que de verdad importa.
• Relación de trabajo no planificado vs planificado: Aunque en ocasiones puede ser complejo de calcular, según sea la organización del MSP, esta sería la métrica reina. Cuanto más peso tenga el trabajo planificado, más saludable (y rentable) será nuestra operación como MSP.

El camino hacia la eficiencia

Para proteger el margen operativo no hay balas de plata, pero sí un método. Este artículo es solo la punta del iceberg de una estrategia completa, cuyos elementos principales hemos desarrollado en nuestro clúster de operaciones para MSP.
Si quieres profundizar en él, te recomendamos explorar nuestros contenidos especializados:

• Reducir horas de soporte en un MSP sin perder SLA: Con estrategias concretas para optimizar la carga de trabajo.
• Detectar incidencias antes de que impacten en el cliente MSP: O cómo pasar de vivir con la lengua fuera reaccionando a todo, a predecir y prevenir los incidentes antes de que ocurran.
• Estandarizar servicios MSP sin depender de scripts manuales: Que es el camino hacia una infraestructura replicable y rentable, dejando atrás soluciones artesanales.
• Operar cientos de clientes MSP con el mismo equipo técnico: Donde profundizamos en el arte (no es arte, pero bueno) de escalar sin multiplicar los costes.
• Romper la dependencia del MSP de técnicos imprescindibles: De modo que aseguremos que su conocimiento (y que un día decidan marcharse a la competencia) no suponga un cuello de botella.

El soporte reactivo es un parásito que absorbe rentabilidad y el éxito para mantener el margen no se mide en incendios apagados, sino evitados.
Pero a menos que ese soporte reactivo sea la excepción y no la regla, nuestros márgenes serán cada vez más reducidos.