Definir se deve usar o Claude para roteamento de tickets

Aqui estão alguns indicadores-chave de que você deve usar um LLM como o Claude em vez de abordagens tradicionais de ML para sua tarefa de classificação:
Processos tradicionais de ML requerem conjuntos de dados rotulados massivos. O modelo pré-treinado do Claude pode classificar tickets efetivamente com apenas algumas dezenas de exemplos rotulados, reduzindo significativamente o tempo de preparação de dados e os custos.
Uma vez que uma abordagem tradicional de ML foi estabelecida, mudá-la é um empreendimento laborioso e intensivo em dados. Por outro lado, conforme seu produto ou necessidades do cliente evoluem, o Claude pode facilmente se adaptar a mudanças nas definições de classes ou novas classes sem re-rotulação extensiva de dados de treinamento.
Modelos tradicionais de ML frequentemente têm dificuldades com dados não estruturados e requerem engenharia de recursos extensiva. A compreensão avançada de linguagem do Claude permite classificação precisa baseada em conteúdo e contexto, em vez de depender de estruturas ontológicas rígidas.
Abordagens tradicionais de ML frequentemente dependem de modelos bag-of-words ou correspondência de padrões simples. O Claude se destaca em compreender e aplicar regras subjacentes quando as classes são definidas por condições em vez de exemplos.
Muitos modelos tradicionais de ML fornecem pouca percepção sobre seu processo de tomada de decisão. O Claude pode fornecer explicações legíveis por humanos para suas decisões de classificação, construindo confiança no sistema de automação e facilitando adaptação fácil se necessário.
Sistemas tradicionais de ML frequentemente têm dificuldades com outliers e entradas ambíguas, frequentemente classificando-os incorretamente ou padronizando para uma categoria catch-all. As capacidades de processamento de linguagem natural do Claude permitem que ele interprete melhor contexto e nuances em tickets de suporte, potencialmente reduzindo o número de tickets mal roteados ou não classificados que requerem intervenção manual.
Abordagens tradicionais de ML tipicamente requerem modelos separados ou processos de tradução extensivos para cada idioma suportado. As capacidades multilíngues do Claude permitem que ele classifique tickets em vários idiomas sem a necessidade de modelos separados ou processos de tradução extensivos, simplificando o suporte para bases de clientes globais.

Construir e implantar seu fluxo de trabalho de suporte LLM

Compreender sua abordagem de suporte atual

Antes de mergulhar na automação, é crucial compreender seu sistema de tickets existente. Comece investigando como sua equipe de suporte atualmente lida com o roteamento de tickets. Considere perguntas como:
  • Quais critérios são usados para determinar qual SLA/oferta de serviço é aplicada?
  • O roteamento de tickets é usado para determinar para qual nível de suporte ou especialista de produto um ticket vai?
  • Existem regras ou fluxos de trabalho automatizados já em vigor? Em quais casos eles falham?
  • Como casos extremos ou tickets ambíguos são tratados?
  • Como a equipe prioriza tickets?
Quanto mais você souber sobre como humanos lidam com certos casos, melhor você será capaz de trabalhar com o Claude para fazer a tarefa.

Definir categorias de intenção do usuário

Uma lista bem definida de categorias de intenção do usuário é crucial para classificação precisa de tickets de suporte com o Claude. A capacidade do Claude de rotear tickets efetivamente dentro do seu sistema é diretamente proporcional a quão bem definidas suas categorias do sistema são. Aqui estão algumas categorias de intenção do usuário e subcategorias de exemplo.
  • Problema de hardware
  • Bug de software
  • Problema de compatibilidade
  • Problema de desempenho
  • Redefinição de senha
  • Problemas de acesso à conta
  • Consultas de cobrança
  • Mudanças de assinatura
  • Consultas sobre recursos
  • Perguntas sobre compatibilidade do produto
  • Informações de preços
  • Consultas de disponibilidade
  • Perguntas de como fazer
  • Assistência de uso de recursos
  • Conselhos de melhores práticas
  • Orientação de solução de problemas
  • Relatórios de bugs
  • Solicitações de recursos
  • Feedback geral ou sugestões
  • Reclamações
  • Consultas de status de pedido
  • Informações de envio
  • Devoluções e trocas
  • Modificações de pedido
  • Assistência de instalação
  • Solicitações de upgrade
  • Agendamento de manutenção
  • Cancelamento de serviço
  • Consultas de privacidade de dados
  • Relatórios de atividade suspeita
  • Assistência de recursos de segurança
  • Falhas críticas do sistema
  • Problemas urgentes de segurança
  • Problemas sensíveis ao tempo
  • Solicitações de treinamento do produto
  • Consultas de documentação
  • Informações de webinar ou workshop
  • Assistência de integração
  • Perguntas de uso de API
  • Consultas de compatibilidade de terceiros
Além da intenção, o roteamento e priorização de tickets também podem ser influenciados por outros fatores como urgência, tipo de cliente, SLAs ou idioma. Certifique-se de considerar outros critérios de roteamento ao construir seu sistema de roteamento automatizado.

Estabelecer critérios de sucesso

Trabalhe com sua equipe de suporte para definir critérios de sucesso claros com benchmarks mensuráveis, limites e objetivos. Aqui estão alguns critérios padrão e benchmarks ao usar LLMs para roteamento de tickets de suporte:
Esta métrica avalia quão consistentemente o Claude classifica tickets similares ao longo do tempo. É crucial para manter a confiabilidade do roteamento. Meça isso testando periodicamente o modelo com um conjunto de entradas padronizadas e visando uma taxa de consistência de 95% ou superior.
Isso mede quão rapidamente o Claude pode se adaptar a novas categorias ou padrões de tickets em mudança. Teste isso introduzindo novos tipos de tickets e medindo o tempo que leva para o modelo alcançar precisão satisfatória (ex: >90%) nessas novas categorias. Vise adaptação dentro de 50-100 tickets de amostra.
Isso avalia a capacidade do Claude de rotear precisamente tickets em múltiplos idiomas. Meça a precisão de roteamento através de diferentes idiomas, visando não mais que uma queda de 5-10% na precisão para idiomas não primários.
Isso avalia o desempenho do Claude em tickets incomuns ou complexos. Crie um conjunto de teste de casos extremos e meça a precisão de roteamento, visando pelo menos 80% de precisão nessas entradas desafiadoras.
Isso mede a equidade do Claude no roteamento através de diferentes demografias de clientes. Audite regularmente decisões de roteamento para vieses potenciais, visando precisão de roteamento consistente (dentro de 2-3%) através de todos os grupos de clientes.
Em situações onde minimizar a contagem de tokens é crucial, este critério avalia quão bem o Claude performa com contexto mínimo. Meça a precisão de roteamento com quantidades variadas de contexto fornecido, visando 90%+ de precisão com apenas o título do ticket e uma breve descrição.
Isso avalia a qualidade e relevância das explicações do Claude para suas decisões de roteamento. Avaliadores humanos podem pontuar explicações em uma escala (ex: 1-5), com o objetivo de alcançar uma pontuação média de 4 ou superior.
Aqui estão alguns critérios de sucesso comuns que podem ser úteis independentemente de um LLM ser usado:
A precisão de roteamento mede com que frequência tickets são corretamente atribuídos à equipe ou indivíduo apropriado na primeira tentativa. Isso é tipicamente medido como uma porcentagem de tickets corretamente roteados do total de tickets. Benchmarks da indústria frequentemente visam 90-95% de precisão, embora isso possa variar baseado na complexidade da estrutura de suporte.
Esta métrica rastreia quão rapidamente tickets são atribuídos após serem submetidos. Tempos de atribuição mais rápidos geralmente levam a resoluções mais rápidas e satisfação melhorada do cliente. Sistemas de classe mundial frequentemente alcançam tempos médios de atribuição de menos de 5 minutos, com muitos visando roteamento quase instantâneo (que é possível com implementações LLM).
A taxa de reroteamento indica com que frequência tickets precisam ser reatribuídos após roteamento inicial. Uma taxa menor sugere roteamento inicial mais preciso. Vise uma taxa de reroteamento abaixo de 10%, com sistemas de alto desempenho alcançando taxas tão baixas quanto 5% ou menos.
Isso mede a porcentagem de tickets resolvidos durante a primeira interação com o cliente. Taxas mais altas indicam roteamento eficiente e equipes de suporte bem preparadas. Benchmarks da indústria tipicamente variam de 70-75%, com performers de topo alcançando taxas de 80% ou superior.
O tempo médio de manuseio mede quanto tempo leva para resolver um ticket do início ao fim. Roteamento eficiente pode reduzir significativamente esse tempo. Benchmarks variam amplamente por indústria e complexidade, mas muitas organizações visam manter o tempo médio de manuseio abaixo de 24 horas para problemas não críticos.
Frequentemente medidas através de pesquisas pós-interação, essas pontuações refletem a felicidade geral do cliente com o processo de suporte. Roteamento eficaz contribui para maior satisfação. Vise pontuações CSAT de 90% ou superior, com performers de topo frequentemente alcançando taxas de satisfação de 95%+.
Isso mede com que frequência tickets precisam ser escalados para níveis superiores de suporte. Taxas de escalação menores frequentemente indicam roteamento inicial mais preciso. Esforce-se por uma taxa de escalação abaixo de 20%, com sistemas de classe mundial alcançando taxas de 10% ou menos.
Esta métrica olha quantos tickets agentes podem lidar efetivamente após implementar a solução de roteamento. Roteamento melhorado deve aumentar a produtividade. Meça isso rastreando tickets resolvidos por agente por dia ou hora, visando uma melhoria de 10-20% após implementar um novo sistema de roteamento.
Isso mede a porcentagem de tickets potenciais resolvidos através de opções de autoatendimento antes de entrar no sistema de roteamento. Taxas mais altas indicam triagem pré-roteamento eficaz. Vise uma taxa de deflexão de 20-30%, com performers de topo alcançando taxas de 40% ou superior.
Esta métrica calcula o custo médio para resolver cada ticket de suporte. Roteamento eficiente deve ajudar a reduzir esse custo ao longo do tempo. Embora benchmarks variem amplamente, muitas organizações visam reduzir o custo por ticket em 10-15% após implementar um sistema de roteamento melhorado.

Escolher o modelo Claude certo

A escolha do modelo depende dos trade-offs entre custo, precisão e tempo de resposta. Muitos clientes descobriram que o claude-3-5-haiku-20241022 é um modelo ideal para roteamento de tickets, pois é o modelo mais rápido e mais econômico na família Claude 3 enquanto ainda entrega resultados excelentes. Se seu problema de classificação requer expertise profunda em assunto ou um grande volume de categorias de intenção com raciocínio complexo, você pode optar pelo modelo Sonnet maior.

Construir um prompt forte

Roteamento de tickets é um tipo de tarefa de classificação. O Claude analisa o conteúdo de um ticket de suporte e o classifica em categorias predefinidas baseadas no tipo de problema, urgência, expertise necessária ou outros fatores relevantes. Vamos escrever um prompt de classificação de tickets. Nosso prompt inicial deve conter o conteúdo da solicitação do usuário e retornar tanto o raciocínio quanto a intenção.
Experimente o gerador de prompts no Console Claude para ter o Claude escrevendo um primeiro rascunho para você.
Aqui está um exemplo de prompt de classificação de roteamento de tickets:
def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Você estará atuando como um sistema de classificação de tickets de suporte ao cliente. Sua tarefa é analisar solicitações de suporte ao cliente e produzir a classificação de intenção apropriada para cada solicitação, junto com seu raciocínio.

        Aqui está a solicitação de suporte ao cliente que você precisa classificar:

        <request>{ticket_contents}</request>

        Por favor, analise cuidadosamente a solicitação acima para determinar a intenção central e necessidades do cliente. Considere o que o cliente está pedindo ou tem preocupações sobre.

        Primeiro, escreva seu raciocínio e análise de como classificar esta solicitação dentro de tags <reasoning>.

        Então, produza o rótulo de classificação apropriado para a solicitação dentro de uma tag <intent>. As intenções válidas são:
        <intents>
        <intent>Suporte, Feedback, Reclamação</intent>
        <intent>Rastreamento de Pedido</intent>
        <intent>Reembolso/Troca</intent>
        </intents>

        Uma solicitação pode ter APENAS UMA intenção aplicável. Inclua apenas a intenção que é mais aplicável à solicitação.

        Como exemplo, considere a seguinte solicitação:
        <request>Olá! Eu tive internet de fibra de alta velocidade instalada no sábado e meu instalador, Kevin, foi absolutamente fantástico! Onde posso enviar minha avaliação positiva? Obrigado pela sua ajuda!</request>

        Aqui está um exemplo de como sua saída deve ser formatada (para a solicitação de exemplo acima):
        <reasoning>O usuário busca informações para deixar feedback positivo.</reasoning>
        <intent>Suporte, Feedback, Reclamação</intent>

        Aqui estão mais alguns exemplos:
        <examples>
        <example 2>
        Entrada do Exemplo 2:
        <request>Eu queria escrever e pessoalmente agradecer pela compaixão que vocês mostraram à minha família durante o funeral do meu pai neste último fim de semana. Sua equipe foi tão atenciosa e prestativa durante todo esse processo; realmente tirou um peso dos nossos ombros. Os folhetos de velório estavam lindos. Nunca esqueceremos a gentileza que vocês nos mostraram e somos muito gratos por quão suavemente os procedimentos correram. Obrigado, novamente, Amarantha Hill em nome da Família Hill.</request>

        Saída do Exemplo 2:
        <reasoning>Usuário deixa uma avaliação positiva de sua experiência.</reasoning>
        <intent>Suporte, Feedback, Reclamação</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Entrada do Exemplo 9:
        <request>Seu site continua enviando pop-ups de anúncios que bloqueiam a tela inteira. Levei vinte minutos apenas para finalmente encontrar o número de telefone para ligar e reclamar. Como posso possivelmente acessar as informações da minha conta com todos esses pop-ups? Vocês podem acessar minha conta para mim, já que seu site está quebrado? Preciso saber qual é o endereço em arquivo.</request>

        Saída do Exemplo 9:
        <reasoning>O usuário solicita ajuda para acessar as informações de sua conta web.</reasoning>
        <intent>Suporte, Feedback, Reclamação</intent>
        </example 9>

        Lembre-se de sempre incluir seu raciocínio de classificação antes de sua saída de intenção real. O raciocínio deve estar encerrado em tags <reasoning> e a intenção em tags <intent>. Retorne apenas o raciocínio e a intenção.
        """
Vamos quebrar os componentes-chave deste prompt:
  • Usamos f-strings do Python para criar o template do prompt, permitindo que o ticket_contents seja inserido nas tags <request>.
  • Damos ao Claude um papel claramente definido como um sistema de classificação que analisa cuidadosamente o conteúdo do ticket para determinar a intenção central e necessidades do cliente.
  • Instruímos o Claude sobre formatação de saída adequada, neste caso para fornecer seu raciocínio e análise dentro de tags <reasoning>, seguido pelo rótulo de classificação apropriado dentro de tags <intent>.
  • Especificamos as categorias de intenção válidas: “Suporte, Feedback, Reclamação”, “Rastreamento de Pedido” e “Reembolso/Troca”.
  • Incluímos alguns exemplos (também conhecido como prompting few-shot) para ilustrar como a saída deve ser formatada, o que melhora a precisão e consistência.
A razão pela qual queremos que o Claude divida sua resposta em várias seções de tags XML é para que possamos usar expressões regulares para extrair separadamente o raciocínio e intenção da saída. Isso nos permite criar próximos passos direcionados no fluxo de trabalho de roteamento de tickets, como usar apenas a intenção para decidir para qual pessoa rotear o ticket.

Implantar seu prompt

É difícil saber quão bem seu prompt funciona sem implantá-lo em um ambiente de produção de teste e executar avaliações. Vamos construir a estrutura de implantação. Comece definindo a assinatura do método para envolver nossa chamada ao Claude. Pegaremos o método que já começamos a escrever, que tem ticket_contents como entrada, e agora retornará uma tupla de reasoning e intent como saída. Se você tem uma automação existente usando ML tradicional, você vai querer seguir essa assinatura de método em vez disso.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Você estará atuando como um sistema de classificação de tickets de suporte ao cliente. 
        ...
        ... O raciocínio deve estar encerrado em tags <reasoning> e a intenção em tags <intent>. Retorne apenas o raciocínio e a intenção.
        """
    # Send the prompt to the API to classify the support request.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent
Este código:
  • Importa a biblioteca Anthropic e cria uma instância de cliente usando sua chave API.
  • Define uma função classify_support_request que recebe uma string ticket_contents.
  • Envia o ticket_contents para o Claude para classificação usando o classification_prompt
  • Retorna o reasoning e intent do modelo extraídos da resposta.
Como precisamos esperar que todo o texto de raciocínio e intenção seja gerado antes de analisar, definimos stream=False (o padrão).

Avaliar seu prompt

Prompting frequentemente requer testes e otimização para estar pronto para produção. Para determinar a prontidão de sua solução, avalie o desempenho baseado nos critérios de sucesso e limites que você estabeleceu anteriormente. Para executar sua avaliação, você precisará de casos de teste para executá-la. O resto deste guia assume que você já desenvolveu seus casos de teste.

Construir uma função de avaliação

Nossa avaliação de exemplo para este guia mede o desempenho do Claude ao longo de três métricas-chave:
  • Precisão
  • Custo por classificação
Você pode precisar avaliar o Claude em outros eixos dependendo de quais fatores são importantes para você. Para avaliar isso, primeiro temos que modificar o script que escrevemos e adicionar uma função para comparar a intenção prevista com a intenção real e calcular a porcentagem de previsões corretas. Também temos que adicionar funcionalidade de cálculo de custo e medição de tempo.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    classification_prompt = f"""Você estará atuando como um sistema de classificação de tickets de suporte ao cliente. 
        ...
        ...O raciocínio deve estar encerrado em tags <reasoning> e a intenção em tags <intent>. Retorne apenas o raciocínio e a intenção.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # Get the usage statistics for the API call for how many input and output tokens were used.
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

      # Check if the model's prediction is correct.
    correct = actual_intent.strip() == intent.strip()

    # Return the reasoning, intent, correct, and usage.
    return reasoning, intent, correct, usage
Vamos quebrar as edições que fizemos:
  • Adicionamos o actual_intent de nossos casos de teste no método classify_support_request e configuramos uma comparação para avaliar se a classificação de intenção do Claude corresponde à nossa classificação de intenção dourada.
  • Extraímos estatísticas de uso para a chamada da API para calcular o custo baseado em tokens de entrada e saída usados

Executar sua avaliação

Uma avaliação adequada requer limites e benchmarks claros para determinar o que é um bom resultado. O script acima nos dará os valores de tempo de execução para precisão, tempo de resposta e custo por classificação, mas ainda precisaríamos de limites claramente estabelecidos. Por exemplo:
  • Precisão: 95% (de 100 testes)
  • Custo por classificação: 50% de redução em média (através de 100 testes) do método de roteamento atual
Ter esses limites permite que você diga rapidamente e facilmente em escala, e com empirismo imparcial, qual método é melhor para você e quais mudanças podem precisar ser feitas para melhor se adequar aos seus requisitos.

Melhorar o desempenho

Em cenários complexos, pode ser útil considerar estratégias adicionais para melhorar o desempenho além das técnicas padrão de engenharia de prompt e estratégias de implementação de guardrails. Aqui estão alguns cenários comuns:

Usar uma hierarquia taxonômica para casos com 20+ categorias de intenção

Conforme o número de classes cresce, o número de exemplos necessários também se expande, potencialmente tornando o prompt pesado. Como alternativa, você pode considerar implementar um sistema de classificação hierárquica usando uma mistura de classificadores.
  1. Organize suas intenções em uma estrutura de árvore taxonômica.
  2. Crie uma série de classificadores em cada nível da árvore, permitindo uma abordagem de roteamento em cascata.
Por exemplo, você pode ter um classificador de nível superior que categoriza amplamente tickets em “Problemas Técnicos”, “Perguntas de Cobrança” e “Consultas Gerais”. Cada uma dessas categorias pode então ter seu próprio sub-classificador para refinar ainda mais a classificação.
  • Prós - maior nuance e precisão: Você pode criar prompts diferentes para cada caminho pai, permitindo classificação mais direcionada e específica ao contexto. Isso pode levar a precisão melhorada e manuseio mais nuançado de solicitações de clientes.
  • Contras - latência aumentada: Esteja ciente de que múltiplos classificadores podem levar a latência aumentada, e recomendamos implementar essa abordagem com nosso modelo mais rápido, Haiku.

Usar bancos de dados vetoriais e recuperação de busca por similaridade para lidar com tickets altamente variáveis

Apesar de fornecer exemplos ser a maneira mais eficaz de melhorar o desempenho, se solicitações de suporte são altamente variáveis, pode ser difícil incluir exemplos suficientes em um único prompt. Neste cenário, você poderia empregar um banco de dados vetorial para fazer buscas de similaridade de um conjunto de dados de exemplos e recuperar os exemplos mais relevantes para uma consulta dada. Esta abordagem, delineada em detalhes em nossa receita de classificação, foi mostrada para melhorar o desempenho de 71% de precisão para 93% de precisão.

Considerar especificamente casos extremos esperados

Aqui estão alguns cenários onde o Claude pode classificar incorretamente tickets (pode haver outros que são únicos à sua situação). Nestes cenários, considere fornecer instruções explícitas ou exemplos no prompt de como o Claude deve lidar com o caso extremo:
Clientes frequentemente expressam necessidades indiretamente. Por exemplo, “Estou esperando meu pacote há mais de duas semanas agora” pode ser uma solicitação indireta para status de pedido.
  • Solução: Forneça ao Claude alguns exemplos reais de clientes desses tipos de solicitações, junto com qual é a intenção subjacente. Você pode obter resultados ainda melhores se incluir uma justificativa de classificação para intenções de tickets particularmente nuançadas, para que o Claude possa generalizar melhor a lógica para outros tickets.
Quando clientes expressam insatisfação, o Claude pode priorizar abordar a emoção sobre resolver o problema subjacente.
  • Solução: Forneça ao Claude direções sobre quando priorizar sentimento do cliente ou não. Pode ser algo tão simples quanto “Ignore todas as emoções do cliente. Foque apenas em analisar a intenção da solicitação do cliente e que informações o cliente pode estar pedindo.”
Quando clientes apresentam múltiplos problemas em uma única interação, o Claude pode ter dificuldade em identificar a preocupação primária.
  • Solução: Esclareça a priorização de intenções para que o Claude possa melhor classificar as intenções extraídas e identificar a preocupação primária.

Integrar o Claude em seu fluxo de trabalho de suporte maior

Integração adequada requer que você tome algumas decisões sobre como seu script de roteamento de tickets baseado no Claude se encaixa na arquitetura do seu sistema maior de roteamento de tickets. Há duas maneiras de fazer isso:
  • Baseado em push: O sistema de tickets de suporte que você está usando (ex: Zendesk) aciona seu código enviando um evento webhook para seu serviço de roteamento, que então classifica a intenção e a roteia.
    • Esta abordagem é mais escalável na web, mas precisa que você exponha um endpoint público.
  • Baseado em pull: Seu código puxa pelos tickets mais recentes baseado em um cronograma dado e os roteia no momento do pull.
    • Esta abordagem é mais fácil de implementar mas pode fazer chamadas desnecessárias ao sistema de tickets de suporte quando a frequência de pull é muito alta ou pode ser excessivamente lenta quando a frequência de pull é muito baixa.
Para qualquer uma dessas abordagens, você precisará envolver seu script em um serviço. A escolha da abordagem depende de quais APIs seu sistema de tickets de suporte fornece.