Servicios de help desk de TI en 2026: modelos, costes reales y qué preguntar

Lo que realmente estás comprando

Dedico mucho tiempo a ver cómo la intención de búsqueda se traduce en una pregunta de compra real, y esta palabra clave es un buen ejemplo de cómo ambas cosas se separan. Alguien que busca "IT help desk services" puede querer un contrato de externalización, una herramienta de tickets, o una explicación de qué hace un help desk. La página de resultados sirve las tres cosas sin etiquetar cuál es cuál, así que lo primero útil que puedo hacer es separarlas.

Empecemos por el vocabulario, porque ni siquiera los proveedores se ponen de acuerdo. La propia definición de IBM es la más limpia: "Los service desks de TI son un superconjunto del help desk estándar. El enfoque principal de un help desk de TI es solucionar problemas, mientras que un service desk se centra de forma más amplia en ofrecer servicios a los usuarios". Atlassian dice lo mismo con más detalle, citando ITIL, y luego reconoce que las etiquetas no sobreviven al contacto con la realidad: citando una investigación de HDI, señala que el 41% de los help desks y service desks se llaman de otra forma completamente distinta.

Así que la pelea taxonómica es en parte teatro. Lo útil de verdad es el alcance del trabajo, que resulta bastante consistente en la descripción que cada proveedor hace de sí mismo.

Esa tabla es la razón por la que la pregunta del modelo de entrega importa. La mitad superior es repetitiva, está documentada y tiene mucho volumen. La mitad inferior necesita a una persona con manos. Cualquier contrato de servicio o herramienta que ponga precio a toda la cola como si fuera una sola cosa te está cobrando lo mismo por ambas mitades.

Esto también explica por qué la misma solicitud llega por cinco puertas distintas. Los empleados las plantean en un portal, por correo, en Slack, en Microsoft Teams, o pasándose por el sitio en persona. Un servicio que solo cubre el portal está cubriendo la más pequeña de esas puertas, algo que conviene comprobar antes de comparar tarifas.

Si todavía estás diseñando el lado de la entrada de solicitudes, nuestra plantilla de help desk de TI y la guía de portal de autoservicio cubren ambas la forma general.

Atlassian clasifica los tipos de solicitud con claridad, y vale la pena tomarlo prestado: una solicitud de servicio es "necesito un Macbook nuevo", un incidente es "la web está caída", un problema es la causa recurrente detrás de incidentes repetidos, y un cambio es una modificación planificada. La mayor parte de lo que gestiona un help desk de TI en el día a día son los dos primeros, y esa división importa para el coste, que es donde esto se pone interesante.

La escalera de escalado es todo el modelo de coste

Aquí está el número que pondría en lo alto de cualquier evaluación. En el informe de resolución en primer nivel de MetricNet, publicado a través de HDI, el coste medio por ticket en Norteamérica se desglosa según el nivel que lo resuelve.

Dos advertencias antes de que nadie haga captura de eso. El informe es una publicación de 2011, así que trata las proporciones como algo duradero y los dólares absolutos como algo desfasado. Y son promedios de una población de benchmark, no de tu propio desk.

Lo que sobrevive a la inflación es el mecanismo, en palabras de Jeff Rumburg: "estos costes son acumulativos. Si un ticket se registra en el nivel 1 y luego se escala al nivel 2 (soporte de escritorio) para su resolución, el coste medio de resolución no es solo 62 dólares, sino 62 dólares más 22 dólares, un total de 84 dólares". Cada escalado paga tanto el peldaño que acaba de abandonar como el que acaba de alcanzar.

Lo que convierte la resolución en primer nivel en la métrica que realmente mueve tu factura. El mismo benchmark sitúa la FLR neta media en 74,3%, con una mediana del 74,9%, un mínimo del 37,6% y un máximo del 97,8%, y señala que solo el 1,4% de los service desks supera el 95%. Los desks que están abajo del todo se describen como operaciones de "registrar y derivar" que resuelven restablecimientos de contraseña y reenvían todo lo demás.

Hay una trampa de definición en la que cae la mayoría de lo que se escribe sobre este tema, y MetricNet es explícito al respecto: "la resolución en primer contacto es una métrica de calidad que afecta fuertemente a la satisfacción del cliente, mientras que la resolución en primer nivel es una métrica de coste que influye fuertemente en el coste total de propiedad". No son lo mismo. Un analista que investiga un problema y devuelve la llamada una hora después no ha logrado la resolución en primer contacto, pero sí ha logrado la resolución en primer nivel. Si un proveedor te cita una de las dos, pregunta cuál es, porque solo la segunda predice lo que vas a pagar.

El coste por ticket también se mueve más según la mezcla de solicitudes que según la eficiencia de tu equipo. El informe de coste por ticket de MetricNet sitúa las incidencias de soporte de escritorio en 48 dólares y las solicitudes de servicio en 113 dólares, aproximadamente 2,4 veces más. Un desk ahogado en aprovisionamiento de nuevos empleados tiene una cola estructuralmente más cara que uno que gestiona restablecimientos de contraseña, y ninguna cantidad de formación a los agentes cierra esa brecha.

Automatizar el lado de las solicitudes es lo que cierra esa brecha, y es el argumento a favor de un portal de autoservicio de verdad antes de que sea un argumento a favor de contratar. También es la razón por la que la automatización de ITSM suele amortizarse más rápido que una ronda de contrataciones, y por la que una capa de soporte al empleado delante de la cola suele acabar siendo el nivel más barato que llegarás a operar.

Las cuatro formas en que los equipos lo gestionan de verdad

Todos los help desks de TI que he visto son alguna mezcla de estos cuatro modelos. Las etiquetas varían, la economía no.

El caso interno es el predeterminado y a menudo es el correcto. También es aquel cuyo coste la gente subestima más, porque no escala con suavidad. No compras 0,3 de un analista. En el momento en que tu cola supera lo que una persona puede cerrar en un mes, tu coste sube de golpe un salario completo, y se queda ahí durante el trimestre tranquilo. Los equipos más pequeños suelen avanzar más con ITSM para pymes y algo de automatización de tickets que con una segunda contratación.

La externalización es donde viven las opiniones más encontradas, y quiero exponerte bien ambos lados, porque internet solo suele darte uno.

El mejor argumento a favor que he leído viene de un hilo de r/msp de 2026, y es un argumento sobre cobertura, no sobre coste.

"It's very difficult to do a true 24x7 with fewer than 5 trained staff. (Math: 168 hours in a week requires four if you're limited to a 40 hour week. On top of that you still need a way to cover absences, making a fifth staffer attractive.) With a high enough volume of calls and revenue to support that staffing level, no problem. With a low enough volume of calls to handle it as on-call wakeups, small problem. But there's a significant gap between the two activity volumes, where staffing up is infeasibly expensive and on-call coverage is not sustainable. That gap is where an outsourced level one team makes sense."

u/peacefinder, r/msp

Ese es el argumento completo, expuesto con justicia. La externalización compra horas de cobertura de forma mucho más fiable que como compra ahorro de coste. Si estás comprando buscando lo segundo, vale la pena hacer primero la aritmética de la siguiente sección.

En contra, la evidencia más fuerte no es que un proveedor concreto fuera malo. Viene de un CTO que hizo la prueba seis veces.

"The owner of the company I am the CTO for has tried it with five or six different firms. None worked out. We learned the hard way. We tried overseas, we tried American. We tried Canadian. We tried every permutation. We have EXCELLENT documentation, and techs were empowered to call us for pointers 24/7. Doesn't matter."

u/IamNabil, r/msp

Seis empresas, tres geografías, buena documentación. Ese es un resultado que no se puede explicar como una mala elección de proveedor, y es la razón por la que trataría un contrato de servicios como una decisión de cobertura y no de ahorro.

El mecanismo detrás de la mayoría de los fracasos es una transferencia de coste más que un ahorro de coste, y un administrador de sistemas en un hilo de 2026 lo describió con precisión.

"If you have a metric of ticket assignment to resolution time prior to the change, compared to the same ticket assignment to resolution time now, that may show management that while they're saving money on the L1/L2 support, they're going to be spending more on the more expensive L3 and above technicians/administrators having to essentially re-do the work that the L1/L2 are supposed to be doing."

u/georgecm12, r/sysadmin

Vuelve a mirar la escalera de escalado y esa cita es simplemente las filas de 22 y 62 dólares reorganizándose. No eliminaste el coste de nivel 1, lo moviste a personas que cuestan tres veces más. Hay un diagnóstico sencillo para esto, de un MSP que heredó una de estas cuentas: si los mismos tickets sencillos siguen llegando, el desk no está aprendiendo.

Los clientes que pagan reportan una versión más suave de lo mismo. De una reseña en G2 de un proveedor de IT gestionado:

"Sometimes response time can take more than a day, and you get varying levels of service depending on your representative."

Oil and energy reviewer, G2

La falta de consistencia según el representante es la queja recurrente, y es justo lo que un primer respondedor con IA bien documentado hace estructuralmente bien, porque responde igual a las 3 de la madrugada que a las 3 de la tarde.

El modelo cogestionado es la respuesta silenciosamente popular y rara vez la que se anuncia. En un hilo de r/msp de enero de 2026 sobre una organización sin ánimo de lucro con 500 puestos de trabajo cotizada a 225 dólares por dispositivo, lo que sale a 112.500 dólares al mes, la respuesta más votada sostiene que el precio lineal por dispositivo "se rompe por completo" a esa escala y aboga por una cuota fija para stack e infraestructura, con el personal facturado por separado. La forma inversa también merece considerarse: mantener el nivel 1 interno y externalizar el escalado, algo más cercano a cómo terminan funcionando en la práctica la mayoría de los acuerdos duraderos, y que encaja bien con las buenas prácticas de ITSM.

Lo que cuestan realmente los servicios de help desk de TI

Me puse a buscar tarifas publicadas. Lo primero que hay que destacar es lo pocas que existen.

Lee con atención la columna "qué obtienes", porque ahí está todo el truco. Solo las cuatro primeras filas te compran una persona o una resolución. Las filas del medio te compran una herramienta detrás de la cual todavía tiene que sentarse una persona. Electric es el ejemplo más claro: se comercializa como soporte de TI, sus planes publicados son una licencia de software por usuario para gestión de dispositivos y SaaS, no hay ningún nivel de help desk, y no aparece ningún compromiso de tiempo de respuesta en ninguna parte de la página de precios.

Las licencias de plataforma están por debajo de todo esto y son una partida independiente. Jira Service Management, Freshservice y ServiceNow tienen cada uno un precio de IA con una unidad distinta, así que un presupuesto de servicios que empaqueta "la herramienta" merece desglosarse antes de compararlo con nada.

Ahora las lagunas. La página de precios de NinjaOne es un formulario de contacto. ConnectWise no publica nada salvo ScreenConnect. El /pricing de Kaseya devuelve un 404, igual que las páginas de precios de CMIT Solutions y TeamLogic IT. Incluso 31West, que publica una tarifa real en sus páginas de servicio, pone un formulario de presupuesto en la página que literalmente se llama Pricing. El patrón es lo bastante claro como para ser una regla: cuanto más se acerca un proveedor a vender mano de obra, más probable es que oculte el precio.

Las tarifas reales salen a la luz en el gremio. En precios de help desk T1, los MSP reportan de 80 a 100 dólares la hora facturados en tramos de quince minutos, con 90 dólares como la cifra más común y un operador citando 200. En tarifas por usuario, 150 dólares por usuario al mes se describe como el punto sostenible, con cifras por encima de 200 vistas pero consideradas difíciles de vender.

La explicación más clara de por qué existe el nivel 1 externalizado vino de un proveedor explicando en voz alta su propia economía unitaria.

"Lets say your effective rate for an L1 on a day time (normal) agreement is ~135 an hour, and that your average L1 is paid between 45k and 55k and is at least 70% billable (utilized). Assuming a 1.2x burden rate, you're losing money on that agreement every time an L1 touches a ticket, because they have to produce 168-198 (3x loaded w2) for you to break even on their work."

u/UsedCucumber4, r/msp

Eso es un proveedor explicando que el nivel 1 humano es estructuralmente difícil de rentabilizar. Vale la pena tenerlo presente cuando llegue un presupuesto, porque te dice de dónde vendrá la presión en el contrato.

Calcula tus propios números

Introduce tu propia plantilla en lugar de fiarte de la media de nadie, incluida la mía. Los supuestos por defecto son visibles y editables, y ese es precisamente el objetivo.

Hay un resultado que vale la pena notar antes de escalarlo. Con los valores por defecto de arriba, el modelo interno se mantiene como el más barato solo mientras toda la cola cabe dentro de un analista, lo que ronda los 265 empleados. Cruza esa línea y estás comprando un segundo salario completo por una fracción del trabajo de una persona, que es exactamente el punto en el que la columna de IA en primera línea se pone por delante. Por debajo de esa línea todavía no tienes un problema de modelo de entrega, tienes un help desk normal.

Lo otro que la herramienta deja claro es que la externalización tiene precio según tu plantilla mientras que tu coste lo marcan tus tickets. Esos dos números se mueven de forma independiente. Una empresa con usuarios tranquilos y bien formados paga la misma tarifa por asiento que una cuya cola está ardiendo, lo cual es estupendo para el proveedor y vale la pena discutirlo en la negociación.

Las preguntas de contrato que deciden si funciona

Esta es la parte en la que más tiempo pasaría, porque es donde un presupuesto que se ve bien se convierte en un mal año.

Pregunta si los tiempos de respuesta se cuentan en horas laborables o en horas de reloj. Las propias ofertas de soporte de Atlassian muestran la trampa a la perfección: en el nivel Standard, el objetivo de severidad uno es 2 horas laborables y el de severidad cuatro es 2 días laborables. En Enterprise, esas mismas filas dicen 30 minutos y 24 horas. Los números destacados cambian, pero también cambió la unidad, y la unidad es el verdadero producto que se está vendiendo.

Pregunta qué cubre el "24/7". En la mayoría de los contratos de soporte reales solo significa la severidad máxima. El nivel 24x5 de Atlassian ofrece cobertura permanente para incidencias de severidad uno de lunes a viernes, y todo lo demás en horario laboral. Un proveedor que ofrezca cobertura "follow-the-sun" debería poder nombrar las regiones que se van pasando el testigo, tal como el Premier Support de Atlassian nombra Australia, Brasil, India, los Países Bajos y Estados Unidos.

Esta es la disputa más común de la categoría, y un MSP describió exactamente cómo se desarrolla.

"Had this happen where client bought the 24/7 package support. The thing is anything after hours and weekends are skeleton crew who just gather information for the 9-5 crew, and client was disappointed in service and expected premium service. Both got into argument, and both had different expectations of 24/7 package."

u/Hebrewhammer8d8, r/msp

Un término medio útil que aparece una y otra vez es 12x7 en lugar de 24x7, que cubre las horas en las que la gente realmente trabaja y es mucho más fácil de cubrir con personal.

Pide la resolución en primer nivel, desglosada y neta de exclusiones. La FLR bruta favorece a un proveedor al que solo se le envían tickets fáciles. La FLR neta mide lo que resolvió frente a lo que podría haber resuelto, que es el número que corresponde a tu factura.

Pregunta qué pasa en la escalada, por escrito. La queja que más escucho sobre el nivel 1 externalizado no es que sea malo respondiendo, es que se convierte en una capa de enrutado que devuelve los mismos tickets a tu equipo interno con una hora extra en el reloj. Si el contrato no define qué es propiedad del nivel 1 de principio a fin, has comprado una cola, no una resolución, y ahí es donde se filtra el dinero, en la ruta de escalado.

La corrección más útil a esa queja vino de un administrador de sistemas replicando a sus propios compañeros, y se me ha quedado grabada.

"You're assuming that your management didn't sign a contract that simply said "take level 0 phone calls and escalate all else". Perhaps they were never meant to do the things you're expecting of them. This IMO is not a problem of the out source agency but a problem with your management."

u/Poncho_au, r/sysadmin

Buena parte de lo que se le achaca a un mal proveedor es un documento de alcance que nadie leyó. Escribe la lista de tipos de ticket que el nivel 1 debe cerrar sin escalar, ponla en el contrato, e informa mensualmente contra ella.

Pregunta quién tiene las credenciales. Esto está poco cubierto en todas las presentaciones de proveedores que he visto. Un desk externalizado necesita acceso a tus sistemas para resolver cualquier cosa, y la pregunta honesta es cómo está delimitado ese acceso. Un dueño de MSP se marchó de un acuerdo precisamente por esto, describiendo proveedores que solo podían ofrecer acceso agrupado y códigos de contraseña de un solo uso compartidos. Pide cuentas nominales, registros de auditoría individuales, y un proceso de baja documentado para su personal, no el tuyo.

Pregunta qué van a publicar realmente. Muy pocos proveedores se comprometen con cifras. 31West es la excepción aquí y vale la pena usarlo como vara de medir: su página de externalización publica llamadas contestadas en menos de 5 tonos, correo en menos de 15 minutos, chat en menos de 60 segundos, una respuesta media de 10 minutos y una resolución media de nivel 1 en menos de 2 horas. No hace falta creerse cada cifra para usarla como el punto de referencia con el que contrastar otros presupuestos.

Si estás redactando esto en un documento, nuestra guía de buenas prácticas de SLA cubre la estructura y gestión de escalado cubre específicamente las cláusulas de traspaso.

Dónde la IA cambia de verdad la aritmética

Ahora la parte con la que abre cualquier presentación de proveedor, por eso la he dejado para el final.

Desviación y resolución son números distintos y solo uno de ellos merece pagarse. La desviación cuenta tickets que nunca se llegaron a abrir, lo cual incluye tanto al empleado que obtuvo una buena respuesta como al que se peleó con un bot, se rindió y te escribió por Slack directamente. La métrica reporta ambos como un éxito.

La prueba más útil para compradores que he encontrado vino de Jeff Orr en LinkedIn, y la pondría textual en un RFP: ¿qué porcentaje del volumen de tickets puede resolver el sistema sin asignación humana? No desviar hacia un artículo de la base de conocimiento, resolver de verdad. Su referencia para despliegues maduros es del 25 al 40 por ciento, y por debajo del 10 por ciento, dice, es solo un chatbot.

Contrasta eso con despliegues reales y no con demos. InDebted tiene IA como primer respondedor en su desk interno de Jira Service Management y reporta un 15% de desviación con un objetivo del 55%. Jason Loyola, su responsable de TI, describió el montaje con sencillez:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Esa es la forma honesta del asunto: una cifra real, a mitad de camino, sobre una cola de TI en producción. No un 90%, ni el primer día.

Las dos cifras más útiles que encontré de administradores de sistemas ejecutando esto en producción están muy alejadas entre sí, y esa distancia es reveladora. Un equipo que perdió a un empleado y decidió no reemplazarlo reportó que "nuestra necesidad de intervención ha bajado un 73%" tras apuntar una IA hacia su propia documentación, aunque tuvieron cuidado de señalar que la cifra venía del panel del proveedor. Otro fue más directo.

"We're using one for password resets and basic account stuff. Works fine for that, cuts tickets by maybe 20%. Triage and routing is still hit or miss. It's good at obvious stuff but anything nuanced still needs a human to sort it out."

u/Dombo96, r/sysadmin

Planifica para ese 20% y date por satisfecho con cualquier cosa por encima. La diferencia entre esas dos cifras se debe sobre todo a la calidad de la documentación, no a la calidad del modelo.

También vale la pena saber que la IA todavía no ha desplazado esta decisión a gran escala. Citando el informe de compensación de Service Leadership, Dave Sobel señala en LinkedIn que la mano de obra ha representado históricamente entre el 75 y el 80% del coste de entrega del servicio, y que solo el 16% de los MSP reporta tener "empleados digitales" funcionales en nivel 1 o 2 en producción. Así que si estás evaluando esto en 2026, vas pronto, no tarde, y los proveedores que te están dando presupuesto todavía siguen pagando a humanos por casi todo.

También hay un techo que nadie anuncia. Un portátil muerto, un cambio de cable, un kit de nuevo empleado: ninguna IA cierra eso, y en la mayoría de las colas de TI representan una parte real del volumen. Si un proveedor promete un 80% de resolución de extremo a extremo en un desk interno, o está contando desviación, o no ha mirado tu mezcla de tickets. Esta es también la diferencia práctica entre un agente de IA y un chatbot: uno actúa en tus sistemas, el otro devuelve un artículo.

El fallo que la mayoría de los equipos encuentran ocurre antes que la IA, y es un problema de documentación, no de modelo. Si tus manuales viven en la cabeza de la gente, un agente no tiene nada de lo que partir para resolver, y desviará porque es lo único que puede hacer. Arreglar la base de conocimiento interna es el requisito previo poco glamuroso, y compensa sea cual sea el modelo de entrega en el que acabes.

Por eso sigo insistiendo a los equipos en que simulen primero contra su propio historial de solicitudes. Te dice dónde está poco desarrollada tu base de conocimiento antes de haber pagado un año entero de nada, y es la misma disciplina que hay detrás de evitar alucinaciones y diseñar un traspaso sensato.

Después, mídelo honestamente. Rastrea lo que el agente hizo realmente, qué herramientas invocó, y dónde un humano lo anuló.

Vale la pena saber dónde está realmente la categoría hoy. La encuesta de SysAid a 718 profesionales de TI encontró un 61% de adopción de IA pero solo un 3,3% funcionando con ejecución autónoma completa, y un tercio que ni siquiera mide la reducción de tickets. La brecha entre la demo y el despliegue es todo el juego, y por eso una tasa de resolución honesta vale más que celebrar una reducción de tickets que no puedes atribuir.

Prueba eesel en tu cola de TI

Si has llegado hasta aquí comparando presupuestos de externalización, aquí tienes la opción que normalmente no está en la lista corta. La mayoría de los equipos de TI que buscan servicios de help desk no tienen un problema de cobertura ni de plataforma, tienen un problema de repetición, y eso requiere una compra distinta.

eesel se incorpora al desk que ya operas como primer respondedor de IA, así que no hay migración y nadie tiene que aprender una herramienta nueva. Se sitúa sobre Jira Service Management, Freshdesk o Slack, aprende de las solicitudes que ya has resuelto además de lo que guardas en Confluence, Notion o SharePoint, redacta y envía respuestas, fija prioridad y SLA, y enruta lo que no debería tocar.

Antes de que toque un solo ticket real lo simulas contra tu propio historial de solicitudes, lo que te dice la tasa de resolución que obtendrías de verdad en lugar de la que aparece en una diapositiva. Cuesta 0,40 dólares por ticket sin coste por asiento, así que la factura sigue el volumen resuelto en lugar de la plantilla, y la configuración se acerca más a media hora que a un trimestre.

Ese es el montaje que el responsable de TI de InDebted puso sobre Jira: primer respondedor en la cola del help desk, funcionando como lo haría un agente. Empieza gratis con 50 dólares de uso y sin tarjeta, o reserva una demo si prefieres que alguien revise contigo tu mezcla de tickets primero.

Si estás en una fase más temprana del proceso, IA para ITSM es el mapa más amplio, software de help desk interno cubre el lado de la plataforma, y software de help desk de TI es la comparativa herramienta por herramienta que este artículo omitió deliberadamente.