Sistema de tickets de service desk: o que é e quanto custa

O que um sistema de tickets de service desk realmente é

Eu desenvolvo as integrações na eesel. O que significa que meus dias passam lendo as APIs desses produtos em vez das páginas de destino deles, e é exatamente aí que a lacuna entre os dois é maior. A página inicial de cada fornecedor diz mais ou menos a mesma frase sobre otimizar o suporte de TI. O que você está realmente comprando é o modelo de dados por baixo que revela.

Vamos começar pela distinção que importa. Um help desk conserta o que quebrou. Um service desk também entrega o que as pessoas pediram. Essa segunda metade é toda a razão pela qual a categoria existe, e o trabalho é estruturalmente diferente: você precisa de uma lista publicada de coisas que podem ser pedidas, depois uma forma de travar cada uma atrás da pessoa certa, além de uma forma de distribuir o trabalho resultante entre equipes que não compartilham fila.

A Atlassian é honesta de forma refrescante ao admitir que a nomenclatura é uma bagunça. Ela cita uma pesquisa da HDI que descobre que 41% dos desks "são chamados de outra coisa", e depois acrescenta que "não há garantia de que os service desks e help desks relatados nessa pesquisa da HDI se alinhem às nossas descrições". Então, não compre pela palavra na caixa. Compre com base em se a ferramenta modela uma solicitação como algo de primeira classe, com uma entrada de catálogo, um aprovador e trabalho derivado, ou apenas como um e-mail com um campo de status. A versão mais longa desse argumento eu escrevi separadamente em help desk vs. service desk.

Um pedido, três números de registro

A forma mais clara de ver a diferença é observar o que acontece com uma única frase.

"Meu laptop não liga" é um incidente. Um registro, um responsável, uma resolução. "Preciso de um laptop novo" é uma solicitação, e dentro do ServiceNow isso vira três registros com três séries de números diferentes. Há a Request (sc_request, prefixo REQ), o contêiner em nível de carrinho para um checkout. Há o Requested Item (sc_req_item, prefixo RITM), um por item de catálogo pedido. Depois as Catalog Tasks (sc_task, prefixo SCTASK), o trabalho de cumprimento propriamente dito, que o fluxo do item gera. A própria referência da Service Catalog API do ServiceNow mostra uma resposta de checkout que traz "number": "REQ0010012" e "table": "sc_request", então isso não é lenda.

Peça um laptop e um monitor em um único checkout, e você recebe um REQ com dois RITM. Cada RITM pode gerar vários SCTASK, já que adquirir, fazer imagem e enviar são trabalhos de três pessoas diferentes. Uma peculiaridade que vale a pena sinalizar antes de montar relatórios: as respostas do catálogo só existem no RITM. O ServiceNow afirma que "as variáveis só estão associadas à tabela do Requested Item [sc_req_item]", motivo pelo qual um técnico trabalhando no SCTASK muitas vezes não consegue ver o que a pessoa realmente pediu, a menos que alguém tenha exposto isso deliberadamente.

O motivo para se importar com a contagem de registros não é organização. É que, segundo os benchmarks da MetricNet de tickets por técnico, a metade de solicitações da sua fila é aproximadamente de três a cinco vezes o trabalho da metade de incidentes, e o custo por ticket decorre disso: $113 por solicitação de serviço contra $48 por incidente em suporte de desktop. Considere esses valores como de 2011, e trate a proporção, não o valor, como o número duradouro.

O catálogo é onde os fornecedores discordam silenciosamente

Todo fornecedor vende a você "um catálogo de serviços". Quase nenhum deles quer dizer a mesma coisa com isso, e as diferenças são grandes o suficiente para mudar qual ferramenta você compra.

O Jira Service Management não tem nenhum produto de catálogo. A Atlassian diz isso diretamente: o template ITSM "vem com um catálogo de serviços de solicitações comuns. Elas são chamadas de tipos de solicitação", e você visualiza seu catálogo indo às configurações do espaço, depois Gestão de solicitações, depois Tipos de solicitação. Não existe um construtor separado. A antiga URL de documentação set-up-a-service-catalog retorna erro 404, porque tal coisa não existe. Isso não é automaticamente ruim, e também significa que não há trava de plano sobre o catálogo, mas se você chegou esperando uma experiência de compra com categorias e preços, vai se surpreender. Um administrador relatou que lhe disseram, em uma chamada de treinamento da Atlassian, que a lista deveria ficar pequena:

"The answer that I got was like, 'You shouldn't have more than 8-10 requests in your help center so if they need unique workflows then it shouldn't be a problem.'"

u/Hefty-Possibility625, r/jira, Reddit

Oito a dez itens é o volume de um help desk. Um catálogo empresarial não é. Se isso conta como orientação ou como um teto estrutural depende de quem você pergunta, mas de qualquer forma revela onde está o centro de gravidade do produto.

O Freshservice coloca o catálogo atrás do seu segundo nível. Uma conta Starter a $19 por agente tem incidentes, base de conhecimento, tarefas e um portal, mas sem catálogo e sem itens de serviço, então também sem solicitações de serviço abertas a partir de um formulário de catálogo. O catálogo começa no Growth, $49, o que representa um salto de 158% sobre o preço de entrada só pela funcionalidade que o torna um service desk. A gestão de SLA cruza na mesma linha, e isso se acumula, porque solicitações filhas são aplicadas contra "os SLAs correspondentes".

A ManageEngine cobra por ele separadamente. O ServiceDesk Plus lista $13 por técnico no Standard, $27 no Professional, e depois vende o catálogo de serviços como complemento: $1.595 por ano na tabela de complementos na nuvem, ou $1.195 na anual. Só no Enterprise, a $67, ele vem incluído. O CMDB é outros $1.595 por ano, somente no Professional.

O SolarWinds o inclui no nível mais baixo. Seu Service Catalog e o Advanced Approval Workflows aparecem ambos como "Incluído" no Essentials, no Advanced e no Premier, o que faz do plano Essentials a $39 a combinação genuína de catálogo e aprovações mais barata desta lista. Dois itens relacionados a aprovação seguem travados: Service Portal Tasks and Approvals, mais o Portal Designer. Ambos precisam do Advanced.

O ServiceNow o inclui e cobra em outro lugar. Service Catalog e Request Management ficam dentro do ITSM Foundation, o nível básico, junto com Incident Management e Asset Management. A página de preços não traz nenhum valor em dólares e apenas um botão "Get Custom Quote", então o catálogo estar livre de trava de plano é um consolo pequeno.

A Halo agrupa literalmente tudo. Um único plano, £69 por agente ao mês faturado anualmente, e os fluxos de aprovação, o CMDB, a gestão de projetos e a IA estão todos no preço base, com a linha explícita "sem níveis, sem complementos, sem funcionalidades trancadas". A pegadinha está na nota de rodapé. Pacotes de onboarding são obrigatórios na compra, a um custo sob medida, e o valor em dólares americanos é injetado do lado do cliente, então só o preço em GBP realmente é exibido.

Aprovações, a etapa que decide tanto seu tempo decorrido quanto sua conta

Aqui está minha leitura honesta, depois de construir contra a maioria dessas APIs: aprovações são o elemento menos pesquisado na compra de um service desk, e é onde vivem tanto o atraso quanto a conta surpresa.

Elas são modeladas de forma completamente diferente por cada fornecedor. No Jira Service Management, uma aprovação existe como uma propriedade de status do fluxo de trabalho, não como uma configuração de formulário. A documentação de aprovação de fluxo de trabalho da Atlassian é direta: a caixa "Include approval step" só fica disponível quando o status já tem pelo menos duas transições, uma para Aprovar e uma para Recusar. Aprovação em várias etapas, então, não é realmente uma funcionalidade do construtor. É você encadeando manualmente vários status portadores de aprovação. O quórum é configurável, embora uma recusa permaneça absoluta: se qualquer aprovador recusar, o item de trabalho é recusado, independentemente do número que você configurou.

O Freshservice substituiu seu antigo modelo sequencial por grupos e cadeias de aprovação: quatro regras de grupo e quatro regras de cadeia, onde grupos rodam em paralelo dentro de uma cadeia, mas só uma cadeia ativa por vez. Ainda no modelo legado? Anote a data. O Freshservice diz que a extensão final para a descontinuação das aprovações legadas é agosto de 2026, "após o que nenhuma outra extensão será concedida". Essa migração também tem uma cauda de API bem desagradável. O antigo endpoint de aprovador único aceita um aprovador de cada vez, e depois da migração cada chamada cria seu próprio grupo, com a regra de cadeia padrão em "Todos os grupos devem aprovar", o que trava silenciosamente as aprovações que antes se resolviam com "qualquer um".

Agora a parte comercial, que é a que eu colocaria na frente de quem assina o contrato.

No Jira Service Management, aprovadores são gratuitos. A Atlassian afirma isso claramente: "aprovadores não precisam de uma licença do Jira Service Management", só precisam ser clientes do espaço de serviço.

No ServiceNow, não. Usuários que só aprovam caem em uma classe medida separadamente chamada Business Stakeholder. O próprio guia de licenciamento de um funcionário da ServiceNow explica como isso funciona:

"Business Stakeholder (BSH): This one catches people off guard because it is measured across two separate tables - one for role assignment and one for approval activity. A user qualifies as a BSH if they hold an Approver role but hold no Fulfiller role. The moment a BSH user gains a Fulfiller-mapped role, they move out of BSH measurement entirely."

About ServiceNow Licensing Guide, ServiceNow Community

Se suas cadeias de aprovação roteiam para sessenta gestores que, de outra forma, nunca tocam em um ticket, essa frase ali é o seu orçamento. E a economia com solicitantes gratuitos desaparece por completo assim que você adiciona o bom portal de funcionários, já que produtos como Employee Center Pro e HRSD cobram pelo modelo Unrestricted User, no qual todo usuário ativo na instância conta.

Profissionais esbarram nisso no momento em que constroem seu primeiro item de catálogo. Em dezembro de 2025, um administrador fez a pergunta óbvia:

"I know I need the itil role for approvers to approve the requests, but, is that it? Isn't there like a 'lower' role that I can assign them that is enough for them to view the answers of the item and approve/reject the catalog task instead of assigning them the itil role?"

u/edoo_stuff, r/servicenow, Reddit

A antiga solução alternativa era a aprovação por e-mail, que contornava totalmente o papel. Uma resposta naquela thread relata que essa porta está se fechando: "Email approvals require the business stakeholder license to be assigned. This has come up for a ton of my clients recently." Então você não pode desenhar uma cadeia de aprovação do ServiceNow sem antes precificar cada pessoa dentro dela.

Cumprimento, e a caixa de seleção que transforma uma solicitação em dez

Assim que a aprovação é concluída, a ferramenta precisa distribuir esse trabalho. Essa é a camada que os compradores avaliam menos e com a qual depois convivem mais.

O mecanismo do Freshservice é uma única caixa de seleção no item de catálogo: "Create Child Requests for each of the items above." Deixe-a desmarcada, e cada linha de item fica dentro de um único ticket atribuído a um agente, que então muda cada item para Entregue ou Cancelado manualmente. Marque-a, e cada item vira um ticket filho individual com System como solicitante, roteado para o departamento que o possui, cada um com seu próprio relógio de SLA. O exemplo prático do próprio Freshservice é um pai New Employee Hire que gera New CRM Account, Apple MacBook e Adobe Photoshop CS6 como filhos.

Essa caixa de seleção é, para mim, a ilustração mais afiada de toda essa categoria. Um interruptor, e essa é a diferença entre uma caixa de entrada compartilhada e um service desk.

Duas coisas sobre isso vão te morder em produção, e ambas estão na própria documentação do Freshservice. Fechar um ticket pai fecha automaticamente todo filho vinculado, com o aviso de "garantir que todas as solicitações de serviço filhas tenham sido cumpridas antes de fechar o ticket pai". Depois há um limite rígido de 100 tarefas sob uma entidade pai, o que soa generoso até que uma onda de onboarding em massa chegue.

O equivalente no ServiceNow é a ação Create Catalog Task dentro do fluxo do item, cunhando um registro sc_task por etapa de trabalho. O Jira Service Management, vale notar, não tem nenhuma distribuição nativa desse tipo. Você obtém um item de trabalho por tipo de solicitação, e o cumprimento entre várias equipes é algo que você constrói sozinho, com automação ou issues filhas.

Ativos são o segundo medidor que ninguém orça

Se um sistema de tickets de service desk rastreia o que distribui, então precisa de um CMDB, e esse CMDB vem com sua própria lista de preços.

• O Freshservice não mede os dispositivos. Em vez disso, cobra Asset Units, sua própria métrica de licenciamento, que você compra em pacotes de 500. Nem o preço do pacote nem a cota incluída por plano são publicados em nenhum lugar dessa página de preços.
• O SolarWinds consegue ser o mais explícito e o mais travado atrás de cotação ao mesmo tempo. A gestão de ativos de TI está "disponível como compra adicional", com "preço de ativos disponível sob solicitação" escrito em cada cartão de plano, e a regra de contagem é ampla: qualquer dispositivo com capacidade de acessar uma rede conta para seu limite de ativos, "mesmo que o endereço IP não esteja sendo rastreado ativamente".
• O Jira Service Management publica cotas de objetos em vez de um preço: 5.000 no Standard, 50.000 no Premium e 500.000 no Enterprise, com um teto de 10 milhões em todo o site por cima. Ultrapasse o limite e as importações falham. Assets também é só para espaços gerenciados pela empresa, então em um espaço gerenciado por equipe não há CMDB.
• A ManageEngine cobra os ativos de TI gerenciados como uma segunda dimensão direta ao lado dos técnicos, e sua página de preços diz exatamente isso: "Se você usa gestão de ativos de TI, paga pelo número de ativos de TI gerenciados."
• A Halo e o ServiceNow incluem ambos o CMDB na oferta base, em um assento de £69 e em uma cotação não publicada, respectivamente.

Quanto custa um sistema de tickets de service desk em 2026

Aqui está a comparação que eu gostaria de ter tido quando comecei a ler essas páginas de preços. Todo valor é um preço de tabela retirado da própria página do fornecedor, verificado em 31 de julho de 2026.

Vale a pena destacar duas leituras dessa tabela.

Primeiro, o assento mais barato e o catálogo mais barato raramente são o mesmo produto. A ManageEngine vence no preço de assento, mas depois cobra $1.595 por ano pelo que o torna um service desk. O ponto de entrada real do Freshservice para um catálogo é $49, não $19. O Zendesk faz a mesma jogada com $29 e $59. O SolarWinds parece caro a $39, até você notar que o catálogo e o motor de aprovação já estão incluídos.

Segundo, o preço de assento para de prever sua conta no momento em que você ativa IA ou ativos. Quatro contadores, não um, e só o primeiro está na página de preços em fonte grande.

A camada de IA tem seu próprio medidor, e a unidade importa mais que a taxa

Cada um desses fornecedores agora vende IA no service desk, e cada um a conta de forma diferente. A unidade importa mais que o número.

O ServiceNow publicou sua tabela de taxas de assists como um PDF jurídico público em 23 de julho de 2026, o que o torna a plataforma grande mais transparente no momento. As linhas relevantes para ITSM: um resumo de incidente é 1 assist, uma recomendação de aprovação é 1, preencher previamente um formulário de catálogo é 1, um tópico de Virtual Agent executado do início ao fim é 10, um pedido de catálogo com várias rodadas é 10, e um fluxo de trabalho agêntico é 25, 50 ou 150, dependendo de quantas ferramentas ele toca. Assists são agrupados no nível da conta entre produção e sub-produção. Um fluxo de trabalho termina na conclusão, em 20 ações, ou após uma hora de inatividade, o que significa que a ação 21 inicia um segundo fluxo de trabalho faturável.

Vale notar nessa tela: o L1 Service Desk AI Specialist, aquele que de fato resolve o volume de nível 1, é exclusivo do Prime. Foundation e Advanced ficam com a IA assistiva.

O Freshservice conta sessões, definidas como qualquer interação que um usuário único tenha com o agente de IA dentro de uma janela de 24 horas, então ele cobra a tentativa, não o resultado. Cada licença Enterprise inclui 1.200 sessões por ano, cem por mês, e a taxa de excedente não é publicada em lugar nenhum. O Freddy AI Copilot custa $29 à parte por agente ao mês no Pro e no Enterprise, o que leva um assento Pro até $128.

O Jira Service Management roda três medidores ao mesmo tempo. Há créditos Rovo empacotados com o assento, e o agente de serviço virtual a partir de $0,30 por conversa assistida acima de 1.000 por mês, mais o Rovo Customer Service a $1 por resolução. A armadilha está na definição de "assistida": a Atlassian conta qualquer conversa associada a uma intenção, seja o agente resolvendo ou escalando, então um ticket escalado ainda é cobrado.

Essa é a pergunta de compra resumida em uma linha. Um medidor de resolução cobra quando funcionou. Um medidor de sessões ou conversas cobra quando tentou.

O que os benchmarks dizem sobre desvio, honestamente

Antes de comprar qualquer coisa com base em um número de desvio, calibre-se pela pesquisa em vez do slide de vendas.

O banco de dados de benchmarking da MetricNet coloca a taxa média de conclusão de autoatendimento para service desks no mundo todo em 10,4%, com um intervalo de zero, para desks sem autoatendimento, até um máximo de 55%. Sua passagem anterior encontrou 8,9%, e observou que "a grande maioria desses incidentes autorresolvidos são redefinições de senha". A resolução líquida no primeiro nível fica em média 74,3%, enquanto apenas 1,4% dos service desks passam de 95%.

Nessa mesma pesquisa há um efeito de segunda ordem que quase ninguém menciona e todo mundo sente: à medida que os tickets fáceis são desviados, "a complexidade média e o tempo médio de atendimento dos incidentes que continuam sendo tratados por agentes ao vivo vão aumentar". O desvio não apenas encolhe a fila. Ele a concentra. Então planeje sua equipe em torno da mistura mais difícil que sobra.

A escada de escalonamento é o motivo pelo qual tudo isso importa financeiramente. A MetricNet precifica o suporte de nível 1 em $22 por ticket, suporte de desktop em $62, nível 3 em $85, suporte de campo em $196 e suporte de fornecedor em $471, e essa escada é cumulativa: um ticket registrado no nível 1 e depois escalado para o nível 2 custa $62 mais $22, não só $62. Considere esses valores como de 2011, e leia a conclusão como duradoura: "maximizar o FLR equivale a minimizar o TCO".

O que quem administra esses desks realmente diz

Páginas de fornecedores não vão te contar nada disso, então aqui está uma leitura de profissionais dos últimos doze meses.

Sobre se um catálogo está funcionando, o teste mais afiado que encontrei não é uma funcionalidade de forma alguma. É um número que ninguém relata:

"Every incident/request should narrow down to an obvious CSI that an idiot in a hurry could categorise, consistently and repeatedly. If everyone is just hitting other, other, other then it's failed. Capital F."

u/gumbrilla, r/ITManagers, Reddit

Vá conferir qual porcentagem das suas solicitações cai em uma categoria genérica. Se for alta, mais itens de catálogo não vão ajudar, e roteamento por IA em cima de uma taxonomia que ninguém consegue navegar também não.

No lado do licenciamento, o mal-entendido mais caro dessa categoria é quem conta como agente. Um comprador da Atlassian publicou seus próprios números ao lado dos do engenheiro de nuvem dele:

"What I think I need (for starters): $ 8500 / year

What the cloud engineer thinks I need (for starters): $ 40,750 / year

JSM Standard - 10 agents - annual cost $2000

Confluence Standard - 10 users - annual cost $ 500

Atlassian access - 200 users - $6.000 (this one hurts)

JSM Standard - 200 agents - annual cost $25,750

Confluence Standard - 200 users - annual cost $ 9000

Atlassian access - 200 users - $6.000" -- u/LooselySubtle, r/atlassian, Reddit

Isso é uma oscilação de 4,8x causada inteiramente por 200 funcionários serem agentes ou solicitantes. Resolva essa questão por escrito antes de comparar quaisquer duas ferramentas.

E sobre IA: a thread mais útil que li este ano foi de um designer de produto da ServiceNow pedindo à própria comunidade histórias de sucesso do Now Assist para usar como referência. As respostas não foram o que ele esperava:

"These features all seem like things that make for a cool demo but don't actually save a company much time or money. Most of our closed incidents never get looked at again, and when they need to be looked at it's not particularly hard to read the history."

u/pnbloem, r/servicenow, Reddit

Outra resposta dentro dessa mesma thread foi direto contra a alegação de precisão:

"There is a persistent belief in the big tech bubble that it can, but it simply isn't good enough. It's auto prediction on steroids. Traditional automation is far more effective than chained ai agents that are only 50% accurate."

u/paablo, r/servicenow, Reddit

Eu vendo IA para filas de suporte, e acho que essa resposta é basicamente justa. Resumo e rascunho são as funcionalidades que melhor demonstram e menos mudam. O que realmente move os números de um service desk é a coisa chata: responder corretamente a pergunta repetida antes de qualquer humano abri-la. Todo o resto é decoração em cima de uma fila que continua do mesmo tamanho.

O que eu realmente checaria antes de assinar

Depois de mais de três anos colocando agentes de IA em filas reais de suporte e TI, as perguntas que eu faria a um fornecedor não se parecem em nada com uma matriz de funcionalidades.

1. Abra uma solicitação de onboarding no teste. Não uma redefinição de senha. Peça um laptop, uma conta e um telefone em um único envio, aprove como duas pessoas diferentes, e depois veja quantos registros existem, e se, de relance, você consegue dizer qual tarefa de cumprimento ainda está aberta.
2. Conte seus aprovadores, depois pergunte como eles são licenciados. Na maioria das ferramentas isso vem grátis. No ServiceNow é uma classe medida, e no ServiceNow o bom portal de funcionários também te move para faturamento por usuário ativo.
3. Pergunte por escrito o que o medidor de IA conta. Sessão, conversa, assist ou resolução. Depois pergunte qual é a taxa de excedente, já que Freshservice e Zendesk publicam ambos a cota mas não a taxa.
4. Peça o preço dos ativos. SolarWinds e Freshservice travam ambos isso atrás de cotação. Não é um item pequeno.
5. Verifique o caminho de exportação antes de ficar preso. O Freshservice não tem nenhuma exportação de UI para o catálogo; a solução documentada é uma chamada de API. Ótimo se você tem engenheiros à mão. Péssimo se não tem.

E uma ressalva honesta sobre minha própria categoria. IA em um service desk não é mágica, e eu tenho as cicatrizes para provar isso. Já tive clientes pagantes, entre eles uma fornecedora dinamarquesa de energia solar, cujo bot inventou respostas e as enviou para clientes reais nos momentos em que a base de conhecimento não tinha correspondência. É exatamente por isso que todo lançamento da eesel é simulado primeiro contra tickets históricos, e por que eu não confiaria em nenhuma alegação de desvio, incluindo a minha, que não tenha sido testada contra o seu próprio histórico de tickets.

A objeção que decide a maioria dessas compras é controle, não preço. Uma líder de CX em uma marca de suplementos com cerca de 7.000 tickets por mês colocou isso melhor do que eu conseguiria: a IA nunca vai responder tudo, mas se ela responde "desculpe, não sei" para tudo o mais, "eu não consigo ir checar todos os meus 7.000 tickets para ver se a IA realmente deu uma boa resposta, aí o objetivo meio que se perde". O que eles queriam era uma IA que só lidasse com aquilo que tem confiança, e deixasse o resto em paz. Perdi esse negócio por causa do roteamento baseado em confiança, e isso tornou o produto melhor.

Como eu escolheria em 2026

Se sua fila é majoritariamente de correção de falhas e você tem menos de dez técnicos, comece com o nível Standard gratuito da ManageEngine ou o Freshservice Starter, e pule o catálogo completamente até que as solicitações realmente superem os incidentes em número. Comprar um catálogo que depois você não preenche é o desperdício mais comum nessa categoria.

Se você precisa de um catálogo real mais aprovações pelo preço honesto mais barato, o SolarWinds Essentials a $39 é a escolha, porque os dois vêm no plano base em vez de serem vendidos à parte depois.

Se você já usa Atlassian, o Jira Service Management é difícil de contestar na estrutura de custo: solicitantes gratuitos e ilimitados, aprovadores gratuitos, $25 com 1 a 15 agentes. Só saiba que a página de preços define a calculadora por padrão em 75 agentes, então os $20 que você vê são uma taxa mista, não de tabela. Entre esperando construir seu catálogo como tipos de solicitação, e sua distribuição como automação.

Se você é uma grande empresa com obrigações reais de gestão de mudanças e CMDB, o ServiceNow é o modelo mais completo aqui, e ninguém argumenta seriamente que o design de incidente, mudança e CMDB esteja errado. A reclamação é sobre custo, cliques e meses, não sobre correção. Sua avaliação no G2 é 4,5 de 5 em 1.915 avaliações, com 70% cinco estrelas e zero uma estrela, o que não é o perfil de um produto ruim.

E se o que você realmente quer é um único preço sem nada travado, a Halo é o único fornecedor aqui que se compromete com isso, desde que você consiga conviver com um custo de onboarding sob medida e um valor publicado só em GBP.

Coloque a eesel na frente do service desk que você já usa

Nada do que foi dito acima é motivo para arrancar seu sistema de tickets, e eu não sugeriria isso. O que muda a economia de um service desk em 2026 não é uma fila diferente. É o que acontece com uma solicitação antes de um técnico sequer abri-la.

É isso que eu construo. A eesel se conecta ao desk que você já tem, aprende com seus tickets passados e com seus documentos existentes no Confluence, Slack, Google Docs ou uma base de conhecimento, e depois responde as solicitações repetidas como primeira resposta. Mesmo tipo de trabalho, seja a fila voltada ao cliente ou TI interna.

Jason Loyola, Head of IT na InDebted, opera exatamente nesse tipo de desk:

"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."

Jason Loyola, Head of IT, InDebted

A equipe dele está hoje em 15% de desvio em tickets internos de TI, com meta de 55%. Eu prefiro citar o número em andamento em vez de um finalizado, porque um lançamento de service desk é uma rampa, não um interruptor.

Duas coisas fazem isso se encaixar nesse problema específico. O preço não tem nenhuma dimensão de assentos: $0,40 por ticket atendido, sem taxa por agente e sem mínimo, então adicionar sessenta aprovadores, ou mil solicitantes, não custa nada. E você pode rotear uma fatia em vez da fila inteira, ou seja, apontá-la para as vinte perguntas repetidas de catálogo que consomem seu tempo de nível 1 e deixar as aprovações de mudança em paz. Se você usa o Jira Service Management, a conexão leva alguns minutos e é gratuita para experimentar.