Na sessão de detalhamento de casos de uso para o SOW [ARI], conduzida pela Renata (dona da Estrutura de Serviços e da Base de Conhecimento na YDUQS), o cliente detalhou toda a jornada de atendimento e a camada de Estrutura de Serviço. Abaixo, os fatos que o cliente trouxe (o estado atual) e, em seguida, os comentários pertinentes da nossa leitura. O ponto central: hoje o Salesforce opera como "tabulador", sem execução nem rastro ponta a ponta, e a lacuna vai além da KB. Isso tem impacto direto no que os agentes conseguem, de fato, resolver, e é exatamente o que a proposta (To-Be) endereça na sequência.

A YDUQS já tem um desenho conceitual robusto (proposto com apoio do arquiteto de solução). É uma ótima referência de visão, mas leia junto com a "Direção do sponsor" mais abaixo: a orientação de Maia/André é não replicar toda essa ambição no MVP. Tratar como backlog de visão e destilar uma Fase 1 no padrão da ferramenta.

O único agente em produção (Cobrança, construído pela Math Group) passou por um assessment do time de SWE Advisory, que catalogou 15 riscos (crítico / alto / médio). Isso muda nossa leitura do To-Be. O agente não está terrível (a base determinística e o agente foram bem construídos), mas carrega lacunas que ficam mais caras a cada novo agente se não forem corrigidas antes de escalar. Ponto sensível: nem o cliente (negócio e TI) nem, em boa parte, o próprio parceiro têm visibilidade destes pontos. Isso precisa ser levado com cuidado, dando visibilidade sem constranger, primeiro ao TI, depois ao negócio.

Três conversas recalibram este material. Em 21/jul, o alinhamento interno SWE × SOW fechou nuvens, prioridades e exclusões do ARI; à tarde, a sessão com o cliente detalhou o WhatsApp unificado e deixou claro que o desafio ali é processual, não sistêmico. Em 28/jul, a sessão de Marketing Cloud e mensageria proativa (com Renê Soares) apresentou o benchmark do Governo e explicitou as dores de gestão de jornadas da YDUQS (racional detalhado no item "Cenário de Marketing Cloud"). Em 30/jul, o time fechou o foco da apresentação de 31/jul: escopo do ARI dos 7 pilares e 3 agentes, sem tratar Conversations x Flex Credits (que fica para o material executivo de 04/ago).

Não dá para colocar todos os tópicos na capacidade contratada. A recomendação da consultoria é não deixar muitas escolhas em aberto (o cliente tem dificuldade de decidir): levamos um ou, no máximo, dois cenários recomendados, com justificativa e interdependências. A regra é fazer o primeiro agente completo, sem gaps, e só então replicar boas práticas para os próximos.

O objetivo do cliente é concentrar em um número único todos os disparos ativos e o atendimento receptivo, de qualquer área (DBM, relacionamento, secretarias, polos próprios e parceiros). Hoje a comunicação é fragmentada: as pontas usam chips de banca em números não verificados, que a Meta vem banindo com velocidade, cortando um canal importante. São 2.600+ pontas (mais de 100 operações próprias e mais de 2.500 de parceiros): centralizar tudo no corporativo não escala, e soltar a rédea coloca em risco o número, a experiência do aluno e a exposição jurídica.

Entendido o estado atual, a proposta da Salesforce ataca a causa raiz: transformar o Salesforce de "tabulador" em plataforma de execução com rastro. Uma única plataforma (Service Cloud + Agentforce + Data Cloud + Knowledge) leva automação a cada camada de contato do aluno, e todo atendimento aterrissa em um caso rastreável, o oposto de hoje. As quatro camadas abaixo organizam os sete pilares por onde o aluno passa. O detalhamento de cada caso de uso vem na sequência.

Esta é a leitura direta do que o ARI entrega de fato: três agentes Agentforce priorizados, na ordem Cobrança → Financeiro → Retenção. Para cada um você encontra, de forma fluida: o que precisamos antes de começar (pré-requisitos), a implementação de setup (a primeira versão que sobe em produção), as evoluções (novas funções e características que vêm depois do setup) e quanto tempo leva. Renovação, Onboarding e Ongoing saem do foco deste material: dependem de discovery dedicado e só entram depois do primeiro agente 100% estável.

Toda estimativa deste material parte de uma squad Agentforce dedicada por caso de uso, com cinco papéis: 1 PM (20h/sem), 1 Solution Architect (40h/sem), 1 Tech Lead (40h/sem), 1 Developer (40h/sem) e 1 Quality Assurance (40h/sem). A conta é 20 + 40 + 40 + 40 + 40 = 180 horas por semana por squad. A base de planejamento é de 8 semanas por agente (6 de desenvolvimento + 1 de testes + 1 de revisão e go-live), ou seja, 8 × 180 = 1.440 horas por agente. Essas 8 semanas cobrem o setup (1ª versão), a primeira onda de evoluções e o ciclo de testes e go-live assistido. Evoluções mais profundas (por exemplo, camada preditiva com Data Cloud) são fases posteriores, sinalizadas caso a caso.

O esforço total é o mesmo nos dois cenários (4.320h). O que muda é o prazo de calendário e o número de pessoas alocadas simultaneamente. Com 3 squads em paralelo (uma por agente), os três saem juntos em 8 semanas. Com 1 squad atuando nos três em sequência, o calendário estica para 24 semanas.

Cada agente ocupa 8 semanas: desenvolvimento (S1–S6), testes (S7) e revisão e go-live (S8). Em paralelo, as três janelas coincidem e o programa fecha em 8 semanas; em sequência, uma squad encadeia os três e fecha em 24 semanas.

Visão de ordem de grandeza por frente de trabalho. Os três agentes consomem ~44% do total; os outros ~56% sustentam a fundação e as nuvens que os fazem performar.

Aluno inadimplente abordado de forma proativa no WhatsApp. O agente autentica, apresenta opções de acordo dentro das réguas YDUQS e fecha a negociação sem intervenção humana sempre que possível, escalando para atendente quando foge da política. O agente já existe em piloto (construído por Math Group + PS), mas o assessment técnico apontou lacunas de segurança, observabilidade e transbordo. Por isso o foco da 1ª versão não é construir do zero, e sim estabilizar sem gaps.

Atende dúvidas e demandas financeiras receptivas nos três canais (WhatsApp, portal e bot do 0800). Como a maior parte do volume de requerimentos é financeira, o objetivo central é deflexão: resolver o contato na conversa, sem abrir requerimento assíncrono no CIA legado. É construção do zero, mas reaproveita a fundação (KB no SF e integração de faturamento) que já começa a ser montada para o Agente de Cobrança.

Agente proativo que identifica alunos em risco de evasão e inicia uma conversa de retenção antes que a evasão aconteça, oferecendo benefícios ou renegociação. No MVP, os sinais determinísticos do Service Cloud (atraso em mensalidade, inatividade no portal, histórico de acordos, não renovação) já viabilizam uma versão funcional. A versão inteligente, com propensão à evasão por modelo, exige Data Cloud e fica para fase posterior. Importante não vender como "retenção inteligente" no MVP.

Esta é a visão do que foi discutido e trazido como caso de uso ao longo do discovery, agora organizada por produto Salesforce e revisada à luz da priorização do ARI: no núcleo, os três agentes (Cobrança, Financeiro, Retenção). Cada produto sustenta ou entrega uma parte da esteira. Para cada caso de uso indicamos qual agente ele sustenta, a fase, a complexidade técnica e o que precisa estar pronto para iniciar o desenvolvimento. Tudo cabe dentro da capacidade contratada do ARI e começa pela estabilização do Agente de Cobrança (prioridade zero).

O escopo foi construído ao longo de ~45 dias junto com os times de Vendas, Delivery e o cliente (Roberto Maia / André). A repriorização de julho/26 eleva a Estrutura de Serviços ao topo, ela é a espinha dorsal que conecta todos os demais pilares. Agentes sem catálogo de serviços estruturado e sem KB ativa não performam. Com os alinhamentos de 21 a 30/jul, os sete pilares passam a ser lidos dentro da capacidade contratada do ARI e com a Fase 0 de elevação do Agente de Cobrança à frente de tudo. O tópico que o cliente conhece como "Copilot" é endereçado dentro da fundação (Pilar 01, Knowledge Base e catálogo de serviços), não como produto isolado.

Sem este pilar, nenhum agente performa bem. A YDUQS revisou o conteúdo da KB no papel e tem uma estratégia de governança definida, mas nada está estruturado dentro do Salesforce. Este pilar constrói a fundação técnica que conecta catálogo de serviços, artigos de KB, filas de atendimento, formulários e workflows em uma estrutura única e consultável por humanos e agentes.

Como um atendimento se move desde o canal de entrada até a resolução, com agente ou humano, usando a estrutura de serviços como espinha dorsal.

Quatro agentes Agentforce cobrindo os principais momentos do relacionamento YDUQS com aluno e candidato. Cada agente opera dentro do Salesforce, consome a KB estruturada (Pilar 01), integra com o Service Cloud para leitura de contexto e usa o WhatsApp como canal principal de conversa. O transbordo para humano é by design em todos eles.

Aluno inadimplente abordado proativamente pelo canal WhatsApp. O agente conduz a negociação e fecha o acordo sem intervenção humana sempre que as réguas permitirem.

Atende dúvidas e demandas financeiras receptivas nos três canais principais. Principal alavanca: deflexão de requerimentos financeiros que hoje entram na fila do CIA legado como atendimentos assíncronos.

Agente proativo que identifica alunos em risco de evasão e inicia uma conversa de retenção antes que a evasão ocorra. Requer perfil de aluno com sinais comportamentais, acesso ao portal, frequência, histórico de pagamento, idealmente via Data Cloud na Fase 2. No MVP, sinais determinísticos do Service Cloud já viabilizam uma versão funcional.

O copiloto acelera o atendimento humano pós-transbordo, reduz TMA, sugere respostas baseadas na KB e no contexto do aluno, e diminui o volume total de atendimentos humanos. A versão anterior foi construída sem as fundações necessárias (sem KB estruturada no SF, sem histórico de conversa, sem atributos do aluno), o que limitou fortemente o resultado. A proposta PS é um design radicalmente diferente, e por isso adotamos a abordagem demo-first: mostramos o funcionamento real antes de comprometer no SOW.

O projeto mais estruturalmente complexo do escopo. Hoje ~80% do volume de captação ainda está fora do Salesforce (solução legada de mensageria), com dependências de PDV, call center e polos. A YDUQS já moveu Estácio matrícula (~20%) para o Salesforce WA e está migrando o canal de candidatos do portal. O que falta: consolidar número único por marca, trazer o restante para o Salesforce e resolver o problema mais urgente do cliente, as pontas (2.600+ operações) fazendo disparos com chips avulsos e sem visibilidade do que central já enviou. Recado das reuniões de 21 e 28/jul: o desafio aqui é processual, não sistêmico. Primeiro se desenha a governança (dono de assunto, calendário, aprovação, hierarquia, franquia), depois a tecnologia encaixa. Marketing Cloud e Data Cloud não resolvem sozinhos. O benchmark do Governo Federal está no material dedicado de Benchmark de Mensageria e o racional das dores de jornadas está no item "Cenário de Marketing Cloud".

A solução não é tirar a autonomia das pontas, é dar-lhes uma ferramenta com governança embutida: seleção de público, visibilidade de custo antes do envio, visibilidade do que central já enviou para aquele candidato, e restrição de volume por período. Mas primeiro vem o processo (dono de assunto, fila, aprovação, calendário), depois a ferramenta. Referência: Governo Federal / gov.br, número único para 13 ministérios e 123 órgãos, ~60% orquestrado pela Casa Civil, tudo utility, zero sobreposição. Detalhes no material de Benchmark de Mensageria.

Em 28/jul, a sessão de mensageria proativa apresentou o benchmark do Governo Federal (Renê Soares) como prova de escala e governança. Ficou claro, porém, que a dor da YDUQS (trazida por Carolina, Diego e Renata) não é o case do Governo em si, e sim a gestão e a visibilidade de jornadas: enxergar o que já foi disparado, controlar o contact rate e evitar sobreposição entre áreas. Ficou combinada uma sessão dedicada para demonstrar a visualização de jornadas na prática (módulo de performance do Marketing Cloud). Este item consolida o racional de valor, sem comprometer plataforma ou migração no ARI agora. O tema é tratado de forma genérica como evolução do Marketing Cloud (dependências contratuais a validar).

Todos os pilares convergem para uma plataforma única no Salesforce. O dado do aluno/candidato é centralizado, os agentes compartilham a mesma KB, os canais usam o mesmo WABA, e o Service Cloud orquestra os transbordos humanos com filas e SLA. O legado CIA e a mensageria legada são descontinuados progressivamente. Este diagrama é a visão macro integrada; a arquitetura técnica de cada agente (componentes, fluxo runtime e integrações) está detalhada agente a agente em "Plano dos 3 agentes".

Riscos identificados a partir das reuniões de Jul/02, Jul/14, do assessment SWE de Jul/15 e das duas reuniões de Jul/21 (escopo interno SWE × SOW e governança de mensageria com o cliente), além do contexto de conta. Organizados por severidade. Cada risco tem um dono sugerido e uma ação de mitigação concreta, não são só alertas, são itens de agenda.

Plano faseado com quick-wins visíveis no curto prazo para sustentar o momentum político do ARI e entregas de maior complexidade distribuídas em fases subsequentes. Os pré-requisitos refletem a cadência combinada em 21/jul: escopo desenhado, aprovado no OTT e apresentado ao cliente até 30/jul, antes das férias. A Fase 0 eleva o Agente de Cobrança (prioridade zero). Tudo que está em Fase 1 deve ser viável com os conversation credits disponíveis (~295K) antes da virada para Flex Credits em Jan/27, e caber nas ~9.816h do ARI.

A mesma proposta lida "de cima": cada fase agrupa os casos de uso que entram naquele momento, na ordem de dependência. A leitura é Fase 0 (blindar o Agente de Cobrança) → Fase 1 (fundação + primeiros agentes e canal) → Fase 2 (expandir agentes e governança) → Fase 3 (dados e fim do legado).

Visão de calendário dos entregáveis. As barras indicam a janela prevista de cada frente; as cores seguem a fase. É uma leitura de sequência e sobreposição, não um cronograma contratual (o detalhamento fino de esforço está em "Plano dos 3 agentes").

Para os casos de uso com interação direta, a jornada de quem usa, ponta a ponta. O resumo "o que é" de cada um está na coluna Detalhamento do roadmap acima; o fluxo conversacional aprofundado está em "Jornadas conversacionais".