Chatbot com estoque desatualizado: o que ele deveria responder quando o sistema cai

O problema não é o dado velho

Um chatbot com estoque desatualizado parece um problema de sincronização. Não é.

O problema aparece um segundo depois: o cliente confirmou uma compra que você não vai conseguir despachar. Agora você tem que escrever para voltar atrás, e isso custa mais do que não ter vendido.

A pergunta que importa não é de quanto em quanto tempo o catálogo atualiza. É o que ele responde quando não consegue saber.

As três formas de ficar desatualizado

Vale separar porque têm consertos diferentes.

Situação	O que causa	Como se conserta
O dado chegou tarde	A sincronização roda a cada X horas	Diminuir o intervalo ou sincronizar na hora que você mudar algo
O dado nunca chegou	A sincronização vem falhando e ninguém viu	Ser avisado quando o catálogo para de chegar
O dado não dá para consultar	Seu sistema não responde naquele momento	Que a resposta diga que não sabe

As duas primeiras se resolvem com configuração. A terceira é a que define se o atendimento automatizado te serve ou te mete em problema.

O que ele deveria responder quando o seu sistema não responde

Há exatamente dois comportamentos possíveis, e a diferença entre eles é a diferença entre uma ferramenta e uma dor de cabeça.

O comportamento ruim: assume que tem estoque e segue. O cliente confirma, o pedido é criado, e o problema aparece no depósito.

O comportamento certo: diz que não consegue confirmar a disponibilidade neste momento, e espera. Não inventa um número, não diz que sim por via das dúvidas, e não corta a conversa.

Na Alumbra é o segundo, e está escrito como limite do produto, não como intenção. Quando o sistema não pode ser alcançado na hora de confirmar um pedido, a resposta é que a disponibilidade é desconhecida. Nunca apresenta um palpite como se fosse estoque que você tem.

O que acontece quando tem menos do que pediram

Este é o caso intermediário e o que mais vezes é mal tratado.

O cliente pediu dez unidades e tem quatro. A saída cômoda é montar o pedido com quatro e avisar depois. Cômoda para o sistema e péssima para o cliente, que descobre quando já não pode fazer nada.

O correto é dizer o que tem, item por item, e esperar a resposta. O cliente decide se leva quatro, se espera, ou se troca por outra coisa. Cortar o pedido em silêncio é tomar uma decisão comercial que não te cabe.

Como evitar chegar nesse ponto

Quatro coisas, em ordem de quanto rendem.

1. Que o catálogo saia do seu sistema, não de uma cópia. Se preço e estoque você carrega duas vezes, eles vão divergir.
2. Escolha a frequência de atualização que o seu sistema aguenta. Mais seguido nem sempre é melhor: se o seu provedor tem limites, forçá-los quebra a sincronização inteira.
3. Sincronize na hora quando acabou de mudar algo. Uma mudança de tabela de preços não espera o próximo ciclo.
4. Ser avisado quando o catálogo para de chegar. Uma sincronização que falha em silêncio é pior do que não ter sincronização.

O ponto quatro é o que mais vezes falta. Um catálogo congelado continua respondendo com dados que parecem bons.

Os preços têm a mesma regra

Tudo o que está acima vale igual para os preços, e ali o erro sai mais caro.

Um preço inventado é uma promessa comercial. Se o atendimento automatizado improvisa um valor porque não conseguiu ler o real, ou você cumpre ou fica mal. A regra é a mesma: o preço sai do seu sistema ou não sai.

Conclusões

• O custo de um estoque desatualizado não é o dado, é ter que voltar atrás.
• O que define a ferramenta é o que ela responde quando não consegue consultar.
• Dizer "não consigo confirmar agora" é a resposta certa, não uma falha.
• Se tem menos do que foi pedido, se diz e se espera: cortar em silêncio é decidir pelo cliente.
• Uma sincronização que falha sem avisar é pior do que não ter sincronização.