Agentes de voz para trocas, cancelamentos e devoluções

Descubra se é uma dúvida ou uma solicitação

Comece pelo objetivo: conhecer uma regra, iniciar uma solicitação ou acompanhar uma já existente. Pergunte uma coisa por vez. Não solicite o número do pedido quando a pessoa precisa apenas de informação geral.

Para regras comerciais, use documentos vigentes aprovados pela empresa. O guia não define direitos legais, prazos de devolução ou condições de reembolso; esses conteúdos precisam ser fornecidos e revisados pelo responsável.

Consulte somente o pedido autorizado

Para consultar um pedido individual, o agente precisa de uma conexão configurada com o sistema responsável. Esse sistema deve conferir se a pessoa tem direito de acesso antes de fornecer dados. Informar um número de pedido na conversa não comprova essa autorização. Combine esse procedimento com o responsável pela integração.

Receba apenas os dados necessários ao processo. Se a verificação falhar, explique o canal da equipe sem revelar informações do pedido. Teste com dados sintéticos antes de conectar registros reais.

Registre sem anunciar aprovação

Exemplo fictício: a pessoa confirma que deseja solicitar uma troca. A ferramenta retorna ‘solicitação recebida’, referência DEMO-42 e ‘aguardando revisão’. Resposta adequada: ‘Sua solicitação foi registrada com a referência DEMO-42 e aguarda revisão’. Não diga que a troca foi aprovada ou que um estorno começou.

Se a ferramenta retornar erro ou resultado incerto, não invente protocolo nem repita a criação sem verificar duplicidade no destino. A estratégia de deduplicação e consulta pertence à integração externa.

# Solicitações
Diferencie dúvida, nova solicitação e acompanhamento.
Explique somente as regras das fontes aprovadas.
Antes de registrar, confirme o tipo de solicitação e os dados necessários.
Após usar a ferramenta, descreva somente o resultado retornado.
Solicitação recebida não significa aprovação, envio ou reembolso.
Em erro ou resultado incerto, explique o limite e o canal da equipe.

Valide resultados e exceções

A tabela abaixo ajuda a testar como o agente explica cada etapa do pedido. Ela é um exemplo de avaliação, não uma integração nativa do Tigy. Use os nomes que aparecem no seu sistema e confira se o cliente consegue entender o que foi recebido, aprovado ou concluído.

Faça um piloto com uma única tarefa

Comece por informar regras ou registrar um tipo de solicitação. Teste mudança de intenção, pedido inexistente, acesso negado, repetição e correção do número. Compare a conversa com o registro criado, não apenas com o status final da chamada.

Amplie depois de confirmar que o agente pede autorização antes de registrar, preserva os dados corrigidos e distingue recebimento de decisão. Meça solicitações duplicadas e encaminhamentos sem transformar exemplos em resultados comprovados.

Pedido registrado significa troca aprovada ou reembolso iniciado?

Não. “Recebido”, “aguardando revisão”, “aprovado” e “concluído” representam etapas diferentes. Confira o significado usado pelo sistema da empresa. Um pedido de troca não é uma troca aprovada, e uma solicitação de cancelamento não comprova que o valor foi devolvido.

Em um exemplo fictício, a API devolve DEMO-42 e “aguardando revisão”. O agente pode confirmar registro e referência, preservando a pendência. Se não houver retorno ou houver erro, não invente protocolo; o receptor precisa de uma estratégia para consultar o resultado e evitar duplicidade antes de repetir a criação.

Descubra qual resultado a pessoa está pedindo

Trocar um produto, cancelar um pedido e devolver uma compra não são a mesma solicitação. Uma pessoa pode usar “cancelar” para dizer que deseja outro tamanho, ou falar “devolver” quando pretende interromper uma assinatura. Antes de explicar condições, identifique a compra e o resultado desejado. Uma pergunta curta, como “Você quer receber outro item ou encerrar essa compra?”, evita conduzir a conversa por uma política que não corresponde à intenção real.

Em uma loja fictícia, um cliente recebeu uma camiseta pequena e pede cancelamento. Se seu objetivo é receber o tamanho correto, a política de troca pode ser a fonte adequada. Outro cliente fez um pedido há poucos minutos e deseja impedir o envio; nesse caso, o estado do pedido importa. Um terceiro já recebeu o produto e quer saber como devolvê-lo. A linguagem inicial parece semelhante, mas a informação necessária e a ação possível mudam em cada cenário.

Explique as condições gerais antes de coletar dados individuais quando isso já responde à dúvida. Quem pergunta “vocês oferecem troca de tamanho?” pode não precisar informar documento e endereço. Se a pessoa quer abrir uma solicitação para uma compra concreta, então peça o identificador necessário e aplique a autorização definida pela operação. O acesso deve servir ao caso, não a uma lista fixa de perguntas que todos precisam responder.

Confirme o objetivo em linguagem comum antes de qualquer gravação. “Você deseja solicitar a troca por um tamanho maior” é mais claro que repetir um código interno da categoria. Se a intenção muda durante a conversa, atualize o pedido e confira se a ação ainda não ocorreu. A integração precisa impedir que uma correção verbal gere duas solicitações incompatíveis para a mesma compra.

Separe elegibilidade, solicitação e conclusão

Uma política pode indicar que determinado caso permite solicitar devolução. Isso não significa que o produto já foi recebido pela empresa, que a análise terminou ou que um reembolso foi realizado. Defina os estados que a integração consegue verificar e as frases correspondentes. “A solicitação foi registrada” comunica uma ação diferente de “a devolução foi aprovada”. Sem essa distinção, a conversa cria expectativas que o sistema operacional não confirma.

Se o envio já começou, o sistema pode recusar um cancelamento e indicar outra orientação prevista pela empresa. O agente deve explicar esse resultado, sem repetir a operação ou prometer uma exceção. Se o pedido ainda aceita cancelamento, confirme somente depois de receber esse resultado do sistema. A ausência de uma mensagem de erro não basta.

Se a ferramenta responde com “em análise”, preserve esse estado. Pergunte à equipe quais dados podem ser informados durante a espera e qual canal permite acompanhamento. Um prazo só deve aparecer quando aprovado e aplicável ao caso. Evite transformar uma média histórica ou um exemplo do documento em compromisso individual. Para reembolso, a confirmação precisa diferenciar aprovação comercial, execução no sistema e informação disponível sobre o recebimento, conforme a integração realmente oferece.

As regras legais e comerciais variam conforme contexto e jurisdição. Este atendimento deve reproduzir a política aprovada e encaminhar dúvidas que exigem análise específica. O agente não precisa improvisar aconselhamento jurídico para parecer completo. Se o cliente contesta uma regra ou apresenta uma exceção que a fonte não cobre, registre o motivo e ofereça o processo de revisão existente. A precisão do estado é parte central da qualidade.

Proteja o pedido contra repetição e mudança de intenção

Chamadas sobre devolução podem ser repetidas porque o cliente não recebeu uma confirmação clara. Antes de criar uma nova solicitação, consulte o estado existente quando essa capacidade está disponível. Se já há um protocolo aberto para o mesmo objetivo, explique como acompanhá-lo. Uma nova ligação não deveria criar automaticamente um segundo pedido de coleta ou outra promessa de reembolso. A prevenção de duplicidade precisa ser implementada na integração, além de ser mencionada no prompt.

Teste uma ferramenta que demora enquanto o cliente pergunta “você já fez?”. O agente precisa explicar se a ação está em andamento ou foi confirmada. Repeti-la imediatamente pode criar outro pedido. Peça ao responsável pela integração que confira se o sistema reconhece tentativas repetidas e permite descobrir o resultado da primeira antes de tentar de novo.

Também teste correções após a confirmação. A pessoa pode dizer “na verdade, prefiro trocar” enquanto uma solicitação de devolução já foi enviada. O agente não deve fingir que a primeira ação nunca ocorreu. Consulte o estado, explique o que pode ser alterado e use uma operação de mudança apenas se ela existir e for permitida. Quando não houver essa capacidade, encaminhe com o contexto necessário, sem prometer que a equipe desfará o pedido automaticamente.

Na coleta de dados, evite perguntas que não são exigidas naquela etapa. Informações de pagamento ou documentos extensos não devem entrar na conversa apenas porque podem ser úteis em algum caso futuro. Estabeleça quais campos são obrigatórios para identificar a compra, quais descrevem o motivo e quais pertencem a outro canal. Um processo com menos dados desnecessários costuma ser mais fácil de concluir e de revisar corretamente.

Avalie a experiência até o resultado no sistema

Medir somente o encerramento da chamada esconde erros importantes. Uma conversa curta pode deixar o cliente sem protocolo; uma conversa cordial pode registrar a categoria errada; uma solicitação aparentemente concluída pode permanecer inexistente no sistema de pedidos. Avalie a identificação da intenção, a aplicação da política, a confirmação da ação e a continuidade posterior. Cada etapa exige uma evidência diferente e deve ser revisada sem presumir que uma boa frase final comprova tudo.

Monte uma amostra com troca de tamanho, cancelamento antes do envio, pedido já enviado, devolução em análise e cliente que retorna para acompanhar um protocolo. Acrescente produto sem informação suficiente, identificador corrigido, consulta indisponível e mudança de intenção. Para cada situação, escreva o estado final esperado e a mensagem permitida. Esses cenários mostram se o agente distingue os tipos de pedido e se mantém precisão quando a ação desejada não pode ser realizada.

Compare solicitações que exigiram correção humana, registros duplicados, dados recolhidos novamente e contatos repetidos por falta de clareza. Separe casos que dependem de inspeção ou decisão posterior: o agente não deve ser responsabilizado por concluir uma análise que está fora do seu escopo. Ainda assim, pode ser avaliado por explicar o processo corretamente e deixar o registro compreensível para a equipe seguinte.

Use as falhas para revisar a parte correspondente. Se o cliente não entende a confirmação, ajuste a linguagem. Se o pedido é classificado errado, melhore a pergunta inicial. Se o sistema aceita operações incompatíveis, corrija a validação da integração. Se a política não descreve uma situação frequente, peça uma decisão ao responsável comercial. Assim, a melhoria do atendimento acompanha o processo real da loja e não depende de tornar o agente mais insistente ou mais confiante diante de uma resposta que continua indisponível.