O Teste Difícil do ServiceNow é o Caso Encerrado, Não a Resposta da IA

Resumo

• O valor técnico do ServiceNow deve ser julgado pela resolução aceita de um caso, incidente ou solicitação real, não pela fluência de uma resposta gerada. A plataforma pode conectar o estado do ticket, o contexto do CMDB, regras de fluxo de trabalho, integrações, controles de acesso, logs de auditoria, Now Assist e agentes de IA, mas cada uma dessas camadas também pode introduzir um modo de falha: dados de configuração desatualizados, atribuição incorreta, incompatibilidade de permissões oculta, tempo limite de integração, incidente duplicado, fechamento prematuro, recomendação alucinada ou um caso reaberto que expõe a correção original como incompleta.
• As evidências públicas sustentam uma afirmação limitada. O ServiceNow possui um maquinário maduro para fluxos de trabalho de casos, estados do ciclo de vida de incidentes, rastreamento de incidentes reabertos, integridade do CMDB, Integration Hub, tratamento de erros do Flow Designer, Workflow Data Fabric, controles de acesso, registros de auditoria e gerenciamento de conflitos de atualização. Esses recursos são relevantes para a confiabilidade porque transformam o trabalho de serviço em transições de estado governadas, em vez de bate-papo livre. Eles não provam que um comprador alcançará custos mais baixos ou resolução mais rápida. O design do processo do cliente, a qualidade dos dados, a qualidade da implementação do parceiro, a confiabilidade dos sistemas externos e as escolhas de licenciamento permanecem decisivos.
• O caso comercial é forte, mas não se comprova por si só. O ServiceNow reportou US$ 13,278 bilhões em receita em 2025, incluindo US$ 12,883 bilhões em receita de assinaturas, e uma taxa de renovação de 98% para cada um dos anos de 2025, 2024 e 2023 em seu Formulário 10-K de 2025. No primeiro trimestre de 2026, reportou US$ 3,671 bilhões em receita de assinaturas e US$ 27,7 bilhões em obrigações de desempenho restantes. Esses números mostram uma grande demanda empresarial por uma plataforma de fluxo de trabalho. Eles não provam que os agentes de IA, a automação do CMDB ou o fechamento de casos entre sistemas reduzem o trabalho após a implementação, supervisão, uso de tokens, atualizações e manutenção de integrações serem contabilizados.

O Caso Encerrado é o Teste Unitário

A maneira mais fácil de superestimar o ServiceNow é avaliá-lo como um gerador de texto. Um usuário faz uma pergunta, o Now Assist resume o incidente, um agente de IA propõe uma próxima etapa e a resposta visível parece competente. Isso não é suficiente. Nos ambientes operacionais para os quais o ServiceNow vende, a resposta é apenas um evento dentro de uma cadeia mais longa. A solicitação deve ser classificada. O serviço ou ativo afetado deve ser identificado. O solicitante deve ter as permissões corretas. O artigo de conhecimento relevante ainda deve ser válido. O incidente ou caso deve ser roteado para o grupo certo.

Sistemas externos podem precisar ser consultados ou atualizados. Uma aprovação pode ser necessária. A correção pode exigir um registro de mudança. A nota de resolução deve explicar o que foi feito. O caso deve ser encerrado sem reabrir imediatamente.

É por isso que o teste mais útil para o ServiceNow é um caso encerrado que permanece encerrado. A Now Platform importa quando preserva contexto, autoridade e evidências durante as transferências. Uma central de serviços que fecha tickets rapidamente suprimindo a complexidade não automatizou a resolução; ela escondeu o trabalho não resolvido. Um caso de atendimento ao cliente que produz uma resposta educada enquanto o sistema de cobrança, direitos ou inventário permanece incorreto não reduziu o custo; ele transferiu o custo para o próximo contato.

Um fluxo de trabalho de segurança ou operações que permite que uma sugestão de IA atualize o registro errado não melhorou a produtividade; tornou o modelo de permissão parte do incidente.

A própria linguagem de produto do ServiceNow aponta para a amplitude da afirmação. A empresa diz que a Plataforma de IA ServiceNow conecta IA, dados e fluxos de trabalho em uma única plataforma, e seu relatório anual de 2025 descreve uma plataforma baseada em nuvem que oferece suporte a aplicativos de fluxo de trabalho nas categorias Tecnologia, CRM e Indústria, Negócios Principais e Criador e Outras (Formulário 10-K de 2025 da ServiceNow). A página do produto ITSM afirma que o ITSM conecta o gerenciamento de incidentes, problemas, mudanças e solicitações em uma única plataforma de IA (ServiceNow ITSM). Essa amplitude é o ponto forte e o risco. O ServiceNow não é apenas um formulário de ticket. É um local onde o trabalho empresarial é representado como estado, dados, permissões e ações.

A pergunta útil é, portanto, restrita: quando uma solicitação entra no sistema, o ServiceNow consegue manter verdade suficiente ao seu redor para decidir o que deve acontecer a seguir? A resposta depende menos de um recurso de IA do que da qualidade do registro subjacente. Uma resposta gerada sem um estado de incidente confiável, contexto atual do CMDB, ACL correta, integração funcional e fluxo de trabalho observável é apenas uma frase plausível. Um fluxo de trabalho menos impressionante que preserve estado e evidências pode ser muito mais valioso.

O que o ServiceNow Realmente Possui

O ServiceNow possui a plataforma, suas aplicações, sua documentação, seu modelo de lançamento, suas obrigações de serviço em nuvem e a superfície de produto em torno do Now Assist, agentes de IA, Workflow Data Fabric, CMDB, ITSM, CSM, Integration Hub, Flow Designer e muitos outros módulos.

Ele não possui a maturidade do processo do cliente, a qualidade dos dados, a taxonomia de serviços, o parque de nuvem, o inventário de endpoints, os dados de RH, os sistemas de cobrança, o provedor de identidade, as ferramentas de monitoramento, o parceiro de serviços gerenciados, as exceções de fluxo de trabalho legadas ou cada modelo e conector de terceiros usados em uma implantação.

Essa fronteira não é uma nota de rodapé defensiva. É o núcleo econômico do produto. O ServiceNow vende uma maneira de coordenar o trabalho entre sistemas que não foram projetados em conjunto. Se a plataforma puder absorver contexto suficiente desses sistemas e aplicar políticas de forma consistente, ela reduz o custo de coordenação. Se a plataforma se tornar mais uma camada de mapeamentos, exceções e registros desatualizados, o custo retorna em serviços de implementação, manutenção de integração, roteamento incorreto, revisão manual e governança da plataforma.

O Formulário 10-K de 2025 da empresa é franco sobre o risco de implementação. Ele afirma que os requisitos de negócios, integração, migração, conformidade e segurança do cliente, bem como erros do ServiceNow, parceiros ou clientes, podem tornar as implementações atrasadas, ineficientes ou malsucedidas, e que implementações malsucedidas ou dispendiosas podem prejudicar renovações e reputação (Formulário 10-K de 2025 da ServiceNow). Esse é o fator de risco correto para este artigo, porque não se trata de saber se o ServiceNow possui recursos. Trata-se de saber se o comprador pode transformar esses recursos em uma prática operacional confiável.

O mesmo documento descreve a arquitetura da plataforma do ServiceNow como aquela que integra IA, dados e fluxos de trabalho, mas também observa os custos crescentes para suportar ofertas de assinatura, mercados regulamentados, serviços de nuvem de terceiros e requisitos de residência de dados. Isso é importante para os compradores porque o valor da plataforma ServiceNow é parcialmente criado pela centralização. Centralização não significa simplificação automática. Significa que mais trabalho é colocado sob um único contrato operacional.

O comprador ganha uma camada comum de fluxo de trabalho, mas também aceita uma dependência do ritmo de lançamento do ServiceNow, estrutura de licenciamento, ecossistema de parceiros e governança específica da plataforma.

A diferença entre propriedade do produto e propriedade do cliente deve moldar cada afirmação de confiabilidade. O ServiceNow pode fornecer um modelo de estado de incidente. O cliente decide se as categorias de incidente fazem sentido. O ServiceNow pode expor indicadores de integridade do CMDB. O cliente decide se as fontes de descoberta e as regras de reconciliação são mantidas. O ServiceNow pode fornecer o Integration Hub. O cliente decide quais credenciais, tentativas de repetição, mapeamentos de dados e dependências de serviços externos são aceitáveis. O ServiceNow pode fornecer o Now Assist e agentes de IA.

O cliente decide onde esses agentes têm permissão para agir e onde um humano deve aprovar.

O Estado do Caso é Mais Importante do que a Conversa

O ciclo de vida do incidente é um local simples para ver por que a integridade do estado é importante. A documentação do ServiceNow afirma que o Gerenciamento de Incidentes gerencia o ciclo de vida dos incidentes desde a criação até o fechamento, com estados como Novo, Em Andamento e Em Espera, e descreve Em Espera como uma transferência temporária de responsabilidade para outra entidade para informações, evidências ou resolução (documentação do ciclo de vida de incidentes do ServiceNow). Essa linguagem é operacionalmente importante. Um caso não é apenas um encadeamento de conversas. É um registro de responsabilidade, evidência e progresso.

A documentação de reabertura do ServiceNow faz a mesma afirmação pelo outro lado. Ela diz que um incidente resolvido pode ser reaberto por determinados usuários, que a reabertura altera o estado de Resolvido para Em Andamento e que campos como Última reabertura por, Última reabertura em e Contagem de reaberturas ajudam a dar suporte a relatórios e auditoria para incidentes reabertos (documentação de reabertura de incidentes do ServiceNow). O rastreamento de reaberturas é um sinal de confiabilidade sóbrio. Um fluxo de trabalho que fecha um caso rapidamente, mas reabre com frequência, não é necessariamente melhor do que um fluxo de trabalho mais lento que resolve o problema subjacente na primeira vez.

É aqui que a assistência de IA deve ser medida com cuidado. O Now Assist for ITSM pode resumir informações de incidentes, gerar notas de resolução de incidentes e resumir bate-papos para uma interação, ao mesmo tempo que ajuda os agentes a entender o contexto do bate-papo e do incidente (documentação do Now Assist for ITSM). Esses recursos podem economizar tempo se reduzirem o trabalho de leitura e redação. Eles também podem criar riscos se os agentes aceitarem resumos que omitem incertezas, se as notas de resolução geradas implicarem trabalho que não foi realizado, ou se o contexto resumido vier de registros desatualizados.

O parâmetro correto não é "a IA escreveu uma boa nota?" É "a nota correspondeu ao estado do caso, ao trabalho realizado e às evidências disponíveis?" Uma nota de resolução que soa clara, mas deixa de mencionar uma dependência de fornecedor, uma mudança não resolvida, uma solução de contorno conhecida ou uma exceção específica do solicitante pode tornar os relatórios mais limpos, enquanto dificulta o próximo incidente. Em uma plataforma construída em torno da auditabilidade, o modo de falha perigoso não é uma prosa estranha. É uma prosa autoritativa anexada a uma transição de estado frágil.

Para casos de uso de atendimento ao cliente, o ServiceNow documenta o gerenciamento de casos como um processo para engajar clientes, categorizar e rotear casos, atribuir trabalho a agentes e gerenciar casos até a resolução e relatórios (documentação de gerenciamento de casos do ServiceNow CSM). Novamente, o valor do produto está no caminho do estado. Um caso de cliente pode envolver direitos de conta, inventário de produtos, serviço de campo, cobrança, histórico de suporte e exceções de política. Se esses registros estiverem errados, a IA pode acelerar a resposta errada. Se esses registros estiverem corretos, a IA pode reduzir o tempo gasto para encontrar a próxima ação responsável.

A lição operacional é direta: os compradores do ServiceNow devem medir a qualidade da resolução, não apenas a velocidade de resposta. A taxa de reabertura, taxa de atribuição incorreta, contagem de redirecionamento manual, tempo em espera por motivo, referências a conhecimento desatualizado, contagem de tentativas de integração e contato pós-resolução com o cliente são indicadores melhores do que o volume de notas geradas. Se a IA reduz o tempo de atendimento enquanto aumenta as reaberturas ou exceções silenciosas, a plataforma otimizou a parte visível do processo e enfraqueceu a real.

O CMDB é a Superfície de Roteamento

O banco de dados de gerenciamento de configuração é frequentemente discutido como um repositório, mas na economia do ServiceNow está mais próximo de uma superfície de roteamento. Se o CMDB representar com precisão serviços, ativos, proprietários, dependências e estado do ciclo de vida, a plataforma pode rotear incidentes, avaliar o impacto e dar suporte à automação com contexto. Se o CMDB estiver incompleto ou contraditório, a automação pode se tornar um mecanismo de desorientação confiante.

A documentação do CMDB Health do ServiceNow afirma que um CMDB saudável é essencial para o uso eficaz e contínuo do produto, e que indicadores como itens de configuração duplicados, campos obrigatórios de IC e auditorias são agregados em pontuações de integridade nos níveis de classe, grupo de integridade e serviço (documentação do CMDB Health do ServiceNow). A redação é importante porque trata a integridade como contínua, não como um marco único de migração. Um CMDB pode ser preciso no lançamento e deteriorar-se à medida que os recursos de nuvem, proprietários, aplicativos e integrações mudam.

O glossário do CMDB também descreve a Identificação e Reconciliação como uma estrutura centralizada para identificar e reconciliar dados de diferentes fontes à medida que os dados entram no CMDB, ajudando a manter a integridade quando várias fontes criam e atualizam registros de IC (glossário do CMDB do ServiceNow). Esse é exatamente o problema certo para a automação empresarial. Vários sistemas afirmam saber o que é um ativo, quem o possui, do que ele depende e se ainda está ativo. O ServiceNow pode ajudar a impor ordem, mas as evidências de sua própria documentação mostram que essa ordem requer regras, funções e manutenção.

O Now Assist for CMDB vai além. A documentação do ServiceNow descreve os agentes de IA usados pelo Now Assist for CMDB, incluindo um agente criador de IC, um resumidor de itens de configuração e um gerenciador de certificação e atestação de dados (documentação do Now Assist for CMDB). Essas são direções úteis porque a higiene do CMDB é trabalhosa. Mas elas também aumentam o padrão de supervisão. Se um agente de IA criar ou resumir um IC, o comprador deve saber qual fonte foi usada, o que foi inferido, o que foi verificado e o que deve ser revisado antes que os fluxos de trabalho dependam dele.

A troca econômica é clara. Um bom CMDB pode reduzir investigações duplicadas e roteamento incorreto. Um CMDB fraco pode tornar cada automação mais cara, porque as equipes precisam verificar se a imagem do ambiente do ServiceNow é confiável. O custo não é apenas a entrada de dados. É a governança necessária para decidir qual fonte de descoberta vence, como as exceções são documentadas, como os registros duplicados são corrigidos e como os sistemas desativados ou substituídos desaparecem da superfície de roteamento antes de acionarem trabalho falso.

É por isso que a promessa do ServiceNow é mais credível para organizações dispostas a tratar a manutenção do CMDB como infraestrutura operacional. É menos credível para compradores que desejam agentes de IA e automação de fluxo de trabalho, deixando as definições de serviço, a propriedade e os registros de configuração ambíguos. A plataforma só pode processar casos tão bem quanto o contexto que recebe.

Integrações Transformam o ServiceNow em um Plano de Controle

O IntegrationHub é central para a afirmação do ServiceNow de que o trabalho empresarial pode transitar entre sistemas. A documentação descreve o Integration Hub como uma forma de automatizar tarefas de integração usando componentes do ServiceNow para o Workflow Studio ou para desenvolver integrações personalizadas, sendo necessária uma assinatura separada (documentação do Integration Hub do ServiceNow). Essa última frase é comercialmente importante. A integração não é apenas uma capacidade técnica. É uma superfície operacional licenciada com custo contínuo.

O tratamento de erros do Flow Designer mostra por que essa superfície deve ser observável. O ServiceNow documenta manipuladores de erros de fluxo que podem identificar erros de fluxo à medida que acontecem, capturar e enviar informações de erro, automatizar a resolução e permitir que os construtores especifiquem a lógica de tratamento de erros de ação (documentação do manipulador de erros de fluxo do ServiceNow). As propriedades do sistema de fluxo também definem quantos detalhes o mecanismo de execução do Flow Designer grava na tabela sys_flow_log, com níveis que variam desde a configuração de diagnóstico mais detalhada até INFO, WARN e ERROR (propriedades do sistema de fluxo do ServiceNow). Estas não são configurações secundárias. Elas determinam se a automação com falha é visível o suficiente para ser confiável.

Um tempo limite de integração pode ser pior do que um atraso humano se o fluxo de trabalho não tornar a falha visível. Um ticket pode parecer atribuído, um status pode parecer atualizado ou uma resposta gerada pode dizer que o trabalho começou enquanto o sistema externo não recebeu a ação. A diferença entre um fluxo de trabalho valioso e um perigoso geralmente é se as exceções se tornam tarefas com proprietários, logs e caminhos de repetição. O ServiceNow fornece ferramentas para isso, mas os clientes devem projetar o caminho de falha deliberadamente.

A documentação de terceiros mostra o mesmo padrão. A AWS afirma que o AWS Service Management Connector for ServiceNow permite que os usuários do ServiceNow provisionem, gerenciem e operem recursos da AWS, rastreiem recursos do AWS Config no CMDB, visualizem e resolvam OpsItems do AWS Systems Manager como incidentes e sincronizem descobertas do AWS Security Hub com incidentes ou problemas do ServiceNow (documentação do AWS Service Management Connector). Uma página separada da AWS mapeia campos do Incident Manager para campos de incidentes do ServiceNow e observa que a AWS encerrará o suporte para o AWS Service Management Connector em 31 de março de 2027 (documentação do AWS Incident Manager no ServiceNow). Esse aviso de fim de suporte é um lembrete útil: o valor da integração também depende do ciclo de vida de outro fornecedor.

A documentação de integração do Jira Service Management da Atlassian descreve fluxos bidirecionais de incidentes e alertas entre o ServiceNow e o Jira Service Management, incluindo mapeamento de atribuições, grupos, ações de alerta e sincronização opcional de usuários e grupos (documentação de integração do ServiceNow com a Atlassian). A página também menciona restrições, incluindo a necessidade de instalação de aplicativos, funções de usuário, opções de mapeamento e limitações em torno de várias integrações sem modificação de código. Este é um suporte independente para um ponto prático: conectar o ServiceNow a outra central de serviços ou plataforma de alerta não é apenas uma chamada de API. É uma tradução de estado.

A documentação pública do aplicativo de loja do Microsoft Sentinel para ServiceNow descreve de forma semelhante a sincronização bidirecional de incidentes, incluindo criação de incidentes, alertas, entidades, comentários, status, gravidade e sincronização de atribuição de proprietário, observando que a integração tradicional do Azure Logic App ou playbook não permite totalmente a sincronização bidirecional e que o aplicativo é executado em uma única instância do ServiceNow sem separação de domínio (README da integração do Microsoft Sentinel com ServiceNow). Essa limitação é importante para grandes empresas, porque a separação de domínio, o design de várias instâncias e os limites de propriedade podem decidir se uma integração é dimensionada de forma limpa.

A conclusão não é que as integrações são ruins. É que a integração é onde o ServiceNow se torna um plano de controle, e planos de controle exigem gerenciamento de mudanças. Cada sistema externo adiciona credenciais, mapeamento de dados, suporte ao ciclo de vida, limites de taxa, alterações de campo, avisos de fornecedores e semântica de falha. O ServiceNow pode reduzir o trabalho de alternar entre sistemas, mas não pode fazer esses sistemas desaparecerem.

Agentes de IA Elevam o Padrão de Permissão

A página de produto de agentes de IA do ServiceNow afirma que os fluxos de trabalho agentivos representam um objetivo de negócios, o AI Agent Orchestrator coordena a colaboração entre equipes de agentes, o AI Agent Studio permite que os usuários criem e personalizem agentes, e o ServiceNow AI Control Tower é posicionado como um hub central para governança e gerenciamento de IA (ServiceNow AI Agents). A documentação do Now Assist afirma que ele usa IA generativa por meio de experiências de conversação e proativas, com acesso dependendo da licença, níveis de produto e disponibilidade de recursos (documentação do Now Assist). A documentação dos agentes de IA do Now Assist afirma que os agentes usam modelos de linguagem de grande escala e podem variar de respostas automatizadas simples a resolução complexa de problemas (documentação de agentes de IA do Now Assist).

Essas afirmações são mais fortes quando os agentes atuam dentro de um fluxo de trabalho governado com autoridade limitada. Elas são mais fracas quando o comportamento do agente é tratado como um substituto para o design do processo. Um agente de serviço humano geralmente sabe quando um caso parece errado, mesmo que o formulário pareça completo. Um agente de IA deve receber barreiras de proteção, acesso à fonte, permissões, limites de revisão e regras de escalonamento que representem esse julgamento. Caso contrário, ele pode cometer erros de baixo atrito em escala.

O registro público de segurança reforça o ponto. O Canadian Centre for Cyber Security publicou um aviso em 13 de janeiro de 2026 observando que o ServiceNow havia publicado um aviso para uma vulnerabilidade crítica afetando as versões do Now Assist AI Agents e Virtual Agent API antes das versões corrigidas especificadas (aviso AV26-022 do Canadian Centre for Cyber Security). O NVD registra outra vulnerabilidade da plataforma de IA do ServiceNow, CVE-2025-11449, como um problema de cross-site scripting refletido que o ServiceNow resolveu implantando uma atualização de segurança relevante para a maioria das instâncias hospedadas e fornecendo atualizações para clientes auto-hospedados, parceiros e clientes hospedados com configuração exclusiva (NVD CVE-2025-11449).

A análise do pesquisador de segurança AppOmni sobre o CVE-2025-12420 argumentou que os agentes de IA podem amplificar falhas de segurança tradicionais e descreveu uma falha de integração do Virtual Agent que permitia a representação de usuários por meio da lógica de vinculação de conta, recomendando controles como configuração mais forte do provedor, processos de aprovação e gerenciamento do ciclo de vida para agentes (pesquisa AppOmni BodySnatcher). Esta é uma fonte de pesquisa de segurança nomeada, não um veredito amplo sobre todas as implantações de IA do ServiceNow. Seu valor é mais restrito: mostra que os caminhos de execução dos agentes de IA podem se tornar caminhos críticos de segurança.

Essa evidência não significa que os compradores devam evitar agentes de IA. Significa que o padrão de permissão deve aumentar. Se um agente pode resumir um registro, o risco é um contexto incompleto. Se um agente pode atualizar um registro, acionar um fluxo de trabalho, acessar uma ferramenta externa ou invocar outro agente, o risco inclui ação não autorizada, identidade errada, vazamento de dados e execução não revisada. Os produtos de governança do ServiceNow podem ajudar, mas o comprador ainda precisa de um inventário de agentes, ferramentas, escopos, credenciais, regras de aprovação e política de descomissionamento.

A IA muda a economia do ServiceNow apenas se reduzir o trabalho aceito, não apenas a digitação manual. Um resumo de caso que economiza três minutos para um agente é útil. Um fluxo de trabalho autônomo que fecha um caso incorretamente, atualiza o registro de cliente errado ou roteia um incidente de segurança para a fila errada é caro. A métrica responsável não é o número de interações de IA. É o número de resoluções aceitas, com evidência de auditoria e baixas taxas de reabertura.

Permissões e Logs de Auditoria Fazem Parte da Resolução

A documentação de controle de acesso do ServiceNow afirma que as ACLs protegem o acesso a novos registros ou alteram o comportamento de segurança padrão, e a criação de ACLs requer elevação à função security_admin (documentação de configuração de ACL do ServiceNow). Sua documentação de exploração de ACL afirma que uma ACL concede acesso apenas se as condições necessárias forem atendidas, incluindo verificações de condição, script e função, além de verificações em nível de tabela e campo para ACLs de registro (documentação de exploração de ACL do ServiceNow). É aqui que a confiabilidade do fluxo de trabalho encontra a governança.

Um fluxo de trabalho pode falhar porque não pode ver um registro, porque vê demais ou porque grava sob uma conta de serviço que obscurece a responsabilidade. Um caso pode ser roteado erroneamente porque o grupo relevante está oculto. Um recurso de IA pode produzir uma resposta fraca porque não tem acesso à fonte que a teria corrigido. Por outro lado, uma integração excessivamente permissiva pode expor registros confidenciais a um processo que nunca deveria tê-los visto. O modelo de permissão correto, portanto, não é apenas um requisito de conformidade. É uma pré-condição para a automação correta.

A evidência de auditoria é igualmente operacional. A documentação de registro de auditoria do ServiceNow afirma que os logs de eventos mostram logins de funcionários do ServiceNow em uma instância do cliente e os logs de transações mostram a atividade na instância, incluindo tentativas de excluir logs (documentação de registro de auditoria do ServiceNow). Essa fonte é especificamente sobre a atividade dos funcionários do ServiceNow, não sobre todo o registro de fluxo de trabalho do cliente, mas ilustra o princípio mais amplo: as plataformas de trabalho empresarial devem ser capazes de explicar quem ou o quê agiu, quando e por qual caminho.

Para os compradores, a pergunta-chave é se cada transição de estado importante possui evidência suficiente. Quem reabriu o incidente? Qual integração atualizou o campo? Qual artigo de conhecimento foi usado? O que o assistente de IA resumiu? Qual status externo mudou? Qual aprovação foi concedida? Qual ACL permitiu ou negou o acesso? Se a plataforma não puder responder a essas perguntas para seus próprios fluxos de trabalho, uma resolução mais rápida se torna mais difícil de confiar.

A mesma lógica se aplica a ambientes regulamentados. O relatório anual do ServiceNow menciona custos para oferecer suporte a clientes em mercados regulamentados e requisitos de residência de dados (Formulário 10-K de 2025 da ServiceNow). Os compradores regulamentados podem valorizar o ServiceNow precisamente porque ele fornece uma superfície de controle comum. Mas esses compradores devem ter cuidado ao tratar os recursos de IA como complementos genéricos de produtividade. Em trabalhos de serviço regulamentados, uma resposta que não pode ser rastreada geralmente não é uma resposta que pode ser usada.

Atualizações e Personalizações Geram uma Conta de Manutenção

O valor da plataforma do ServiceNow cresce à medida que mais fluxos de trabalho migram para ela. O mesmo acontece com a conta de manutenção. A documentação de atualização torna isso concreto. O ServiceNow afirma que os registros personalizados que possuem versões atuais na tabela Customer Updates são ignorados durante uma atualização, e resolver uma atualização ignorada pode significar manter a personalização, mesclar alterações, reverter para a versão atualizada ou revisar a omissão sem ação (documentação de resolução de atualização ignorada do ServiceNow). A lista de alterações ignoradas existe para evitar que as personalizações sejam sobrescritas e para ajudar a rastrear registros ignorados que precisam de revisão (documentação de alterações ignoradas do ServiceNow).

Este é o custo prático da adaptação da plataforma. O ServiceNow é valioso em parte porque os clientes podem adaptar os fluxos de trabalho aos seus próprios processos. Mas cada personalização pode se tornar uma decisão de atualização posteriormente. Um comprador que personaliza fortemente formulários de incidentes, regras de negócios, ACLs, integrações, tabelas e comportamento da interface do usuário pode obter um ajuste melhor no curto prazo e mais trabalho de revisão no longo prazo.

Um comprador que permanece mais próximo da plataforma base pode atualizar com mais facilidade, mas pode precisar alterar os processos internos para se adequar ao produto.

A documentação do Plano de Atualização do ServiceNow afirma que o trabalho pós-atualização, como confirmar conjuntos de atualização, instalar plugins e aplicativos e várias atualizações, pode ser demorado, e que os planos de atualização podem automatizar tarefas rastreando ações e repetindo etapas nas instâncias necessárias (documentação do Plano de Atualização do ServiceNow). Esse é um recurso útil, mas também prova o ponto: a manutenção é um fluxo de trabalho por si só. A plataforma que automatiza o trabalho deve ser operada por meio de um trabalho estruturado.

Isso é importante para a história da IA. Os recursos de IA não eliminam a complexidade da atualização. Eles podem adicionar suas próprias dependências de lançamento, restrições de disponibilidade de modelo, considerações de licenciamento, problemas de ciclo de vida do agente e tarefas de governança. A documentação do Now Assist for ITSM observa que alguns provedores de modelo e recursos de IA não estão disponíveis para determinados ambientes nacionais, FedRAMP, Departamento de Defesa IL5, protegidos pelo IRAP da Austrália, auto-hospedados ou outros ambientes restritos (documentação do Now Assist for ITSM). Isso não é uma crítica; é um lembrete de que a disponibilidade da IA faz parte do envelope de implantação.

O teste de manutenção do comprador deve incluir contagens de registros ignorados, horas de mesclagem manual, alterações de incidentes pós-atualização, reteste de integração, disponibilidade de recursos de IA, validação de agentes e regressão dos fluxos de trabalho principais. Uma demonstração raramente mostra esse trabalho. A propriedade da produção sempre mostra.

O Sinal Comercial é a Demanda, Não a Prova

O desempenho financeiro do ServiceNow mostra que o mercado está disposto a pagar por esse modelo operacional. Em 2025, a empresa reportou uma receita total de US$ 13,278 bilhões, com receita de assinaturas de US$ 12,883 bilhões, um aumento de 21% ano a ano. A receita de assinaturas representou 97% da receita total. Ela também reportou uma margem bruta de assinatura de 80% e afirmou que os contratos de assinatura normalmente têm uma duração de três anos, com uma taxa de renovação de 98% para cada um dos anos de 2025, 2024 e 2023 (Formulário 10-K de 2025 da ServiceNow).

No primeiro trimestre de 2026, o ServiceNow reportou uma receita de assinaturas de US$ 3,671 bilhões, receita total de US$ 3,770 bilhões, obrigações de desempenho restantes atuais de US$ 12,64 bilhões e obrigações de desempenho restantes de US$ 27,7 bilhões. Também afirmou que os clientes do Now Assist com gastos de mais de US$ 1 milhão em valor anual de contrato cresceram mais de 130% ano a ano (resultados do primeiro trimestre de 2026 do ServiceNow). Esses números são importantes porque mostram que o ServiceNow não está vendendo uma ferramenta de fluxo de trabalho de nicho. É uma importante plataforma de software empresarial com expansão substancial dentro de grandes contas.

Mas a demanda não é prova de resultado. Uma taxa de renovação pode refletir valor, custo de mudança, dependência de processo incorporado, inércia de aquisição ou uma mistura dos quatro. Grandes obrigações de desempenho restantes mostram receita contratada, não se os tickets reabertos diminuíram. A alta margem bruta de assinatura mostra um forte negócio de software, não se uma implementação específica reduziu a mão de obra de serviço após taxas de parceiros e custos indiretos de governança.

A questão comercial para um comprador é, portanto, local. O ambiente ServiceNow reduz o número de transferências necessárias para resolver o trabalho de serviço? Ele reduz o custo da coleta de evidências? Ele reduz o trabalho duplicado entre ITSM, CSM, segurança, operações e RH? Ele torna mais fácil agir com segurança nos sistemas externos? Ele permite que a IA lide com solicitações rotineiras com menos reaberturas? Ou se torna uma camada de controle de alto custo que requer administradores especializados, consultores, integrações personalizadas e negociações de licenciamento para cada novo fluxo de trabalho?

A resposta pode variar conforme a organização. Uma grande empresa com centrais de serviço fragmentadas, práticas inconsistentes de CMDB, baixa visibilidade de casos e vários pontos de integração pode achar que a plataforma comum do ServiceNow é mais barata do que continuar coordenando por e-mail, planilhas e conhecimento tribal. Uma organização menor ou mais disciplinada pode achar que a amplitude da plataforma adiciona mais cerimônia do que benefício. O sucesso financeiro do ServiceNow comprova um amplo mercado. Ele não substitui a devida diligência.

Workflow Data Fabric Torna os Contratos de Dados o Próximo Teste de Confiabilidade

O Workflow Data Fabric é a tentativa do ServiceNow de tornar os dados externos mais utilizáveis por fluxos de trabalho e agentes de IA. A página do produto afirma que ele conecta dados entre sistemas, adiciona contexto de negócios por meio de um catálogo de dados unificado e aplica controles de governança baseados em políticas para que a IA possa entender como uma empresa funciona e tomar ações confiáveis (ServiceNow Workflow Data Fabric). A documentação descreve a Página Inicial do Workflow Data Fabric como uma base de dados unificada que conecta os dados corporativos onde eles residem, os governa por meio de contratos estáveis e os deixa prontos para fluxos de trabalho, análises e IA (documentação da Página Inicial do Workflow Data Fabric).

Essa é uma boa direção porque a IA e os fluxos de trabalho falham quando o contexto está disperso. A documentação de termos-chave define um produto de dados como um pacote governado e reutilizável construído a partir de uma ou mais interfaces de dados, e uma interface de dados como um contrato de dados estável e governado que pode representar uma única tabela, tabelas unidas ou uma união de fontes, ao mesmo tempo em que impõe compatibilidade com versões anteriores para proteger os consumidores de alterações drásticas (termos-chave do Workflow Data Fabric). Essa linguagem é mais útil do que a linguagem de marketing porque nomeia o que deve ser operado: um contrato.

As limitações são igualmente instrutivas. A documentação para gerenciar tabelas de data fabric afirma que uma tabela de data fabric pode representar virtualmente dados externos, mas os usuários devem verificar a exclusividade ao definir chaves primárias, não podem remover uma chave primária após a definição sem excluir e recriar a tabela de data fabric, e só podem referenciar uma tabela com uma chave primária definida em determinados contextos (Gerenciando tabelas de data fabric). Esses detalhes mostram que o acesso de cópia zero ou virtual não elimina a modelagem de dados. Ele muda onde a disciplina de modelagem é aplicada.

O monitoramento de assinaturas também é importante. O ServiceNow afirma que as assinaturas do Workflow Data Fabric incluem tokens usados para recursos e que o uso de tokens pode ser rastreado no Gerenciamento de Assinaturas (monitoramento de uso do Workflow Data Fabric). Isso torna o teste econômico mais concreto. Se cada fluxo de trabalho habilitado para IA consumir recursos do data fabric, os compradores precisam saber quais ações gastam tokens, como isso se relaciona com o valor do negócio e se o uso cresce com a automação bem-sucedida ou com retrabalho evitável.

O Workflow Data Fabric poderia melhorar a confiabilidade do ServiceNow se ajudar agentes e fluxos de trabalho a consumir dados governados sem integrações pontuais intermináveis. Poderia enfraquecer o caso econômico se se tornar outra camada de licenciamento e contrato de dados que apenas especialistas entendem. O teste certo para o comprador não é se os dados podem ser conectados em uma demonstração. É se os administradores de dados podem manter contratos, ACLs, linhagem, chaves primárias e mudanças de ciclo de vida sob demanda real.

Onde o ServiceNow Pode Falhar com o Comprador

O ServiceNow pode falhar de maneiras comuns que são fáceis de ignorar durante um ciclo de vendas. O CMDB pode conter ICs duplicados ou desatualizados, fazendo com que os incidentes sejam roteados para o proprietário errado. Um artigo de conhecimento pode estar desatualizado, mas ainda influenciar um resumo do Now Assist. Uma integração pode ter sucesso no ServiceNow e falhar no sistema externo, ou o contrário. Uma ACL pode negar a um fluxo de trabalho o registro de que ele precisa, causando uma resposta parcial. Uma conta de serviço muito poderosa pode permitir que um fluxo de trabalho aja sem responsabilidade suficiente.

Um incidente resolvido pode reabrir porque a transição de estado original foi prematura.

A plataforma também pode falhar comercialmente. Um fluxo de trabalho pode exigir uma assinatura adicional do Integration Hub, um recurso do Workflow Data Fabric, um direito do Now Assist, um conector desenvolvido por parceiro ou um aplicativo personalizado. Isso não torna o fluxo de trabalho ruim, mas altera o custo total. Um comprador deve contabilizar serviços de implementação, administração, suporte de parceiros, treinamento, testes, revisão de atualização, administração de dados, monitoramento de integração, governança de IA e expansão de licenças, não apenas a linha de assinatura no primeiro formulário de pedido.

A IA pode falhar ao parecer muito útil. Uma nota de resolução gerada pode reduzir a digitação enquanto diminui a qualidade probatória. Um agente de IA pode rotear ou categorizar incidentes com precisão suficiente para impressionar em termos agregados, mas com erros de casos limites suficientes para criar usuários irritados e limpeza manual oculta. Um resumidor pode omitir a única ressalva que importa. Um fluxo de trabalho com vários agentes pode passar trabalho de um agente para outro de uma forma que é difícil para os supervisores humanos reconstruírem.

O ServiceNow também pode se tornar pegajoso de uma forma que é economicamente racional, mas estrategicamente limitante. A dependência não é apenas a exportação de dados. É o modelo operacional: estados de tickets, classes do CMDB, tipos de caso do CSM, lógica do Flow Designer, spokes do Integration Hub, ACLs, conjuntos de atualização, relatórios, aprovações, aplicativos personalizados, habilidades de parceiros e treinamento de usuários. Uma vez que uma empresa roteia o trabalho de serviço crítico pelo ServiceNow, substituí-lo significa reconstruir a forma como o trabalho é representado. Isso pode valer a pena. Não deve ser ignorado.

O modo de falha mais sério é o falso fechamento. Uma empresa compra o ServiceNow para tornar o trabalho visível e governável. Se os fluxos de trabalho fecham registros antes que o problema do mundo real seja resolvido, a plataforma inverteu seu propósito. Os compradores devem tratar reaberturas, tickets duplicados, retornos de clientes, transferências não resolvidas e desvios manuais como sinais de confiabilidade de primeira classe.

O Teste do Comprador Deve Ser um Caso Representativo

Uma avaliação séria do ServiceNow deve acompanhar um caso representativo desde a entrada até o encerramento duradouro. Para ITSM, isso pode ser um incidente que afeta o serviço vinculado a um recurso de nuvem, um registro do CMDB, um alerta de monitoramento, um artigo de conhecimento, uma solicitação de mudança e um sistema de operações externo. Para CSM, pode ser um problema do cliente que exige contexto da conta, validação de direitos, dados de inventário ou cobrança, uma tarefa de back-office e comunicação com o cliente.

Para segurança, pode ser uma vulnerabilidade ou incidente que exige propriedade do ativo, enriquecimento de gravidade, aprovação, rastreamento de remediação e evidências.

O comprador deve registrar cada transição de estado, sugestão de IA, chamada de integração, verificação de permissão, caminho de erro, atualização de sistema externo, aprovação humana e condição de reabertura. Deve quebrar deliberadamente uma integração, alimentar um registro desatualizado do CMDB, testar uma incompatibilidade de permissão e perguntar o que a plataforma mostra. Deve comparar o tempo economizado em resumo e roteamento com o tempo gasto validando dados, mantendo mapeamentos e supervisionando exceções.

As métricas mais úteis são práticas. Conte as atribuições iniciais incorretas. Conte os redirecionamentos manuais. Conte os incidentes reabertos após a resolução. Conte os casos encerrados sem evidência de resolução. Conte os registros do CMDB com proprietários ausentes ou identidades duplicadas. Conte as falhas de integração que se tornaram tarefas visíveis. Conte os registros ignorados na atualização e o tempo de mesclagem manual. Conte as sugestões geradas por IA aceitas, rejeitadas ou editadas pelos agentes. Conte a fração de sugestões de IA aceitas que posteriormente se correlacionaram com reaberturas ou retornos de clientes.

Conte o uso de tokens para ações de IA e data fabric se esses recursos forem licenciados.

Esse tipo de teste é menos glamoroso do que uma demonstração de IA generativa, mas responde à pergunta real. O ServiceNow ganha sua posição de plataforma quando torna o trabalho empresarial mais fácil de concluir corretamente. Ele não ganha essa posição apenas inserindo IA na primeira resposta.

O Que Mudaria o Julgamento

O caso positivo para o ServiceNow se fortaleceria se a empresa e seu ecossistema publicassem mais evidências independentes em torno dos resultados de resolução aceita: mudanças na taxa de reabertura após a adoção do Now Assist, reduções de roteamento incorreto após a remediação da integridade do CMDB, visibilidade de falhas de integração, tempo médio de mesclagem manual nas atualizações, taxas de exceção dos agentes de IA, custo de token por resolução aceita e reduções verificadas pelo cliente nas transferências. Os dados financeiros públicos e a documentação do produto comprovam escala e capacidade.

Eles não comprovam esses resultados de implantação.

O caso enfraqueceria se os caminhos de execução dos agentes de IA produzissem repetidamente avisos de segurança, se os clientes descobrissem que a governança do CMDB e do data fabric consumisse mais mão de obra do que os fluxos de trabalho economizados, se os ciclos de vida das integrações se tornassem uma fonte recorrente de interrupções ou conectores sem suporte, ou se a complexidade do licenciamento fizesse com que cada projeto de automação dependesse de novos direitos.

Também enfraqueceria se as práticas específicas da plataforma do ServiceNow tornassem a migração ou coexistência com outros sistemas mais cara do que os custos de coordenação que a plataforma removeu.

As evidências atuais situam-se entre esses polos. O ServiceNow possui profundidade de produto credível nas partes da confiabilidade do fluxo de trabalho que importam: estado, CMDB, integrações, ACLs, auditoria, gerenciamento de atualizações e governança de IA. A empresa também possui forte demanda comercial e evidências de renovação. A questão não resolvida é a qualidade da implantação. O ServiceNow pode fornecer a superfície operacional, mas o comprador ainda deve manter a verdade que flui através dela.

Conclusão

O ServiceNow é melhor compreendido como um sistema para transformar o trabalho de serviço confuso em transições de estado governadas em todos os sistemas corporativos. Seus recursos de IA são importantes, mas não são o teste mais difícil do produto. O teste difícil é se uma solicitação real se torna um caso corretamente roteado, resolvido e auditável sem ocultar exceções, violar permissões, confiar em dados desatualizados ou reabrir após um fechamento prematuro.

Para o comprador certo, o ServiceNow pode reduzir o custo de coordenação ao colocar o estado do incidente, o trabalho de caso do cliente, o contexto do CMDB, integrações, aprovações, assistência de IA e evidências de auditoria em um único modelo operacional. Para o comprador errado, ou para um comprador que não deseja financiar a higiene de dados e a governança do fluxo de trabalho, ele pode se tornar um local caro para centralizar a confusão.

O veredito é condicional, mas claro. A plataforma do ServiceNow é mais forte quando a organização a trata como infraestrutura para um trabalho responsável, não como uma camada de respostas geradas. Se a Now Platform ajuda a fechar casos corretamente, manter as evidências intactas e tornar as exceções visíveis, ela ganha seu lugar. Se ela apenas torna a primeira resposta mais rápida, o trabalho real não foi automatizado; ele simplesmente foi movido para mais fundo na fila.