O sistema de tickets do ServiceNow: como funciona e quanto custa

O que é realmente um sistema de tickets do ServiceNow

Comecemos pela base. A base explica tudo que vem acima dela.

Todo ticket no ServiceNow vive em uma tabela que estende um único pai. A própria documentação da empresa é direta sobre isso: a tabela Task "é uma classe base que fornece campos para as principais aplicações de ITSM, como Incident, Problem e Change Management. Todas as aplicações que estendem a tabela Task compartilham esses campos em comum."

Você não pode escrever diretamente em task. Se tentar, um Task Interceptor impede e obriga a escolher primeiro uma tabela filha. O campo sys_class_name então registra qual filha foi escolhida. Para sempre.

Aqui está toda a família com os nomes exatos das tabelas, já que o nome da tabela é o que determina o comportamento:

Os prefixos também não são fixos no código. Eles existem como linhas na tabela sys_number, sob System Definition, e qualquer administrador pode alterá-los, segundo a documentação do ServiceNow sobre numeração de registros. Vindo de uma ferramenta plana como o Zendesk, essa é a primeira diferença real que se sente: aqui o tipo de registro é uma decisão de esquema, não uma lista suspensa em um formulário.

O retorno de toda essa herança é real, e merece o devido crédito antes que eu comece a apontar falhas. Aprovações, regras de atribuição, SLAs, monitores de inatividade e fluxos funcionam todos sobre qualquer coisa que estenda task, então você os constrói uma única vez. Essa é a parte que uma ferramenta de help desk menor não consegue igualar, e é o que separa uma plataforma de um sistema de tickets automatizado. Os usuários também percebem isso.

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

Louis B., G2

É assim que um registro se parece quando você está dentro dele. Repare nos campos que fazem o trabalho de roteamento, Assigned to e Assignment group, ambos herdados diretamente de task:

Uma solicitação, três números de ticket

É aqui que o primeiro dia dá errado, para quase todo mundo.

Alguém pede um notebook. Em um sistema de tickets normal isso é um ticket, e na maioria dos sistemas de tickets internos continua sendo um único ticket até a entrega. O ServiceNow transforma isso em três tipos de registro, porque o Request Management modela deliberadamente o pedido, o item e o trabalho como coisas separadas:

1. REQ em sc_request, o container no nível do carrinho. Um checkout gera um REQ.
2. RITM em sc_req_item, um por item do catálogo. Um notebook e um monitor no mesmo checkout significam um REQ carregando dois RITMs.
3. SCTASK em sc_task, o próprio trabalho de cumprimento, gerado pelo fluxo do RITM. Comprar, configurar a imagem, depois enviar: três SCTASKs a partir de um único RITM.

Então uma única pessoa pedindo uma única coisa pode facilmente gerar cinco registros distribuídos em três séries numéricas, com três lugares separados para verificar um status. Não é um bug. Essa é a separação entre carrinho, item e trabalho, construída de propósito. E é também, de forma consistente, o que faz novos agentes tropeçarem:

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

Andrei F., Knowledge Specialist, Capterra

Os itens de catálogo que geram a maior parte desse volume são os mais banais. Solicitações de acesso são a maior categoria isoladamente e a que mais vale a pena automatizar. Pedidos de kits e equipamentos vêm logo atrás, e nosso guia sobre solicitações de hardware trata deles separadamente.

Uma armadilha que vale a pena conhecer se você é quem constrói o catálogo: as variáveis só existem em sc_req_item. O ServiceNow diz isso claramente: "Variáveis não são suportadas em tabelas estendidas." Tudo que o usuário digitou no formulário do catálogo, portanto, fica no RITM, e fazer com que chegue até o SCTASK, onde o fulfiller de fato pode ver, é um ato deliberado de configuração. Se seus fulfillers ficam perguntando "que tamanho de monitor eles queriam", essa é a razão.

O ciclo de vida do incidente, estado por estado

Incidentes são a metade mais simples. O modelo de estados está publicado por completo.

Você leu certo, não existe 4 nem 5. São buracos deixados para trás pelo modelo anterior ao Helsinki, que tinha três estados de espera separados onde agora há apenas um, On Hold. O próprio artigo de conhecimento do ServiceNow, KB0564465, publica o mapeamento e diz exatamente o que quebra: "se você tinha um workflow que era acionado no estado 5, precisa modificá-lo para ser acionado no estado 3, motivo 2."

Agora a parte que mais me surpreendeu na documentação. O ServiceNow recomenda não instalar o modelo de estados moderno em instâncias atualizadas. Ou seja, muitas instâncias de produção de longa data ainda rodam o velho formato de cinco estados por baixo de uma interface moderna. Qualquer relatório ou workflow escrito em cima de um número de estado bruto depende da versão, então é uma pergunta real a fazer antes de herdar a instância de outra pessoa.

Três comportamentos que pegam as pessoas de surpresa

Prioridade não é uma decisão do agente. Ela é calculada a partir de uma grade 3x3 de Impact e Urgency, e o campo vem somente leitura. O ServiceNow diz isso diretamente na página de regras de busca de prioridade: "Respondentes individuais de incidentes não podem alterar as regras de busca de prioridade." Um P3 que todo mundo concorda que deveria ser P1 se torna uma conversa com um administrador, não uma lista suspensa.

O fechamento automático é um job agendado, não um temporizador no registro. Duas consequências decorrem disso. Primeiro, a trilha de auditoria mente, porque "atribui o nome do administrador que estava logado quando o job Autoclose Incidents é executado ao campo Updated by." Segundo, um monitor de inatividade "reinicia esse relógio de fechamento automático a cada vez que é acionado", então uma instância que roda ambos os recursos acumula silenciosamente incidentes Resolved que nunca fecham, e nada expõe o conflito. A correção, segundo a documentação do ServiceNow, é uma Reset Condition de [Incident state] [is not] [Resolved].

Fechar um pai não fecha seus filhos. Resolver, sim. Fechar, não. Coloque cem filhos sob um incidente pai de uma queda de rede, e fechar o pai deixa cem registros Resolved esperando por chamadores individuais, segundo a tabela de sincronização pai-filho. Essa assimetria costuma contribuir para um backlog de tickets que parece pior em um painel do que realmente é.

Como os tickets são realmente roteados

O roteamento funciona sobre dois campos herdados, assigned_to e assignment_group, por isso se comporta da mesma forma em todo tipo de registro. Regras de atribuição os definem automaticamente sempre que as condições coincidem.

Uma regra sobre essas regras merece um cartaz. Da documentação de regras de atribuição: "Regras de atribuição não podem sobrescrever atribuições existentes (incluindo atribuições definidas por um valor padrão ou por uma regra de atribuição executada anteriormente)." Um valor padrão bem-intencionado em assignment_group, então, desativa silenciosamente toda regra de roteamento escrita depois. E quando várias regras coincidem, apenas a de menor valor de ordem é executada. Sempre.

Também existe uma armadilha de permissões, e ela parece um bug na primeira vez que você a encontra: um usuário com o papel itil não pode atribuir um incidente a um grupo que tenha o papel admin ou security_admin, nem a nenhum grupo cujo pai tenha esses papéis.

Para uma leitura mais aprofundada sobre como acertar essa camada, nosso guia sobre roteamento de tickets com IA vai além do que posso cobrir aqui, enquanto o artigo complementar sobre marcação de tickets com IA cobre a metade da classificação. A visão de categoria mais ampla está no nosso guia sobre ticketing de TI automatizado.

SLAs, e o campo que não faz nada

O Service Level Management do ServiceNow é forte, e uma única task pode carregar vários SLAs ao mesmo tempo, cada um rastreado em seu próprio registro task_sla. Os usuários avaliam bem essa parte:

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

vignesh m., admin, G2

Duas coisas valem a pena saber antes de desenhar seus acordos.

Primeiro. A distinção entre SLA, OLA e Underpinning Contract, à qual todo curso de ITIL dedica uma hora, dentro do produto é apenas um rótulo. A nota do ServiceNow sobre o campo Type tem apenas uma frase: "Type é usado apenas para fins de relatório." Mesmo motor, mesmas condições, cálculos idênticos. O campo Target de Response versus Resolution segue a mesma lógica, existindo "apenas para fins de filtragem, busca e relatório."

Segundo, dias não são dias úteis. A documentação explica a armadilha: "O número de dias especificado neste campo é convertido em blocos de 24 horas. Se o campo Schedule identifica um cronograma com dias de oito horas, uma duração de 1 dia faz o SLA ser violado três dias úteis depois." Design razoável. Também uma forma muito fácil de colocar em produção um SLA que falha durante um ano inteiro antes que alguém perceba.

Também vale saber: em uma instância moderna, Breached não é, de forma alguma, um estágio de task_sla. Os estágios são In progress, Cancelled, Paused e Completed. Breached sobrevive apenas "em sistemas que usam o motor de SLA de 2010, ou que rodam em modo de compatibilidade", e ainda assim o widget visual do temporizador continua mostrando-o, então os dois vocabulários não concordam. Construa relatórios de SLA em cima disso, e essa discrepância vai te encontrar.

Autoatendimento, e o que o Virtual Agent realmente desvia

O autoatendimento é onde vive a história do volume de tickets, e onde os níveis começam a importar.

O Virtual Agent completo é competente. O ServiceNow entrega tópicos de ITSM pré-construídos que fazem trabalho real. Check IT Ticket Status lista os tickets ativos de um usuário com estágio e última atualização. Escalate IT Ticket eleva a urgência em um nível, com justificativa obrigatória. Há também tópicos para reserva de salas de reunião e equipamentos atribuídos. O próprio desvio é definido de forma estrita, como "quando um usuário faz uma pergunta ou solicitação que não resulta em um ticket ou assistência humana."

Virtual Agent Lite, o que os clientes de níveis inferiores recebem, é um animal diferente. Vem com dois tópicos, Check Ticket Status e Report an Issue. Sem nenhum NLU, apenas correspondência de palavras-chave. Você não pode adicionar tópicos nem canais. E, criticamente, não tem nenhum painel de análise, então não há forma suportada de medir o quanto ele desviou. Avaliar o desvio no Lite significa avaliar algo que você não pode medir, o que vale a pena saber antes de compará-lo com qualquer chatbot de service desk que de fato reporta uma taxa de resolução. Equipes que esbarram nesse muro costumam acabar olhando para alternativas ao Virtual Agent.

Mais uma restrição incomoda em produção. Passar para um humano exige um humano. "Pelo menos um agente ao vivo precisa estar disponível ao transferir a partir do Virtual Agent, caso contrário o usuário final recebe uma mensagem no agents available e a conversa não é transferida." Não existe nenhum fallback de ticket documentado nesse caminho, exatamente o momento em que um bom design de handoff de IA mais importa.

A entrada por e-mail tem sua própria versão do problema. A classificação como encaminhamento vence a marca d'água, então o ServiceNow "classifica qualquer e-mail que atenda a esses critérios como um encaminhamento, mesmo que a mensagem contenha uma marca d'água ou número de registro que de outra forma o classificaria como uma resposta." Em termos simples, encaminhar uma thread de e-mail para o ServiceNow sempre cria um ticket duplicado.

Quanto custa um sistema de tickets do ServiceNow em 2026

Agora a parte pela qual todo mundo realmente veio.

O ServiceNow não divulga preço, e é por isso que nosso guia de preços do ServiceNow existe. Conferi novamente a página de preços de ITSM no próprio dia em que escrevo isso. Três pacotes, Foundation, Advanced e Prime. Um único botão dizendo "Get Custom Quote". Nenhum símbolo de moeda em nenhum lugar da página. Os únicos números em toda a matriz comparativa são limites de capacidade para tabelas do App Engine Starter e registros de Process Mining.

Desde 9 de abril de 2026, os antigos níveis Standard, Pro, Pro Plus, Enterprise e Enterprise Plus desapareceram, com os SKUs legados chegando ao fim de venda em 1º de julho de 2026. Foundation, Advanced e Prime são agora a única estrutura que um novo comprador vê.

Leia a linha de IA duas vezes. Ela resume todo o empacotamento em uma única linha. A IA que de fato fecha um ticket sem um humano é exclusiva do Prime. Foundation e Advanced recebem, em vez disso, IA assistiva: resumos, rascunhos, um chatbot. Um MVP do ServiceNow escrevendo na comunidade diz a mesma coisa sobre construções personalizadas, que o Prime "é o único nível que permite construir habilidades de IA e agentes de IA totalmente novos e personalizados na plataforma." Então o AI Agent Studio é um recurso do nível superior, e não da plataforma como um todo, e o panorama de custo mais completo está no nosso detalhamento de preços de IA do ServiceNow.

A divisão aparece também no próprio marketplace do ServiceNow, onde o L1 IT Service Desk AI Specialist fica ao lado do filtro de persona que nomeia Fulfiller como sua própria classe licenciada:

Por quem você realmente paga

Este é o único fato que torna "quanto custa o ServiceNow" respondível. Para ITSM, a cobrança é sobre o papel de Fulfiller. Um funcionário do ServiceNow que escreve o guia de licenciamento o define como "seus agentes principais de service desk, gestores de casos e responsáveis por fluxos de trabalho. Qualquer pessoa que trabalha ativamente e resolve registros", contados como usuários ativos que fizeram login nos últimos 365 dias.

Requesters, ou seja, os funcionários que abrem os tickets, não são contados. Uma vantagem real em relação a ferramentas cobradas por assento, e o mesmo tipo de economia que torna o Jira Service Management mais barato que o Jira comum para um caso de uso de suporte.

Depois chegam as duas exceções.

Um gestor que apenas aprova coisas conta como um Business Stakeholder medido separadamente, não como um usuário gratuito. E alguns produtos cobram pelo modelo Unrestricted User, no qual todo usuário ativo da instância conta. HRSD e Employee Center Pro estão ambos nesse grupo. Assim, a economia de "requesters são gratuitos" evapora no dia em que você compra o bom portal, ou no dia em que o RH quer entrar.

O tamanho dessa decisão não é pequeno. Um ServiceNow Certified Technical Architect escreve publicamente:

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

Bill Martin, ServiceNow Community

Então um funcionário do ServiceNow aparece nos comentários para corrigir a leitura equivocada comum sobre a alternativa:

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

Lenny Leppers, ServiceNow Community

Mais duas armadilhas do mesmo arquiteto, nenhuma das quais aparece em qualquer página de preços. O licenciamento é por instância, então instâncias separadas para América do Norte e EMEA dobram a conta. E ele coloca os usuários fantasmas em "20-25% das licenças do ServiceNow" em grandes empresas, frente a um aumento anual de 7 a 12%. Nosso guia de tipos de licença percorre o conjunto completo caso você esteja no meio de uma negociação.

O medidor de assists, agora público

Aqui está a novidade. Em 23 de julho de 2026, o ServiceNow publicou o Now Assist Overview como documento legal, e a tabela de preços por ação veio junto. Até oito dias antes de eu escrever isto, nenhum desses números era público.

Um assist é "uma unidade usada para medir o uso das habilidades do Now Assist por meio de ações de habilidade executadas", e é consumido "seja em instâncias de produção ou de sub-produção." As entitlements ficam agrupadas no nível de conta e são reiniciadas no aniversário da sua compra, em vez de no ano civil. Se você ultrapassar, "o ServiceNow pode faturar o Cliente pelo uso excedente."

O intervalo, ao longo de três ordens de grandeza, é a verdadeira história:

Um "fluxo de trabalho agêntico" termina ao ser concluído, em 20 ações, ou após uma hora de inatividade. Qualquer coisa além dessas 20 ações inicia um novo fluxo de trabalho faturável. Então um ticket pode custar como se fossem dois.

A frase à qual continuo voltando vem de um guia prático do ServiceNow: "A surpresa para a maioria das equipes é que o maior consumo não vem de usuários digitando prompts. É a automação rodando em segundo plano." Ele nomeia quatro fontes de consumo silencioso. Virtual Agent recorrendo ao Now Assist em um tópico sem correspondência, resumo de workspace disparando ao abrir um case, habilidades personalizadas do Skill Kit, e instâncias de sub-produção. O ServiceNow lançou interruptores de emergência e alertas de pico em junho de 2026 para conter tudo isso, com uma instrução documentada de não desativar as notificações porque "ambientes de sub-produção também consomem assists!"

O ServiceNow não divulga um tamanho de pool para os novos níveis, então aplique seus próprios números contra a última alocação que de fato publicou: 6.000 assists por fulfiller por ano, sob o modelo legado Pro Plus.

Mova o controle deslizante do agente autônomo de 5% para 15% e observe o que acontece. Esse único movimento é toda a diferença entre a IA assistiva e a IA autônoma pela qual você comprou o Prime. É também por isso que eu gostaria de uma previsão de assists por escrito durante a conversa do contrato, não depois dela.

O que as pessoas realmente dizem sobre trabalhar com isso

Quero ser justo aqui. É fácil montar um texto de ataque a partir de uma busca por reclamações.

O corpus não sustenta isso. O ServiceNow ITSM está em 4,5 de 5 em 1.915 avaliações no G2, 70% delas com cinco estrelas e, notavelmente, zero por cento com uma estrela. O Capterra o coloca em 4,5 em 352 avaliações. Ninguém sério argumenta que o modelo de incidente, mudança e CMDB está errado.

O que dizem é que é pesado. As próprias contagens de tags do G2 colocam Ease of Use como o atributo mais elogiado, com 168 menções, com Learning Curve (72), Expensive (60) e Complexity (56) logo atrás. Essa tensão é o resumo honesto do produto.

Sobre a experiência do dia a dia:

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

Chris C., G2

Sobre a curva de aprendizado, de um desenvolvedor que mesmo assim deu 4,5 de 5:

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

Shruti C., Developer, G2

E a metáfora mais afiada de todo o conjunto, de uma implementação que claramente deu errado:

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

Verified User in Insurance, G2

O contrapeso, e acho que é a coisa mais verdadeira que alguém disse em todo o conjunto: a opinião da maioria das pessoas sobre o ServiceNow é, na verdade, uma opinião sobre a implementação de outra pessoa. Um comentarista do Hacker News colocou assim, que "uma instância bem gerenciada consegue voar", e culpou a maioria das experiências ruins por clientes "arrastando código horrível e apps LCNC mal projetados." Isso combina com o que eu vejo. A plataforma raramente é o problema. O formulário de 400 campos que alguém construiu em cima dela, geralmente é.

Onde ele se encaixa, e onde eu não usaria

O ServiceNow é a escolha certa quando tickets não são o ponto central. Se o que você precisa são incidentes vinculados a uma CMDB, gestão de mudanças com autorização CAB real, registros de problema que sobrevivem aos incidentes que os originaram, além de um único motor de fluxo de trabalho que abranja TI, suporte de RH e instalações, nada no mercado intermediário se compara. Cara a cara contra o Freshservice, essa amplitude é todo o argumento. Nessa escala, vale o dinheiro.

Eu não compraria isso para tocar uma simples fila. Se ticket entra, ticket sai é todo o trabalho, você vai pagar preço de plataforma corporativa por uma fração da plataforma, e a reclamação sobre a ferramenta de ticketing cara se escreve sozinha. Um comentarista do Hacker News descreveu um CIO fazendo exatamente isso: substituindo um rastreador existente para apenas duas filas, sem CMDB e sem gestão de mudanças, por "128k por ano." Se essa é a forma da sua necessidade, nosso resumo para equipes pequenas ou as opções de código aberto são a resposta honesta.

O terceiro caso é o interessante, e é onde a maioria dos leitores deste artigo realmente está. O ServiceNow já está instalado, não vai a lugar nenhum, e a fila continua crescendo. Arrancá-lo não está sobre a mesa. Adicionar um nível Prime para que um especialista de IA possa fechar tickets de nível um é uma conversa de orçamento com um medidor não publicado anexado. Isso deixa uma única alavanca, a mesma na qual todo projeto de IA para help desk de TI eventualmente aterrissa: desvio na entrada.

Experimente o eesel na frente da sua fila do ServiceNow

Deixe-me ser direto sobre o que estou e o que não estou oferecendo aqui. A versão honesta é, de qualquer forma, mais útil.

O eesel não é um plugin do ServiceNow. Não há integração com o ServiceNow na nossa página de integrações, e prefiro dizer isso aqui do que deixar você descobrir no meio de um teste.

O que o eesel faz é ficar um passo antes, nos canais onde as perguntas de TI realmente começam. Ele responde no Slack, no Microsoft Teams e por e-mail, antes de qualquer um abrir um formulário. O conhecimento a partir do qual ele responde é a documentação que você já escreveu, onde quer que ela esteja hoje: Confluence, Google Docs, Notion, um help center.

Eu construo os agentes que fazem isso, então o mecanismo importa para mim. O agente busca na sua documentação real, responde quando tem base para isso, e fica em silêncio quando não tem. Essa última parte é o jogo inteiro. Depois de ver um bot de voz confiante dando respostas erradas em uma fila ao vivo, agora simulamos todo rollout contra tickets históricos antes que ele chegue a uma pessoa real, e tudo abaixo do limite de confiança escala em vez de chutar.

O número que eu destacaria não é nosso. Jason Loyola, Head of IT da InDebted, roda o eesel como primeiro respondente no help desk de TI interno deles, e os resultados são públicos: 15% dos problemas recebidos totalmente desviados hoje, com 55% como meta à medida que o conhecimento é reescrito a partir de tickets resolvidos. Sua própria descrição da configuração: "Basicamente age exatamente como um agente agiria."

Mais duas limitações, já que você deve conhecê-las antes de experimentar. Ele não vai corrigir um problema de documentação. Se a resposta para "como consigo um notebook novo" não está escrita em lugar nenhum da sua base de conhecimento interna, nenhuma IA vai inventá-la. E é uma camada, não uma substituição, então seu modelo de incidentes, mudanças e CMDB permanece exatamente onde está. O preço funciona por ticket tratado em vez de por assento, o que pelo menos significa que a conta não sobe toda vez que a TI contrata alguém.

Você pode experimentar gratuitamente e apontá-lo para as perguntas que o seu service desk responde cinquenta vezes por mês, e então ver quantas delas realmente precisavam de um ticket.