Antes de assinar contrato, faça um teste piloto de assistente virtual com duas a quatro semanas, um único fluxo de atendimento, clientes reais e três números acordados à partida: custo por conversa, taxa de transferência para uma pessoa e taxa de resolução sem intervenção humana. Se o fornecedor recusar um período de teste com estas condições, é um sinal para continuar a procurar.
Um piloto não é uma demonstração guiada pelo vendedor: é uma experiência controlada pelo seu negócio, com dados seus, em que o assistente responde a perguntas reais de quem já é cliente. E tem custos que deixaram de ser teóricos: desde 1 de outubro de 2026, a Meta passou a cobrar cada mensagem de serviço enviada por empresas no WhatsApp ao utilizador, e estas mensagens não eram cobradas desde 1 de novembro de 2024. O piloto tem de medir esse consumo desde o primeiro dia, com o custo por conversa no centro do relatório final.
Definir o âmbito do piloto
Escolha um único fluxo: marcações, horários e preços, ou estado de um pedido. Um âmbito estreito expõe os limites do assistente em poucas semanas; um âmbito largo esconde-os atrás de relatórios agradáveis. Como regra prática, 30 a 50 conversas reais chegam para decidir sobre um fluxo único — abaixo disso, os números não separam sorte de desempenho.
Teste com clientes representativos, não só com colegas da equipa, e inclua quem tem menos à-vontade com a tecnologia: as regras para clientes com baixa literacia digital valem também dentro do piloto, porque são estes clientes os primeiros a encontrar becos sem saída. Num cenário fictício de uma florista, o piloto cobriria apenas três pedidos: encomendar, alterar a hora de levantamento e cancelar — nada mais.
Escolher métricas antes de começar
Escreva as métricas e os limiares antes da primeira conversa; definidos no fim, tendem a aprovar o que foi medido. A tabela é um exemplo ilustrativo de scorecard para uma pequena empresa — ajuste os limiares ao seu atendimento e registe a linha de base da semana anterior, atendida só por pessoas.
| Métrica | Como medir | Limiar de aprovação (exemplo) |
|---|---|---|
| Taxa de resolução sem pessoa | Conversas fechadas pelo assistente ÷ total | Igual ou acima de 60% |
| Taxa de transferência para pessoa | Conversas passadas a alguém ÷ total | Igual ou abaixo de 30% |
| Tempo de primeira resposta | Mediana dos tempos de primeira resposta | Abaixo de 1 minuto |
| Custo por conversa | (Mensalidade + consumo) ÷ conversas | Abaixo do custo humano equivalente |
| Erros críticos | Respostas erradas sobre preço, horário ou dados | Zero |
Verifique também o que o scorecard não apanha sozinho: o assistente deve confirmar as escolhas do cliente antes de agir, repetindo data e hora antes de marcar, e nunca inventar horários, preços ou disponibilidade que não estejam no sistema.
Desenhar as duas semanas de teste
- Semana 1, testes internos: duas pessoas fazem 20 a 30 perguntas reais colhidas do histórico de atendimento e registam todas as falhas, com data e captura de ecrã.
- Prepare os dados: carregue horários, serviços, preços e exceções atualizados; um piloto com dados desatualizados falha por culpa própria, não do fornecedor.
- Semana 2, clientes reais: avise os clientes de que estão num teste, dê saída fácil para uma pessoa e acompanhe as conversas todos os dias.
- Registe tudo: cada transferência, erro, desistência e correção do fornecedor num ficheiro simples, para poder comparar no fim.
- Compare com a linha de base: meça o mesmo fluxo atendido só por pessoas e ponha os dois lados na mesma tabela.
- Decida com o scorecard: aplique os limiares definidos no início, sem reabrir a negociação depois de ver os resultados.
Durante o teste processa dados de clientes: nomes, números de telefone e, por vezes, detalhes do pedido. O Regulamento (UE) 2016/679 aplica-se às conversas do piloto desde a primeira mensagem de teste, porque envolvem o tratamento de dados pessoais de pessoas identificáveis. Antes de arrancar, confirme com o fornecedor onde os dados ficam guardados, durante quanto tempo e quem pode aceder-lhes.
Custos reais do piloto
Exija por escrito três custos separados: implementação, mensalidade da plataforma e consumo por mensagem. No WhatsApp, há duas regras que mudam a conta: as respostas automáticas só podem ser enviadas dentro de uma janela de atendimento de 24 horas, que se abre com a primeira mensagem do cliente e se reinicia sempre que o cliente volta a escrever; fora dessa janela, só são possíveis modelos de mensagem pré-aprovados, também cobrados.
Se o fornecedor usar o Meta Business Agent para gerar as respostas, a cobrança é feita por tokens: a Meta cobra estas mensagens com uma taxa global de $2.00 USD por 1 milhão de tokens, e uma mensagem típica consome 20,000–25,000 tokens, o que equivale a aproximadamente 4–5 cents (USD) por mensagem. Converta para euros com a taxa do dia da fatura e some a mensalidade antes de comparar com o custo do atendimento humano. O restante orçamento do piloto — horas de implementação, mensalidade do mês de teste e consumo estimado — deve aparecer em linhas separadas (mais um exemplo ilustrativo, não uma medição).
Critérios de decisão no fim
- Aprovar: o scorecard cumpre os limiares, os erros críticos são zero e o fornecedor explica cada falha com correção datada.
- Estender: os números ficam perto dos limiares e as falhas concentram-se num único tema — corrija e repita mais duas semanas.
- Rejeitar: erros críticos sem correção, recusa em partilhar registos de conversa ou custos que só ficam claros na fatura.
Termine sempre com uma decisão escrita e datada. Um piloto sem decisão registada transforma-se em meses de mensalidade paga sem benefício medido — e é esse o resultado que um teste bem feito existe para evitar.