Agente de atendimento para rede de academias

O desafio

A rede operava 12 unidades com uma base ativa de 9 mil alunos. O canal principal de contato era o WhatsApp - cancelamentos, dúvidas sobre horários, reativações, reclamações de equipamentos, negociação de inadimplência. Tudo chegava na mesma fila, gerenciada por três atendentes com acesso compartilhado a um grupo do WhatsApp Business.

O problema não era de tamanho de equipe. Era de estrutura: sem triagem, qualquer mensagem - de “qual o horário do pilates?” a “quero cancelar minha matrícula” - consumia o mesmo tempo e atenção de um humano. O resultado era uma fila que se acumulava durante a madrugada e explodia às 7h, quando as academias abriam.

Dois problemas secundários ampliavam o impacto:

• Churn silencioso: alunos com intenção de cancelamento que não conseguiam resposta em menos de 24 horas simplesmente paravam de aparecer e contestavam a cobrança no cartão.
• Carga cognitiva: os atendentes respondiam as mesmas 15 perguntas dezenas de vezes por dia. A produtividade para tarefas que exigiam julgamento - negociar inadimplência, reter um aluno insatisfeito - era baixa porque a atenção estava fragmentada.

A restrição técnica importante: a rede operava com um sistema de gestão legado (SaaS nacional de academias) que não tinha API pública documentada. Qualquer integração precisaria ser construída sobre a interface web ou sobre exportações de dados agendadas.

A solução

Optamos por um agente baseado em LangGraph com três camadas de responsabilidade distintas.

Camada de triagem e intenção

Toda mensagem recebida pelo Twilio passa por um classificador de intenção antes de entrar no grafo de estados. Não usamos um modelo de classificação dedicado - o próprio Claude 3.5 Haiku (rápido, barato) classifica a intenção em uma das categorias definidas:

• Informações gerais (horários, endereços, modalidades)
• Financeiro (boleto, inadimplência, cancelamento, pausa)
• Operacional (equipamento com problema, acesso negado, sumiço de item)
• Comercial (interesse em plano, upgrade, indicação)
• Escalamento imediato (ameaça de Procon, assédio, emergência médica)

Essa classificação determina qual nó do grafo LangGraph é ativado, qual conjunto de ferramentas está disponível para o agente, e qual o nível de autonomia permitida.

Camada de execução com ferramentas

Para as categorias de maior volume (informações gerais e financeiro), o agente tem acesso a ferramentas específicas:

tools = [
    get_student_status,        # consulta base PostgreSQL sincronizada
    get_schedule_by_unit,      # horários atualizados via scraping agendado
    get_financial_position,    # saldo e parcelas em aberto
    send_payment_link,         # gera link de pagamento via gateway
    log_interaction,           # registra toda interação no CRM interno
]

A sincronização com o sistema legado acontece via n8n: um workflow roda a cada 30 minutos, faz scraping autenticado da interface web do sistema de gestão, extrai os dados relevantes (situação de matrícula, parcelas, histórico de frequência) e atualiza um banco PostgreSQL que o agente consulta em tempo real.

Essa abordagem é pragmática - não é ideal, mas funcionou sem exigir modificação no sistema legado e sem depender de uma API que não existia.

Camada de escalamento

Quando o agente identifica um cenário fora do seu escopo - intenção de cancelamento com NPS implicitamente baixo, menção a problema jurídico, segundo contato sobre o mesmo problema não resolvido - ele executa um escalamento estruturado:

1. Resume a conversa em um parágrafo objetivo
2. Cria um ticket no sistema interno com prioridade calculada
3. Notifica o atendente humano via canal interno (Slack)
4. Informa o aluno que um humano vai responder em até X minutos (SLA definido por turno)

O histórico completo da conversa, incluindo a intenção classificada e as ferramentas já consultadas, fica disponível para o atendente no momento do atendimento. Zero repetição de contexto.

Resultados

O agente entrou em produção na quarta semana do projeto, inicialmente em modo shadow (processando mensagens mas não respondendo) para validação de classificação de intenção. Na semana 5, foi ativado para resposta autônoma nas categorias de menor risco.

O throughput de 340% não significa que as academias cresceram: a mesma base de alunos gerava o mesmo volume de contato. O que mudou foi a capacidade de absorção. O que antes acumulava fila agora era resolvido em minutos.

Os três atendentes foram realocados para trabalho ativo de retenção: ligar para alunos com queda de frequência, negociar reativações, fazer upsell de planos. Uma função que existia no papel mas nunca era executada por falta de tempo.

A métrica que mais surpreendeu a gestão foi o tempo de resposta na madrugada. Antes: zero respostas entre 23h e 7h. Depois: tempo médio de resposta de 3 minutos, 24 horas por dia.