Duas formas de dar a um agente o contexto da sua empresa

Um agente que escreve bem e usa ferramentas com competência ainda vai fazer um trabalho medíocre para você se não souber que a Acme cancelou no mês passado, que a Priya agora cuida das renovações ou que suas condições de pagamento padrão mudaram em março. O modelo não é a limitação. O que ele sabe sobre a sua empresa é.

Há duas formas de resolver isso, e elas levam a produtos diferentes. Vistas de fora, as duas são descritas do mesmo jeito: o agente conhece o seu negócio.

Buscar quando a pergunta chega

Jean-Denis Greze, CEO da Town, descreveu sua arquitetura a Casey Newton em agosto, com mais detalhes do que fundadores costumam dar. A Town tira amostras do seu e-mail e da sua agenda para montar uma wiki pequena, de cinco a 20 páginas, deliberadamente abstrata para guardar pouca informação privada. Depois, nas palavras dele:

“Você pode pensar na wiki como um mapa: quando você pede ao sistema para fazer algo, ele olha na wiki, que aponta para e-mails ou eventos da agenda, e traz esses itens para a sessão. Além disso, ele faz busca federada. Quando você faz uma pergunta, usamos os mecanismos de busca do Gmail, do Calendar, do Notion e de todos os outros serviços, só para aquela pergunta, para trazer os dados certos ao vivo. Não reindexamos todos os outros dados.”

Essa última frase revela a decisão de design. O mapa é pequeno e barato de manter. O trabalho pesado acontece a cada pergunta, sobre mecanismos de busca que outra empresa já construiu e já mantém atualizados.

É uma boa resposta. Você herda o índice do Gmail em vez de pagar para reconstruí-lo. Nada fica desatualizado, porque você lê a fonte no momento em que precisa. Você armazena muito menos, o que reduz o que há para proteger. E nunca erra sobre o que está num e-mail, porque acabou de ler o e-mail.

Até onde a busca ao vivo chega

A busca só encontra o que uma consulta consegue nomear.

Três problemas aparecem o tempo todo:

Coisas escritas com palavras que você nunca buscaria. Alguém encerra uma longa conversa sobre reembolsos com “vamos voltar ao jeito antigo”. Essa mensagem mudou sua política de devolução, e ela nunca contém a expressão “política de devolução”. Uma busca pela política pula essa mensagem e entrega a mensagem mais antiga que usa essas palavras, que agora está errada. Ler a conversa conforme ela chega capta a mudança, porque a conversa em volta diz qual era o jeito antigo.

Coisas que só existem entre mensagens. O endereço de um cliente mudou numa assinatura em junho, e o contrato que você está prestes a renovar ainda tem o antigo. Você só percebe isso se a camada de conhecimento guardou os dois.

Coisas que você não sabe que deveria perguntar. A busca ao vivo responde a pergunta que você pensou em fazer. Digamos que um cliente tenha 480 lojas e tenha mencionado uma vez, de passagem, que vai fechar 100 delas. Você abre a conta para preparar uma renovação, vê 480 contra um plano que vai até 500 e oferece o plano maior a uma empresa que está prestes a encolher. Ninguém digita “eles estão fechando lojas” numa caixa de busca, porque ninguém sabia que devia se perguntar isso.

Dá para ampliar o mapa para cobrir mais disso. Mas o mapa cresce, e no momento em que ele guarda conteúdo real em vez de ponteiros, você está mantendo uma camada de conhecimento, e as vantagens de privacidade e atualização começam a virar manutenção.

Manter a camada

Escolhemos construir a camada de conhecimento para resolver esses problemas. Liderei uma equipe de produto que construía produtos de gestão do conhecimento no Facebook, para uso interno e para clientes externos via Workplace, então já vi essa abordagem fracassar.

Nossa abordagem processa as mensagens conforme elas chegam. Compromissos, decisões, mudanças de contato e perguntas em aberto são registrados numa camada que persiste, e automações a atualizam conforme as coisas mudam. Você não está fazendo uma pergunta na hora da leitura. Está mantendo um modelo do negócio a partir do qual uma pergunta pode ser respondida.

Isso resolve os três problemas acima. A camada de conhecimento registra aquela conversa sobre reembolsos como uma mudança na política de devolução, então uma pergunta posterior a encontra sem precisar adivinhar quais palavras a conversa usou. Contradições aparecem porque ela guarda os dados mais recentes e o histórico. E o fechamento das lojas chega à conta antes que alguém pense em perguntar, então nada depende de a consulta certa ocorrer a você.

Os custos são grandes:

A manutenção nunca para. As bases de conhecimento em que trabalhei antes morreram por falta de manutenção, não porque a ideia estivesse errada. Alguém precisa mantê-las, e como normalmente essa não é a função principal de quem mantém, elas apodrecem. A aposta é que a extração e a atualização aconteçam automaticamente, ou a camada não vale nada.

Construir a camada inicial é crítico. Dá para importar o que já está estruturado, um CRM, mais obviamente, e dá para processar o histórico de mensagens. Até isso terminar, a camada está vazia e não vale nada, o que deixa uma má primeira impressão. A busca ao vivo não tem partida a frio nenhuma, porque lê sistemas que já estavam cheios.

A pergunta que acho que nenhum de nós resolveu

A partida a frio é onde eu mais contestaria o meu próprio lado, e é a parte sobre a qual eu mais gostaria de ser contestado.

A resposta óbvia é construir a camada inicial a partir do histórico de mensagens que já está ali, já que um ano de e-mail contém a maior parte do que uma empresa sabe sobre seus clientes. Estamos testando se isso funciona. Os primeiros resultados em recortes estreitos são animadores.

As duas são razoáveis, e qual funciona melhor ainda é uma questão em aberto. Hoje um comprador nem consegue diferenciá-las, porque as duas são vendidas como “o agente conhece o seu negócio”.