Fluxo de trabalho de chatbot: como projetar um que resolve tickets

O que um fluxo de trabalho de chatbot realmente é

Tire tudo de um chatbot e sobram duas coisas: uma interface de conversa, e a lógica por baixo que decide o que acontece a seguir. Essa lógica é o fluxo de trabalho, e é o verdadeiro motor por trás de qualquer IA de atendimento ao cliente. A Tidio coloca isso claramente em seu guia de fluxogramas de conversa: chatbots são "pouco mais do que diagramas de árvore de decisão equipados com uma interface de usuário conversacional".

Isso é verdade sobre a forma de um fluxo de trabalho, mas a parte interessante é o que preenche cada nó. Um fluxo de trabalho não é só "se o usuário clicar em A, vá para B". Um bom fluxo de trabalho precisa entender uma mensagem que nunca viu, encontrar a resposta certa em uma base de conhecimento e saber a diferença entre uma pergunta que pode encerrar com segurança e uma que nunca deveria tocar. O mapa é a parte fácil. O julgamento dentro de cada etapa é o que faz um fluxo de trabalho de chatbot ter sucesso ou fracassar.

Aqui está tudo em um relance, e depois eu percorro cada etapa.

As seis etapas de um fluxo de trabalho de chatbot de suporte

Quase todo fluxo de trabalho de chatbot de suporte, baseado em regras ou com IA, passa pelas mesmas seis etapas. Nomeá-las torna óbvio onde o seu está fraco.

1. Gatilho. Algo dá início ao fluxo de trabalho: um cliente abre a bolha de chat, envia um e-mail, manda mensagem pelo WhatsApp, ou um novo ticket chega no helpdesk. O gatilho também carrega contexto que você vai querer depois, como o canal, o histórico de pedidos do cliente ou em qual página ele estava.
2. Entender a intenção. O bot descobre o que a pessoa realmente quer. Um fluxo baseado em regras faz isso com botões e palavras-chave; um fluxo de trabalho com IA lê o texto livre diretamente, então "minha encomenda ainda não chegou" e "cadê meu pedido" caem na mesma intenção sem que você tenha programado nenhuma das duas formulações.
3. Recuperar conhecimento. O bot busca a resposta em uma central de ajuda, tickets anteriores, documentos internos, ou um sistema ao vivo como um banco de dados de pedidos. Essa é a etapa que a maioria das demos pula e da qual a maioria dos fluxos de trabalho reais depende para viver ou morrer: um bot sem embasamento simplesmente inventa coisas.
4. Decidir e ramificar. Com a intenção e uma resposta em mãos, o fluxo de trabalho escolhe um caminho: responder diretamente, fazer uma pergunta de esclarecimento, executar uma ação, ou escalar. Esse é o cérebro do fluxo de trabalho, e é onde a verificação de confiança se encaixa.
5. Executar uma ação. Para perguntas simples, a "ação" é só responder. Para resoluções reais, é fazer algo: consultar um pedido, emitir um reembolso, marcar e encaminhar o ticket, atualizar um campo. Um fluxo de trabalho que só consegue falar, nunca agir, tem como teto o desvio e nunca chega à resolução.
6. Resolver ou escalar. A conversa termina de uma de duas formas: o bot a resolve, ou a transfere de forma limpa para um humano com todo o contexto anexado. Uma transferência que joga o cliente em uma fila nova para reexplicar tudo não é uma transferência, é um castigo.

Veja como as etapas de 2 a 6 se parecem dentro de um produto real, em vez de em um diagrama: o cliente pergunta, o agente responde a partir de conhecimento conectado, e no momento em que não consegue ajudar, oferece um humano.

Vi exatamente essa sequência acontecer recentemente no chat ao vivo do site de uma ferramenta de SEO: o bot respondeu a duas perguntas de como fazer, tiradas da documentação, e no instante em que o usuário digitou "posso falar com um humano?", ele transferiu sem hesitar. Esse desvio limpo seguido de transferência é como um fluxo de trabalho saudável se parece na prática, e é o padrão que vale a pena projetar.

Fluxos de trabalho baseados em regras vs. de agente de IA

A decisão mais importante que você vai tomar não é uma etapa, é que tipo de fluxo de trabalho você está construindo. Os dois parecem semelhantes num quadro branco e se comportam de forma totalmente diferente em produção.

Um fluxo de trabalho baseado em regras é uma árvore de decisão que você desenha à mão. É previsível e barato de raciocinar, e para um fluxo estreito e de alto volume ("verificar o status do meu pedido" atrás de três botões), funciona muito bem. A armadilha é tudo o que sai do script, e a matemática é brutal: a Tidio aponta que uma árvore "simples" de apenas sete perguntas de sim ou não já se ramifica em 128 cenários possíveis, motivo pelo qual a própria regra deles é "um bot de decisão, um tópico". Passe desse ponto e o cliente digita algo que você não previu, e o bot não tem para onde mandá-lo, o clássico beco sem saída do fluxograma. Você acaba mantendo uma árvore em constante crescimento, adicionando ramificações toda vez que surge uma nova formulação, e mesmo assim ela não consegue acompanhar o ritmo de como as pessoas realmente escrevem.

Um fluxo de trabalho de agente de IA inverte o esforço. Em vez de você enumerar cada caminho, o agente lê a intenção em texto livre, recupera a resposta do seu conhecimento e decide o que fazer, incluindo reconhecer quando está além da sua capacidade. Você deixa de desenhar ramificações; passa a definir barreiras de proteção.

Isso não é um argumento de que "regras estão mortas". Muitos bons fluxos de trabalho usam regras para as partes determinísticas (horário comercial, um número de pedido obrigatório) e deixam a compreensão de linguagem nebulosa para a IA. Mas se você está construindo um fluxo de trabalho de suporte esperando lidar com toda a variedade do que os clientes escrevem, uma árvore de decisão pura vai brigar com você para sempre. É o mesmo motivo pelo qual as equipes deixam de usar bots roteirizados e passam para um verdadeiro agente de IA à medida que o volume cresce.

Os dois pontos de decisão que realmente importam

Uma vez que uma IA faz a compreensão da linguagem, seu trabalho de projeto se resume a duas perguntas: quando o bot deve agir sozinho, e quando deve sair do caminho? Acerte isso e o resto do fluxo de trabalho praticamente se resolve sozinho.

Roteie pela confiança, não por palavras-chave

O controle mais pedido que ouço das equipes de suporte é o roteamento baseado em confiança: deixar o bot lidar só com aquilo de que tem certeza, e deixar o resto em paz. Uma líder de CX numa marca de suplementos DTC, que roda cerca de 7.000 tickets por mês no Gorgias, expressou esse medo melhor do que eu conseguiria. A IA nunca vai responder 100% das perguntas, ela me disse, e se ela simplesmente responder "desculpe, não sei", ela não pode voltar e checar 7.000 tickets para ver se realmente ajudou. O que ela queria era uma IA que "só lide com os tickets que tem confiança para lidar, e todos os outros, deixe em paz".

Esse é todo o argumento para pontuar a confiança na etapa de decidir e ramificar. Um fluxo de trabalho que responde a tudo é um fluxo de trabalho que vai errar com confiança. Um fluxo de trabalho que pontua sua própria certeza consegue resolver automaticamente os tickets fáceis, rascunhar uma resposta para um humano nos casos intermediários, e nunca tocar nos que não entende.

Essa também é sua melhor defesa contra alucinações. Em vez de torcer para que o modelo se comporte, você define um piso: abaixo de um limite, o bot rascunha em vez de enviar, ou escala em vez de adivinhar. O limite de confiança de intenção é um controle real em ferramentas maduras, não uma abstração.

Projete o escalonamento, não o cole depois

O outro ponto de decisão é a transferência para o humano, e ele merece tanto projeto quanto o caminho ideal. Ouço o objetivo declarado quase de forma idêntica em ligações de vendas: um gerente de suporte em um serviço de rastreamento de ônibus, lidando com 200 a 250 tickets do Zendesk por mês, queria um agente capaz de "lidar com 60% dos tickets recebidos do Zendesk e saber quando trazer uma pessoa de verdade para uma análise e resolução melhores". A metade "saber quando trazer uma pessoa de verdade" é a metade importante.

Um bom escalonamento carrega a conversa inteira, o contexto do cliente e o melhor palpite do bot sobre o problema direto para o humano ou fila corretos, para que ninguém precise reexplicar nada. É por isso que os construtores maduros tratam a transferência como uma etapa terminal com uma carga real anexada: no construtor do agente de IA do Zendesk, "transferir para o agente" é uma etapa final que cria silenciosamente um ticket carregando todo o histórico da conversa que o cliente nunca vê. A eesel faz o mesmo, deixando uma resposta rascunhada e o contexto como uma nota interna, ou transferindo para o helpdesk, dependendo de como você configurou.

Você também vai querer controle sobre o que o bot está autorizado a tocar. Equipes reais pedem isso o tempo todo ("há certos tickets que eu não quero que passem pela IA"), e um fluxo de trabalho que não consegue excluir um tipo de ticket, ou só agir quando explicitamente acionado, não está pronto para uma fila em produção. Escalonamento não é um fallback; é uma ramificação de primeira classe. Nossa análise completa sobre escalonamentos de agente de IA aprofunda a mecânica.

Erros comuns em fluxos de trabalho de chatbot

Clientes conseguem descrever um fluxo de trabalho quebrado melhor do que qualquer especificação. Um tópico do r/automation acertou em cheio os sintomas:

"the tells: loop you back to FAQ, ask you to rephrase (3 times), refuse to escalate. the fix isn't a smarter chatbot. it's a chatbot that knows when to hand off."

A maioria dos fluxos de trabalho quebrados falha das mesmas poucas maneiras. Fique de olho nestas:

• Becos sem saída. O clássico baseado em regras. Todo caminho deveria levar a algum lugar, mesmo que esse "lugar" seja um humano. Se uma ramificação pode prender um cliente sem jeito de avançar, é um bug.
• Automação excessiva. Deixar o bot responder a tudo para perseguir um número de desvio. É assim que você acaba com respostas erradas dadas com confiança, em escala. Limite o bot ao que ele tem certeza.
• Sem embasamento de conhecimento. Um fluxo de trabalho com uma ótima árvore de decisão e nada de onde recuperar informação vai improvisar, e respostas de suporte improvisadas são o caminho para acabar em uma captura de tela nas redes sociais. Embase toda resposta em documentos reais e tickets anteriores.
• Escalonamento como um pensamento tardio. Transferir para uma fila fria onde o cliente reexplica tudo. Carregue o contexto junto.
• Lançar às cegas. Soltar um fluxo de trabalho com clientes reais sem nunca tê-lo testado contra as mensagens que ele realmente vai receber. O que nos leva à última etapa, e a mais frequentemente pulada.

Teste o fluxo de trabalho antes de colocá-lo no ar

Aqui está a parte que quase ninguém faz, e o motivo pelo qual eu a incluo em todo lançamento: rode o fluxo de trabalho contra seus tickets históricos reais antes de ele falar com um cliente. Aprendi isso da maneira difícil, vendo um bot de tom confiante dar respostas erradas silenciosamente, então agora a primeira coisa que qualquer agente novo faz é uma simulação sobre tickets anteriores, não uma conversa ao vivo.

Uma simulação reproduz milhares dos seus tickets fechados pelo fluxo de trabalho e mostra exatamente o que ele teria dito, qual porcentagem teria resolvido, e em quais temas ele é fraco, tudo antes de ir ao ar. Você encontra as lacunas, adiciona os documentos que faltam, ajusta o limite de confiança e roda de novo. Isso transforma o "esperamos que funcione" em um número que você pode apontar, o que é basicamente a diferença entre um fluxo de trabalho em que você confia e um que te deixa nervoso toda manhã.

O retorno de um fluxo de trabalho testado aparece rápido. A Gridwise teve a eesel resolvendo 73% de suas solicitações de nível 1 no primeiro mês, com resultados visíveis durante um teste de 7 dias. A Smava roda um agente totalmente automatizado sobre mais de 100.000 tickets alemães por mês. Nenhum desses números vem de um prompt de sorte; eles vêm de um fluxo de trabalho que foi testado contra tickets reais antes de ser lançado.

Experimente a eesel para o seu fluxo de trabalho de chatbot

Se você leu até aqui, consegue ver o trabalho que um fluxo de trabalho de chatbot exige: mapear etapas, embasar respostas, ajustar a confiança, projetar o escalonamento, testar tudo. A eesel faz esse trabalho por você. Você conecta seu helpdesk e documentos, ela constrói o fluxo de trabalho a partir dos seus tickets e conhecimento anteriores desde o primeiro dia, você configura quando ela entra em ação e como transfere em linguagem simples, e simula tudo contra tickets históricos antes que um único cliente veja.

Ela se conecta ao Zendesk, Freshdesk, Gorgias, Slack, Shopify, Confluence e mais de 100 outras ferramentas, funciona em mais de 80 idiomas nativamente, e é cobrada por uso a $0,40 por ticket sem taxa por assento. Esse modelo tende a sair mais barato do que folha de pagamento assim que você faz as contas. Você pode ver um fluxo de trabalho rodando ao vivo dentro do seu helpdesk:

A forma mais rápida de ver se um fluxo de trabalho de chatbot se encaixa na sua fila é rodar um contra os seus próprios tickets. Isso é um teste gratuito, sem cartão, e a simulação te conta sua taxa de resolução real antes de você se comprometer com qualquer coisa.