O agente existia. A conversa não se mantinha de pé.
O ponto de partida já incluía um agente de cobrança via WhatsApp. O problema era que a operação não conseguia sustentar a jornada com estabilidade em produção.
A cada etapa relevante, o fluxo dependia de consultas entre sistemas satélites para identificar o aluno, recuperar a dívida e buscar opções de negociação. Como o agente não conseguia esperar o retorno dessas chamadas sem comprometer o andamento da conversa, o resultado era uma experiência marcada por respostas genéricas, ruptura de contexto e pouca capacidade real de negociar.
Esse desenho produzia três efeitos diretos. O primeiro era operacional: falhas recorrentes na comunicação entre sistemas interrompiam a jornada. O segundo era de experiência: o aluno percebia um canal pouco fluido e abandonava a conversa. O terceiro era de eficiência: o custo técnico por interação permanecia alto, mesmo sem entrega proporcional de valor na negociação.
A hipótese do projeto foi clara. Para fazer a jornada funcionar, era preciso tirar a conversa da dependência de chamadas síncronas a cada passo e reorganizar a arquitetura com outra lógica.
Primeiro consolidar o contexto, depois conduzir a negociação
A resposta foi redesenhar o fluxo para que a informação chegasse antes da fricção.
A MATH reestruturou a jornada para um modelo híbrido. Em vez de acionar o agente em toda a conversa, o fluxo passou a começar em um bot responsável pela identificação do aluno, solicitação de dados quando necessário, consulta prévia da dívida e recuperação antecipada das opções de negociação disponíveis.
Essa mudança alterou o papel da arquitetura. Dados que antes eram consultados repetidamente ao longo da conversa passaram a ser consolidados logo no início e armazenados em background. Com isso, a jornada deixou de depender de múltiplas ações dentro do Agentforce para avançar.
A segunda frente foi a ampliação do escopo funcional. A negociação deixou de operar em uma faixa limitada de possibilidades e passou a contar com mais opções dentro da própria jornada, o que fortaleceu a utilidade do canal antes da necessidade de escalonamento.
A terceira frente foi a passagem para atendimento especializado. Quando a automação já não era suficiente, o atendimento humano passou a receber a conversa com mais contexto estruturado, o que reduz repetição, melhora continuidade e aumenta a chance de evolução da interação.
O ganho da arquitetura veio quando a jornada parou de consultar o sistema no meio da conversa e passou a entrar na conversa com a informação já preparada.
Menos ruptura, mais negociação, uma base melhor para evoluir
O primeiro resultado foi a redução do custo técnico da interação. Ao concentrar consultas no início da jornada e diminuir a dependência de chamadas repetidas entre plataformas, a operação passou a funcionar com menos esforço técnico por conversa.
O segundo resultado foi a diminuição das falhas operacionais. A jornada deixou de sofrer tanto com interrupções provocadas pelo retorno entre sistemas, o que aumentou a estabilidade do fluxo e reduziu a frequência de respostas genéricas ou desalinhadas com o contexto do aluno.
O terceiro resultado foi a ampliação das possibilidades de negociação. Com mais informação consolidada no início e uma estrutura funcional mais ampla, o canal passou a oferecer alternativas mais úteis para continuidade da conversa.
O quarto resultado apareceu na transição para atendimento humano. A passagem deixou de ocorrer com perda de contexto e passou a entregar ao especialista uma base mais organizada de informações para seguir a interação com mais qualidade.
O quinto resultado foi estrutural. O projeto criou uma camada de dados e acompanhamento que passa a permitir mensurações futuras mais consistentes da jornada, o que amplia a capacidade da operação de evoluir o canal com mais critério.
