Classificação e roteamento de tickets Zendesk AI: Intelligent Triage nativo vs classificador próprio

Pela ajuda da Zendesk conferida neste guia, o Intelligent Triage classifica tickets novos por tópico, sentimento, idioma e entidades (ex.: produtos), com base no assunto e no primeiro comentário público. Tópico e sentimento podem atualizar com respostas se a detecção dinâmica estiver ligada; o idioma não atualiza a cada resposta. Cada classificação traz confiança High/Medium/Low para agentes, não uma probabilidade 0–1 com limiar como numa API de modelo. Agentes podem corrigir campos; isso não retreina o modelo. Este artigo resume páginas públicas; planos, add-ons e rótulos (Topic vs Intent) podem mudar: verifique o Admin Center antes de comprar ou reconstruir triggers.

Fique no Intelligent Triage quando suas regras mapeiam limpo para tópicos, faixas de sentimento e idiomas, e os agentes já trabalham com views e triggers. Encaixa: sentimento negativo de alta confiança para view prioritária; roteamento por idioma; macro se o tópico for um how-to conhecido. Você evita outra chave, outro domínio de falha e outro lugar para o texto. Herda o empacotamento Zendesk: automação de fluxos exige Copilot conforme a documentação. Se os tópicos cobrirem ~80–90% do volume após um mês de correções, ML próprio costuma ser prematuro. Meça correções e rotas erradas no Zendesk antes de somar um modelo externo.

Adicione um classificador externo quando o Intelligent Triage não expressar seu contrato de filas. Exemplos: separar “risco de chargeback” da cobrança comum; pontuar urgência numa rubrica de três níveis independente do sentimento; exigir review explícito com evidência mista. High/Medium/Low pode ser grosso demais para portões 0,75 vs 0,90. Você também pode precisar de scoring sombra num conjunto rotulado que o Explore não guarda, ou de um log de decisão neutro para auditoria. Deixe criação de tickets, macros e UI no Zendesk; mova só o julgamento. Se só faltam tópicos, crie-os primeiro no Admin Center: costuma ser mais barato.

Mantenha o Zendesk como sistema de registro. Na criação do ticket (ou trigger filtrado), o middleware lê assunto e primeiro comentário, remove segredos e faz POST de Choice—e opcionalmente Score—para https://jevmodel.app/api/v1/systemone com chave JevModel no servidor. Mapeie rótulos para tags, grupos ou campos; nunca deixe o modelo definir permissões ou reembolsar. Se HTTP falhar, code !== 0, rótulos desconhecidos ou probabilidades próximas, atribua fila humana. O JevModel aceita só texto/JSON, teto 8.000 caracteres, 1–8 perguntas, Choice 2–12, 10 runs grátis/dia UTC após e-mail. Sem chave de idempotência: dedupe por ticket id. Veja support-triage para fila+urgência; aqui o foco é quando sair do caminho nativo.

{
  "state": {"ticket_id": "123", "subject": "Charged twice", "comment": "Please fix my invoice."},
  "questions": {
    "queue": {
      "type": "choice",
      "instructions": "Choose the support queue.",
      "criteria": {
        "billing": "Charges, refunds, invoices.",
        "technical": "Product bugs or outages.",
        "review": "Mixed or unclear; needs a person."
      }
    }
  }
}

Leia a tabela como restrições, não como acurácia universal. A qualidade dos tópicos no Zendesk é por conta e não é republicada aqui. A acurácia do JevModel nos seus tickets não está medida até rotular uma amostra.

Execute o classificador próprio em paralelo por 2–4 semanas sem mudar o roteamento ao vivo. Registre tópico Zendesk, rótulo custom, probabilidades, fila final do agente e tempo de resolução. Aceite o corte só se rotas automáticas erradas couberem no orçamento e a revisão for operável. Donos: suporte (rótulos), engenharia (timeouts/retries), segurança (quais campos podem sair). Se não vencer o Intelligent Triage no seu scorecard, fique no nativo—ou combine: Triage para idioma, Choice próprio para fila.