Cada mensagem recebe um próximo passo claro.

Cada item mostra por que razão lá está.

A fila contém decisões pendentes, itens de alternativa, identidades ambíguas, falhas técnicas e confirmações. Reclamar trabalho não aprova uma proposta.

Dados de exemplo; nada do que é mostrado é uma caixa de correio real.

Uma recomendação ao lado da mensagem.

Intenção, prioridade, uma faixa de confiança, candidatos a cliente e a decisão de encaminhamento, com as versões da regra, do manifesto e da escala de serviço, e um «porquê desta rota» numerado.

Dois clientes possíveis, pelo que uma pessoa tem de escolher. Dados de exemplo.

A mesma ordem para cada mensagem.

O encaminhamento foi concebido para seguir uma sequência fixa, em que o primeiro passo aplicável define a rota. Uma proposta abaixo do limiar de confiança nunca se encaminha a si própria: passa para uma alternativa com responsável, onde uma pessoa decide.

Quatro resultados honestos.

O OneMail foi concebido para identificar o cliente a partir de números, referências, moradas e trabalho anterior, e para mostrar candidatos ordenados com o motivo pelo qual cada um corresponde.

Sessenta minutos úteis até uma primeira decisão.

Os itens são assinalados como perto do incumprimento quando tiverem sido usados 45 minutos. Os calendários de serviço são pré-visualizados e publicados como política; os feriados aplicáveis são um dado fornecido pelo cliente. Alterar a política nunca mexe nos prazos já definidos.

Configuração de exemplo.

Confirmar, corrigir, esclarecer ou reatribuir.

• Os operadores confirmam, corrigem, pedem esclarecimentos, escolhem entre candidatos a cliente ou reatribuem. As proteções de versão impedem que duas pessoas atuem sobre uma decisão desatualizada.
• A espera pelo cliente é um relógio separado: após um pedido de esclarecimento, seguem-se um lembrete e um aviso de encerramento em dias úteis acordados, e uma resposta posterior reabre a conversa original.
• Respostas a partir de templates aprovados. Os templates são versionados por configuração regional e passam por submissão, aprovação e ativação segundo o princípio dos quatro olhos. A resolução de um template nunca inventa uma língua alternativa.

• As evidências acompanham a decisão. O nível de confiança, os excertos de origem realçados, os candidatos de identidade, os dados em falta e as versões exatas das regras e dos modelos ficam no registo de auditoria.
• Nada é sobrescrito. A reavaliação de uma mensagem preserva as decisões anteriores como eventos imutáveis, e as correções mantêm a versão anterior no histórico. Os registos de auditoria são só de acréscimo (append-only).
• Cada efeito secundário tem uma chave, uma entrada no livro-razão e um comprovativo. Um tempo limite esgotado é um resultado desconhecido, nunca motivo para uma nova tentativa duplicada. Os comandos de fila usam chaves de idempotência, pré-condições de versão, comprovativos de comando atómicos e uma outbox.
• Sem falsas anulações. Cada ação automática tem uma compensação ou um caminho de recuperação manual, e o trabalho irreversível nunca é apresentado como anulável.

Cada campo remete para a sua origem.

A análise, o OCR e uma tradução de trabalho rastreável produzem campos tipificados. Cada campo inclui a passagem de origem e o nível de confiança, e recebe um estado explícito de «em falta» quando a mensagem não o indica.

A informação em falta é mostrada como em falta. Dados de exemplo.

Campos com a respetiva origem, ou marcados como em falta.

• produtotapete transportadoralta
• localFábrica 4alta
• número de clienteC-20417exata
• telefone de contactoem faltapedir no esclarecimento

Um tempo limite esgotado é um resultado desconhecido, nunca motivo para uma nova tentativa duplicada.

Cada efeito secundário inclui uma chave de ação determinística, uma entrada no livro-razão e um comprovativo do sistema de destino.

As instruções no correio são dados, não comandos.

Os modelos nunca recebem credenciais, e uma instrução oculta num anexo não pode escolher um destino nem agir.

Aprovação por uma segunda pessoa.

Configuração de exemplo.

Quem gere o quê.

• A sua equipa gere o Kubernetes, o armazenamento, a rede, o seu fornecedor de identidade e a MFA, a localização por país, o SIEM e a resposta a incidentes.
• A versão do OneMail fornece predefinições de privilégio mínimo, aplicação exata do âmbito, artefactos assinados, comprovativos e recuperação documentada.

Não é reivindicada qualquer certificação. A localização dos dados, a localização do tratamento e a conservação são documentadas antes da entrada em produção.

Mínimos de disponibilidade, não dimensionamento.

Três domínios de falha, um cluster PostgreSQL de três instâncias, RabbitMQ com três membros, pelo menos três nós OpenSearch, duas ou mais réplicas de cada API e worker, e nós GPU apenas quando os modelos locais estiverem ativados. Se a IA estiver indisponível, a receção continua a funcionar.

O que a sua equipa de TI fornece.

• Dados do tenant do Microsoft 365 e do Entra e uma caixa de correio partilhada de piloto identificada; uma caixa de correio info@ real apenas com autorização explícita, para etiquetagem em sombra
• Acesso à caixa de correio através do Exchange Application RBAC no grupo exato de caixas de correio (só de leitura para um piloto), nunca Mail.Read para todo o tenant
• Registos de aplicações e consentimento de administrador, um grupo de primeiro administrador e grupos de operadores
• Uma subscrição do Azure e um grupo de recursos com direitos de implantação, bem como um nome de anfitrião DNS
• Uma função de leitura no Dataverse, se a identificação estiver no âmbito; a função de escrita apenas se as escritas estiverem ativadas
• Decisões de proteção de dados antes de qualquer correio real: fundamento de licitude, geografia do tratamento e do alojamento dos modelos, se é necessário um modelo alojado internamente, prazos de conservação, e se é necessária uma avaliação de impacto sobre a proteção de dados (AIPD) ou uma notificação à comissão de trabalhadores