Atender 52,000 usuarios de TI al mes exige mucho más que ampliar una mesa de ayuda: requiere operación omnicanal, automatización, conocimiento reutilizable, observabilidad, escalamiento L1-L3, integración con endpoints y campo, y gobierno por productividad. A esa escala, el objetivo no es cerrar más tickets, sino reducir el tiempo que usuarios y procesos permanecen improductivos.
- Soporte integral de usuarios: modelo operativo que conecta Service Desk, autoservicio, inteligencia artificial, gestión de endpoints, soporte especializado y atención en sitio para restaurar la productividad del usuario de punta a punta. No termina cuando se genera un ticket; termina cuando el usuario puede volver a trabajar.
- First Contact Resolution (FCR): porcentaje de interacciones resueltas correctamente en el primer contacto, sin transferencias, reaperturas ni escalamiento adicional. En una operación de gran volumen, aumentar FCR reduce tanto el costo del soporte como el tiempo improductivo del usuario.
- Tiempo a productividad: intervalo entre el momento en que una fricción tecnológica impide o degrada el trabajo y el momento en que el usuario recupera la capacidad necesaria para continuar. Es diferente del tiempo de cierre del ticket: un ticket puede permanecer administrativo o técnicamente abierto aun cuando el usuario ya opere, o cerrarse sin que la productividad se haya restablecido por completo.
PeopleCert posiciona el Service Desk como un punto de contacto central entre proveedor y usuarios y vincula su efectividad con la experiencia, la relación de servicio y la mejora continua.
Tabla comparativa
| Dimensión | Mesa de soporte reactiva | Soporte integral preparado para escala | Resultado de negocio |
| Demanda | Atiende conforme llegan tickets | Pronostica volumen, picos y criticidad | Capacidad predecible |
| Canales | Canales aislados | Voz, portal, chat, correo y canales digitales bajo un mismo contexto | Menos repetición y espera |
| Priorización | Urgencia declarada por el usuario | Impacto en producción, venta, operación o servicio | Protege procesos críticos |
| Resolución | Escalamiento principalmente humano | Autoservicio → IA → agente → especialista/campo | Menor costo por resolución |
| Conocimiento | Depende de experiencia individual | Knowledge base viva y reutilizable | Menor dependencia de personas |
| Automatización | Scripts aislados | Runbooks y flujos end-to-end | Menor esfuerzo manual |
| Prevención | Reacciona después de la falla | Telemetría, recurrencias y problem management | Incidentes evitados |
| Atención física | Despacho después del diagnóstico básico | Diagnóstico remoto antes de mover recursos | Menos visitas y second-time fix |
| Gobierno | Tickets, SLA y volumen | FCR, MTTR, tiempo a productividad, TCO, XLA y recurrencia | Decisiones ejecutivas |
| Economía | Más volumen = más personas | Mayor volumen absorbido por automatización y Shift-Left | Escalabilidad del costo |
¿Qué cambia cuando el soporte debe atender a 52,000 usuarios al mes?
Kenos by Scanda publica una escala operativa de 52,000 usuarios de TI atendidos al mes, junto con más de 25,000 puntos de venta atendidos y experiencia operativa en múltiples países de Latinoamérica. Es importante interpretar correctamente el dato: 52,000 usuarios no significa 52,000 tickets mensuales. El número de agentes necesario no puede calcularse a partir del universo de usuarios. Depende de variables como:
- Interacciones por usuario.
- Distribución horaria.
- Estacionalidad.
- Porcentaje de incidentes frente a solicitudes.
- Duración promedio de atención.
- FCR.
- Nivel de autoservicio.
- Automatización.
- Distribución por canal.
- Complejidad tecnológica.
- Cobertura horaria.
- Escalamientos a L2, L3 y proveedores.
- Necesidad de atención en sitio.
El error más frecuente es responder al crecimiento aumentando headcount. Eso escala el costo casi al mismo ritmo que escala la demanda. La alternativa es modificar la mezcla de resolución: qué porcentaje se resuelve automáticamente, cuánto mediante asistencia de IA, cuánto en primer contacto y qué proporción realmente necesita especialistas o intervención física.
Kenos by Scanda establece precisamente este modelo escalonado: auto-resolución, resolución asistida por IA y atención humana en sitio, reservando la intervención más costosa para los casos donde aporta valor.
Lo que unos minutos representan a esta escala
Hay una forma sencilla de entender el impacto. Si un universo de 52,000 usuarios perdiera el mismo tiempo productivo durante un mes, el efecto matemático sería:
| Fricción promedio por usuario/mes | Horas productivas acumuladas |
| 1 minuto | 867 horas |
| 5 minutos | 4,333 horas |
| 10 minutos | 8,667 horas |
| 15 minutos | 13,000 horas |
| 30 minutos | 26,000 horas |
Este cálculo es un escenario matemático de sensibilidad, no tiempo perdido observado en Kenos by Scanda. La conclusión sí es relevante: a esta escala, ahorrar uno o dos minutos en una interacción deja de ser una optimización marginal. Por eso el KPI que interesa a dirección no debería ser únicamente “cuánto tardamos en cerrar el ticket”, sino “cuánto tiempo productivo devolvimos al negocio”.
Los requisitos de un soporte integral de usuarios a escala
1. Una entrada omnicanal con contexto único. El usuario puede iniciar su contacto por teléfono, chat, portal o correo. Lo que no debería hacer es explicar el incidente nuevamente cada vez que cambia de canal.Un modelo escalable necesita:
- Identidad única del usuario.
- Historial de interacciones.
- Activo o endpoint asociado.
- Aplicaciones utilizadas.
- Incidentes anteriores.
- Ubicación.
- Nivel de criticidad.
- SLA aplicable.
- Base de conocimiento relacionada.
La operación de Service Desk de Kenos by Scanda contempla atención omnicanal, escalamiento L1-L3, soporte de accesos, workplace y aplicaciones, así como integración con ITSM, catálogo y CMDB.
El contexto reduce uno de los costos invisibles de soporte: hacer que el usuario se convierta en integrador de la propia mesa de servicio.
2. Priorización por impacto de negocio, no por quién reclama más fuerte. A gran escala, una cola FIFO deja de ser suficiente.No tiene el mismo impacto:
- Una falla de impresora administrativa.
- Un acceso detenido durante un cierre financiero.
- Una terminal detenida en hora pico.
- Un usuario de producción sin acceso al ERP.
- Un ejecutivo sin correo.
- Un grupo completo sin conectividad.
La priorización debe considerar: Impacto × criticidad × usuarios afectados × proceso de negocio × tiempo.
Esto evita que el volumen esconda lo verdaderamente costoso. HappySignals reportó, en su benchmark global 2025 basado en más de 2.28 millones de respuestas, que aproximadamente 13% de los tickets concentraba 80% del tiempo perdido por los usuarios. El mensaje para dirección es importante: el objetivo no es optimizar todos los tickets por igual, sino localizar la fricción que destruye más productividad.
3. FCR alto y Shift-Left antes de aumentar personal. Una interacción que pasa por cuatro equipos consume cuatro veces capacidad organizacional antes de considerar el tiempo del usuario.Por ello deben revisarse:
- FCR.
- Transferencias por interacción.
- Reaperturas.
- Escalamientos evitables.
- Tiempo entre grupos resolutores.
- Tickets regresados por información incompleta.
- Casos potencialmente automatizables.
El principio es sencillo: resolver el problema en el nivel menos costoso capaz de resolverlo correctamente. Eso significa mover conocimiento de L3 hacia L2, de L2 hacia L1 y, cuando el riesgo lo permita, de L1 hacia autoservicio o automatización.
No significa eliminar especialistas; significa evitar que desperdicien tiempo resolviendo aquello que ya debería ser repetible.
4. Knowledge Management que sobreviva a la rotación. Atender decenas de miles de usuarios con conocimiento guardado en la memoria de algunos técnicos es riesgo operativo.El conocimiento debe convertirse en un activo operacional:
- Artículos validados.
- Soluciones vinculadas con incidentes.
- Runbooks.
- Árboles de decisión.
- Scripts.
- Procedimientos por aplicación.
- Historial de error conocido.
- Workarounds.
- Contenido utilizable por humanos y agentes de IA.
Cada incidente resuelto pero no documentado obliga a pagar nuevamente por el mismo aprendizaje. En palabras menos ceremoniales: si la solución vive únicamente en la cabeza de “Juan, que lleva diez años aquí”, no es conocimiento corporativo; es una dependencia.
5. IA aplicada primero a lo repetitivo y medible. A escala, la IA tiene sentido cuando elimina trabajo concreto.Los primeros candidatos suelen ser:
- Clasificación.
- Enriquecimiento del ticket.
- Identificación de intención.
- Recuperación de conocimiento.
- Password reset.
- Solicitud de accesos estandarizados.
- Instalación de software autorizada.
- Diagnóstico guiado.
- Routing.
- Resumen para el siguiente nivel.
- Detección de recurrencias.
IBM describe el AI Service Desk como una arquitectura capaz de automatizar intake, clasificación, autoservicio y workflows, permitiendo manejar mayor volumen sin que el personal tenga que crecer al mismo ritmo. Microsoft, por su parte, señala que sus escenarios de agentes de IA para help desk pueden reducir tiempos de resolución entre 40% y 60% al integrarse con conocimiento y sistemas de tickets. Es un dato del fabricante y no una garantía universal, pero ilustra por qué la automatización está cambiando la economía del soporte.
La regla para dirección debe ser: automatización implementada ≠ automatización adoptada ≠ resolución conseguida. Hay que medir las tres.
6. Service Desk, endpoint y campo no pueden operar como islas. Un soporte integral no debe limitarse al canal de atención.Para resolver rápido necesita saber:
- Qué dispositivo tiene el usuario.
- Qué configuración debería tener.
- Si está actualizado.
- Qué cambió.
- Si presenta degradación.
- Si puede remediarse remotamente.
- Si existe una falla general.
- Si necesita intervención física.
Ahí se conectan Service Desk, UEM, DEX, observabilidad y Field Service. El portafolio corporativo de Kenos plantea precisamente esta integración entre Service Desk, AI Service Desk, Endpoint Management, Field Service y continuidad de canales, bajo gobierno y métricas comunes.
La consecuencia económica es relevante: un diagnóstico remoto correcto puede evitar una visita, mientras que uno incorrecto agrega traslado, tiempo muerto y una posible segunda visita.
7. Problem Management: eliminar demanda, no administrarla mejor. Una mesa puede cumplir SLA y seguir siendo ineficiente si resuelve la misma falla miles de veces.A escala deben existir procesos para identificar:
- Incidentes recurrentes.
- Aplicaciones con mayor tiempo improductivo.
- Equipos o versiones con mayor falla.
- Solicitudes de alto volumen.
- Grupos con reaperturas elevadas.
- Incidentes causados por cambios.
- Ubicaciones con comportamiento atípico.
La evolución correcta es: ticket → patrón → causa raíz → conocimiento → automatización → incidente evitado. Un Service Desk maduro reduce progresivamente la demanda evitable.
¿Cómo evitar que el crecimiento de usuarios eleve el TCO?
La economía del soporte no se transforma preguntando únicamente cuánto cuesta cada agente. Debe analizarse el costo completo: TCO del soporte = personas + tecnología + proveedores + escalamiento + campo + recurrencia + tiempo improductivo del usuario. El crecimiento de usuarios deja de ser lineal cuando más resolución migra hacia:
- Autoservicio.
- IA.
- Runbooks.
- Remediación remota.
- FCR.
- Prevención.
Gartner plantea que la optimización del Service Desk debe perseguir simultáneamente eficiencia, productividad de usuario, confiabilidad y disponibilidad del servicio, no simplemente reducción de costo.
Un ejemplo de por qué el costo por ticket puede engañar
Supongamos dos mesas:
Mesa A
- Ticket barato.
- Muchas transferencias.
- Alto tiempo de espera.
- Alto volumen recurrente.
Mesa B
- Ticket ligeramente más caro.
- FCR alto.
- Mayor automatización.
- Menor recurrencia.
- Menor tiempo improductivo.
Finanzas podría elegir A si sólo ve costo unitario. El negocio probablemente preferirá B cuando incorpore el costo de productividad. La pregunta correcta es: ¿Cuánto cuesta mantener productivo al usuario? No solamente: ¿Cuánto cuesta cerrar su ticket?
¿Cómo traducir el soporte a EBITDA, ROI y riesgo operativo?
Impacto en productividad
Una fórmula útil es: Costo de productividad perdida = usuarios afectados × horas improductivas × costo laboral cargado por hora. La fórmula debe aplicarse con datos reales de la organización, no con benchmarks generales. Además, productividad recuperada no equivale automáticamente a EBITDA. Para convertirla en impacto financiero deben verificarse efectos como:
- Menos horas extra.
- Menor contratación incremental.
- Mayor capacidad transaccional.
- Menor outsourcing.
- Mayor producción.
- Menor pérdida de venta.
- Menos penalizaciones contractuales.
ROI del soporte integral
Puede modelarse así: ROI = (beneficio económico anual – costo anual del servicio) / costo anual del servicio. Donde el beneficio puede integrar:
- Tiempo productivo recuperado.
- Reducción de TCO.
- Menos visitas.
- Menos reincidencia.
- Menor MTTR.
- Menor costo de escalamiento.
- Automatización.
- Reducción de interrupciones.
Kenos by Scanda reporta públicamente $2.5 millones MXN de ahorro anual por automatización de soporte dentro de su evidencia operativa. Debe tratarse como evidencia de un caso previo, no como promesa de ahorro para cualquier nuevo cliente.
Riesgo y auditoría
Una mesa integral también debe producir evidencia:
- Identidad del solicitante.
- Cambios realizados.
- Aprobaciones.
- Accesos.
- Tiempos.
- Escalamientos.
- Dispositivo involucrado.
- Bitácoras.
- Evidencia de resolución.
Esto es particularmente importante en organizaciones reguladas. El enfoque de Kenos by Scanda es preciso en este punto: se deben prometer controles y evidencia, no garantizar cumplimiento regulatorio, porque la responsabilidad final de cumplimiento corresponde al cliente.
¿Qué métricas debe revisar la dirección?
Una operación preparada para 52,000 usuarios no debería llegar al comité con una diapositiva cuyo gran triunfo sea “cerramos 18,462 tickets”. Dirección debería poder responder, al menos:
- FCR: ¿qué porcentaje se resolvió en el primer contacto?
- Tiempo a productividad: ¿cuánto tardó realmente el usuario en volver a operar?
- MTTR: ¿cuánto tardan los incidentes relevantes en recuperarse?
- Resolución sin intervención humana: ¿qué porcentaje fue autoservicio o automatización?
- Adopción del autoservicio: ¿los usuarios realmente utilizan los canales habilitados?
- Reincidencia: ¿qué proporción de la demanda ya había ocurrido?
- Backlog crítico: ¿qué permanece abierto con impacto de negocio?
- Costo por usuario productivo: ¿la operación se vuelve más eficiente al crecer?
- Visitas evitadas: ¿cuánto se resolvió de manera remota?
- SLA: ¿se entregó el servicio comprometido?
- XLA: ¿la experiencia y productividad acompañaron al SLA?
- CSAT/NPS: ¿cómo percibe el usuario el soporte?
- Automatización efectiva: ¿cuántas interacciones fueron realmente resueltas, no sólo clasificadas por IA?
Kenos by Scanda propone métricas como disponibilidad por punto, tiempo a productividad, resolución sin intervención humana, adopción de autoservicio, incidentes evitados y costo por punto operando.
¿Qué evidencia aporta Kenos by Scanda a una operación de esta escala?
El argumento de Kenos no parte únicamente de una arquitectura teórica. Los materiales corporativos documentan:
- 52,000 usuarios TI atendidos al mes.
- Más de 25,000 puntos de venta atendidos.
- Cobertura operativa en 22 ciudades de 6 países.
- Operación de soporte y continuidad bajo modelos 24×7.
- Un caso de Service Desk con 30% de interacciones automatizadas y 20% de reducción de TCO.
- Un caso con más de 37% de reducción de MTTR en incidentes mayores.
- $2.5 millones MXN de ahorro anual asociado a automatización de soporte en evidencia publicada por Kenos.
Estas cifras no deben presentarse como resultados garantizados para un nuevo cliente. Su función comercial es distinta: demostrar que automatización, TCO, recuperación, productividad y escala pueden medirse en una operación real. Ese matiz aumenta la credibilidad del contenido y, de paso, evita la tradicional gimnasia comercial de convertir un caso de éxito en ley de la física.
Conclusión predictiva
Atender 52,000 usuarios de TI al mes no será, cada vez menos, un problema de dimensionamiento de agentes. Será un problema de mezcla de resolución. La IA absorberá clasificación, conocimiento, solicitudes repetitivas y parte creciente del diagnóstico; el soporte humano se concentrará en excepciones, incidentes críticos, juicio, coordinación y mejora continua. IBM ya describe esta evolución como una forma de aumentar escala sin replicar proporcionalmente el crecimiento del personal.
Por ello, las organizaciones que sigan administrando el Service Desk por número de tickets tendrán cada vez menos visibilidad del valor generado. Las que midan tiempo a productividad, FCR, recurrencia, automatización efectiva y costo por usuario productivo podrán conectar la operación de soporte con productividad, TCO y retorno financiero.
En ese modelo, Kenos by Scanda funciona como facilitador de productividad del usuario sin fricciones: conecta Service Desk, IA, endpoints, atención en sitio, datos y gobierno para reducir interrupciones y devolver capacidad productiva al negocio.
¿Su Service Desk puede crecer sin que crezcan al mismo ritmo el costo y la fricción?
El siguiente paso es establecer una línea base: volumen, recurrencia, FCR, tiempo a productividad, automatización y TCO. A partir de esos datos se pueden identificar las tres fricciones que más capacidad consumen y construir un roadmap de 90 días con resultados medibles.
Hable con Kenos by scanda y evalúe qué porcentaje de su soporte todavía depende de intervención humana y cuánto tiempo productivo podría recuperar su organización.
FAQ
- ¿Cuántos agentes se necesitan para soportar a 52,000 usuarios? No puede calcularse únicamente con el número de usuarios. El dimensionamiento requiere conocer interacciones mensuales, distribución horaria, tiempo promedio de atención, FCR, canales, cobertura, complejidad, estacionalidad, automatización y porcentaje de escalamiento. Dos organizaciones con 52,000 usuarios pueden necesitar capacidades radicalmente diferentes.
- ¿Cómo puede un CFO justificar la inversión en un Service Desk integral? Debe comparar el TCO actual contra un baseline que incluya no sólo personal y herramientas, sino tiempo improductivo, reincidencia, visitas, escalamiento y costo de interrupción. La inversión se justifica cuando la reducción de esos costos y la productividad recuperada superan el costo incremental del modelo.
- ¿La automatización y la IA en el Service Desk incrementan el riesgo de seguridad? Pueden hacerlo si se automatizan privilegios sin controles. La arquitectura debe incorporar verificación de identidad, mínimo privilegio, aprobaciones, segregación de funciones, trazabilidad y límites claros de ejecución. Los casos de mayor impacto o privilegio deben mantener intervención o aprobación humana.
