Sistema de tickets em nuvem: o guia do comprador 2026

O que um sistema de tickets em nuvem realmente é

Tire o marketing de cima e há três coisas empilhadas aqui. Um registro: um ticket por solicitação, que carrega um assunto e um solicitante, um status, uma prioridade, mais quaisquer campos personalizados que você adicionar. Uma fila: as regras que decidem em quem o ticket recai, e quando o relógio começa a correr. E um contrato, que é o fornecedor operando os servidores, escolhendo a região, publicando (ou não publicando) um número de disponibilidade, e então cobrando você mensalmente.

Esse registro é a diferença toda entre isso e uma caixa de entrada compartilhada. Que é a comparação que a maioria das equipes pequenas está realmente fazendo, e eu detalho isso em caixa de entrada compartilhada vs sistema de tickets. O mesmo registro também separa configurações voltadas ao cliente das voltadas ao funcionário. O mesmo software roda um sistema de tickets interno para TI e para RH, e depois a categoria mais pesada sistema de tickets ITSM empilha gestão de mudanças e ativos em cima disso.

A nuvem já é o padrão agora, não uma escolha. O Zendesk é SaaS multi-tenant sobre a AWS, sem nenhuma opção auto-hospedada, segundo seu centro de confiança. A Gorgias fica no Google Cloud em vez da AWS. A Zoho é a exceção. Ela opera seus próprios data centers, em pares de cidades primária e secundária em oito regiões, mais uma região separada na China, todos listados no Know Your Datacenter.

Se o que você quer especificamente é um software que você mesmo hospeda, essa é uma lista completamente diferente. Minha seleção de sistema de tickets de código aberto é o ponto de partida certo.

O que a "nuvem" compra é real. Sem fins de semana de upgrade. Sem planejamento de capacidade também, além de um aplicativo móvel que funciona, e um novo canal vira uma chave em vez de um projeto. O que ela custa é controle sobre exatamente as três coisas acima. O resto deste guia trata das partes dessa troca que aparecem no quarto mês, não no primeiro dia.

Sistemas de tickets em nuvem comparados nos números que importam

Aqui está o mesmo conjunto de fornecedores, alinhados nas dimensões que realmente fazem diferença. Cada número é a taxa de cobrança anual retirada da própria página de preços do fornecedor, no final de julho de 2026. "Não encontrado" significa que o fornecedor não publica nenhum número que eu tenha conseguido localizar, o que já diz algo por si só. Suítes ITSM corporativas ficam fora desta tabela de propósito, porque o ServiceNow é um processo de compra completamente diferente.

Duas coisas saltam dessa tabela. Primeiro, o assento mais barato e o mês mais barato raramente são do mesmo fornecedor, porque tanto o medidor de IA quanto a trava de relatórios mexem no número real. Segundo, Gorgias e eesel são as duas únicas linhas em que adicionar mais uma pessoa à equipe não muda a conta em nada.

Calcule o que um mês realmente custa

As páginas de preços sempre citam uma taxa de assento. Um mês é o que ninguém cita. Insira seu próprio volume abaixo, e a aritmética roda sobre as taxas publicadas de 2026 da tabela acima.

Rode isso com 1.000 tickets e 5 agentes, e o formato do mercado aparece imediatamente. Os fornecedores que parecem baratos na linha de assento não são os que terminam mais baratos no mês. A linha do Zendesk nem consegue ser completada, porque ele publica a unidade, mas não o preço.

O modelo de dados do ticket é a parte que você não pode redesenhar depois

Toda demo mostra a caixa de entrada. Quase nenhuma mostra os campos, o que é uma pena, porque o modelo de campos é aquilo com que você ainda vai conviver no terceiro ano.

O Zendesk traz seis status padrão (New, Open, Pending, On-hold, Solved, Closed), e vários deles são de mão única. Assim que você move um ticket para fora de New, a documentação é explícita ao dizer que "você não pode mudar o status de volta para New". Closed também não pode ser definido manualmente, já que o fechamento é gerenciado por uma automação, e com as automações de fechamento desligadas, os tickets se fecham 28 dias após serem resolvidos, seguindo uma regra que "não pode ser alterada". Status personalizados existem em todos os planos Suite e são limitados a 100 por conta, mas apenas os primeiros 10 ativos aparecem no seletor, segundo gerenciamento de status de tickets.

O Freshdesk traz quatro status que você não pode excluir, mais um campo de prioridade que "não pode ser editado e está fixado diretamente em nossos sistemas porque está diretamente ligado à funcionalidade das Políticas de SLA", segundo seu guia de campos de ticket. Para status personalizados, é preciso ter Growth ou superior. Nesse mesmo documento também há uma armadilha real de perda de dados: mude ou exclua uma opção de lista suspensa que já esteja em uso, e "o valor desse campo será alterado para nulo" nos tickets existentes.

O Jira Service Management modela isso de forma diferente, e mais rígida: um tipo de solicitação fica sobre um tipo de trabalho, que por sua vez fica sobre um fluxo de trabalho, e a própria explicação da Atlassian avisa que "se você criar um item de trabalho sem um tipo de solicitação, suas solicitações não terão acesso a todos os recursos do Jira Service Management". É o único aqui que separa status (onde o trabalho está) de resolução (como ele terminou).

O HubSpot não tem, no sentido usual, nenhum campo de status. Um ticket ali é um registro de CRM sobre um pipeline, e a documentação da HubSpot observa que "para tickets, os estágios do pipeline são chamados de status por padrão, mas são os mesmos que os estágios de outros objetos". Flexível, até o momento em que você percebe que pipelines extras exigem Starter ou superior, e que Category e Language são propriedades exclusivas do Enterprise.

Por que isso importa numa terça-feira qualquer? Porque o modelo de status é o que decide o que o número do seu backlog realmente significa. Um líder de suporte resumiu o modo de falha melhor do que qualquer documentação de fornecedor:

"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."

Our Help desk ticketing system shows 200 open tickets but half of them have had no user response, Reddit

Noventa dos duzentos tickets "abertos" estavam parados esperando um cliente silencioso. A contagem de abertos nunca foi o backlog de verdade. A solução é um status de pendência mais uma regra de fechamento automático, exatamente o tipo de coisa que só se consegue construir quando o modelo de status permite. Um administrador no r/ITManagers cortou o backlog de um grupo em 54%, só fechando automaticamente os tickets com mais de cinco dias.

O mesmo aviso vale para a prioridade também. Deixar que os solicitantes a definam soa democrático, mas termina como seria de se esperar:

"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."

u/bitslammer, Reddit

Se você ainda está definindo as regras da sua fila, meus guias de roteamento de tickets e marcação de tickets vão um nível mais fundo do que esta seção pode.

O medidor de IA é uma segunda conta, e cada fornecedor conta diferente

Essa é a maior mudança no ticketing em nuvem desde 2024, e também é onde a maioria dos orçamentos de 2026 dá errado. Todo fornecedor agora vende uma camada de IA. Todo fornecedor a mede separadamente dos assentos, e nenhum par de fornecedores cobra a mesma unidade. Vale destacar que essa camada vem em dois sabores que convém distinguir: o agente voltado ao cliente que fecha tickets sozinho, e o copiloto de help desk que redige para um humano. Eles são cobrados de forma diferente e mexem em números diferentes, o que é todo o argumento em um help desk com IA.

Leia primeiro as definições, mais do que os números:

• O Zendesk cobra a resolução verificada. Desde 18 de maio de 2026 há três níveis: a escalação assistida (a IA ajudou, um humano terminou) não é cobrada, a resolução contida (a IA terminou, falhou na verificação de 72 horas) também não é cobrada, e a resolução verificada é cobrada. O que é um modelo mais justo do que aquele que substituiu. A taxa ainda não está em nenhuma página pública.
• O Freshdesk cobra a sessão, definida como todas as interações entre um usuário e o agente dentro de uma janela de 24 horas. Ou seja, cobra a tentativa, não o resultado. 500 sessões vêm incluídas tanto no Growth, Pro quanto no Enterprise, depois disso é 49 $ a cada 100 sessões.
• A Gorgias cobra a interação automatizada a 1,50 $, e não há desconto por volume em nenhum plano publicado, mais um segundo medidor sobre tickets a 0,40 $ ou 0,36 $ cada acima da cota, segundo sua página de preços.
• O Help Scout cobra a resolução a 0,75 $, e é incomumente rígido sobre o que conta: uma por conversa, e não é contada quando o cliente escala, ou busca na base de conhecimento, faz mais perguntas, ou clica em "ainda preciso de ajuda".
• O Jira Service Management roda três medidores ao mesmo tempo: créditos Rovo em pacote, depois 1 $ por resolução do Rovo Customer Service, e 0,30 $ por conversa assistida do agente virtual, em que uma conversa assistida conta qualquer conversa associada a uma intenção "independentemente de o agente de serviço virtual resolver o problema ou escaloná-lo".
• A eesel cobra 0,40 $ por ticket ou conversa atendida, não pela resposta, sem taxa de plataforma nem taxa de assento abaixo do Enterprise, segundo as taxas publicadas.

A unidade é todo o argumento aqui. Quando o Zendesk introduziu seu modelo de resolução automatizada, a reclamação nunca foi sobre o preço:

"Complete trash lol, stuff I used to get free now counts as an AR. Most of the ARs are abandoned chats. There's no dispute resolution process. Complete scam. I used to like Zendesk but since trying the new bot and now this I have little good will left"

u/Kerrick, Reddit

E em volume real, a conta não é pequena. Uma equipe B2B SaaS com dois agentes e cerca de 1.900 tickets por mês fez a conta em voz alta: "Mesmo com uma taxa de desvio conservadora de 50%, isso são cerca de 1.425-1.900 $/mês só de IA, além do nosso plano já existente."

Duas perguntas práticas para qualquer fornecedor, antes de assinar a linha de IA. Primeiro, consiga por escrito a definição de um evento cobrável, incluindo o que acontece com chats abandonados e com escalações. Segundo, peça uma ferramenta de previsão, porque cobrança por consumo sem uma é exatamente o que o financeiro vai contestar. Essa lacuna é uma reclamação real: um administrador observou que o Zendesk ainda não tinha lançado uma ferramenta de previsão de AR meses depois de o modelo ser lançado.

Também vale ser honesto sobre o que a camada de IA não faz. A partir dos nossos próprios dados de teste, um varejista alemão de joias online rodando cerca de 1.000 tickets por mês em Zendesk e Shopify obteve 93% de precisão na triagem e 100% de detecção de spam, mas apenas 12% dos rascunhos saíram como estavam, e houve uma taxa de erro factual de 7% nos rascunhos. A triagem foi a vitória. O piloto automático ainda não estava lá. Se você quiser os modos de falha em detalhe, eu os detalhei em alucinações de IA no suporte e passando de IA para um humano.

Disponibilidade e residência: as duas cláusulas que os compradores pulam

Aqui está a parte que surpreende quem só lê páginas de preços. No ticketing em nuvem, uma promessa de disponibilidade costuma ser um upsell de nível de suporte, e não um termo padrão.

O acordo de cliente padrão do Zendesk não traz nenhum número de disponibilidade, e ele afirma que os serviços não serão ininterruptos. O número de 99,9% que todo mundo cita se aplica ao Premier Support, que cobre exatamente cinco produtos, com Explore, Talk, WFM e QA ficando fora desse escopo.

O Help Scout é ainda mais direto, e presta o serviço "como está" e "conforme disponível" em seus termos de serviço. O acordo SaaS do Front não contém nenhum percentual de disponibilidade, nem nenhum regime de créditos de serviço. A Freshworks também não publica nada para o Freshdesk. A Zoho é quem publica um número real: 99,9% mensal, que ela detalha como "aproximadamente 43,8 minutos por mês" de inatividade permitida.

A residência de dados segue a mesma história, só que com uma reviravolta no momento do cadastro. A região do Freshdesk "só pode ser selecionada no momento da criação da conta", e mudá-la depois significa um ticket de suporte mais uma janela de migração não cotada, segundo seu documento de armazenamento de dados. A Zoho atribui o data center no cadastro e não replica entre regiões, e então dá 14 dias após a desativação antes que a conta antiga e seus dados sejam excluídos, segundo seu guia de migração de DC. O complemento regional do Zendesk é gratuito no Suite Professional e acima, mas está "incluído, mas não ativado automaticamente", e até que você o ative, o Zendesk "pode mover os dados de conta de clientes que não têm ou não ativaram o complemento Data Center Location entre regiões sem aviso prévio", segundo a documentação do complemento. O Front escolherá sua região por você, a menos que você peça, e mesmo assim ele diz que os dados "podem ser hospedados fora da região escolhida".

Um administrador de segurança que estava lidando exatamente com isso no r/sysadmin resumiu bem a versão realista:

"And yes, trying to get all your data permanently resident in the EU is nigh impossible if you're using major cloud providers. For example, Microsoft's EU data boundary has a boat load of exceptions."

u/Borgquite, Security Admin, Reddit

A frase final dele é a que vale levar para uma reunião de compras: você está avaliando e gerenciando o risco, não eliminando-o. Peça a lista de subprocessadores. Pergunte onde os backups ficam, e também o que acontece num failover, porque um failover regional é exatamente o momento em que uma promessa de residência é testada. A própria página de status da Freshworks registrou um desses casos, migrando clientes afetados para fora da região MEA rumo à EU North durante uma interrupção da AWS.

Relatórios são onde as travas de plano mordem mais forte

Ninguém troca de sistema de tickets por causa de um gráfico. Todo mundo reclama dos gráficos.

As travas são mais íngremes do que as páginas de preços sugerem. A construção de relatórios personalizados no Zendesk começa no Suite Professional, um salto de 60 $ por agente ao mês em relação ao Suite Team. A exportação de dados da interface do Zendesk não está disponível nos planos Team e vem desligada por padrão, então o dono da conta precisa contatar o suporte para ativá-la. A nova opção de relatórios do Freshdesk só está disponível a partir do Pro, e em nenhum plano o Freshdesk tem painel ao vivo. O Zoho Desk libera relatórios personalizados no Standard, mas mantém os painéis de SLA para o Professional e acima. O Front coloca relatórios personalizados atrás do Enterprise a 105 $ por assento. A Gorgias é a exceção aqui, oferecendo painéis, relatórios de SLA e CSAT, e exportação CSV também, em todos os planos de helpdesk.

O Help Scout é o que vale conhecer, porque sua página de preços insinua algo que sua própria documentação depois nega. Perguntado diretamente se dá para construir seus próprios relatórios, a documentação responde "Não no app", e direciona os clientes para a API, o Zapier, ou ferramentas de BI de terceiros. Essa linha de "relatórios personalizados" na página de preços significa visualizações de filtros salvas.

Mesmo onde o construtor existe, a usabilidade é um custo real. Um líder de suporte que já construiu painéis numa ferramenta de BI de verdade ainda assim bateu na parede:

"I have never found anything as complex as Zendesk explore.

I've worked with ThoughtSpot building dashboards, reports and exports but omg Zendesk, you are taking so much of my time!!!!!!!!"

u/kayscakes, Reddit

E quando a camada nativa derrota as pessoas, a solução alternativa é sempre a mesma:

"The reports and automations can be somewhat difficult to navigate. We ended up just exporting all of our tickets every month and creating our own reports through Power query in Excel."

Trent B., Director of Client Care, Capterra

Um diretor de atendimento ao cliente fazendo uma exportação manual mensal é um item de custo real. Então, antes de comprar, construa os três relatórios que você realmente roda toda semana durante o teste, não depois dele. Meus tutoriais de relatórios do Zendesk e acompanhamento de SLA são a forma mais rápida de ver se a ferramenta realmente consegue fazer isso.

Migração: os tickets se movem, a estrutura muitas vezes não

Trocar de sistema de tickets em nuvem é mais fácil do que trocar de software on-premise, e mais difícil do que a página de migração de qualquer fornecedor sugere. Os tickets em si exportam sem problema. O que quebra é tudo que dava a eles seu significado, começando pelas tags de tickets sobre as quais seus relatórios são construídos, depois os rótulos de campos personalizados, e também as notas internas.

"I have exported my historical tickets to XML but not going to work. First my tickets are a mess. They are not properly organized, tagged, or anything. Lot of the info chatGPT would need to understand is in custom fields which are not labeled in any export."

u/ToastyPasta, Reddit

Esse é um negócio de 15 milhões de dólares em receita que estava no mesmo sistema desde 2015. Campos personalizados sem rótulo na exportação também são o motivo mais comum pelo qual o treinamento de IA com tickets antigos trava depois de uma migração. O modelo vê o corpo do ticket, e nenhum dos dados de disposição que o tornavam útil.

A outra coisa que vale nomear com honestidade: um fornecedor estabelecido há 15 anos ainda pode perder um comprador sênior por razões inteiramente mundanas.

"Zendesk is very configurable, though I struggle to think of what I like about Zendesk. I found the reporting tool in particular to be very difficult to use. Their AI offerings felt bolted on versus integrated, and their integrations didn't work particularly well. Support was not timely. Pricing was not competitive. This is why we moved to another tool."

Gail D., Senior Director of Customer Support, G2

Quatro razões numa só respiração, e nenhuma delas é uma funcionalidade faltando. Se você está nesse caminho, minhas seleções de alternativas ao Zendesk e melhor software de helpdesk mostram onde essas equipes acabam pousando.

O que eu verificaria antes de assinar

Seis coisas, na ordem em que eu realmente as verificaria.

1. Construa seus três relatórios semanais durante o teste. Não uma demo de relatórios. Os seus, com seus próprios campos, no plano que você pretende comprar. Isso sozinho elimina mais listas curtas do que qualquer outra coisa.
2. Consiga por escrito a definição do que é IA cobrável. Especificamente: chats abandonados, conversas escaladas, e contatos repetidos dentro da janela. A taxa de resolução que te informam não significa nada até você saber o que conta como uma.
3. Exporte uma amostra e reimporte em algum lugar. Verifique se os rótulos dos campos personalizados sobrevivem, e as tags e notas internas também, não só o corpo dos tickets.
4. Encontre a cláusula de disponibilidade no contrato, não na página de marketing. Se estiver atrelada a um nível de suporte, cote esse nível agora.
5. Confirme a região de dados no cadastro, não depois. No Freshdesk e na Zoho, essa é uma decisão de uma única chance.
6. Conte os assentos que você terá em 18 meses. O preço por agente se acumula. Se você espera que a equipe dobre, as opções baseadas em uso mudam de posição inteiramente na lista.

Se a dor que te levou às compras é volume, e não software, resolva isso primeiro. Um backlog de tickets geralmente responde melhor a regras de fechamento automático mais um caminho de escalação que funcione, do que a uma migração.

A alavanca mais rápida sobre o próprio volume é treinar a IA na sua base de conhecimento, em vez de adicionar mais assentos. As equipes de TI têm sua própria versão disso, que eu cubro em ticketing de TI automatizado.

Vale colocar a promessa de desvio em perspectiva também. Fornecedores vão citar números como o "até 80% das interações" do Zendesk, enquanto o benchmarking da MetricNet, publicado pela HDI, coloca a taxa média de conclusão de autoatendimento para service desks no mundo todo em 10,4 por cento, variando de zero a 55. A leitura honesta é que a diferença entre esses dois números é principalmente qualidade de configuração. A forma de descobrir de que lado você fica é testar com seus próprios tickets históricos, antes de se comprometer.

Experimente a eesel no sistema de tickets em nuvem que você já tem

A maioria das equipes lendo isso não precisa de um novo sistema de tickets em nuvem. O que elas precisam é que o que já usam pare de consumir o volume de nível 1.

Esse é o trabalho que a eesel faz. Ela se conecta ao Zendesk, Freshdesk, Gorgias, Front e outros em poucos minutos, treina com seus tickets anteriores, sua central de ajuda e documentos internos, e então responde ou redige com a sua voz dentro da ferramenta que seus agentes já têm aberta. Duas coisas fazem ela se encaixar especialmente neste guia. Primeiro, ela roda uma simulação contra seus tickets históricos antes de tocar numa fila ao vivo, então você vê a taxa de resolução e a redação nos seus próprios dados primeiro, e isso existe porque já vimos um bot confiante inventar respostas para clientes reais. Segundo, ela cobra 0,40 $ por ticket atendido sem taxa de assento, o que faz de um rollout parcial uma opção real: 1.000 tickets por mês com 200 direcionados à IA custam 80 $, não um upgrade de plano.

Também é justo dizer onde ela não é a resposta. Se você precisa que a IA tente cada ticket sem exceção e produza uma resposta confiante em todos eles, não é assim que ela é construída, e um líder de CX de uma marca de suplementos nos disse exatamente isso durante um negócio que perdemos: "Preciso de uma IA que só atenda os tickets nos quais ela está confiante, e todos os outros, deixe quietos." Isso é intencional, e é o design certo para quem não consegue auditar 7.000 tickets por mês. A Gridwise relatou ter resolvido 73% das solicitações de nível 1 no primeiro mês após um teste de 7 dias, que é exatamente o tipo de resultado para o qual a cobrança de rollout parcial foi pensada.

Comece pela página de preços se o que você quer é a conta, ou pela integração com Zendesk se quiser ver funcionando na fila que você já tem.