Resumen
- El valor técnico de ServiceNow debe juzgarse por la resolución aceptada de un caso, incidente o solicitud real, no por la fluidez de una respuesta generada. La plataforma puede conectar el estado del ticket, el contexto de la CMDB, las reglas de flujo de trabajo, las integraciones, los controles de acceso, los registros de auditoría, Now Assist y los agentes de IA, pero cada una de esas capas también puede introducir un modo de fallo: datos de configuración obsoletos, asignación incorrecta, discrepancia de permisos oculta, tiempo de espera de integración, incidente duplicado, cierre prematuro, recomendación alucinada o un caso reabierto que expone que la solución original fue incompleta.
- La evidencia pública respalda una afirmación limitada. ServiceNow tiene una maquinaria madura para flujos de trabajo de casos, estados del ciclo de vida de incidentes, seguimiento de incidentes reabiertos, salud de la CMDB, Integration Hub, manejo de errores de Flow Designer, Workflow Data Fabric, controles de acceso, registros de auditoría y gestión de conflictos de actualización. Estas características son relevantes para la confiabilidad porque convierten el trabajo de servicio en transiciones de estado gobernadas en lugar de conversaciones sueltas. No prueban que un comprador logrará un menor costo o una resolución más rápida. El diseño de los procesos del cliente, la calidad de los datos, la calidad de la implementación del socio, la confiabilidad de los sistemas externos y las decisiones de licencia siguen siendo decisivas.
- El argumento comercial es sólido pero no se prueba a sí mismo. ServiceNow reportó $13,278 millones en ingresos en 2025, incluidos $12,883 millones de ingresos por suscripciones, y una tasa de renovación del 98 por ciento para cada uno de 2025, 2024 y 2023 en su Formulario 10-K de 2025. En el primer trimestre de 2026, reportó $3,671 millones de ingresos por suscripciones y $27,700 millones de obligaciones de desempeño restantes. Estas cifras muestran una gran demanda empresarial de una plataforma de flujo de trabajo. No prueban que los agentes de IA, la automatización de la CMDB o el cierre de casos entre sistemas reduzcan el trabajo después de contabilizar la implementación, supervisión, uso de tokens, actualizaciones y mantenimiento de integraciones.
El caso cerrado es la prueba unitaria
La forma más fácil de sobrevalorar ServiceNow es evaluarlo como un generador de texto. Un usuario hace una pregunta, Now Assist resume el incidente, un agente de IA propone un siguiente paso y la respuesta visible parece competente. Eso no es suficiente. En los entornos operativos a los que se vende ServiceNow, la respuesta es solo un evento dentro de una cadena más larga. La solicitud debe clasificarse. El servicio o activo afectado debe identificarse. La persona que llama debe tener los permisos correctos. El artículo de conocimiento relevante debe seguir siendo válido. El incidente o caso debe enrutarse al grupo correcto.
Es posible que se necesite consultar o actualizar sistemas externos. Puede ser necesaria una aprobación. La solución puede requerir un registro de cambio. La nota de resolución debe explicar lo que se hizo. El caso debe cerrarse sin reabrirse inmediatamente.
Es por eso que la prueba más útil para ServiceNow es un caso cerrado que permanece cerrado. La Now Platform importa cuando preserva el contexto, la autoridad y la evidencia en las transferencias. Un centro de servicios que cierra tickets rápidamente suprimiendo la complejidad no ha automatizado la resolución; ha ocultado trabajo no resuelto. Un caso de servicio al cliente que produce una respuesta educada mientras el sistema de facturación, derechos o inventario sigue siendo incorrecto no ha reducido el costo; ha trasladado el costo al siguiente contacto.
Un flujo de trabajo de seguridad u operaciones que permite que una sugerencia de IA actualice el registro incorrecto no ha mejorado la productividad; ha convertido el modelo de permisos en parte del incidente.
El propio lenguaje de producto de ServiceNow apunta a la amplitud de la afirmación. La compañía dice que la ServiceNow AI Platform conecta IA, datos y flujos de trabajo en una sola plataforma, y su informe anual de 2025 describe una plataforma basada en la nube que admite aplicaciones de flujo de trabajo en las categorías de Tecnología, CRM e Industria, Negocio Principal, y Creador y Otros (ServiceNow 2025 Formulario 10-K). La página de producto de ITSM dice que ITSM conecta la gestión de incidentes, problemas, cambios y solicitudes en una sola plataforma de IA (ServiceNow ITSM). Esa amplitud es el punto y el riesgo. ServiceNow no es solo un formulario de ticket. Es un lugar donde el trabajo empresarial se representa como estado, datos, permisos y acciones.
Por lo tanto, la pregunta útil es concreta: cuando una solicitud ingresa al sistema, ¿puede ServiceNow mantener suficiente veracidad a su alrededor para decidir qué debería suceder después? La respuesta depende menos de una característica de IA que de la calidad del registro subyacente. Una respuesta generada sin un estado de incidente confiable, un contexto de CMDB actual, una ACL correcta, una integración funcional y un flujo de trabajo observable es solo una oración plausible. Un flujo de trabajo menos deslumbrante que preserva el estado y la evidencia puede ser mucho más valioso.
Lo que realmente posee ServiceNow
ServiceNow posee la plataforma, sus aplicaciones, su documentación, su modelo de lanzamiento, sus obligaciones de servicio en la nube y la superficie de producto en torno a Now Assist, agentes de IA, Workflow Data Fabric, CMDB, ITSM, CSM, Integration Hub, Flow Designer y muchos otros módulos.
No posee la madurez de los procesos del cliente, la calidad de los datos, la taxonomía de servicios, el inventario de endpoints, los datos de RR.HH., los sistemas de facturación, el proveedor de identidad, las herramientas de monitoreo, el socio de servicios gestionados, las excepciones de flujos de trabajo heredados o cada modelo y conector de terceros utilizado en una implementación.
Ese límite no es una nota defensiva al pie de página. Es el núcleo económico del producto. ServiceNow vende una forma de coordinar el trabajo entre sistemas que no fueron diseñados para funcionar juntos. Si la plataforma puede absorber suficiente contexto de esos sistemas y aplicar políticas de manera consistente, reduce el costo de coordinación. Si la plataforma se convierte en otra capa de mapeos, excepciones y registros obsoletos, el costo regresa en servicios de implementación, mantenimiento de integraciones, enrutamiento incorrecto, revisión manual y gobernanza de la plataforma.
El Formulario 10-K de 2025 de la compañía es franco sobre el riesgo de implementación. Dice que los requisitos comerciales, de integración, migración, cumplimiento y seguridad del cliente, así como los errores de ServiceNow, socios o clientes, pueden hacer que las implementaciones se retrasen, sean ineficientes o no tengan éxito, y que las implementaciones fallidas o costosas pueden perjudicar las renovaciones y la reputación (ServiceNow 2025 Formulario 10-K). Ese es el factor de riesgo adecuado para este artículo porque no se trata de si ServiceNow tiene características. Se trata de si el comprador puede convertir esas características en una práctica operativa confiable.
El mismo documento describe la arquitectura de la plataforma de ServiceNow como una que integra IA, datos y flujos de trabajo, pero también señala costos crecientes para respaldar las ofertas de suscripción, los mercados regulados, los servicios en la nube de terceros y los requisitos de residencia de datos. Eso es importante para los compradores porque el valor de la plataforma de ServiceNow se crea en parte mediante la centralización. La centralización no significa que la simplificación sea automática. Significa que más trabajo se coloca bajo un solo contrato operativo.
El comprador obtiene una capa de flujo de trabajo común, pero también acepta una dependencia de la cadencia de lanzamiento de ServiceNow, la estructura de licencias, el ecosistema de socios y la gobernanza específica de la plataforma.
La diferencia entre la propiedad del producto y la propiedad del cliente debería dar forma a cada afirmación de confiabilidad. ServiceNow puede proporcionar un modelo de estado de incidente. El cliente decide si las categorías de incidentes tienen sentido. ServiceNow puede exponer indicadores de salud de la CMDB. El cliente decide si se mantienen las fuentes de descubrimiento y las reglas de reconciliación. ServiceNow puede proporcionar Integration Hub. El cliente decide qué credenciales, reintentos, mapeos de datos y dependencias de servicios externos son aceptables. ServiceNow puede proporcionar Now Assist y agentes de IA.
El cliente decide dónde esos agentes pueden actuar y dónde un humano debe aprobar.
El estado del caso es más importante que la conversación
El ciclo de vida del incidente es un lugar sencillo para ver por qué importa la integridad del estado. La documentación de ServiceNow dice que la Gestión de Incidentes gestiona el ciclo de vida de los incidentes desde la creación hasta el cierre, con estados como Nuevo, En Progreso y En Espera, y describe En Espera como un cambio temporal de responsabilidad a otra entidad para información, evidencia o resolución (Documentación del ciclo de vida de incidentes de ServiceNow). Ese lenguaje es operativamente importante. Un caso no es solo un hilo de conversación. Es un registro de responsabilidad, evidencia y progreso.
La documentación de reapertura de ServiceNow hace el mismo punto desde el otro extremo. Dice que un incidente resuelto puede ser reabierto por ciertos usuarios, que la reapertura cambia el estado de Resuelto a En Progreso, y que campos como Reabierto por última vez, Reabierto por última vez en y Recuento de reaperturas ayudan a respaldar los informes y la auditoría de incidentes reabiertos (Documentación de reapertura de incidentes de ServiceNow). El seguimiento de reaperturas es una señal de confiabilidad sobria. Un flujo de trabajo que cierra un caso rápidamente pero lo reabre con frecuencia no es necesariamente mejor que un flujo de trabajo más lento que resuelve el problema subyacente la primera vez.
Aquí es donde la asistencia de IA debe medirse cuidadosamente. Now Assist para ITSM puede resumir la información del incidente, generar notas de resolución de incidentes y resumir el chat de una interacción, al tiempo que ayuda a los agentes a comprender el chat y el contexto del incidente (Documentación de Now Assist for ITSM). Esas capacidades pueden ahorrar tiempo si reducen el trabajo de lectura y redacción. También pueden crear riesgos si los agentes aceptan resúmenes que omiten incertidumbre, si las notas de resolución generadas implican trabajo que no se realizó, o si el contexto resumido proviene de registros obsoletos.
El punto de referencia correcto no es '¿la IA escribió una buena nota?' Sino '¿la nota correspondía al estado del caso, al trabajo realizado y a la evidencia disponible?' Una nota de resolución que suena nítida pero no menciona una dependencia del proveedor, un cambio no resuelto, una solución alternativa conocida o una excepción específica del llamante puede hacer que los informes sean más limpios y al mismo tiempo dificultar el próximo incidente. En una plataforma construida en torno a la auditabilidad, el modo de fallo peligroso no es la prosa torpe. Es la prosa autorizada adjunta a una transición de estado débil.
Para los casos de uso de servicio al cliente, ServiceNow documenta la gestión de casos como un proceso para interactuar con los clientes, categorizar y enrutar casos, asignar trabajo a los agentes y gestionar los casos hasta la resolución y la presentación de informes (Documentación de gestión de casos de CSM de ServiceNow). Una vez más, el valor del producto radica en la ruta del estado. Un caso de cliente puede involucrar derechos de cuenta, inventario de productos, servicio de campo, facturación, historial de soporte y excepciones de pólizas. Si esos registros son incorrectos, la IA puede acelerar la respuesta incorrecta. Si esos registros son correctos, la IA puede reducir el tiempo dedicado a encontrar la siguiente acción responsable.
La lección operativa es sencilla: los compradores de ServiceNow deben medir la calidad de la resolución, no solo la velocidad de respuesta. La tasa de reapertura, la tasa de asignación incorrecta, el recuento de reenrutamientos manuales, el tiempo en espera por motivo, las referencias a conocimientos obsoletos, el recuento de reintentos de integración y el contacto con el cliente posterior a la resolución son mejores indicadores que el volumen de notas generadas.
Si la IA reduce el tiempo de manejo al tiempo que aumenta las reaperturas o las excepciones silenciosas, la plataforma ha optimizado la parte visible del proceso y debilitado la real.
La CMDB es la superficie de enrutamiento
La base de datos de gestión de configuración a menudo se discute como un repositorio, pero en la economía de ServiceNow se acerca más a una superficie de enrutamiento. Si la CMDB representa con precisión los servicios, activos, propietarios, dependencias y estado del ciclo de vida, la plataforma puede enrutar incidentes, evaluar el impacto y respaldar la automatización con contexto. Si la CMDB es incompleta o contradictoria, la automatización puede convertirse en un motor de desorientación confiado.
La documentación de CMDB Health de ServiceNow dice que una CMDB saludable es esencial para el uso efectivo y continuo del producto, y que indicadores como elementos de configuración duplicados, campos de CI requeridos y auditorías se agregan en puntuaciones de salud a nivel de clase, grupo de salud y servicio (Documentación de CMDB Health de ServiceNow). La redacción importa porque trata la salud como algo continuo, no como un hito de migración único. Una CMDB puede ser precisa en el lanzamiento y deteriorarse a medida que cambian los recursos en la nube, los propietarios, las aplicaciones y las integraciones.
El glosario de la CMDB también describe la Identificación y Reconciliación como un marco centralizado para identificar y conciliar datos de diferentes fuentes a medida que los datos ingresan a la CMDB, lo que ayuda a mantener la integridad cuando múltiples fuentes crean y actualizan registros de CI (Glosario de CMDB de ServiceNow). Ese es exactamente el problema adecuado para la automatización empresarial. Múltiples sistemas afirman saber qué es un activo, quién es su propietario, de qué depende y si todavía está activo. ServiceNow puede ayudar a imponer orden, pero la evidencia de su propia documentación muestra que este orden requiere reglas, roles y mantenimiento.
Now Assist para CMDB va más allá. La documentación de ServiceNow describe los agentes de IA utilizados por Now Assist para CMDB, incluido un agente creador de CI, un resumidor de elementos de configuración y un administrador de certificación y atestación de datos (Documentación de Now Assist for CMDB). Estas son direcciones útiles porque la higiene de la CMDB es laboriosa. Pero también elevan el estándar de supervisión. Si un agente de IA crea o resume un CI, el comprador debe saber qué fuente se utilizó, qué se infirió, qué se verificó y qué debe revisarse antes de que los flujos de trabajo dependan de ello.
El intercambio económico es claro. Una buena CMDB puede reducir la investigación duplicada y el mal enrutamiento. Una CMDB débil puede encarecer cada automatización porque los equipos deben verificar si la imagen del entorno de ServiceNow es confiable. El costo no es solo la entrada de datos. Es la gobernanza necesaria para decidir qué fuente de descubrimiento prevalece, cómo se documentan las excepciones, cómo se remedian los registros duplicados y cómo los sistemas retirados o reemplazados desaparecen de la superficie de enrutamiento antes de que desencadenen trabajo falso.
Es por eso que la promesa de ServiceNow es más creíble para las organizaciones dispuestas a tratar el mantenimiento de la CMDB como infraestructura operativa. Es menos creíble para los compradores que desean agentes de IA y automatización de flujos de trabajo mientras dejan ambiguas las definiciones de servicio, la propiedad y los registros de configuración. La plataforma solo puede procesar casos tan bien como el contexto que recibe.
Las integraciones convierten a ServiceNow en un plano de control
IntegrationHub es fundamental para la afirmación de ServiceNow de que el trabajo empresarial puede moverse entre sistemas. La documentación describe Integration Hub como una forma de automatizar tareas de integración utilizando componentes de ServiceNow para Workflow Studio o para desarrollar integraciones personalizadas, y se requiere una suscripción por separado (Documentación de ServiceNow Integration Hub). Esa última frase es comercialmente importante. La integración no es solo una capacidad técnica. Es una superficie operativa con licencia y costo continuo.
El manejo de errores de Flow Designer muestra por qué esa superficie debe ser observable. ServiceNow documenta manejadores de errores de flujo que pueden identificar errores de flujo a medida que ocurren, capturar y enviar información de errores, automatizar la resolución y permitir que los creadores especifiquen la lógica de manejo de errores de acción (Documentación del manejador de errores de flujo de ServiceNow). Las propiedades del sistema de flujo también definen cuánto detalle escribe el motor de ejecución de Flow Designer en la tabla sys_flow_log, con niveles que van desde la configuración de diagnóstico más detallada hasta INFO, WARN y ERROR (Propiedades del sistema de Flow Designer de ServiceNow). Estas no son configuraciones secundarias. Determinan si la automatización fallida es lo suficientemente visible como para confiar en ella.
Un tiempo de espera de integración puede ser peor que un retraso humano si el flujo de trabajo no hace visible el fallo. Un ticket puede parecer asignado, un estado puede parecer actualizado, o una respuesta generada puede decir que el trabajo ha comenzado mientras que el sistema externo no recibió la acción. La diferencia entre un flujo de trabajo valioso y uno peligroso a menudo radica en si las excepciones se convierten en tareas con propietarios, registros y rutas de reintento. ServiceNow proporciona herramientas para eso, pero los clientes deben diseñar la ruta de fallo deliberadamente.
La documentación de terceros muestra el mismo patrón. AWS dice que el AWS Service Management Connector para ServiceNow permite a los usuarios de ServiceNow aprovisionar, administrar y operar recursos de AWS, rastrear recursos de AWS Config en la CMDB, ver y resolver OpsItems de AWS Systems Manager como incidentes, y sincronizar hallazgos de AWS Security Hub con incidentes o problemas de ServiceNow (Documentación del AWS Service Management Connector). Una página separada de AWS mapea los campos de Incident Manager con los campos de incidentes de ServiceNow y señala que AWS finalizará el soporte para AWS Service Management Connector el 31 de marzo de 2027 (Documentación de AWS Incident Manager en ServiceNow). Ese aviso de fin de soporte es un recordatorio útil: el valor de la integración también depende del ciclo de vida de otro proveedor.
La documentación de integración de Jira Service Management de Atlassian describe flujos bidireccionales de incidentes y alertas entre ServiceNow y Jira Service Management, incluido el mapeo de asignaciones, grupos, acciones de alerta y sincronización opcional de usuarios y grupos (Documentación de integración de Atlassian con ServiceNow). La página también menciona restricciones, incluida la necesidad de instalación de la aplicación, roles de usuario, opciones de mapeo y limitaciones en torno a múltiples integraciones sin modificación de código. Este es un respaldo independiente para un punto práctico: conectar ServiceNow a otro service desk o plataforma de alertas no es solo una llamada a la API. Es una traducción de estado.
La documentación pública de la aplicación de la tienda Sentinel de Microsoft para ServiceNow describe de manera similar la sincronización bidireccional de incidentes, incluida la creación de incidentes, la sincronización de alertas, entidades, comentarios, estado, gravedad y asignación de propietario, al tiempo que señala que la integración tradicional de Azure Logic App o playbook no permite completamente la sincronización bidireccional y que la aplicación se ejecuta en una sola instancia de ServiceNow sin separación de dominios (README de integración de Microsoft Sentinel con ServiceNow). Esa limitación es importante para las grandes empresas porque la separación de dominios, el diseño de múltiples instancias y los límites de propiedad pueden decidir si una integración escala de manera limpia.
La conclusión no es que las integraciones sean malas. Es que la integración es donde ServiceNow se convierte en un plano de control, y los planos de control requieren gestión de cambios. Cada sistema externo agrega credenciales, mapeo de datos, soporte de ciclo de vida, límites de velocidad, cambios de campo, avisos de proveedores y semántica de fallos. ServiceNow puede reducir el trabajo de cambiar de un sistema a otro, pero no puede hacer que esos sistemas desaparezcan.
Los agentes de IA elevan el estándar de permisos
La página de producto de agentes de IA de ServiceNow dice que los flujos de trabajo agentivos representan un objetivo comercial, AI Agent Orchestrator coordina la colaboración entre equipos de agentes, AI Agent Studio permite a los usuarios crear y personalizar agentes, y ServiceNow AI Control Tower se posiciona como un centro central para la gobernanza y gestión de IA (ServiceNow AI Agents). La documentación de Now Assist dice que utiliza IA generativa a través de conversaciones y experiencias proactivas, con acceso que depende de la licencia, los niveles de producto y la disponibilidad de funciones (Documentación de Now Assist). La documentación de los agentes de IA de Now Assist dice que los agentes utilizan modelos de lenguaje grandes y pueden variar desde respuestas automatizadas simples hasta la resolución de problemas complejos (Documentación de los agentes de IA de Now Assist).
Esas afirmaciones son más sólidas cuando los agentes actúan dentro de un flujo de trabajo gobernado con autoridad limitada. Son más débiles cuando el comportamiento del agente se trata como un sustituto del diseño de procesos. Un agente de servicio humano a menudo sabe cuándo un caso huele mal incluso si el formulario parece completo. Un agente de IA debe recibir barreras de protección, acceso a fuentes, permisos, umbrales de revisión y reglas de escalación que representen ese juicio. De lo contrario, puede cometer errores de baja fricción a escala.
El historial de seguridad pública refuerza el punto. El Canadian Centre for Cyber Security publicó un aviso el 13 de enero de 2026 señalando que ServiceNow había publicado un aviso para una vulnerabilidad crítica que afectaba a Now Assist AI Agents y Virtual Agent API en versiones anteriores a las versiones parcheadas especificadas (Aviso AV26-022 del Canadian Centre for Cyber Security). NVD registra otra vulnerabilidad de ServiceNow AI Platform, CVE-2025-11449, como un problema de cross-site scripting reflejado que ServiceNow solucionó implementando una actualización de seguridad relevante para la mayoría de las instancias alojadas y proporcionando actualizaciones para clientes autogestionados, socios y clientes alojados con configuración única (NVD CVE-2025-11449).
El informe del investigador de seguridad AppOmni sobre CVE-2025-12420 argumentó que los agentes de IA pueden amplificar las fallas de seguridad tradicionales y describió una falla de integración de Virtual Agent que permitía la suplantación de usuarios a través de la lógica de vinculación de cuentas, al tiempo que recomendaba controles como una configuración más sólida del proveedor, procesos de aprobación y gestión del ciclo de vida de los agentes (Investigación BodySnatcher de AppOmni). Esta es una fuente de investigación de seguridad nombrada, no un veredicto amplio sobre todas las implementaciones de IA de ServiceNow. Su valor es más limitado: muestra que las rutas de ejecución de los agentes de IA pueden convertirse en rutas críticas de seguridad.
Esa evidencia no significa que los compradores deban evitar los agentes de IA. Significa que el estándar de permisos debe elevarse. Si un agente puede resumir un registro, el riesgo es un contexto incompleto. Si un agente puede actualizar un registro, activar un flujo de trabajo, acceder a una herramienta externa o invocar a otro agente, el riesgo incluye acciones no autorizadas, identidad incorrecta, fuga de datos y ejecución no revisada. Los productos de gobernanza de ServiceNow pueden ayudar, pero el comprador aún necesita un inventario de agentes, herramientas, alcances, credenciales, reglas de aprobación y política de desmantelamiento.
La IA cambia la economía de ServiceNow solo si reduce el trabajo aceptado, no solo la escritura manual. Un resumen de caso que le ahorra a un agente tres minutos es útil. Un flujo de trabajo autónomo que cierra incorrectamente un caso, actualiza el registro de cliente incorrecto o enruta un incidente de seguridad a la cola equivocada es costoso. La métrica responsable no es el número de interacciones de IA. Es el número de resoluciones aceptadas, con evidencia de auditoría y bajas tasas de reapertura.
Los permisos y los registros de auditoría son parte de la resolución
La documentación de control de acceso de ServiceNow dice que las ACL aseguran el acceso a nuevos registros o cambian el comportamiento de seguridad predeterminado, y que la creación de ACL requiere elevación al rol security_admin (Documentación de configuración de ACL de ServiceNow). Su documentación de exploración de ACL dice que una ACL otorga acceso solo si se cumplen las condiciones requeridas, incluidas las comprobaciones de condiciones, scripts y roles, además de comprobaciones a nivel de tabla y campo para las ACL de registros (Documentación de exploración de ACL de ServiceNow). Aquí es donde la confiabilidad del flujo de trabajo se encuentra con la gobernanza.
Un flujo de trabajo puede fallar porque no puede ver un registro, porque ve demasiado o porque escribe bajo una cuenta de servicio que difumina la responsabilidad. Un caso puede ser mal enrutado porque el grupo relevante está oculto. Una función de IA puede producir una respuesta débil porque carece de acceso a la fuente que la habría corregido. Por el contrario, una integración demasiado permisiva puede exponer registros confidenciales a un proceso que nunca debería haberlos visto. Por lo tanto, el modelo de permisos correcto no es solo un requisito de cumplimiento. Es una condición previa para una automatización correcta.
La evidencia de auditoría es igualmente operativa. La documentación de registro de auditoría de ServiceNow dice que los registros de eventos muestran los inicios de sesión de los empleados de ServiceNow en una instancia de cliente y que los registros de transacciones muestran la actividad en la instancia, incluidos los esfuerzos para eliminar registros (Documentación de registro de auditoría de ServiceNow). Esa fuente se refiere específicamente a la actividad de los empleados de ServiceNow, no a todo el registro de flujo de trabajo del cliente, pero ilustra el principio más amplio: las plataformas de trabajo empresarial deben poder explicar quién o qué actuó, cuándo y a través de qué ruta.
Para los compradores, la pregunta clave es si cada transición de estado importante tiene suficiente evidencia. ¿Quién reabrió el incidente? ¿Qué integración actualizó el campo? ¿Qué artículo de conocimiento se utilizó? ¿Qué resumió el asistente de IA? ¿Qué estado externo cambió? ¿Qué aprobación se otorgó? ¿Qué ACL permitió o denegó el acceso? Si la plataforma no puede responder esas preguntas para sus propios flujos de trabajo, la resolución más rápida se vuelve más difícil de confiar.
La misma lógica se aplica a los entornos regulados. El informe anual de ServiceNow menciona costos para respaldar a los clientes en mercados regulados y requisitos de residencia de datos (ServiceNow 2025 Formulario 10-K). Los compradores regulados pueden valorar ServiceNow precisamente porque proporciona una superficie de control común. Pero esos compradores deben tener cuidado de tratar las funciones de IA como complementos genéricos de productividad. En el trabajo de servicio regulado, una respuesta que no se puede rastrear a menudo no es una respuesta que se pueda utilizar.
Las actualizaciones y personalizaciones generan una factura de mantenimiento
El valor de la plataforma de ServiceNow crece a medida que más flujos de trabajo se trasladan a ella. Lo mismo ocurre con la factura de mantenimiento. La documentación de actualización lo hace concreto. ServiceNow dice que los registros personalizados que tienen versiones actuales en la tabla Customer Updates se omiten durante una actualización, y resolver una actualización omitida puede significar conservar la personalización, fusionar cambios, revertir a la versión actualizada o revisar la omisión sin acción (Documentación de resolución de actualizaciones omitidas de ServiceNow). La lista de cambios omitidos existe para evitar que las personalizaciones se sobrescriban y para ayudar a realizar un seguimiento de los registros omitidos que necesitan revisión (Documentación de cambios omitidos de ServiceNow).
Este es el costo práctico de la adaptación de la plataforma. ServiceNow es valioso en parte porque los clientes pueden adaptar los flujos de trabajo a sus propios procesos. Pero cada personalización puede convertirse en una decisión de actualización más adelante. Un comprador que personaliza en gran medida los formularios de incidentes, las reglas comerciales, las ACL, las integraciones, las tablas y el comportamiento de la interfaz de usuario puede obtener un mejor ajuste a corto plazo y más trabajo de revisión a largo plazo.
Un comprador que se mantiene más cerca de la plataforma base puede actualizar de manera más fluida, pero puede necesitar cambiar los procesos internos para adaptarse al producto.
La documentación del Plan de actualización de ServiceNow dice que el trabajo posterior a la actualización, como confirmar conjuntos de actualizaciones, instalar complementos y aplicaciones, y múltiples actualizaciones, puede llevar mucho tiempo, y que los planes de actualización pueden automatizar tareas mediante el seguimiento de acciones y la repetición de pasos en las instancias necesarias (Documentación del Plan de actualización de ServiceNow). Esa es una característica útil, pero también demuestra el punto: el mantenimiento es un flujo de trabajo en sí mismo. La plataforma que automatiza el trabajo debe operarse a sí misma a través de un trabajo estructurado.
Esto es importante para la historia de la IA. Las funciones de IA no eliminan la complejidad de las actualizaciones. Pueden agregar sus propias dependencias de versión, restricciones de disponibilidad de modelos, consideraciones de licencia, problemas del ciclo de vida de los agentes y tareas de gobernanza. La documentación de Now Assist para ITSM señala que algunos proveedores de modelos y funciones de IA no están disponibles para ciertos entornos locales, FedRAMP, Departamento de Defensa IL5, Australia IRAP-Protected, autogestionados u otros entornos restringidos (Documentación de Now Assist for ITSM). Eso no es una crítica; es un recordatorio de que la disponibilidad de la IA es parte del alcance de la implementación.
La prueba de mantenimiento del comprador debe incluir recuentos de registros omitidos, horas de fusión manual, cambios de incidentes posteriores a la actualización, repetición de pruebas de integración, disponibilidad de funciones de IA, validación de agentes y regresión de flujos de trabajo clave. Una demostración rara vez muestra ese trabajo. La propiedad en producción siempre lo hace.
La señal comercial es demanda, no prueba
El desempeño financiero de ServiceNow muestra que el mercado está dispuesto a pagar por este modelo operativo. En 2025, la compañía reportó ingresos totales de $13,278 millones, con ingresos por suscripciones de $12,883 millones, un aumento del 21 por ciento año tras año. Los ingresos por suscripciones representaron el 97 por ciento de los ingresos totales. También reportó un porcentaje de ganancia bruta por suscripciones del 80 por ciento y dijo que los acuerdos de suscripción suelen tener una duración de tres años, con una tasa de renovación del 98 por ciento para cada uno de 2025, 2024 y 2023 (ServiceNow 2025 Formulario 10-K).
En el primer trimestre de 2026, ServiceNow reportó ingresos por suscripciones de $3,671 millones, ingresos totales de $3,770 millones, obligaciones de desempeño restantes actuales de $12,640 millones y obligaciones de desempeño restantes de $27,700 millones. También dijo que los clientes de Now Assist que gastan más de $1 millón en valor de contrato anual crecieron más del 130 por ciento año tras año (Resultados del primer trimestre de 2026 de ServiceNow). Esas cifras importan porque muestran que ServiceNow no está vendiendo una herramienta de flujo de trabajo de nicho. Es una importante plataforma de software empresarial con una expansión sustancial dentro de las grandes cuentas.
Pero la demanda no es una prueba de resultados. Una tasa de renovación puede reflejar valor, costo de cambio, dependencia de procesos integrados, inercia de adquisiciones o una combinación de los cuatro. Las grandes obligaciones de desempeño restantes muestran ingresos contratados, no si los tickets reabiertos disminuyeron. Un alto margen bruto de suscripciones muestra un negocio de software sólido, no si una implementación particular redujo la mano de obra de servicio después de las tarifas de los socios y los gastos generales de gobernanza.
Por lo tanto, la pregunta comercial para un comprador es local. ¿El entorno de ServiceNow reduce la cantidad de transferencias necesarias para resolver el trabajo de servicio? ¿Reduce el costo de la recopilación de evidencia? ¿Reduce el trabajo duplicado entre ITSM, CSM, seguridad, operaciones y RR.HH.? ¿Hace que sea más fácil actuar sobre los sistemas externos de manera segura? ¿Permite que la IA maneje solicitudes rutinarias con menos reaperturas?
¿O se convierte en una capa de control de alto costo que requiere administradores especializados, consultores, integraciones personalizadas y negociaciones de licencia para cada nuevo flujo de trabajo?
La respuesta puede variar según la organización. Una gran empresa con mesas de servicio fragmentadas, prácticas de CMDB inconsistentes, poca visibilidad de los casos y múltiples puntos de integración puede encontrar que la plataforma común de ServiceNow es más barata que seguir coordinándose por correo electrónico, hojas de cálculo y conocimiento tribal. Una organización más pequeña o más disciplinada puede encontrar que la amplitud de la plataforma agrega más ceremonia que beneficio. El éxito financiero de ServiceNow demuestra un mercado amplio. No reemplaza la diligencia debida.
Workflow Data Fabric convierte los contratos de datos en la próxima prueba de confiabilidad
Workflow Data Fabric es el intento de ServiceNow de hacer que los datos externos sean más utilizables por los flujos de trabajo y los agentes de IA. La página del producto dice que conecta datos entre sistemas, agrega contexto empresarial a través de un catálogo de datos unificado y aplica controles de gobernanza basados en políticas para que la IA pueda comprender cómo funciona una empresa y tomar medidas confiables (ServiceNow Workflow Data Fabric). La documentación describe Workflow Data Fabric Home como una base de datos unificada que conecta los datos empresariales donde residen, los gobierna a través de contratos estables y los prepara para flujos de trabajo, análisis e IA (Documentación de Workflow Data Fabric Home).
Es una buena dirección porque la IA y los flujos de trabajo fallan cuando el contexto está disperso. La documentación de términos clave define un producto de datos como un paquete gobernado y reutilizable construido a partir de una o más interfaces de datos, y una interfaz de datos como un contrato de datos gobernado y estable que puede representar una sola tabla, tablas unidas o una unión de fuentes, al tiempo que impone la compatibilidad con versiones anteriores para proteger a los consumidores de cambios incompatibles (Términos clave de Workflow Data Fabric). Ese lenguaje es más útil que el lenguaje de marketing porque nombra lo que debe operarse: un contrato.
Las limitaciones son igualmente instructivas. La documentación para administrar tablas de data fabric dice que una tabla de data fabric puede representar virtualmente datos externos, pero los usuarios deben verificar la unicidad al definir claves principales, no pueden eliminar una clave principal después de la definición sin eliminar y volver a crear la tabla de data fabric, y solo pueden hacer referencia a una tabla con una clave principal definida en ciertos contextos (Administración de tablas de data fabric). Estos detalles muestran que el acceso virtual o sin copia no elimina el modelado de datos. Cambia dónde se aplica la disciplina de modelado.
El monitoreo de suscripciones también es importante. ServiceNow dice que las suscripciones a Workflow Data Fabric incluyen tokens utilizados para capacidades y que el uso de tokens se puede rastrear en la Gestión de Suscripciones (Monitoreo de uso de Workflow Data Fabric). Eso hace que la prueba económica sea más concreta. Si cada flujo de trabajo habilitado para IA consume capacidades de data fabric, los compradores deben saber qué acciones gastan tokens, cómo se traduce eso en valor comercial y si el uso crece con una automatización exitosa o con retrabajo evitable.
Workflow Data Fabric podría mejorar la confiabilidad de ServiceNow si ayuda a los agentes y flujos de trabajo a consumir datos gobernados sin interminables integraciones únicas. Podría debilitar el argumento económico si se convierte en otra capa de licencias y contratos de datos que solo los especialistas entienden. La prueba correcta para el comprador no es si los datos se pueden conectar en una demostración. Es si los administradores de datos pueden mantener contratos, ACL, linaje, claves principales y cambios de ciclo de vida bajo una demanda real.
Dónde puede fallar ServiceNow al comprador
ServiceNow puede fallar de maneras comunes que son fáciles de pasar por alto durante un ciclo de ventas. La CMDB puede contener CI duplicados u obsoletos, lo que hace que los incidentes se enruten al propietario incorrecto. Un artículo de conocimiento puede estar desactualizado pero aún así influir en un resumen de Now Assist. Una integración puede tener éxito en ServiceNow y fallar en el sistema externo, o viceversa. Una ACL puede denegar a un flujo de trabajo el registro que necesita, provocando una respuesta parcial. Una cuenta de servicio demasiado poderosa puede permitir que un flujo de trabajo actúe sin suficiente responsabilidad.
Un incidente resuelto puede reabrirse porque la transición de estado original fue prematura.
La plataforma también puede fallar comercialmente. Un flujo de trabajo puede requerir una suscripción adicional a Integration Hub, una capacidad de Workflow Data Fabric, un derecho de Now Assist, un conector creado por un socio o una aplicación personalizada. Eso no hace que el flujo de trabajo sea malo, pero cambia el costo total.
Un comprador debe contar los servicios de implementación, la administración, el soporte de socios, la capacitación, las pruebas, la revisión de actualizaciones, la administración de datos, el monitoreo de integraciones, la gobernanza de la IA y la expansión de licencias, no solo la línea de suscripción en el primer formulario de pedido.
La IA puede fallar por parecer demasiado útil. Una nota de resolución generada puede reducir la escritura al tiempo que disminuye la calidad probatoria. Un agente de IA puede enrutar o categorizar incidentes con suficiente precisión para impresionar en conjunto, pero con suficientes errores en casos extremos como para crear usuarios enojados y una limpieza manual oculta. Un resumidor puede omitir la única advertencia que importa. Un flujo de trabajo de múltiples agentes puede pasar el trabajo de un agente a otro de una manera que es difícil de reconstruir para los supervisores humanos.
ServiceNow también puede volverse pegajoso de una manera que es económicamente racional pero estratégicamente limitante. El encierro no es solo la exportación de datos. Es el modelo operativo: estados de tickets, clases de CMDB, tipos de casos de CSM, lógica de Flow Designer, radios de Integration Hub, ACL, conjuntos de actualizaciones, informes, aprobaciones, aplicaciones personalizadas, habilidades de los socios y capacitación de los usuarios. Una vez que una empresa enruta el trabajo de servicio crítico a través de ServiceNow, reemplazarlo significa reconstruir la forma en que se representa el trabajo. Puede valer la pena.
No debe ignorarse.
El modo de fallo más grave es el cierre falso. Una empresa compra ServiceNow para hacer que el trabajo sea visible y gobernable. Si los flujos de trabajo cierran registros antes de que se resuelva el problema del mundo real, la plataforma ha invertido su propósito. Los compradores deben tratar las reaperturas, los tickets duplicados, las devoluciones de llamadas de clientes, las transferencias no resueltas y las omisiones manuales como señales de confiabilidad de primera clase.
La prueba del comprador debe ser un caso representativo
Una evaluación seria de ServiceNow debe seguir un caso representativo desde la admisión hasta el cierre duradero. Para ITSM, podría ser un incidente que afecta el servicio vinculado a un recurso en la nube, un registro de CMDB, una alerta de monitoreo, un artículo de conocimiento, una solicitud de cambio y un sistema de operaciones externo. Para CSM, podría ser un problema del cliente que requiere contexto de cuenta, validación de derechos, datos de inventario o facturación, una tarea administrativa y comunicación con el cliente.
Para seguridad, podría ser una vulnerabilidad o incidente que requiera propiedad de activos, enriquecimiento de gravedad, aprobación, seguimiento de remediación y evidencia.
El comprador debe registrar cada transición de estado, sugerencia de IA, llamada de integración, verificación de permisos, ruta de error, actualización del sistema externo, aprobación humana y condición de reapertura. Debe romper deliberadamente una integración, introducir un registro de CMDB obsoleto, probar una discrepancia de permisos y preguntar qué muestra la plataforma. Debe comparar el tiempo ahorrado en resúmenes y enrutamiento con el tiempo dedicado a validar datos, mantener mapeos y supervisar excepciones.
Las métricas más útiles son prácticas. Cuente las asignaciones iniciales incorrectas. Cuente los reenrutamientos manuales. Cuente los incidentes reabiertos después de la resolución. Cuente los casos cerrados sin evidencia de resolución. Cuente los registros de CMDB con propietarios faltantes o identidades duplicadas. Cuente las fallas de integración que se convirtieron en tareas visibles. Cuente los registros omitidos en actualizaciones y el tiempo de fusión manual. Cuente las sugerencias generadas por IA aceptadas, rechazadas o editadas por los agentes.
Cuente la fracción de sugerencias de IA aceptadas que luego se correlacionaron con reaperturas o devoluciones de llamadas de clientes. Cuente el uso de tokens para IA y acciones de data fabric si esas funciones tienen licencia.
Este tipo de prueba es menos glamorosa que una demostración de IA generativa, pero responde a la pregunta real. ServiceNow se gana su posición como plataforma cuando facilita la realización correcta del trabajo empresarial. No se gana esa posición simplemente insertando IA en la primera respuesta.
Qué cambiaría el juicio
El caso positivo para ServiceNow se fortalecería si la compañía y su ecosistema publicaran más evidencia independiente sobre los resultados de resolución aceptada: cambios en la tasa de reapertura después de la adopción de Now Assist, reducciones de enrutamiento incorrecto después de la remediación de la salud de la CMDB, visibilidad de las fallas de integración, tiempo promedio de fusión manual en las actualizaciones, tasas de excepción de los agentes de IA, costo de tokens por resolución aceptada y reducciones verificadas por el cliente en las transferencias.
Los datos financieros públicos y la documentación del producto demuestran escala y capacidad. No demuestran esos resultados de implementación.
El caso se debilitaría si las rutas de ejecución de los agentes de IA produjeran repetidamente avisos de seguridad, si los clientes descubrieran que la gobernanza de CMDB y data fabric consume más mano de obra de la que ahorran los flujos de trabajo, si los ciclos de vida de las integraciones se convirtieran en una fuente recurrente de interrupciones o conectores no compatibles, o si la complejidad de las licencias hiciera que cada proyecto de automatización dependiera de nuevos derechos.
También se debilitaría si las prácticas específicas de la plataforma de ServiceNow hicieran que la migración o la coexistencia con otros sistemas fuera más costosa que los costos de coordinación que eliminó la plataforma.
La evidencia actual se encuentra entre esos polos. ServiceNow tiene una profundidad de producto creíble en las partes de confiabilidad del flujo de trabajo que importan: estado, CMDB, integraciones, ACL, auditoría, gestión de actualizaciones y gobernanza de IA. La compañía también tiene una fuerte demanda comercial y evidencia de renovación. La pregunta no resuelta es la calidad de la implementación. ServiceNow puede proporcionar la superficie operativa, pero el comprador aún debe mantener la verdad que fluye a través de ella.
En resumen
ServiceNow se entiende mejor como un sistema para convertir el trabajo de servicio desordenado en transiciones de estado gobernadas en todos los sistemas empresariales. Sus funciones de IA son importantes, pero no son la prueba más difícil del producto. La prueba difícil es si una solicitud real se convierte en un caso correctamente enrutado, resuelto y auditable sin ocultar excepciones, romper permisos, confiar en datos obsoletos o reabrirse después de un cierre prematuro.
Para el comprador adecuado, ServiceNow puede reducir el costo de coordinación al poner el estado de los incidentes, el trabajo de casos de clientes, el contexto de la CMDB, las integraciones, las aprobaciones, la asistencia de IA y la evidencia de auditoría en un solo modelo operativo. Para el comprador equivocado, o para un comprador que no esté dispuesto a financiar la higiene de datos y la gobernanza del flujo de trabajo, puede convertirse en un lugar costoso para centralizar la confusión.
El veredicto es condicional pero claro. La plataforma de ServiceNow es más sólida cuando la organización la trata como infraestructura para un trabajo responsable, no como una capa de respuestas generadas. Si la Now Platform ayuda a cerrar casos correctamente, mantener la evidencia intacta y hacer visibles las excepciones, se gana su lugar. Si solo hace que la primera respuesta sea más rápida, el trabajo real no se ha automatizado; simplemente se ha movido más adentro de la cola.