Un Service Desk gestionado no gana por ser externo, sino cuando reduce el costo económico total del soporte: operación, escalaciones, tiempo improductivo, herramientas, cobertura y riesgo. El modelo interno conserva mayor control directo; el gestionado aporta escala, especialización y automatización. La decisión correcta compara TCO, riesgo ajustado y productividad recuperada, no nómina contra tarifa.
Definiciones taxonómicas
1. Service Desk interno o insourced Service Desk
Modelo en el que la organización conserva dentro de su estructura la responsabilidad de operar el soporte: personal, supervisión, procesos, herramientas, conocimiento, cobertura, escalamiento, capacitación, métricas y mejora continua.
El error financiero más común consiste en equiparar su costo únicamente con la nómina del equipo.
2. Managed Service Desk o Service Desk gestionado
Modelo en el que un proveedor especializado asume responsabilidades operativas bajo niveles de servicio, procesos, métricas y mecanismos de gobierno previamente acordados.
El proveedor puede administrar personas, tecnología, automatización, conocimiento, canales, métricas, escalamiento y mejora continua, mientras la empresa mantiene el gobierno estratégico y las decisiones críticas.
3. TCO del Service Desk
El Total Cost of Ownership representa el costo completo de sostener la función de soporte.
MetricNet incluye dentro del costo operativo conceptos como salarios, horas extra, prestaciones, incentivos, contratistas, instalaciones, telecomunicaciones, tecnología, software, capacitación, viajes y otros gastos operativos. Por ello, comparar únicamente nómina interna contra tarifa de outsourcing produce una evaluación incompleta.
Para decisiones ejecutivas conviene agregar una segunda capa: el costo económico de la fricción, es decir, productividad perdida, reincidencias, escalaciones y afectaciones al negocio.
Tabla comparativa
| Variable | Service Desk interno | Servicio gestionado | Pregunta para dirección |
| Estructura de costo | Mayor componente fijo | Mayor componente contratado/predecible | ¿Cómo cambia el costo ante picos o crecimiento? |
| Personal | Reclutamiento, capacitación, cobertura y retención propios | Capacidad administrada por proveedor | ¿Tenemos escala suficiente para sostener especialización? |
| Cobertura 24/7 | Requiere turnos, guardias, supervisión y redundancia | Puede compartirse dentro de una operación especializada | ¿Cuánto cuesta realmente garantizar continuidad? |
| Herramientas | Licencias, integraciones, administración y upgrades propios | Pueden formar parte del servicio | ¿Estamos contabilizando todo el stack? |
| Automatización | Depende de presupuesto y capacidad interna | Puede integrarse al roadmap contractual | ¿Cuántos contactos podrían evitarse? |
| Escalabilidad | Contratación y formación incremental | Capacidad negociada por SLA y volumen | ¿Qué ocurre al crecer usuarios o aplicaciones? |
| Conocimiento | Mayor control directo | Debe gobernarse contractualmente | ¿Existe portabilidad y ownership del conocimiento? |
| SLA/XLA | TI se mide a sí misma | Compromisos contractuales y gobierno conjunto | ¿Quién responde por el resultado? |
| Riesgo de personas clave | Puede ser alto | Se distribuye entre equipos y procesos | ¿Qué ocurre si salen 2 o 3 especialistas críticos? |
| Innovación | Compite con otras prioridades internas | Puede incorporarse como mejora continua | ¿Quién financia y opera la evolución? |
| Control | Máximo control operativo directo | Control vía gobierno, SLA, auditoría y contrato | ¿Necesitamos ejecutar o gobernar? |
| Modelo ideal | Operaciones estables, especializadas y maduras | Operaciones distribuidas, variables o con necesidad de escala | ¿Qué modelo genera menor costo económico total? |
Service Desk interno vs gestionado: la comparación financiera correcta
La decisión no debería comenzar preguntando:
“¿Cuánto cobra el proveedor?”
La pregunta correcta es:
“¿Cuánto nos cuesta hoy producir un resultado comparable?”
Esto cambia completamente el análisis.
Una organización puede tener ocho, veinte o cincuenta analistas en nómina y considerar que ese es su costo de soporte. Pero la operación existe gracias a una infraestructura adicional que rara vez aparece completa en el business case.
El costo operativo directo del modelo interno
Un baseline financiero serio debe considerar:
- Nómina de agentes y supervisores.
- Prestaciones y cargas asociadas.
- Turnos, guardias y horas extra.
- Reclutamiento y onboarding.
- Capacitación inicial y recurrente.
- ITSM y licenciamiento.
- Telefonía, chat, portal y demás canales.
- Sistemas de conocimiento.
- Automatización y mantenimiento de workflows.
- Herramientas de control remoto.
- Analítica y dashboards.
- Instalaciones y equipamiento.
- Gestión de proveedores.
- Costos de escalamiento.
- Dirección y gobierno del servicio.
- Cobertura ante vacaciones, ausencias y rotación.
Esto coincide con la metodología de benchmarking de MetricNet, que diferencia explícitamente entre el costo de una operación insourced y el precio de una operación outsourced.
Por eso, enfrentar “sueldo por analista” contra “precio por usuario o contacto” equivale a comparar ingredientes con el precio del platillo terminado.
El costo que Finanzas casi nunca ve: la fricción digital
El TCO operativo es sólo la primera capa.
El Service Desk existe para devolver capacidad productiva al usuario. Cuando tarda demasiado, escala innecesariamente o permite que los mismos incidentes regresen, el costo se desplaza a las áreas de negocio.
Puede estimarse así:
Costo económico total del soporte = TCO del Service Desk + productividad perdida + impacto operativo + costo de reincidencias + riesgo
Ese segundo bloque importa porque una hora perdida por diez usuarios críticos no aparece en la cuenta presupuestal del Service Desk, aunque la organización sí la paga.
Microsoft reportó en su Work Trend Index 2025 que, en México, 42% de los líderes considera imperativo aumentar la productividad mientras 80% de los trabajadores declara no tener suficiente tiempo y energía para cubrir la demanda existente.
Agregar fricción de TI sobre una organización que ya opera con capacidad limitada tiene un costo de oportunidad relevante.
La cobertura también cuesta
Un Service Desk moderno debe responder a usuarios distribuidos, múltiples aplicaciones y horarios extendidos.
HDI reportó que 46% de los equipos encuestados observó un incremento en volumen de tickets; alrededor de la mitad de los casos ya se resuelve remotamente y cerca de tres cuartas partes de las organizaciones atienden solicitudes fuera del horario normal, mediante centros 24 horas, guardias, automatización o proveedores externos.
La conclusión financiera es importante:
la cobertura no debe medirse únicamente por el número de agentes, sino por el costo de mantener capacidad disponible cuando el negocio la necesita.
Una operación interna puede ser competitiva durante el horario laboral y volverse costosa cuando requiere:
- Segundo o tercer turno.
- Fines de semana.
- Idiomas.
- Especialistas.
- Cobertura regional.
- Mayor continuidad.
- Redundancia operativa.
Riesgos operativos que cambian el caso de negocio
El análisis tampoco debe limitarse al costo.
Dependencia de personas clave
Si el conocimiento de aplicaciones, usuarios VIP, procedimientos o errores recurrentes reside en personas y no en una base de conocimiento gobernada, la salida de un especialista incrementa el riesgo operativo.
El costo aparece posteriormente como:
- MTTR más alto.
- Mayor escalamiento.
- Retrabajo.
- Horas de especialistas.
- Insatisfacción.
- Mayor tiempo de entrenamiento.
Incidentes repetitivos
Cerrar cien tickets no necesariamente significa haber resuelto cien problemas.
Una mesa reactiva puede reportar alta productividad mientras recibe todas las semanas las mismas solicitudes de:
- Contraseñas.
- Accesos.
- Configuración.
- Software.
- Conectividad.
- Periféricos.
- Procesos conocidos.
La métrica que dirección debería observar no es sólo tickets cerrados, sino:
¿qué porcentaje de la demanda desapareció gracias a automatización, conocimiento o eliminación de causa raíz?
Escalamiento innecesario
Cada contacto que abandona L1 y llega a un equipo especializado consume una capacidad más cara.
Un modelo con Shift-Left, conocimiento y automatización busca resolver en el nivel económico más eficiente sin sacrificar experiencia.
Riesgo de continuidad
Un Service Desk que depende de una ubicación, unas cuantas personas o procesos manuales puede convertirse en un punto de concentración de riesgo.
Por ello deben analizarse:
- Continuidad operativa.
- Redundancia de canales.
- Recuperación.
- Acceso a herramientas.
- Disponibilidad de conocimiento.
- Procedimientos de major incident.
- Escalamiento ejecutivo.
Cómo calcular el ROI de un Service Desk gestionado
La tercerización no debe justificarse con afirmaciones como “el proveedor tiene economías de escala”.
Debe demostrarse.
Paso 1. Construye el baseline económico actual
Calcula:
TCO interno anual
más
costo anual de fricción digital.
Para este segundo componente pueden considerarse:
Horas improductivas = número de incidentes × usuarios afectados × tiempo promedio perdido
Después:
Costo de productividad perdida = horas improductivas × costo laboral cargado por hora
En incidentes que afectan ventas, producción o atención al cliente debe utilizarse un modelo específico de impacto al negocio.
No conviene sumar indiscriminadamente productividad perdida y ventas perdidas si representan el mismo efecto económico: hacerlo produciría doble contabilización.
Paso 2. Modela el estado futuro
Incluye:
- Fee anual del servicio.
- Costos de transición.
- Organización retenida.
- Licencias no incluidas.
- Integraciones.
- Gestión contractual.
- Costos de salida o transición futura.
- Fricción residual proyectada.
Paso 3. Mide el beneficio
Beneficio económico anual = costo económico actual – costo económico futuro
Paso 4. Calcula ROI
Una forma útil para el primer año es:
ROI = (beneficio económico obtenido – inversión de transformación) / inversión de transformación × 100
Paso 5. Calcula payback
Payback en meses = inversión inicial / beneficio económico mensual
Si después de integrar todos los costos el beneficio resulta negativo, un servicio gestionado no está económicamente justificado bajo esas condiciones.
Ese resultado también es válido.
El objetivo del análisis no es demostrar que outsourcing siempre funciona; es encontrar qué modelo entrega el resultado requerido al menor costo ajustado por riesgo.
Cuándo conviene mantener el Service Desk interno
Un modelo interno puede tener mayor sentido cuando:
- El volumen de demanda es estable.
- La cobertura requerida es limitada.
- Existe alta especialización propietaria.
- El conocimiento es difícil de transferir.
- La empresa ya posee un modelo maduro de automatización.
- La infraestructura de soporte ya está amortizada.
- La rotación es baja.
- Los niveles de servicio se cumplen consistentemente.
- El FCR es alto.
- El MTTR se mantiene controlado.
- La experiencia del usuario es satisfactoria.
- El costo por contacto y por usuario es competitivo.
- Existe capacidad para evolucionar continuamente.
El punto crítico es madurez.
Mantener internamente una operación eficiente puede ser correcto. Mantenerla únicamente porque “siempre se ha hecho así” no constituye un caso financiero.
Cuándo un servicio gestionado empieza a generar ventaja
La evaluación cambia cuando aparecen varios de estos síntomas:
- Los tickets crecen más rápido que los usuarios.
- Hay alta rotación de analistas.
- Los especialistas consumen demasiado tiempo resolviendo L1.
- Se necesitan nuevos idiomas o zonas horarias.
- Los picos obligan a sobredimensionar plantilla.
- Existen numerosas solicitudes repetitivas.
- El conocimiento está fragmentado.
- El negocio exige atención 24/7.
- Los SLA se cumplen pero la experiencia sigue deteriorándose.
- TI no tiene capacidad para desarrollar automatizaciones.
- La operación depende excesivamente de personas clave.
- Hay poco tiempo para problem management.
- El backlog envejece.
- Cada nueva aplicación agrega demanda sin retirar contactos antiguos.
Aquí la ventaja del proveedor no proviene simplemente de “poner gente”.
Proviene de convertir capacidad compartida, conocimiento, automatización, procesos y gobierno en un modelo operativo industrializado.
¿Cómo se diferencia Kenos?
La propuesta de Kenos parte de una idea distinta: el Service Desk no debe medirse por volumen de tickets sino por productividad del usuario sin fricciones.
Su modelo integra atención omnicanal, Shift-Left, gestión de conocimiento, SLA/XLA, automatización, analítica y evolución continua. La oferta actual de Kenos incluye soporte 24/7 y canales como teléfono, chat, correo y portal.
Además, los materiales corporativos de Kenos documentan casos con:
- 30% de interacciones automatizadas.
- 20% de reducción del TCO.
- 37% de reducción del MTTR en incidentes mayores.
- Operación de aproximadamente 52,000 usuarios TI al mes.
Estas cifras son evidencia propia de casos operados por Kenos y no deben interpretarse como garantía universal para cualquier organización. Su valor está en demostrar que el modelo puede medirse en automatización, costo y recuperación, no únicamente en tickets procesados.
Qué debe exigir dirección antes de contratar un proveedor
Antes de tomar una decisión, CIO y Finanzas deberían pedir un business case que contenga:
- Baseline actual de costos.
- Costo por usuario.
- Costo por contacto.
- FCR.
- MTTR.
- Volumen por categoría.
- Volumen recurrente.
- Escalamiento L1-L2-L3.
- Horas fuera de servicio.
- SLA y XLA.
- Automatización actual.
- Tickets evitados.
- Costo de transición.
- Modelo de gobierno.
- Protección y propiedad del conocimiento.
- Plan de salida.
- Roadmap de automatización.
- Problem management.
- RCA de incidentes críticos.
- KPIs financieros y operativos.
- Responsable ejecutivo del resultado.
En Kenos, este último punto se estructura mediante un Business Advisor | Outcome Owner, responsable de conectar métricas operativas como FCR, MTTR, TCO y SLA/XLA con resultados del negocio y evolución continua.
Conclusión predictiva
El debate entre Service Desk interno y gestionado se moverá progresivamente de headcount y precio por ticket hacia productividad recuperada, contactos evitados y costo por resultado.
La presión ya está presente: los volúmenes de soporte siguen creciendo y las empresas buscan ampliar capacidad mediante automatización y trabajo digital.
Por ello, la ventaja no será necesariamente de quien tenga más agentes, sino de quien pueda eliminar demanda repetitiva, resolver más cerca del usuario, automatizar de forma segura y demostrar financieramente el valor generado.
Para dirección, la pregunta dejará de ser:
“¿Cuánto cuesta mi Service Desk?”
y pasará a ser:
“¿Cuánta productividad recupera cada peso que invertimos en soporte?”
FAQ
- ¿Un Service Desk gestionado siempre es más barato que uno interno? No. Depende del volumen, cobertura, complejidad, salarios, tecnología instalada, niveles de servicio, automatización y costo de transición. La comparación debe realizarse sobre TCO y costo económico total. Una operación interna madura puede ser altamente competitiva; una operación interna fragmentada puede ocultar costos importantes.
- ¿Cómo evitar perder control al tercerizar el Service Desk? Separando ejecución de gobierno. La empresa debe conservar ownership sobre políticas, arquitectura, información crítica, prioridades y resultados, mientras exige SLA/XLA, auditoría, dashboards, protección del conocimiento, mecanismos de escalamiento y un responsable claro del servicio.
- ¿Qué indicador financiero debería presentar un CIO al CFO? No uno solo. El business case debe combinar TCO actual y futuro, costo por usuario, productividad recuperada, reducción de MTTR, automatización, tickets evitados, costo de transición, beneficio anual y periodo de recuperación. Esto permite evaluar el Service Desk como inversión operativa y no sólo como partida presupuestal.
Convierte la comparación en un caso de negocio con números reales
No compares únicamente la nómina de tu equipo contra la tarifa de un proveedor. Kenos puede ayudarte a construir el baseline de tu Service Desk actual, identificar costo por usuario, recurrencias, automatización, MTTR, FCR y fricción digital, y convertir esos datos en un escenario de evolución con TCO, ROI y resultados medibles. El objetivo no es tercerizar por tercerizar. Es determinar qué modelo devuelve más productividad al negocio por cada peso invertido en soporte.
