Resumo
A segmentação de dados de suporte quebra em um único passo: o nível fica no cliente, mas o relatório lê o ticket. No Gorgias, Help Scout e Front, campos no nível do cliente funcionam em regras e views, mas os filtros de analytics leem dados no nível do ticket, como tags e campos de conversa. Um nível que você nunca copia para o ticket fica invisível para o relatório.
A solução é a mesma em todos os lugares: mantenha nível, plano e região em uma única fonte de verdade (CRM ou cobrança) e faça uma regra copiá-los para cada ticket novo como tag ou campo. Assim o mesmo campo alimenta relatórios, roteamento e metas de SLA. Fique atento aos limites de plano: SLAs por segmento exigem Help Scout Plus, filtros de conta no analytics do Front exigem Professional, e as políticas de SLA do Zendesk não estão na suíte de entrada.
Eu construo agentes de IA na eesel, e todos eles leem esses campos antes de responder. Uma equipe B2B de telemática no Zendesk pediu exatamente isso à eesel numa chamada de vendas: etiquetagem automática a partir de uma lista de tags definida mais campos de ticket preenchidos automaticamente. Essa camada de temas é a parte que o colega de IA da eesel resolve dentro do seu helpdesk, para que seus segmentos fiquem limpos sem agentes etiquetando à mão.
O que a segmentação de dados de suporte realmente abrange
Segmentar é dividir seus dados de suporte para que as médias parem de esconder problemas. Uma mediana de tempo de primeira resposta de 4 horas pode parecer boa enquanto suas 20 principais contas esperam o dobro, porque escrevem sobre assuntos mais difíceis.
Eu penso nisso como três camadas em cada ticket:
- Quem: nível do cliente, plano, região, receita, valor do tempo de vida do cliente. Isso pertence ao cliente e deve vir do seu CRM ou sistema de cobrança.
- O quê: tema, área do produto, intenção. Isso pertence ao ticket e muda a cada vez.
- Como: canal (e-mail, chat, telefone, redes sociais). Seu helpdesk captura isso sozinho.
A camada do "como" é grátis. A camada do "o quê" é onde vive a etiquetagem de tickets, e onde a maioria das equipes já tem dificuldade. A camada do "quem" é o foco principal deste guia, porque é a que falha em silêncio ao chegar aos seus relatórios.
A consistência da etiquetagem costuma ser a primeira baixa. Um líder de customer success descreveu isso no Reddit:
"Tried tagging tickets ourselves for a few months which worked fine the first month, then fell apart the second we onboarded a couple more csms and every one of them tagged things their own way."
Por que seus dados de nível nunca aparecem nos relatórios
Este é o padrão que encontrei ao percorrer a documentação de cinco helpdesks. Os dados do cliente ficam no cliente, contato, organização ou conta. Regras e views geralmente conseguem lê-los. Mas o módulo de analytics filtra por dados no nível do ticket.
Três exemplos concretos:
- Gorgias: os filtros do Analytics são data, agente, canal, integração, loja, tag, campos de ticket e qualidade. O filtro de campo de cliente existe, mas nas Views, não no Analytics.
- Help Scout: as Report Views filtram por caixa de entrada, tag, pasta e campo personalizado. Propriedades do cliente não estão nessa lista.
- Front: o filtro de campos personalizados do analytics cobre apenas campos personalizados de conversa, nos tipos Texto, Lista suspensa ou Sim/Não. Campos personalizados de contato não estão lá, embora contas estejam (no Professional).
Então o passo de "carimbar" é o trabalho inteiro: uma regra que dispara na criação do ticket e grava o nível do cliente no ticket como tag ou campo. O Front diz isso quase palavra por palavra na própria documentação de regras: guarde Revenue, Tier e Region na conta, faça uma regra adicionar uma tag VIP e depois use essas tags "to filter conversations in analytics, views, and other rules".
O carimbo tem um segundo benefício. Ele congela o segmento no momento em que o ticket foi criado. Se uma conta passar de Growth para Enterprise no mês que vem, os tickets do trimestre passado continuam aparecendo em Growth, o que geralmente é o que você quer.
Onde os dados de segmento ficam em cada helpdesk
Comparei os cinco helpdesks que mais vejo nas implantações da eesel. Os preços são os exibidos na página de preços de cada fornecedor em 2026-10-06.
| Helpdesk | Onde ficam nível/plano | Regras conseguem ler | Relatórios conseguem filtrar | SLA por segmento | Plano necessário |
|---|---|---|---|---|---|
| Zendesk | Campos de organização e de usuário | Sim, via tags e campos da organização | Via tags e campos do ticket | Políticas de SLA sobre campos padrão e personalizados | SLAs no Suite Growth ou Support Professional e acima |
| Gorgias | Campos de cliente (máx. 4 ativos), dados do Shopify | Sim, além de total gasto e contagem de pedidos do Shopify | Só depois de copiar para uma tag ou campo de ticket | Não é um recurso de ticket | Todos os planos Helpdesk, a partir de US$ 10/mês por 50 tickets |
| Help Scout | Propriedades de contato e de empresa (50 de cada) | Somente Plus ou Pro | Via tags ou campos personalizados; propriedades não listadas | Plus: 2 políticas, Pro: ilimitadas | Plus US$ 45 ou Pro US$ 75 por usuário/mês |
| Front | Contas e campos personalizados de contato | Sim, "Account/contact custom field contains" | Filtro de contas no Professional; campos de contato via tags | Não consta na documentação | Starter US$ 25 (10 regras), Professional US$ 65 (20 regras) |
| Zoho Desk | Módulos de contas e contatos | Sim, valores de campos personalizados | Relatórios personalizados unem Tickets com Contas | Planos de suporte e contratos por conta | Relatórios personalizados a partir do Standard (US$ 14/usuário/mês) |
Duas coisas se destacam. O Zoho Desk é o único em que um relatório consegue unir tickets a dados de conta de forma nativa, porque os relatórios personalizados escolhem um módulo principal e um relacionado. Em todos os outros, a regra de copiar para o ticket é obrigatória.
E o plano mais barato raramente faz o trabalho completo. O Help Scout restringe condições de propriedade do cliente em workflows ao Plus ou Pro. O Front limita o Starter a 10 regras, que acabam rápido quando nível, região e plano precisam de uma cada.
Escolha seu helpdesk: a receita de segmentação
Clique no seu helpdesk para ver o caminho exato dos dados do cliente até um relatório que você possa filtrar.
Zendesk: as organizações carregam o nível
O lar natural do nível no Zendesk é a organização. Você pode mapear um domínio de e-mail para uma organização, de modo que todos do domínio de um cliente entrem nela automaticamente. Um campo de organização do tipo lista suspensa transforma então o nível em uma tag que acompanha os tickets de cada membro.
Um administrador do Zendesk descreveu exatamente essa receita no Reddit, quando alguém perguntou como marcar como Tier 1 os tickets do domínio de um grande cliente:
"I would create an Organization drop-down field for your Tiers. This will apply a tag to that Org, and anytime an End User that's in the Org submits a ticket, they will have the Tier tag applied directly to the Ticket. Next you would setup the SLA's and use the "Tag contains the following" for each Tier."
A partir daí, uma política de SLA pode usar a tag de nível como condição, já que as condições aceitam campos padrão e personalizados. As políticas de SLA exigem Suite Growth ou superior (ou Support Professional). A página de preços atual do Zendesk lista o Suite Team a US$ 55 e o Suite Professional a US$ 115 por agente por mês na cobrança anual. Se você trabalha com metas por nível, reserve orçamento para o nível superior. Meu passo a passo de SLA do Zendesk cobre as metas, e as boas práticas de SLA explicam em que valores defini-las.
Uma equipe com cerca de 5.000 tickets por mês descreveu até onde isso vai:
"We utilize a tiering system for organizations by MRR. We utilize that tier to set the priority of tickets and have the incoming ticket queue sorted by priority and grouped by SLA. Our top tier orgs have a 1 hour FRT, tiers 2 & 3 have a 2 hour FRT and so on."
Para relatórios, a tag de nível é a aposta segura. Se você quer resultados de SLA por organização nos relatórios, a receita de tempo de primeira resposta é um bom modelo para adaptar.
Gorgias: os dados do Shopify fazem metade do trabalho
O Gorgias tem uma vantagem para equipes de e-commerce: os dados do Shopify já estão lá. O glossário de regras lista contagem de pedidos do cliente, total gasto, tags do cliente e data de criação como condições, descrevendo o total gasto como útil para sinalizar clientes de alto valor. Assim, uma regra pode ler "total spent greater than $1,000" e definir a prioridade ou atribuir uma equipe VIP, sem nenhuma sincronização com CRM. Esse mesmo contexto do Shopify é o que a integração da eesel com o Gorgias lê antes de responder.
Para o que o Shopify não sabe, há os campos de cliente: Sim/Não, Lista suspensa, Número ou Texto, em todos os planos Helpdesk. Três pegadinhas da documentação:
- Apenas quatro campos de cliente podem estar ativos ao mesmo tempo. Um quinto exige arquivar um.
- Você não pode alterar o tipo de um campo depois de criá-lo.
- Os metafields do Shopify (até 10 por categoria por loja) só aparecem para clientes e pedidos criados ou atualizados após a importação, então clientes mais antigos ficam em branco até comprarem de novo.
Depois, adicione o carimbo. Como o Analytics não filtra por campo de cliente, adicione "Add tags" ou "Set ticket field" à mesma regra. O guia de tags VIP explica a regra.
Quanto aos nomes, mantenha as tags de nível curtas e com prefixo (tier_gold, tier_silver) para que fiquem agrupadas na ordenação; as tags do Gorgias cobrem o resto. O Gorgias cobra por volume de tickets, não por usuário: o Starter custa US$ 10 por mês por 50 tickets e o Pro US$ 360 por 2.000, segundo a página de preços.
Help Scout: propriedades, mas com restrições
O Help Scout separa bem os dados. As propriedades do cliente guardam fatos no nível do contato, como nome do plano ou status de cobrança (até 50 propriedades de contato e 50 de empresa). Os campos personalizados de conversa guardam fatos por ticket, como o tipo de pergunta.
O problema é o plano. Condições de workflow em Customer Property e Company exigem Plus ou Pro, e as condições de SLA também. No Standard, você tem uma política de SLA sem nenhuma condição.
Duas pegadinhas a mais que vale conhecer antes de montar:
- Uma nova política de SLA só vale para conversas criadas depois da política, segundo a documentação de SLA. Seu backlog existente de tickets enterprise não será alcançado.
- As propriedades de empresa só são atualizadas pela API. Zapier e Beacon Identify ainda não as suportam.
O Plus custa US$ 45 e o Pro US$ 75 por usuário por mês conforme exibido; o detalhamento dos preços do Help Scout tem a tabela completa. Se você também quer tags de tema sem trabalho manual, a etiquetagem com IA para Help Scout preenche a camada do "o quê", e a integração da eesel com o Help Scout faz isso dentro da caixa de entrada.
Front: as contas são o lugar certo
As contas do Front representam as empresas com que você trabalha e estão em todos os planos. Campos personalizados de conta como Revenue, Account Manager e Account Tier podem ser sincronizados do Salesforce, HubSpot ou Dynamics 365. O conselho do próprio Front é guardar por padrão os dados de regras nas contas e usar campos de contato só quando o responsável certo depende de quem escreveu.
As regras podem então atribuir com base em um campo de conta. Um campo do tipo membro da equipe, como Account Manager, envia cada conversa direto ao seu responsável:
No Professional e acima, o Analytics tem um filtro de Accounts, então você vê métricas por conta sem carimbo:
Esse filtro, porém, escolhe contas individuais, não "todas as contas Gold". Para reportar por nível, você ainda precisa da regra que adiciona uma tag de nível. Dois limites da documentação: as métricas de conta não são retroativas, começam quando a conta é criada, e um domínio de e-mail só pode pertencer a uma conta. Se duas unidades de negócio compartilham um domínio, planeje isso cedo. A integração da eesel com o Front lê as mesmas tags de conta ao redigir respostas. O Front custa US$ 25 (Starter, 10 regras), US$ 65 (Professional, 20 regras) e US$ 105 (Enterprise) por usuário por mês, com cobrança anual; o post sobre preços do Front tem mais detalhes.
Zoho Desk: segmentos embutidos em contratos
O Zoho Desk é o mais centrado em contas dos cinco. Os tickets trazem uma busca de Account Name, as contas têm Industry e Annual Revenue de fábrica, e os relatórios personalizados podem usar Tickets como módulo principal com Contas como relacionado.
O recurso mais forte aqui são os planos de suporte. Você agrupa clientes em planos, vincula cada conta a um plano por meio de um contrato e anexa um SLA. O próprio exemplo da Zoho define uma meta de resposta de 3 horas para contas com 50 a 100 licenças e outra separada acima de 500. Os planos também podem ter limite de créditos (digamos, 5 tickets por mês), e os tickets além do crédito saem do SLA. Isso faz do segmento um direito, não apenas um rótulo.
A armadilha é a sincronização com o CRM. A integração com o Zoho CRM importa apenas registros criados ou modificados no último ano na primeira execução. Uma conta enterprise que não mudou há 18 meses não virá até que alguém mexa nela. Os relatórios personalizados começam no Standard (US$ 14 por usuário por mês, anual); a atribuição round-robin é do Professional (US$ 23) e a atribuição por habilidades do Enterprise (US$ 40).
Como configurar a segmentação de dados de suporte em 5 passos
Esta ordem funciona em qualquer uma das cinco ferramentas:
- Escolha de 3 a 5 segmentos nos quais você vai agir. Nível, plano, região e talvez o responsável pela conta. Se ninguém vai rotear, reportar ou precificar de forma diferente por um segmento, deixe-o de fora. O limite de quatro campos do Gorgias é uma boa disciplina mesmo que sua ferramenta permita 50.
- Escolha uma única fonte de verdade. Normalmente o CRM para nível e responsável, e a cobrança para o plano. Sincronize com o helpdesk (HubSpot, Salesforce e Zoho CRM têm caminhos nativos) em vez de pedir que os agentes preencham.
- Use campos de valor fixo, não texto livre. Uma lista suspensa não pode ser escrita errado. Help Scout e Front avisam que valores de campo e IDs diferenciam maiúsculas e minúsculas nas importações.
- Carimbe o ticket na criação. Uma regra por segmento que copia o valor para o ticket como tag ou campo. É isso que faz o relatório por segmento funcionar e o que as regras de roteamento leem.
- Preencha o histórico de propósito. As métricas de conta do Front, os SLAs do Help Scout e os metafields do Gorgias valem apenas daqui para frente. Decida se você precisa do histórico e, se precisar, exporte e etiquete os tickets antigos em lote antes de confiar na linha de tendência.
Depois agregue valor na ordem que sua equipe consegue absorver:
Os relatórios vêm primeiro porque mostram se o segmento vale a ação. Roteamento e metas de SLA vêm em seguida, quando você sabe que a fila enterprise está mais lenta. O terceiro passo, fazer sua IA responder de modo diferente por segmento, só funciona quando os dois primeiros estão limpos.
Onde a IA se encaixa e onde não deve entrar
A IA é boa em uma camada e a ferramenta errada para outra.
A camada do "o quê" é um bom encaixe. Ler um ticket e escolher um tema de uma lista fixa é classificação, e supera pedir que seis agentes concordem sobre as tags. O segredo é a lista fixa: a etiquetagem com IA é tão consistente quanto a lista de tags que você fornece. Meus guias sobre classificar tickets com IA e reduzir falsos positivos aprofundam o assunto, e a priorização de tickets se apoia nas mesmas tags.
A camada do "quem" não. Nível, plano e região são fatos sobre o cliente. Devem vir do seu CRM ou da cobrança, nunca de uma IA adivinhando pela assinatura do e-mail. Se o dado não está no helpdesk, conserte primeiro a sincronização.
Um administrador de helpdesk resumiu bem a ideia geral:
"Adding AI onto a badly designed system will not help at all - it will only make matters worse. Get the basics of support right first before trying to add AI - it will never be a magic fix."
Concordo, e isso combina com o que vejo ao construir agentes. Quando os campos de segmento estão limpos, o agente pode lê-los antes de responder: pular o artigo de autoatendimento para um cliente enterprise e passar para o gerente da conta, ou citar os limites corretos do plano a um cliente Starter. Quando estão bagunçados, o agente herda a bagunça. O panorama de ferramentas de triagem compara como diferentes ferramentas de IA lidam com essa camada.
Erros comuns de segmentação
- Segmentos demais. Uma lista de 40 níveis não é segmentação, é ruído. Os agentes esquecem ou aplicam errado as tags com mais frequência quando elas são específicas demais.
- Segmentar no relatório, não no ticket. Exportar tickets e cruzá-los com uma planilha do CRM todo mês funciona uma vez, depois ninguém faz. Carimbe na criação.
- Sobrescrever o histórico. Se sua regra atualiza o nível a cada atualização do ticket, o upgrade de um cliente reescreve o passado. Carimbe só na criação.
- Ninguém é dono da lista. Alguém precisa aprovar novos valores de tag, ou a lista volta a crescer. É o mesmo problema da deriva da base de conhecimento.
- Esquecer o limite de plano. Calcule o preço do plano de que você precisa para SLAs por segmento (Help Scout Plus, Zendesk Suite Growth e acima, Front Professional para analytics de conta) antes de desenhar o workflow.
Se você está segmentando porque clientes críticos continuam sendo soterrados, o cenário de organizações VIP e os guias de transbordo de suporte cobrem o lado do roteamento, e o suporte multimarca cobre a segmentação por marca em vez de por nível.
Experimente a eesel para manter os segmentos limpos
Se sua equipe usa um dos helpdesks acima, o colega de IA de helpdesk da eesel entra na fila que você já opera e cuida da camada de temas: lê cada ticket novo, escolhe a tag da sua lista fixa e preenche os campos de ticket dos quais seus relatórios dependem. Como ele lê o nível que suas regras carimbaram, você pode dizer em linguagem simples como tratar cada segmento, por exemplo "for enterprise accounts, draft a reply and tag the account manager instead of sending".
Antes de entrar no ar, a eesel executa uma simulação com seus tickets passados, para você conferir as tags dela com o que sua equipe realmente escolheu. A visão de relatórios mostra então o volume de tarefas e quais ações foram aprovadas ou rejeitadas.
O preço é um plano mensal fixo de créditos em que um ticket ou chat conta como 1 crédito, com usuários ilimitados; o plano gratuito inclui 100 créditos sem cartão. Experimente a eesel na sua própria fila e veja se as tags dela batem com as dos seus agentes.