O fluxo de contingência precisa das mesmas garantias do principal
Seguir coletando dados enquanto ninguém atende é uma decisão defensável de produto, e ela se volta contra o visitante se a coleta repetir o que ele já forneceu.
Quando não há ninguém disponível, continuar a conversa coletando o que o atendente vai precisar depois é uma decisão defensável: transforma uma espera vazia em preparação e aumenta a chance de a conversa ser retomada com utilidade.
A decisão só funciona sob uma condição: a coleta precisa saber o que já tem. É exatamente aí que a implementação padrão falha. A documentação de parâmetros do Dialogflow CX declara que "If the end-user provides multiple parameter values in a single conversation turn during form filling, usually only one form parameter is set" — o visitante que envia tudo de uma vez tem a maior parte do que enviou ignorada.
O resultado é pior do que não ter continuado. Um aviso honesto de indisponibilidade, seguido de silêncio, é frustrante e coerente. Um aviso honesto seguido de perguntas sobre o que já foi respondido comunica outra coisa: que ninguém está lendo. A tentativa de melhorar a espera acaba assinando a impressão que ela pretendia evitar.
O teste que separa os dois casos é barato e específico: percorrer o fluxo de contingência enviando todos os dados na primeira mensagem, e verificar se a próxima pergunta leva em conta o que chegou. Um fluxo de contingência que nunca foi percorrido assim está no ar sem ter sido testado no caso que mais importa — o do visitante que colabora.