El sistema de tickets de ServiceNow: cómo funciona y cuánto cuesta

Qué es realmente un sistema de tickets de ServiceNow

Empecemos desde abajo. La base explica todo lo que hay encima.

Cada ticket en ServiceNow vive en una tabla que extiende de un único padre. La propia documentación de la empresa es directa al respecto: la tabla Task "es una clase base que proporciona campos para las aplicaciones ITSM principales como Incident, Problem y Change Management. Todas las aplicaciones que extienden la tabla Task comparten estos campos en común".

No puedes escribir directamente en task. Si lo intentas, un Task Interceptor te detiene y te obliga a elegir primero una tabla hija. El campo sys_class_name registra entonces qué hija elegiste. Para siempre.

Aquí está toda la familia con los nombres exactos de tabla, ya que el nombre de la tabla es lo que determina el comportamiento:

Los prefijos tampoco están fijados en el código. Son filas en la tabla sys_number bajo System Definition, y cualquier administrador puede cambiarlos, según la documentación de ServiceNow sobre numeración de registros. Si vienes de una herramienta plana como Zendesk, esta es la primera diferencia real que notas: aquí el tipo de registro es una decisión de esquema, no una lista desplegable en un formulario.

El beneficio de toda esa herencia es real, y merece reconocimiento antes de que empiece a señalar problemas. Aprobaciones, reglas de asignación, SLA, monitores de inactividad y flujos funcionan todos sobre cualquier cosa que extienda task, así que los construyes una vez. Eso es algo que una herramienta de mesa de ayuda más pequeña no puede igualar, y es lo que separa una plataforma de un sistema de tickets automatizado. Los usuarios también lo notan.

"Keeping requests, incidents, and changes connected is the core of this platform, which I really appreciate. Plus, finding related knowledge without leaving the ticket open. And lastly, bringing different IT tools together through integrations."

Louis B., G2

Así es como se ve un registro una vez que estás dentro de uno. Fíjate en los campos que hacen el trabajo de enrutamiento, Assigned to y Assignment group, ambos heredados directamente de task:

Una solicitud, tres números de ticket

Aquí es donde el primer día sale mal, para casi todos.

Alguien pide un portátil. En un sistema de tickets normal eso es un ticket, y en la mayoría de los sistemas de tickets internos sigue siendo un ticket hasta la entrega. ServiceNow lo convierte en tres tipos de registro, porque Request Management modela deliberadamente la petición, el artículo y el trabajo como cosas separadas:

1. REQ en sc_request, el contenedor a nivel de carrito. Un checkout da un REQ.
2. RITM en sc_req_item, uno por artículo del catálogo. Un portátil y un monitor en el mismo checkout significan un REQ con dos RITM.
3. SCTASK en sc_task, el propio trabajo de cumplimiento, generado por el flujo del RITM. Adquirirlo, formatearlo y enviarlo: tres SCTASK a partir de un único RITM.

Así que una persona que pide una sola cosa puede generar fácilmente cinco registros repartidos en tres series de números, con tres lugares distintos donde ir a comprobar un estado. No es un error. Es la separación de carrito, artículo y trabajo, construida a propósito. Y es también, de forma constante, lo que hace tropezar a los agentes nuevos:

"At times, especially as a beginner, it may be hard to navigate with all the various levels of a customer ticket--Interactions, Requests, RITMs, SCTasks etc. And then there's the occasional what seems like a bug."

Andrei F., Knowledge Specialist, Capterra

Los artículos del catálogo que generan la mayor parte de este volumen son los más aburridos. Las solicitudes de acceso son la categoría individual más grande y la que más merece automatizarse. Las peticiones de kits y equipos le siguen de cerca, y nuestra guía sobre solicitudes de hardware las trata por separado.

Una trampa que conviene conocer si eres quien construye el catálogo: las variables solo existen en sc_req_item. ServiceNow lo dice claramente: "Las variables no son compatibles con las tablas extendidas". Todo lo que el usuario escribió en el formulario del catálogo queda entonces en el RITM, y hacer que llegue al SCTASK, donde el fulfiller realmente puede verlo, es un acto deliberado de configuración. Si tus fulfillers no dejan de preguntar "qué tamaño de monitor querían", esa es la razón.

El ciclo de vida del incidente, estado por estado

Los incidentes son la mitad más simple. El modelo de estados está publicado en su totalidad.

Lo leíste bien, no existe el 4 ni el 5. Son huecos quemados, dejados por el modelo anterior a Helsinki, que tenía tres estados de espera separados donde ahora hay uno solo, On Hold. El propio artículo de conocimiento de ServiceNow KB0564465 publica el mapeo y te dice exactamente qué se rompe: "si tenías un flujo de trabajo que se activaba en el estado 5, debes modificarlo para que se active en el estado 3, motivo 2."

Ahora la parte que más me sorprendió en la documentación. ServiceNow recomienda no instalar el modelo de estados moderno en instancias actualizadas. Lo que significa que muchas instancias de producción de larga vida siguen ejecutando la vieja forma de cinco estados bajo una interfaz moderna. Cualquier informe o flujo de trabajo escrito contra un número de estado en bruto depende de la versión, así que es una pregunta real que hacer antes de heredar la instancia de otra persona.

Tres comportamientos que sorprenden

La prioridad no es una decisión del agente. Se calcula a partir de una cuadrícula de 3x3 de Impact y Urgency, y el campo viene de solo lectura. ServiceNow lo dice directamente en la página de reglas de búsqueda de prioridad: "Los responsables individuales de incidentes no pueden cambiar las reglas de búsqueda de prioridad." Un P3 que todos coinciden en que debería ser un P1 se convierte en una conversación con un administrador, no en una lista desplegable.

El cierre automático es un trabajo programado, no un temporizador en el registro. De ahí se derivan dos consecuencias. Primero, el rastro de auditoría miente, porque "asigna el nombre del administrador que tenía la sesión iniciada cuando se ejecuta el trabajo Autoclose Incidents al campo Updated by." Segundo, un monitor de inactividad "reinicia este reloj de cierre automático cada vez que se activa", así que una instancia que ejecuta ambas funciones acumula silenciosamente incidentes Resolved que nunca se cierran, y nada saca el conflicto a la luz. La solución, según la documentación de ServiceNow, es una Reset Condition de [Incident state] [is not] [Resolved].

Cerrar un padre no cierra sus hijos. Resolverlo sí. Cerrarlo no. Pon cien hijos bajo un padre de una interrupción de red, y cerrar el padre deja cien registros Resolved esperando a llamantes individuales, según la tabla de sincronización padre-hijo. Esa asimetría es un contribuyente habitual a un backlog de tickets que se ve peor en un panel de lo que realmente es.

Cómo se enrutan realmente los tickets

El enrutamiento funciona sobre dos campos heredados, assigned_to y assignment_group, por eso se comporta igual en todos los tipos de registro. Las reglas de asignación los establecen automáticamente cuando coinciden las condiciones.

Hay una regla sobre esas reglas que merece un póster. De la documentación de reglas de asignación: "Las reglas de asignación no pueden sobrescribir asignaciones existentes (incluidas las establecidas por un valor predeterminado o por una regla de asignación ejecutada previamente)." Un valor predeterminado bien intencionado en assignment_group deshabilita entonces, en silencio, todas las reglas de enrutamiento que escribas después. Y cuando varias reglas coinciden, solo se ejecuta la de menor valor de orden. Siempre.

También hay una trampa de permisos, y la primera vez que la encuentras parece un error: un usuario con el rol itil no puede asignar un incidente a un grupo que tenga el rol admin o security_admin, ni a ningún grupo cuyo padre tenga esos roles.

Para profundizar más en cómo hacer bien esta capa, nuestra guía sobre enrutamiento de tickets con IA va más allá de lo que puedo cubrir aquí, mientras que el artículo complementario sobre etiquetar tickets con IA cubre la mitad de la clasificación. La visión más amplia de la categoría está en nuestra guía sobre tickets de TI automatizados.

SLA, y el campo que no hace nada

El Service Level Management de ServiceNow es sólido, y una sola task puede llevar varios SLA a la vez, cada uno rastreado en su propio registro task_sla. Los usuarios lo valoran así:

"The SLA tracking feature is another aspect I like, as it helps our team assess the performance of the person resolving issues."

vignesh m., admin, G2

Hay dos cosas que vale la pena saber antes de diseñar tus acuerdos.

Primero. La distinción entre SLA, OLA y contrato de respaldo, a la que cualquier curso de ITIL dedica una hora entera, dentro del producto es solo una etiqueta. La nota de ServiceNow sobre el campo Type ocupa una sola frase: "Type se usa únicamente con fines de generación de informes." Mismo motor, mismas condiciones, mismos cálculos exactos. El campo Target de Response frente a Resolution es la misma historia, existe "solo con fines de filtrado, búsqueda y generación de informes."

Segundo, los días no son días hábiles. La documentación explica la trampa: "El número de días especificado en este campo se convierte en bloques de 24 horas. Si el campo Schedule identifica un horario de días de ocho horas, una duración de 1 día hace que el SLA se incumpla tres días hábiles después." Un diseño razonable. También una forma muy fácil de lanzar un SLA que falla durante un año antes de que alguien lo note.

Vale la pena saber también: en una instancia moderna, Breached no es en absoluto una etapa de task_sla. Las etapas son In progress, Cancelled, Paused y Completed. Breached sobrevive solo "en sistemas que usan el motor de SLA de 2010, o que funcionan en modo de compatibilidad", y aun así el widget visual del temporizador sigue mostrándolo, así que los dos vocabularios no coinciden. Construye reportes de SLA sobre eso, y esa discrepancia te encontrará.

Autoservicio, y qué desvía realmente el Virtual Agent

El autoservicio es donde vive la historia del volumen de tickets, y donde los niveles empiezan a importar.

El Virtual Agent completo es capaz. ServiceNow trae temas de ITSM preconstruidos que hacen trabajo real. Check IT Ticket Status lista los tickets activos de un usuario con su etapa y última actualización. Escalate IT Ticket eleva un nivel la urgencia, con una justificación obligatoria. También hay temas para reservar salas de conferencias y equipos asignados. La desviación en sí está definida de forma estricta, como "cuando un usuario hace una pregunta o una solicitud que no termina en un ticket ni en asistencia humana."

Virtual Agent Lite, lo que reciben los clientes de niveles inferiores, es un animal distinto. Trae dos temas, Check Ticket Status y Report an Issue. Sin NLU alguno, solo coincidencia de palabras clave. No puedes añadir temas ni canales. Y, de forma crítica, no tiene panel de análisis, así que no hay forma admitida de medir cuánto desvió. Evaluar la desviación en Lite significa evaluar algo que no puedes medir, algo que vale la pena saber antes de compararlo con cualquier chatbot de mesa de servicio que sí reporte una tasa de resolución. Los equipos que chocan con ese muro suelen terminar mirando alternativas a Virtual Agent.

Otra restricción muerde en producción. Transferir a un humano requiere un humano. "Debe haber al menos un agente en vivo disponible al transferir desde Virtual Agent, de lo contrario el usuario final ve un mensaje de no agents available y su conversación no se transfiere." No existe ningún respaldo documentado de ticket en esa ruta, que es exactamente el momento en el que más importa un buen diseño de traspaso de IA.

La recepción por correo electrónico tiene su propia versión del problema. La clasificación como reenvío gana a la marca de agua, así que ServiceNow "clasifica cualquier correo que cumpla estos criterios como un reenvío, incluso si el mensaje contiene una marca de agua o número de registro que de otro modo lo clasificaría como una respuesta." En términos claros, reenviar un hilo de correo a ServiceNow siempre crea un ticket duplicado.

Cuánto cuesta un sistema de tickets de ServiceNow en 2026

Ahora la parte por la que todos vinieron en realidad.

ServiceNow no publica precios, por eso existe nuestra guía de precios de ServiceNow. Volví a revisar la página de precios de ITSM el mismo día en que escribo esto. Tres paquetes, Foundation, Advanced y Prime. Un botón que dice "Get Custom Quote." Ningún símbolo de moneda en toda la página. Los únicos números en toda la matriz comparativa son los límites de capacidad para las tablas de App Engine Starter y los registros de Process Mining.

Desde el 9 de abril de 2026 los antiguos niveles Standard, Pro, Pro Plus, Enterprise y Enterprise Plus desaparecieron, y los SKU heredados llegaron a fin de venta el 1 de julio de 2026. Foundation, Advanced y Prime son ahora la única estructura que ve cualquier comprador nuevo.

Lee la fila de IA dos veces. Es todo el empaquetado en una sola línea. La IA que realmente cierra un ticket sin un humano es exclusiva de Prime. Foundation y Advanced obtienen en su lugar IA asistiva: resúmenes, borradores, un chatbot. Un MVP de ServiceNow escribiendo en la comunidad dice lo mismo sobre las construcciones personalizadas, que Prime "es el único nivel que te permite construir habilidades y agentes de IA personalizados y completamente nuevos en la plataforma." Así que AI Agent Studio es una función del nivel superior más que de la plataforma en general, y el panorama de costos más completo está en nuestro desglose de precios de IA de ServiceNow.

La división aparece también en el propio marketplace de ServiceNow, donde el L1 IT Service Desk AI Specialist se sitúa junto al filtro de persona que nombra a Fulfiller como su propia clase con licencia:

A quién pagas realmente

Este es el único hecho que hace que "cuánto cuesta ServiceNow" sea siquiera respondible. Para ITSM, se factura sobre el rol de Fulfiller. Un empleado de ServiceNow que escribe la guía de licencias lo define como "tus agentes principales de la mesa de servicio, gestores de casos y responsables de flujos de trabajo. Cualquiera que trabaje activamente y resuelva registros", contados como usuarios activos que iniciaron sesión en los últimos 365 días.

Los solicitantes, es decir, los empleados que abren los tickets, no se cuentan. Una ventaja real frente a las herramientas por asiento, y el mismo tipo de ahorro que hace que Jira Service Management sea más barato que Jira normal para un caso de uso de soporte.

Entonces llegan las dos excepciones.

Un gerente que solo aprueba cosas cuenta como un Business Stakeholder medido por separado, no como un usuario gratuito. Y algunos productos facturan bajo el modelo de Unrestricted User, donde cuenta cada usuario activo de la instancia. HRSD y Employee Center Pro están ambos en ese grupo. Así que el ahorro de "los solicitantes son gratis" se evapora el día que compras el buen portal, o el día en que RR. HH. quiere entrar.

El tamaño de esa decisión no es pequeño. Un arquitecto técnico certificado de ServiceNow escribe públicamente:

"In the world of ServiceNow platform governance, one decision stands above the rest in terms of financial impact: choosing between the Fulfiller (Named User) and the Unrestricted User model. As a ServiceNow Certified Technical Architect (CTA), I've seen this single choice result in a $780,000 variance in spend over a standard 3-year contract."

Bill Martin, ServiceNow Community

Entonces un empleado de ServiceNow aparece en los comentarios para corregir la lectura errónea habitual de la alternativa:

"One quick correction though: Unrestricted Users (UU) aren't actually flat fee. They're still user-based. The "unrestricted" part means unlimited roles within the module, but if the customer's sys_user table grows, they're buying more UU licenses."

Lenny Leppers, ServiceNow Community

Dos trampas más del mismo arquitecto, ninguna de las cuales aparece en ninguna página de precios. Las licencias son por instancia, así que tener instancias separadas para Norteamérica y EMEA duplica la factura. Y sitúa a los usuarios fantasma en "un 20-25% de las licencias de ServiceNow" en grandes empresas, frente a un incremento anual del 7 al 12%. Nuestra guía de tipos de licencia recorre todo el conjunto si estás en plena negociación.

El medidor de assists, ahora público

Aquí está la novedad. El 23 de julio de 2026, ServiceNow publicó el Now Assist Overview como documento legal, y con él llegó el tarifario por acción. Hasta ocho días antes de escribir esto, ninguna de esas cifras era pública.

Un assist es "una unidad usada para medir el uso de las habilidades de Now Assist mediante acciones de habilidad realizadas", y se consume "tanto en instancias de producción como de sub-producción." Los derechos se agrupan a nivel de cuenta y se reinician en el aniversario de tu compra en lugar de en el año natural. Si los superas, "ServiceNow puede facturar al Cliente por el uso excedente."

La dispersión, a través de tres órdenes de magnitud, es la verdadera historia:

Un "flujo de trabajo agéntico" termina al completarse, a las 20 acciones, o tras una hora de inactividad. Cualquier cosa después de esas 20 acciones inicia un nuevo flujo de trabajo facturable. Así que un ticket puede costarte como dos.

La frase a la que sigo volviendo viene de una guía práctica de ServiceNow: "La sorpresa para la mayoría de los equipos es que el mayor consumo no proviene de usuarios escribiendo prompts. Es la automatización ejecutándose en segundo plano." Nombra cuatro fuentes de consumo silencioso. Virtual Agent recurriendo a Now Assist en un tema sin coincidencia, el resumen del espacio de trabajo activándose al abrir un caso, habilidades personalizadas de Skill Kit, e instancias de sub-producción. ServiceNow lanzó interruptores de emergencia y alertas de picos en junio de 2026 para contener todo esto, con una instrucción documentada de no desactivar las notificaciones porque "¡Los entornos de sub-producción también consumen assists!"

ServiceNow no publica un tamaño de grupo para los niveles nuevos, así que aplica tus propios números contra la última asignación que sí publicó: 6.000 assists por fulfiller al año, bajo el modelo heredado Pro Plus.

Mueve el control deslizante del agente autónomo del 5% al 15% y observa qué pasa. Ese único movimiento es toda la diferencia entre la IA asistiva y la IA autónoma por la que compraste Prime. También es por eso que yo querría un pronóstico de assists por escrito durante la conversación del contrato, no después de ella.

Lo que la gente dice realmente sobre trabajar con esto

Quiero ser justo aquí. Es fácil construir un artículo hostil a partir de una búsqueda de quejas.

El conjunto de datos no respalda uno. ServiceNow ITSM tiene 4,5 sobre 5 en 1.915 reseñas en G2, el 70% de ellas con cinco estrellas y, cabe destacar, cero por ciento con una estrella. Capterra lo sitúa en 4,5 sobre 352 reseñas. Nadie serio argumenta que el modelo de incidente, cambio y CMDB esté mal planteado.

Lo que dicen es que es pesado. El propio recuento de etiquetas de G2 sitúa Ease of Use como el atributo más elogiado con 168 menciones, con Learning Curve (72), Expensive (60) y Complexity (56) justo detrás. Esa tensión es el resumen honesto del producto.

Sobre la experiencia diaria:

"There's a lot of clicks which takes a long time"

Chris C., G2

Sobre la curva de aprendizaje, de un desarrollador que aun así le dio 4,5 sobre 5:

"ServiceNow IT Service Management is huge, and when I started as a developer, it took months to really understand how everything connects like tables, scripts, workflows, ACLs. The documentation exists but is scattered, and half the time, you end up finding answers in community forums instead of official docs."

Shruti C., Developer, G2

Y la metáfora más afilada de todo el conjunto, de una implementación que claramente salió mal:

"Imagine you go to a car dealer to buy a new car. You pay the money and you get the keys. When you get outside to pick your new car you see a bunch of parts in a pile. So if you want to drive your car you need to put it together."

Verified User in Insurance, G2

El contrapeso, y creo que es lo más cierto que dijo alguien en todo el conjunto: la opinión de la mayoría de la gente sobre ServiceNow es en realidad una opinión sobre la implementación de otra persona. Un comentarista de Hacker News lo expresó como que "una instancia bien gestionada puede volar", y culpó a la mayoría de las malas experiencias a clientes que "arrastran código horrible y apps LCNC mal diseñadas." Eso coincide con lo que yo veo. La plataforma rara vez es el problema. El formulario de 400 campos que alguien construyó encima suele serlo.

Dónde encaja, y dónde yo no lo usaría

ServiceNow es la decisión correcta cuando los tickets no son el punto central. Si lo que necesitas son incidentes vinculados a una CMDB, gestión de cambios con autorización CAB real, registros de problemas que sobreviven a los incidentes que los originaron, más un único motor de flujo de trabajo que abarque TI, soporte de RR. HH. e instalaciones, nada en el mercado medio lo iguala. Frente a frente contra Freshservice, esa amplitud es todo el argumento. A esa escala, vale el dinero.

Yo no lo compraría para gestionar una simple cola. Si tickets que entran y tickets que salen es todo el trabajo, pagarás precios de plataforma empresarial por una fracción de la plataforma, y la queja de la herramienta de tickets cara se escribe sola. Un comentarista de Hacker News describió a un CIO haciendo exactamente eso: reemplazando un rastreador existente para solo dos colas, sin CMDB ni gestión de cambios, por "128k al año." Si esa es la forma de tu necesidad, nuestro resumen para equipos pequeños o las opciones de código abierto son la respuesta honesta.

El tercer caso es el interesante, y es donde realmente se encuentra la mayoría de los lectores de este artículo. ServiceNow ya está instalado, no va a ninguna parte, y la cola sigue creciendo. Arrancarlo no está sobre la mesa. Añadir un nivel Prime para que un especialista de IA pueda cerrar tickets de nivel uno es una conversación de presupuesto con un medidor no publicado adjunto. Eso deja una única palanca, la misma en la que acaba aterrizando todo proyecto de IA para mesa de ayuda de TI: la desviación en el punto de entrada.

Prueba eesel delante de tu cola de ServiceNow

Déjame ser directo sobre lo que ofrezco y lo que no ofrezco aquí. La versión honesta es de todos modos más útil.

eesel no es un plugin de ServiceNow. No hay integración de ServiceNow en nuestra página de integraciones, y prefiero decirlo aquí antes que dejar que lo descubras a mitad de una prueba.

Lo que hace eesel es situarse un paso antes, en los canales donde realmente empiezan las preguntas de TI. Responde en Slack, en Microsoft Teams y por correo electrónico, antes de que nadie abra un formulario. El conocimiento con el que responde es la documentación que ya escribiste, viva donde viva hoy: Confluence, Google Docs, Notion, un centro de ayuda.

Yo construyo los agentes que hacen esto, así que el mecanismo me importa. El agente busca en tu documentación real, responde cuando tiene fundamento para hacerlo, y se queda callado cuando no lo tiene. Esa última parte es todo el juego. Tras ver cómo un bot con voz confiada daba respuestas equivocadas en una cola en vivo, ahora simulamos cada implementación contra tickets históricos antes de que llegue nunca a una persona real, y cualquier cosa por debajo del umbral de confianza escala en lugar de adivinar.

El número que señalaría no es nuestro. Jason Loyola, Head of IT de InDebted, ejecuta eesel como primer respondiente en su mesa de TI interna, y los resultados son públicos: 15% de los problemas entrantes desviados por completo hoy en día, con 55% como objetivo a medida que el conocimiento se escribe de vuelta desde los tickets resueltos. Su propia descripción de la configuración: "Esencialmente actúa igual que lo haría un agente."

Dos límites más, porque deberías conocerlos antes de probarlo. No va a arreglar un problema de documentación. Si la respuesta a "cómo consigo un portátil nuevo" no está escrita en ningún lugar de tu base de conocimiento interna, ninguna IA va a inventarla. Y es una capa, no un reemplazo, así que tu modelo de incidentes, cambios y CMDB se queda exactamente donde está. El precio funciona por ticket gestionado en lugar de por asiento, lo que al menos significa que la factura no sube cada vez que TI contrata a alguien.

Puedes probarlo gratis y apuntarlo a las preguntas que tu mesa de servicio responde cincuenta veces al mes, y ver cuántas de ellas necesitaron realmente un ticket.