Introdução: por que formalizar um handover para totens e ecrãs

Um avatar de acolhimento (IA) instalado num totem ou ecrã proporciona uma primeira camada de informação e orientação. Contudo, certas solicitações ficam fora do âmbito automatizável ou exigem a intervenção de um conselheiro humano. Conceber um processo de escalada fiável evita rupturas no percurso, preserva a confidencialidade dos dados e facilita a tomada de conta pelas equipas.

Este playbook dirige‑se a implementações físicas: compara padrões técnicos de escalada, explica que decisões de arquitetura tomar, aborda a UX e o consentimento multilingue, propõe indicadores de aceitação e fornece uma checklist de exploração 24/7 e de formação das equipas.

Padrões de escalada: vantagens, limites e casos de uso

Quatro padrões aparecem frequentemente para passar de um avatar de acolhimento (IA) para um agente humano. A escolha depende do contexto operativo, da infra‑estrutura existente e do nível de espera aceitável para o utilizador.

  • Ponte de voz em tempo real (voice to agent): o avatar liga o utilizador a um conselheiro por áudio direto. Vantagem: continuidade vocal e atendimento imediato. Limite: requer integração telefónica ou CCaaS e capacidade de postos em tempo real.

  • Fila de espera virtual: o utilizador entra numa fila digital e aguarda atendimento. Vantagem: gestão ordenada dos pedidos e possibilidade de estimar a posição. Limite: exige um mecanismo back‑end para gerir a fila e informar o utilizador; não é adequado se o atendimento tiver de ser instantâneo.

  • Criação de ticket / callback: o avatar cria um caso ou ticket com o contexto, com opção de contacto por parte de um agente. Vantagem: boa rastreabilidade e adaptável a picos. Limite: a conversa é interrompida e a retomada do contexto requer uma transferência estruturada da informação.

  • Co‑navegação ou acompanhamento híbrido: um conselheiro retoma o contexto conversacional (texto/resumos) e orienta o utilizador remotamente. Vantagem: permite ao conselheiro ler o histórico e prosseguir sem repetição. Limite: pressupõe uma integração que transmita o contexto e, frequentemente, uma ferramenta web ou um cliente de agente acessível.

Decisões de arquitetura e integrações: que dados transmitir e como

Antes de qualquer integração, liste os objetivos: reduzir a fricção para o utilizador, preservar a confidencialidade e fornecer ao conselheiro a informação útil para o tratamento. As integrações necessárias variam conforme o padrão escolhido e implicam frequentemente webhooks, APIs REST ou uma ligação a CCaaS/CRM.

  • Que dados transmitir: um resumo contextual da sessão, as últimas interações (perguntas-chave e respostas), documentos ou provas referenciadas, a língua utilizada e o modo de interação (voz, táctil). Evite enviar dados sensíveis desnecessários.

  • Formato e transporte: privilegiar payloads estruturados (JSON) via webhook seguro. Uma integração específica pode permitir o envio para um CRM ou centro de contacto. Defina no desenho quais os valores obrigatórios e quais são opcionais.

  • Retoma de contexto RAG: se o avatar se apoia numa base de conhecimento, transmitir apontadores ou excertos pertinentes pode ajudar o agente. Trata‑se de uma retomada de contexto, não de uma exportação completa da base documental.

  • Segurança e confidencialidade: cifrar os fluxos, autenticar endpoints e minimizar a superfície de dados partilhada. Definir quem tem direito de aceder à transcrição e durante quanto tempo, em conformidade com a política de dados da organização.

Aspetos técnicos detalhados: webhooks, retoma de contexto e multimodalidade

A implementação técnica concentra‑se em três pontos: mecanismo de chamada (webhook/API), formato do contexto e gestão da multimodalidade (voz + táctil). Essas escolhas influenciam latência, robustez e a capacidade de retomar a conversa sem perda de informação.

  • Webhooks e endpoints: conceber webhooks capazes de receber um snapshot de sessão. Uma integração específica pode desencadear a criação de um ticket, alertar um agente ou colocar na fila de um CCaaS.

  • Snapshot de sessão: privilegiar um resumo estruturado em vez de longos transcripts. Incluir metadados úteis: língua, timestamp, tipo de interação, consentimento. A retoma de contexto RAG pode limitar‑se a algumas passagens essenciais extraídas da base de conhecimento.

  • Multimodalidade: para totens vocais, prever a ligação entre a sessão de voz e o fluxo de texto. SANIA pode operar em voz e táctil conforme a configuração. A integração responsável deve permitir ao conselheiro conhecer o modo inicial para adaptar a sua intervenção.

UX e consentimento multilingue: regras práticas para uma transição clara

Uma transição bem sucedida não depende só da tecnologia. A experiência do utilizador e a gestão do consentimento são centrais, sobretudo em totens públicos e num contexto multilingue.

  • Informar antes de transferir: antes de iniciar a escalada, o avatar deve explicar de forma simples o que vai ocorrer (por exemplo: ligação, criação de ticket, contacto posterior) e pedir a concordância do utilizador.

  • Recolha e rastreabilidade do consentimento: capturar o consentimento verbal ou táctil conforme o canal. A natureza desse consentimento deve ser registada com a sessão e tornada acessível ao agente, em conformidade com a política de dados da organização.

  • Scripts multilingues e adaptativos: prever formulações claras nas línguas relevantes. SANIA pode comunicar em mais de 100 línguas numa configuração adaptada, o que facilita a captura do consentimento na língua do utilizador.

  • Gestão de informações sensíveis: se a conversa contiver dados pessoais ou sensíveis, convidar sistematicamente o utilizador a mudar para um canal seguro ou a contactar o serviço presencialmente. Não transmitir dados sensíveis sem consentimento explícito.

SLA, métricas e critérios de aceitação operacionais

Definir objetivos operacionais permite aceitar ou ajustar o processo de escalada. Esses objetivos devem ser realistas e depender dos recursos do centro de contacto e dos picos de afluência de cada local.

  • Exemplos de métricas a seguir (a implementar com as suas ferramentas): taxa de escalada por canal, taxa de aceitação da escalada pelos utilizadores, tempo médio entre pedido e atendimento humano, taxa de retoma do contexto sem nova explicação pelo utilizador.

  • Medição e recolha: esses indicadores exigem instrumentação dedicada. Uma organização pode optar por extrair esses dados a partir dos logs, do CRM ou das ferramentas CCaaS ligadas conforme a configuração escolhida.

  • Critérios de aceitação: antes da produção em larga escala, definir critérios qualitativos e operacionais (por ex. capacidade de atendimento em horas de pico, compreensão multilingue suficiente para captar o consentimento).

Checklist de exploração 24/7 e recomendações de formação

Garantir a disponibilidade e a qualidade de um handover requer procedimentos operacionais e formação dirigida das equipas. Segue‑se uma checklist operacional para preparar a exploração contínua.

  • Preparar runbooks para cada padrão de escalada: procedimento de ligação, geração de ticket, gestão de filas e retoma de contexto.

  • Monitorização e testes: verificar regularmente toda a cadeia (ASR, LLM, RAG, webhooks, CCaaS). Prever testes end‑to‑end em condições reais e cenários multilingues.

  • Plano de contingência: definir procedimentos quando a integração com o centro de contacto estiver indisponível (mensagem clara para o utilizador, opção de criação de ticket local).

  • Formação dos agentes: sensibilizar os conselheiros para a natureza do contexto transmitido pelo avatar, para as possíveis limitações dos resumos automáticos e para as regras de confidencialidade. Preparar scripts de acolhimento para reengajar um visitante que já tenha interagido com o avatar.

  • Governance e revisões: organizar revisões regulares entre DSI, suporte e responsáveis pelo acolhimento para ajustar regras de escalada, templates de contexto e scripts de consentimento.

Perguntas frequentes (FAQ)

P : O avatar guarda automaticamente as conversas que serão transmitidas ao agente?

R : A conservação e a transmissão dos dados dependem da configuração escolhida. Uma organização deve definir que dados são guardados, durante quanto tempo e se podem ser transmitidos a um CRM ou centro de contacto via integração específica.

P : É possível garantir que o agente disponha de todo o contexto para retomar a conversa sem que o utilizador repita?

R : Enviar um resumo estruturado e excertos relevantes facilita a retoma. No entanto, a qualidade da retomada depende do formato do contexto enviado e da interface utilizada pelo agente. Recomenda‑se testar cenários representativos e ajustar o payload de contexto em conformidade.

Para saber mais

A implementação de um handover eficaz entre um avatar de acolhimento (IA) e um agente humano combina decisões técnicas, regras de UX e organização. SANIA pode ser implementada em ecrã ou totem interativo, operar em voz e táctil conforme a configuração e explorar uma base de conhecimento própria da sua organização para alimentar o contexto. Para avaliar de forma concreta como integrar este playbook no seu ambiente e definir as integrações necessárias, pode solicitar uma demonstração da SANIA.