Exemplo: aplicar a arquitetura estruturada de conceção a um agente autónomo de suporte de e-mail

Este exemplo ilustra a aplicação da arquitetura completa e estruturada de conceção a uma situação real.

Problema: a caixa de entrada do suporte de TI está inundada de e-mails. Os representantes de suporte de TI leem manualmente cada mensagem, identificam os números dos pedidos de suporte, acedem ao ServiceNow, pesquisam na base de dados de conhecimento e respondem. Este processo é lento, repetitivo e propenso a erros.

Resultado desejado: processar e-mails de suporte em segundos, não em horas. Reduza o trabalho manual, acelere os tempos de resposta e melhore a experiência dos colaboradores.

Categoria Descrição de exemplo
Objetivo Porque é que este agente existe? Que problema está a resolver? Quem vai utilizar o agente?
  • Reduzir a triagem manual dos e-mails da caixa de entrada do suporte de TI.
  • Detetar automaticamente a intenção, os números de pedidos de suporte e as ações necessárias.
  • Fornecer respostas precisas sem intervenção humana.
  • Melhorar os tempos de resposta e reduzir o registo de tarefas pendentes.
Quadro de trabalhos a executar:
  • Como agente de suporte de TI
  • Preciso de processar automaticamente os e-mails recebidos
  • Para poder focar-me em questões complexas em vez de triagem repetitiva
Critérios de êxito:
  • E-mails processados de ponto a ponto sem envolvimento humano.
  • Pesquisas de pedidos de suporte exatos.
  • Respostas por e-mail de alta qualidade.
  • Redução significativa no tempo de triagem manual.
Acionadores Chega um novo e-mail à caixa de correio partilhada do suporte de TI.

Considerações de dados:
  • Os e-mails podem conter informações confidenciais.
  • A extração de dados deve ser robusta para formatos não estruturados.
  • O token do sistema deve ter acesso de leitura/escrita ao ServiceNow.
Ferramentas e integrações O que o agente realmente faz:
  • Analisa o e-mail de entrada e identifica a intenção.
  • Extrai ou infere o número do pedido de suporte (se presente).
  • Obtém o estado do pedido de suporte ou as informações relevantes do ServiceNow.
  • Pesquisa na base de dados de conhecimento para responder a perguntas.
  • Compõe e envia uma resposta completa e contextual.
  • Cria ou atualiza pedidos de suporte, quando necessário.
Sistemas: ServiceNow (dependência crítica), base de dados de conhecimento (SharePoint ou similar), Outlook, Graph APIs
Requisitos: autenticação por token do sistema, limites de taxa e novas tentativas da API, conectividade fiável entre sistemas
Dependências entre equipas: equipa administrativa do ServiceNow, operações de suporte de TI, proprietários da base de dados de conhecimento
Canais Notificações do Teams para escalamento e dashboards administrativos para auditoria e monitorização.
Conhecimento e dados Detalhe as informações em que o agente se baseia:
  • Conteúdo da base de dados de conhecimento de RH e TI para passos de resolução de problemas.
  • Histórico de pedidos de suporte para personalizar as respostas
  • Mapeamentos de categorias (hardware, software, reposição de palavra-passe, problemas de rede).
  • Regras de classificação de intenções.
  • Padrões para extração de pedidos de suporte (#12345, INC12345, etc.).
Expetativas de qualidade:
  • A base de dados de conhecimento deve ser revista regularmente.
  • O conhecimento deve incluir políticas atualizadas.
  • Evite fluxos de resolução de problemas obsoletos ou preteridos.
Fluxos e orquestração Responsabilidades humanas:
  • Processe os escalamentos quando o agente não consegue classificar a intenção.
  • Aprovar ou rever ações de alto risco (por exemplo, encerramento de pedidos de suporte).
  • Atualizar o conteúdo da base de dados de conhecimento para que as respostas do agente permaneçam precisas.
  • Monitorizar registos de auditoria e desempenho.
Responsabilidades do agente:
  • Responder a consultas de rotina.
  • Confirmar o estado do pedido de suporte.
  • Redigir respostas utilizando fontes de conhecimento validadas.
  • Sugerir perguntas esclarecedoras quando o e-mail for ambíguo.
Componentes deterministas:
  • Deteção do número do pedido.
  • Fluxo de contingência "Nenhum pedido de suporte encontrado".
  • Encaminhamento explícito para categorias (reposições de palavras-passe, problemas de hardware, pedidos de software).
Componentes flexíveis:
  • Compreensão de linguagem natural do e-mail.
  • Geração automática de respostas com base no conteúdo da BDC.
Notas de estruturação:
  • Utilize passos estruturados para a recuperação e validação antes de responder.
  • Evite um estilo de conversa semelhante ao humano. Os e-mails têm de ser precisos.
Instruções e comportamento Estas instruções de alto nível definem como o agente pensa e age:
  • Valide sempre os números do pedido de suporte extraídos antes de os utilizar.
  • Se nenhum pedido de suporte for encontrado, faça uma pergunta esclarecedora antes de prosseguir.
  • Utilize apenas fontes aprovadas da BDC para os passos de resolução de problemas.
  • Mantenha as respostas concisas, factuais e profissionais.
  • Nunca divulgue detalhes do pedido de suporte a menos que o remetente seja o requerente.
  • Quando houver ambiguidade, responda com perguntas esclarecedoras.
  • Registe todas as ações para auditoria.
Tom e estilo:
  • Profissional e útil.
  • Nada de conversa desnecessária.
  • Formatação adequada ao e-mail.
Arquitetura e composição do agente Potenciais agentes subordinados:
  • Um Agente de Resposta da Base de Dados de Conhecimento para lidar com a pesquisa e extração de artigos.
  • Um Agente de Pedidos de Suporte para lidar com as interações com o ServiceNow.
  • Um Agente de Classificação para categorizar a intenção.
Benefícios:
  • Separação clara de funções.
  • Manutenção e iteração mais fáceis.
  • Menor risco de ações não intencionais.
Governação e gestão de risco Riscos a considerar:
  • Classificação errada da intenção do utilizador.
  • Responder com passos de resolução de problemas incorretos.
  • Expor dados confidenciais de pedidos de suporte a utilizadores não autorizados.
  • A automatização excessiva leva a ações não conformes.
Mitigações
  • Utilize o controlo de acesso baseado em funções.
  • Registe todas as ações em termos de auditoria e rastreabilidade.
  • Inclua comportamento de contingência para mensagens ambíguas.
  • Mantenha fontes de conhecimento atualizadas e validadas.
  • Restrinja a possibilidade de modificar ou fechar pedidos de suporte sem aprovação humana.
Considerações de governação:
  • Autenticação: utiliza um token ao nível do sistema para o ServiceNow e segue as políticas organizacionais para aceder a caixas de correio partilhadas.
  • Autorização: o agente pode ler e atualizar pedidos de suporte, criar novos pedidos de suporte, responder a e-mails. O agente não pode fechar pedidos de suporte nem modificar campos sensíveis.
  • Auditabilidade: todas as ações registadas (analisar → pesquisar → responder), ações com falha sinalizadas para revisão, verificações regulares de auditoria para validar a segurança e a conformidade.
Avaliação e otimização Métricas:
  • Percentagem de e-mails totalmente automatizados.
  • Precisão da extração dos pedidos de suporte.
  • Tempo médio de resposta em relação ao processamento manual.
  • Número de escalamentos.
  • Indicadores de satisfação do utilizador.
  • Taxas de alucinações/erros.
Telemetria:
  • Cada ação realizada pelo agente (analisar → pesquisar → responder).
  • Falhas e acionadores de contingência.
  • Chamadas de ferramentas para o ServiceNow.
  • Conteúdo das respostas geradas (para QA).