Como usar Jev no n8n para fazer a triagem de atendimentos

Desenhe o resultado antes de conectar os nodes

Nosso exemplo é uma empresa de serviços com três equipes: comercial, suporte e financeiro. O fluxo recebe uma mensagem, sugere uma equipe e abre uma tarefa na fila correspondente. Quando a mensagem não permite decidir, uma pessoa faz a triagem. Nenhuma resposta de Jev altera contrato, cobrança ou permissão de acesso.

Considere a mensagem fictícia: Meu acesso funciona, mas recebi uma cobrança que não reconheço. Preciso falar com alguém. O critério da empresa encaminha a questão de cobrança ao financeiro e preserva o pedido de atendimento humano. Esse é o resultado esperado para o exercício, não uma resposta observada em uma chamada ao modelo.

Escolha um responsável pela fila de revisão e um prazo de acompanhamento antes de ativar qualquer integração. Sem isso, o caminho de exceção apenas transfere o problema para uma lista que ninguém consulta.

Escolha entre o community node e HTTP Request

A TypeSafe mantém o pacote @typesafe-ai/n8n-nodes-typesafe-ai. Ele é um community node, não um componente do núcleo do n8n. A documentação do n8n diferencia os métodos de instalação conforme o ambiente e a verificação do pacote. Confira o que sua instância permite antes de escolher esse caminho.

Outra opção é usar HTTP Request para chamar diretamente a API da TypeSafe. Esse caminho evita instalar o pacote adicional, mas exige configurar a requisição e interpretar a resposta. Os dois caminhos continuam dependendo de uma conta e de uma chave válidas da TypeSafe.

O README do fornecedor informa testes do pacote com n8n 2.40. Essa informação não equivale a uma instalação testada pela Genial nem garante compatibilidade com qualquer versão. Este artigo descreve a configuração documental; não apresenta um workflow importado ou uma execução real.

Aprofunde este tema: Jev IA: como usar no Playground e na API com um exemplo →

Prepare cada mensagem como um evento identificável

Comece com entrada manual e mensagens fictícias. Cada item deve ter um identificador de evento, a mensagem e o contexto mínimo necessário. O identificador permite acompanhar o item até a tarefa final e detectar reenvios do mesmo evento. Ele não precisa ser um telefone ou outro dado pessoal.

Antes de enviar conteúdo ao modelo, verifique se há texto, se o formato é o esperado e se aquela origem está autorizada a alimentar o fluxo. Preserve no registro interno os campos necessários à correlação, mas selecione explicitamente o que será enviado em state.

Se houver várias unidades, o fluxo precisa conhecer a unidade a partir do contexto autorizado da integração. A classificação da mensagem não deve conceder ao modelo a escolha livre de acessar outra unidade. Uma indicação de destino continua limitada às permissões da aplicação.

Dê ao evento uma identidade estável e mantenha o controle de unidade e permissões fora da classificação.

Configure a avaliação no node da TypeSafe

No pacote da TypeSafe, Evaluate devolve respostas para o item; Route encaminha o item conforme uma pergunta. Para o primeiro piloto, Evaluate facilita observar o resultado antes de ligar os destinos. Configure a credencial de API, selecione o modelo e use um estado preparado explicitamente.

Crie uma pergunta Choice sobre a equipe responsável. Adicione Noul se precisar avaliar separadamente a solicitação de atendimento humano. Durante a avaliação, desligar Simplify preserva probabilidades e uso de tokens. Não confunda o identificador da pergunta com uma instrução: a pergunta e os critérios precisam descrever a tarefa.

Alternativa: configure a mesma chamada com HTTP Request

O corpo da chamada segue o contrato da API, independentemente da interface usada para enviá-lo. O kit de Jev disponível no bloco de material desta página inclui exemplos JSON para estudar e adaptar. Esses arquivos são exemplos de requisição, não uma promessa de importação automática de um workflow n8n.

Separe dúvida, erro e recusa de uma ação

Uma resposta de baixa confiança é uma avaliação concluída com incerteza. Uma credencial inválida ou um serviço indisponível é uma falha técnica. Já uma ação proibida pela política da empresa deve ser barrada mesmo quando a classificação parece clara. Misturar essas situações faz a operação perder informações sobre a causa do problema.

O README da TypeSafe alerta que Continue pode levar itens com erro a uma saída normal. Prefira uma saída de erro explícita e trate o campo de erro antes de qualquer ação. A equipe deve conseguir diferenciar item aguardando revisão de item aguardando nova tentativa técnica.

Limite as tentativas adicionais. Reenviar indefinidamente uma requisição aumenta a fila sem resolver uma chave inválida. Quando houver recuperação automática de uma falha transitória, preserve o identificador do evento e evite criar tarefas duplicadas. Consulte os limites atuais da conta; eles podem mudar.

Confirme que o encaminhamento aconteceu

Após escolher a fila, a integração ainda precisa registrar a tarefa no sistema de atendimento. Guarde o identificador devolvido pelo destino e registre se a criação foi confirmada. Se o destino falhar, o item continua pendente, mesmo que Jev tenha classificado corretamente a mensagem.

Uma mensagem ao cliente dizendo que a solicitação foi encaminhada deve depender dessa confirmação. Na etapa inicial do piloto, a pessoa revisora pode controlar essa comunicação. Depois, a automação pode assumir partes do fluxo com critérios e registros já conhecidos.

Em uma repetição do mesmo evento, consulte o resultado anterior antes de criar outra tarefa. Decida também como tratar uma atualização legítima do cliente: ela pode complementar a tarefa existente, sem ser confundida com um simples reenvio técnico. Esse detalhe evita histórico fragmentado e atendimento em duplicidade.

Teste o percurso completo antes de conectar o canal real

Prepare casos fictícios com assuntos claros, dois assuntos, texto incompleto, pedido de humano e conteúdo tentando forçar uma categoria. Acrescente situações que o modelo não resolve: credencial inválida, demora da API, destino indisponível e evento repetido. O comportamento esperado de cada caminho deve estar escrito antes do teste.

Compare a classificação com a revisão da equipe e acompanhe o que aconteceu depois. Observe quantos itens exigiram revisão, quantos foram corrigidos, quantas tarefas ficaram pendentes e se algum evento produziu duplicidade. Isso mostra onde melhorar o processo sem atribuir toda falha ao modelo.

Quando o fluxo for adotado, acompanhe mudanças de versão, critérios e volume. O artigo de avaliação deste cluster aprofunda como organizar essa revisão. Para aplicação em escolas, há um guia específico sobre unidade, curso, turno e agenda. Se a demanda envolver vários apps e equipes, o conteúdo sobre GeniOS apresenta a oferta de ecossistema da Genial; a eventual integração com Jev precisa ser definida e validada no projeto.