O modelo coleta, o código decide

Num dos negócios do grupo, quem atende pelo WhatsApp é um assistente. Ele responde sobre o cardápio e os eventos, consulta o histórico e a fidelidade de quem está falando, sugere música e anota reservas. São dezoito ferramentas no total, e nenhuma delas cria pedido, cobra ou movimenta dinheiro. Essa foi a primeira regra, decidida antes de ele conversar com a primeira pessoa.

A segunda regra veio depois, de um erro. Um dia o assistente recusou uma reserva que estava certa, porque aplicou o horário de corte da casa no momento errado. A conversa foi educada, a resposta foi bem escrita, e a decisão estava errada.

O conserto não foi melhorar a instrução do modelo. Foi tirar a decisão dele. Hoje, na reserva, o modelo coleta os dados, conta o que entendeu e passa adiante. Quem decide se a reserva entra é o código, que aplica o horário da casa sempre do mesmo jeito. A instrução que ficou escrita para o modelo é curta: não recuse por conta própria.

Essa divisão vale bem além de reserva de mesa. Um modelo de linguagem é muito bom em entender o que a pessoa quis dizer, em juntar informação espalhada e em explicar a resposta. Ele não é o lugar certo para uma regra de negócio que precisa dar o mesmo resultado toda vez, como um horário, um limite de crédito, um desconto ou um prazo.

Quando uma empresa pergunta onde colocar um agente dentro do ERP ou do atendimento, a nossa resposta começa por três perguntas:

1. 01Quais ações esse agente pode tomar sozinho, e quais só pode sugerir?
2. 02Onde está escrita a regra que confere as condições antes da ação, e quem é dono dela?
3. 03Qual é o jeito simples de interromper o agente depois, se algo der errado?

Se as três respostas existem antes da primeira conversa com cliente, o agente entra em produção com freio. Se não existem, ele entra com a melhor das intenções e um dia recusa uma reserva que estava certa.