Sistema de tickets da Salesforce: como os cases realmente funcionam em 2026

O que as pessoas querem dizer com "sistema de tickets da Salesforce"

Todo helpdesk tem um substantivo para aquilo que um agente trabalha. O Zendesk tem tickets, o Jira tem work items, e a Salesforce tem Cases. A referência do objeto define isso em uma linha: o objeto Case "representa um case, que é um problema ou questão do cliente".

O nome mudou de novo. A Salesforce Help agora exibe um aviso na tabela de edições de serviço dizendo "Service Cloud agora é Agentforce Service", alertando ao mesmo tempo que o nome antigo ainda aparece por todo o produto e na documentação. Se você está lendo material de fornecedor de 2025, está lendo sobre o mesmo produto sob outro rótulo. Nosso panorama do Service Cloud traz o tour mais amplo do produto.

O ponto estrutural importante é que um Case é um objeto padrão de primeira classe na plataforma de CRM, não um complemento anexado. Ele suporta toda a superfície de API, de create() a upsert(), e é por isso que um ticket da Salesforce pode ser vinculado a uma Account, uma Opportunity e um Asset sem que ninguém precise construir uma sincronização. Esse é o motivo real pelo qual as empresas permanecem: o ticket fica no mesmo registro que o dinheiro.

Se você ainda está pesando categorias, nosso guia sobre software de sistema de tickets cobre as alternativas, e o panorama de integrações da Salesforce mapeia o que mais se conecta ao mesmo registro.

Uma pequena armadilha para quem escreve código de integração: como case é uma palavra reservada em Java, a nota sobre palavras reservadas diz que talvez seja preciso escrever seu aplicativo "usando _case em vez de Case".

O registro Case: os campos dos quais todo o seu fluxo de trabalho depende

Quase toda pergunta de fluxo de trabalho no ticketing da Salesforce volta a um punhado de campos padrão. Aqui estão os que têm peso, direto da referência da API v67.0.

Essa linha de OwnerId é a coisa mais útil de entender sobre o ticketing da Salesforce. Como ela aponta para um User ou um Group, e um Group é a forma como a Salesforce modela uma fila, "atribuir a uma pessoa" e "atribuir à caixa de entrada de uma equipe" são literalmente a mesma operação. Não existe um campo de fila separado para manter sincronizado, o que é mais organizado do que a maioria dos helpdesks consegue.

As picklists de fábrica são menores do que as pessoas lembram. Segundo o próprio artigo de valores padrão de picklists da Salesforce, uma organização nova recebe valores de Status New, On Hold e Escalated; valores de Type Problem, Question, Feature Request e Duplicate; e cinco valores de Case Reason. Tudo além disso é trabalho de administrador.

"Closed" é mais interessante do que parece. Não é fixo em código, é dado. Um objeto separado somente leitura, CaseStatus, traz um indicador IsClosed por valor, e a referência de CaseStatus observa que "vários valores de status de case podem representar um Case fechado". Assim, é possível lançar Closed - Resolved e Closed - No Response como status distintos, e cada relatório continua calculando corretamente. Essa é uma vantagem real sobre helpdesks que só oferecem três compartimentos fixos de status.

Os agentes trabalham o case no Case Feed, que a documentação do Case Feed descreve como exibindo "eventos importantes do case em ordem cronológica" em vez de um muro de listas relacionadas. Algo a saber antes de migrar: segundo as notas sobre listas relacionadas, no Case Feed "os comentários privados foram substituídos por case notes, que são posts do Chatter", e não aparecem mais na lista relacionada Case Comments. Times que fazem relatórios sobre notas internas caem exatamente nessa armadilha.

Um feed longo também é onde os agentes perdem tempo, e é por isso que os resumos de case da Salesforce se tornaram um recurso de IA de destaque. O padrão geral está coberto no nosso guia de resumo de tickets.

Como os tickets entram na Salesforce, e os limites que ninguém cita para você

A Salesforce documenta exatamente cinco canais que criam cases: voz, e-mail, formulários web, aplicativos de mensageria e chat web ou in-app. Depois disso, tudo flui pelo Omni-Channel.

A divisão que importa para o orçamento é simples. E-mail e formulários web são gratuitos com a sua edição. Todo canal em tempo real é um add-on pago.

O número de 5.000 cases a cada 24 horas no Web-to-Case é o número publicado mais afiado de todo o sistema, e seu comportamento de estouro vale a pena ler duas vezes. Requisições excedentes caem em uma fila pendente compartilhada com o Web-to-Lead, o proprietário de case padrão recebe um e-mail, e essa fila em si tem teto de 50.000. Além disso, "requisições adicionais são rejeitadas e não entram na fila", e o administrador só é notificado das primeiras cinco. Depois disso, o silêncio é indistinguível de estar funcionando.

Mais duas coisas que pegam as pessoas no meio da construção. O Web-to-Case não suporta anexos de forma alguma, então qualquer fluxo em que clientes enviem capturas de tela ou logs não pode usar o formulário web. E o teto diário do Email-to-Case escala com sua quantidade de licenças, não com seu volume de tickets, e é compartilhado com todos os outros serviços de e-mail da organização. Um time de 10 assentos tem um total de 10.000 e-mails por dia, o que soa generoso até que um serviço Email-to-Apex silenciosamente consuma o mesmo orçamento. Varejistas que esbarram nesses tetos costumam recorrer ao roteamento de tickets com IA em vez de comprar mais licenças.

A antiga opção compatível com firewall também sumiu. A página de configurações do Email-to-Case da Salesforce agora diz que a versão instalável do agente "não é mais suportada, e o agente não está disponível para download". Manter o e-mail de suporte dentro da própria rede agora exige uma construção sob medida.

Por fim, a documentação alerta ativamente contra a configuração multi-endereço que a maioria dos times tenta primeiro. Enviar para vários endereços de roteamento "cria cases duplicados e só encadeia com o case que tem a atividade de e-mail mais recente". Um único endereço mais case teams é o padrão suportado.

Roteamento: uma regra ativa, e a caixa de seleção que decide tudo

Aqui está a restrição que molda toda implementação de ticketing da Salesforce que já vi. Sua organização pode ter exatamente uma regra de atribuição de cases ativa. As diretrizes de regras de atribuição dizem isso claramente: "Sua organização pode ter uma regra de atribuição de cases ativa por vez".

Essa única regra é generosa internamente. Ela comporta até 3.000 entradas de regra, das quais 300 podem ser baseadas em fórmulas, com 25 critérios de filtro por entrada e 200 ações por regra. A avaliação segue o princípio de primeiro-que-corresponde: a configuração de regras de atribuição diz que a Salesforce "atribui o item e para de avaliar" assim que uma entrada corresponde. Se nada corresponder, o case cai para o Default Case Owner nas Support Settings, motivo pelo qual uma entrada final que pega tudo é prática padrão.

Agora a parte que gera tickets de suporte sobre a própria ferramenta de suporte. As regras de atribuição disparam automaticamente para cases web e de e-mail. Para criação manual, se a regra roda ou não depende de uma caixa de seleção no layout da página. Crie um case pela aba Cases com essa caixa desmarcada e, segundo a documentação de atribuição de cases, "você é automaticamente registrado como proprietário do case". Pela API é pior: é preciso enviar um AssignmentRuleHeader na chamada de criação, ou nenhuma regra roda, o que é o motivo clássico pelo qual todo case criado via API acaba no usuário de integração.

Um administrador da Salesforce que se descreve como especialista em Omni-Channel resumiu a versão prática disso no Reddit:

"So this is a tricky example of Case Assignment rules and having your page layout or lightning page set to have the run assignment rules checked or not."

u/mayday6971, Reddit

A solução dele, para o que vale, foi um Flow disparado por registro que verifica se a configuração de roteamento está em branco antes de rotear. O caminho declarativo precisou de código para ser confiável, o que é um resumo bem justo do ticketing da Salesforce em geral. Nosso guia de automação de cases da Salesforce aprofunda esse padrão, e o panorama mais amplo de automação da Salesforce cobre o Flow em si.

Omni-Channel e o modelo de capacidade

Assim que um case está em uma fila, o Omni-Channel o empurra para um representante em vez de deixar os representantes escolherem à vontade. Os representantes têm um número de capacidade, a configuração de roteamento de cada fila diz quanto dela um case consome, e dois modelos decidem quem recebe o trabalho: Least Active escolhe quem está usando menos capacidade, Most Available escolhe quem tem mais capacidade livre. A documentação do modelo de capacidade limita um representante a "no máximo 100 itens de trabalho abertos por vez".

Três restrições para planejar:

• O roteamento acontece uma única vez. Segundo a documentação do Omni-Channel: "Se os valores de campo no item de trabalho mudarem depois que o item é roteado, a lógica de roteamento não é reaplicada." Repriorizar um case não o roteia novamente.
• Recusar não desfaz a atribuição. A documentação de opções de roteamento diz que o Omni-Channel "considera o trabalho como atribuído assim que roteia um item de trabalho para um representante, independentemente de o representante aceitar ou recusar", e um item recusado continua pertencendo a quem recusou até que seja roteado novamente.
• O Omni-Channel padrão está sendo descontinuado com o lançamento do Summer '26, e segundo o panorama do Omni-Channel, a Salesforce "atualiza automaticamente sua organização para o Enhanced Omni-Channel" durante o lançamento.

O roteamento baseado em habilidades é a ferramenta mais precisa e o lado mais afiado dela. Ative-o para uma fila e, segundo a documentação de configuração de roteamento, "a associação da fila deixa de valer para o roteamento". Se ninguém tiver a habilidade exigida, o case simplesmente não é roteado, fica em um Skills Backlog. Também é limitado por edição: roteamento baseado em habilidades e fluxos Omni estão disponíveis em Professional, Enterprise, Unlimited e Developer with Agentforce Service, deixando de fora, notavelmente, a edição Performance.

Quando funciona, as pessoas gostam. Um avaliador do G2 capturou o motivo:

"Omni-Channel routing is another feature I didn't realize I'd rely on so heavily. It's not perfect, but the fact that it distributes load across agents based on capacity rather than just round-robin has made a real difference in team morale—nobody feels like they're getting buried while someone else is coasting."

Mahesh D., Small-Business, G2

Os SLAs rodam sobre entitlements, não sobre o ticket

Esta é a seção que eu leria duas vezes antes de prometer um tempo de resposta a um cliente. As regras de escalonamento na Salesforce são um temporizador mais um e-mail. O verdadeiro motor de SLA é o Entitlement Management, uma cadeia de quatro objetos: um Entitlement diz a quem se deve suporte, um processo de entitlement é a linha do tempo, e os milestones são os relógios individuais que caem no case.

A configuração é robusta. Você tem 1.000 processos de entitlement por organização com 10 milestones cada, status de milestone Compliant, Open Violation e Closed Violation, e campos passíveis de relatório como TimeRemainingInMins e IsViolated, que tornam os dashboards de SLA diretos.

Depois vêm as limitações, que a Salesforce documenta abertamente e que, na minha opinião, são subestimadas na maioria das decisões de compra:

• Segundo os limites de entitlement: "Entitlements não se aplicam automaticamente a cases criados com Web-to-Case ou Email-to-Case." Seus dois canais de entrada gratuitos são exatamente os dois que pulam o motor de SLA, a menos que você escreva Apex.
• Segundo as notas de conclusão de milestone: "Milestones não são marcados como concluídos automaticamente." A conclusão automática exige um trigger Apex.
• Segundo as regras de ativação de processo: "Depois que um processo de entitlement é ativado, você não pode excluir seus milestones nem criar ações de milestone." O processo é versionado em vez disso.
• Segundo a limitação de visualização em lista: "O campo Case Milestone Status não está disponível em visualizações de lista no Lightning Experience."

O comportamento do temporizador tem sua própria lógica, que vale a pena internalizar. Os relógios de milestone pausam fora do horário comercial, então um milestone de primeira resposta de 60 minutos começando às 16h30 contra um horário comercial de 9h às 17h termina às 9h30 do dia seguinte. E pausar um milestone depois que ele já foi violado não muda nada: o comportamento do temporizador de milestone declara que os temporizadores "contam o tempo total decorrido depois que o milestone é violado, independentemente de o temporizador ter sido parado".

As regras de escalonamento compartilham a mesma restrição de regra única ativa que a atribuição, têm teto de cinco ações por entrada, e dependem de o horário comercial estar configurado antes. A opção mais traiçoeira de toda a funcionalidade é a configuração de início do escalonamento "quando o case é criado, e desativar após a primeira modificação do case", que cancela o escalonamento permanentemente no momento em que qualquer agente toca no case. O próprio exemplo da Salesforce: um case criado às 9h com um escalonamento de cinco horas, editado às 10h, nunca escalona.

Os times contornam isso de duas formas: um trigger Apex, ou uma camada que monitora a fila de forma independente. Nosso guia de gestão de SLA cobre a primeira, e gestão de escalonamento com IA cobre a segunda.

Aqui está o resumo honesto: o ticketing da Salesforce te dá um motor de SLA capaz de expressar quase qualquer coisa, e espera que você traga um administrador e um desenvolvedor para fazê-lo se comportar. Se essa troca vale a pena depende, na maior parte, de quantas pessoas você tem.

Quanto um sistema de tickets da Salesforce realmente custa em 2026

Os preços de tabela são públicos e claros. O que você paga não é.

Todos os cinco vêm diretamente da página de preços do Service Cloud. Agora os add-ons que aparecem na tabela de comparação de recursos dessa mesma página:

Leia essa primeira linha de novo. No Enterprise, a página de preços lista o Knowledge Management como "Somente leitura. Leitura/escrita disponível para compra." Um sistema de tickets em que seus agentes não conseguem escrever um artigo de conhecimento sem um adicional de $75 é uma definição incomum de "incluso", e isso molda silenciosamente como os times abordam a criação de conhecimento com IA.

Nosso detalhamento de preços de add-ons e o guia de preços de licença de plataforma têm as matrizes completas.

A camada de IA é medida separadamente

O Agentforce, a IA que responde cases, não faz parte do preço do assento, a menos que você esteja na edição de $550. Ele tem três pontos de entrada de consumo: Salesforce Foundations a $0, Flex Credits a $500 por 100.000 créditos, e Conversations a $2 por conversa. Você não pode misturar os dois últimos, já que "Flex Credits e Conversations não são suportados na mesma organização".

A Salesforce publica seus próprios exemplos de cálculo, e é o material de preços mais útil que a empresa disponibiliza:

A coluna do meio é a que vale a pena olhar, porque é um ticket de suporte. Uma conversa de gestão de case executa três ações (identificar o cliente, buscar seus cases, adicionar um comentário), o que dá 60 Flex Credits, ou seja, $0,30 em créditos contra $2,00 no modelo de conversa. O mesmo trabalho, quase 7x o preço, dependendo apenas de qual contrato você assinou. Nosso guia de Flex Credits desmonta a matemática dos créditos e preços do Agentforce cobre o lado da licença.

Uma coisa que a Salesforce não publica: o que conta como uma "conversa". A página de preços não define limite de turnos, duração de sessão ou exigência de resolução para a unidade de $2. Também não publica a taxa contratual de excedente, apenas que "não há penalidade de excedente", segundo os termos de preços do Agentforce, e que a cobrança ocorre a posteriori pela sua taxa contratada. E Flex Credits não usados "não são transferidos para os períodos de assinatura seguintes".

Insira seus próprios números

Se você quiser conferir o resultado com os próprios números da Salesforce, nosso guia da calculadora de preços e o post preços de IA da Salesforce trabalham a mesma matemática pela direção oposta.

Onde os times realmente ficam presos

O Salesforce Service Cloud tem 4,4 de 5 no G2 com base em 7.357 avaliações, sendo 63% delas com cinco estrelas. Não é um produto ruim. As reclamações se concentram em três lugares específicos.

A escada de licenciamento. Um avaliador de pequena empresa descreveu com precisão a experiência de renovação:

"Pricing is where it gets a little frustrating. It starts feeling reasonable until you realize the features you actually need day to day are sitting behind another add on or a higher tier. Storage, advanced reporting, extra automation capabilities — it all adds up quietly until your renewal conversation becomes a bit of a shock."

Mahesh D., Small-Business, G2

O imposto de administração. O ticketing da Salesforce se configura para praticamente qualquer coisa, e alguém precisa fazer essa configuração. Um tech lead que conduziu um rollout de mais de 600 assentos em cinco clouds resumiu isso no Hacker News:

"I entered the move skeptical of Salesforce's value; I left impressed with the flexibility of the platform but aghast at the costs and development effort required to do much of anything."

billbrown, Hacker News

O medidor de IA sem teto. Este é o mais novo, e o que eu questionaria com mais rigor em uma call de vendas. Uma thread de julho de 2026 documentou que o Agentforce e o Digital Wallet não têm parada automática:

"There are currently no native hard caps, circuit breakers, or real-time consumption alerts to automatically halt credit drain. The system prioritizes operational continuity for their servers, leaving the customer exposed to un-capped financial liability."

Agentforce & Digital Wallet lack hard caps for async loops, Reddit

Isso não é teórico. Outro administrador descreveu a fatura:

"We got $40k bill cuz our retriever jobs hit the fan when an intern ran web crawler once, failed and Salesforce support created two new for testing, so we have to also pay for the negligence of sf support staff."

u/Simple-Art-2338, Reddit

Existe um quarto tema que importa mais do que dinheiro: o que a IA faz quando erra. Um time relatou que um agente do Agentforce mostrou um artigo de conhecimento de uso interno a um cliente, com instruções de cancelamento inclusas, em vez de escalar. O Salesforce Premier Support acabou rastreando a causa até um template de prompt que usava o retriever padrão com acesso a todos os artigos de Knowledge.

Já escrevemos sobre por que esse padrão de falha é tão comum em alucinações de IA no suporte, e sobre como é uma boa prática de handoff de IA.

Nosso post sobre limitações de IA do Service Cloud cobre o resto, e governança de IA da Salesforce cobre os controles que você pode colocar ao redor disso.

Você deveria rodar o suporte na Salesforce?

Aqui vai minha leitura honesta depois de viver nessa documentação.

Fique com o ticketing da Salesforce se seus cases realmente precisam de contexto de CRM para serem respondidos, e você tem um administrador. Se a resposta para "onde está esse pedido, quanto ele pagou, qual é o contrato dele" mora na Salesforce, colocar o ticket em outro lugar significa construir uma sincronização que você vai manter para sempre. Nada na categoria supera um Case vivendo nativamente no registro Account. Nossa comparação Service Cloud vs Zendesk cobre essa troca em detalhes.

Procure outra opção se você é um time de suporte pequeno sem capacidade administrativa dedicada. Os recursos pelos quais você compraria a Salesforce, entitlements, roteamento por habilidades e Knowledge com leitura e escrita, estão todos trancados atrás de níveis de edição, Apex, ou ambos. Um time de cinco pessoas acaba pagando complexidade e preço de empresa grande sem conseguir nem o monitoramento de entitlement, nem o administrador para operá-lo.

Nossas listas de melhores sistemas de tickets para times pequenos e sistemas de tickets gratuitos são pontos de partida melhores.

O guia sistema de tickets com IA cobre o que automatizar primeiro depois que você já escolheu um. Se o seu problema é realmente volume, comece por redução de tickets em vez de uma migração.

O caso intermediário interessante, que é o que mais vejo, é o de times que ficam na Salesforce e simplesmente não querem comprar a IA por cima. Essa é uma opção real, e vale a pena detalhar.

Adicionando IA aos cases da Salesforce sem o medidor de créditos

Existem duas formas de automatizar uma fila de tickets da Salesforce, e elas têm formatos bem diferentes.

O caminho nativo é o Agentforce. Você compra uma edição que o suporta, ativa, constrói os topics e actions, e depois fica de olho no medidor. Ele está profundamente integrado à plataforma, o que é uma vantagem real quando sua automação precisa tocar seis objetos padrão. Nosso post sobre Agentforce customer service cobre o que ele faz bem. Para a versão de grande empresa, leia Service Cloud AI for enterprise, e para a mecânica por baixo, Salesforce AI in Service Cloud.

Se você prefere comparar o campo antes de se comprometer, fizemos as contas em melhor chatbot da Salesforce e olhamos o ângulo de assistência ao agente em helpdesk copilot.

O caminho em camada deixa sua configuração do Service Cloud exatamente como está e coloca um agente de IA por cima do objeto Case. Foi isso que construímos na eesel: funciona dentro dos cases e feeds do Service Cloud, respeita as regras de atribuição, regras de escalonamento e entitlements que você já configurou, e nunca pede que você reconstrua o roteamento.

A parte que eu realmente destacaria, porque é o que impediu aquele incidente de artigo de conhecimento interno de ser possível na nossa pilha, é a simulação. Você roda o agente contra seus cases passados antes de ele tocar em um ao vivo, vê onde ele é forte e onde é fraco, e só então ativa. A thread do Reddit sobre perder um cliente por causa de uma resposta ruim de IA é uma história sobre implantar sem essa etapa.

Experimente a eesel nos seus cases da Salesforce

Se você está no Service Cloud e o orçamento do Agentforce te fez fazer uma careta, esta é a versão que eu testaria primeiro. A eesel entra como agente de IA dentro do Salesforce Service Cloud, sem widget de chatbot e sem caixa de entrada separada. Ela redige e envia respostas, adiciona notas internas, roteia cases para filas, e atualiza os campos que você esperaria que fossem atualizados: priority, status, owner. Ela também gerencia os prazos de SLA. O material de origem são os seus próprios cases passados, mais artigos de Knowledge e templates de e-mail.

Três coisas que importam especificamente para um comprador da Salesforce. A configuração é sem código e a página afirma menos de 30 minutos, o que é uma ordem de magnitude diferente de uma construção de Agentforce. Você escolhe exatamente quais cases ela toca, por tipo de registro, fila, canal ou condição, então dá para começar com rascunhos no tier 1 e expandir quando confiar. E o preço é uma taxa fixa de 40 centavos por case atendido, sem taxa de plataforma e sem cobrança por assento, então o número na calculadora acima continua sendo o número na fatura.

Um time de software de logística no Service Cloud conseguiu integrar totalmente em cerca de uma hora, abrangendo 717 itens de conhecimento. Você tem $50 de uso gratuito para testar nos seus próprios cases primeiro, sem cartão, e tudo pausa automaticamente quando você atinge o limite de gasto que definir. Comece com eesel para Salesforce ou explore a lista completa de integrações se o seu stack for mais amplo do que um único helpdesk.