Relacionamento Comercial
Inteligente
Uma plataforma de autosserviço e comunicação ativa, conectando os clientes e empregados da Dataprev aos seus sistemas internos, via Slack + Agentforce, sem depender de horário de atendimento.
Fonte: números citados pelo time da Dataprev nas reuniões de discovery (jun e 14 jul 2026). Valores com "~" são estimativas ainda em validação, não medições fechadas.
O que mudou nesta versão
A leitura inicial deu o panorama. Esta versão incorpora as jornadas detalhadas, a volumetria dos sistemas e as decisões de escopo. Três pontos redefinem o racional: (1) o foco de curto prazo é integração e simplificação sobre os sistemas atuais, sem substituir Pronto nem Clarity; (2) Change Management entra como pilar formal do projeto, e não como acessório; (3) o licenciamento Slack proposto é o Enterprise+, com custo por usuário previsível e desconto por faixa de volume, o que endereça o principal risco financeiro levantado por Pedro.
📎 Fontes e premissas deste material transparência ▶
Este documento é um rascunho interno de discovery. Todo dado quantitativo vem de fala direta do time da Dataprev ou de referência de mercado explicitamente citada. Nada aqui é projeção comercial fechada.
- Reuniões de discovery Dataprev, jun e 14 jul 2026: volumetria de chamados no Pronto, base de clientes, público interno da Conexão, sistemas legados, decisões de escopo e cadência de próximos passos.
- Estimativa de licenças Slack: ordem de grandeza levantada por Pedro (Dataprev), ainda a validar com o desenho de acessos por cliente. Sinalizada com "~".
- Referências de produtividade do Slack: números de mercado a confirmar com material oficial Salesforce antes de uso externo.
- Identidade visual: paleta ancorada no gov.br Design System (token blue-warm-vivid, primária #1351B4) e na marca gov.br (azul, verde e amarelo). O azul institucional Dataprev segue a mesma família.
Origem do Projeto
📖 Como chegamos aqui
Este projeto nasce de dentro da Dataprev, não de uma demanda top-down, mas de uma percepção construída de baixo para cima por quem vive o operacional. Pedro Oliveira (DERC) e Maik observaram, a partir da experiência com o Serviço na Ponta, que a mesma lógica de automação e IA que estava transformando o atendimento ao cidadão poderia, e deveria, ser aplicada ao relacionamento comercial com os clientes institucionais da Dataprev e à operação interna dos próprios empregados.
"A gente foi vendo o projeto do serviço na ponta elevar de nível e ganhar notoriedade. E olhando para o relacionamento comercial, a gente falou: por que não trazer essa mesma lógica para dentro?"
A visão foi validada em cascata: do assessor ao gerente executivo (Rogério de Almeida Gomes, DERC), chegou ao superintendente Saulo, que aprovou. Com um novo diretor recém-chegado (1 semana), a janela para um golaço estratégico é agora.
Janela estratégica: defeso eleitoral
O volume de demandas tende a reduzir durante o período eleitoral, criando espaço para estruturar o projeto antes da retomada de velocidade total. Quando acelerar novamente, a plataforma já estará desenhada.
🏛️ Patrocínio Executivo
Construído de baixo para cima, raro e valioso em organizações públicas.
Equipe Envolvida
Pedro Oliveira
Idealizador do projeto, visão comercial, jornadas internas
Dataprev · DERCMaik
Referência técnica, coordenação do projeto, Serviço na Ponta
Dataprev · DERCJuliane Lopes
Arquitetura estratégica, discovery, identificação de oportunidades
Salesforce PS BrasilJuliana Brites
Relacionamento comercial, contratação, estrutura de OS
Salesforce PS BrasilRafael Roquette
Gerente de programa, coordenação das frentes Salesforce × Dataprev
Salesforce PS BrasilNelson Stebulaitis Filho
Direcionamento estratégico, definição de KPIs e escopo junto com Juliane
Salesforce PS BrasilMarcos Alirio
Entusiasta de processos e CRM, foi um dos gestores do projeto de CRM na Dataprev
DataprevRenato Soti
Account Executive de Core, cobrindo a conta enquanto Fernanda Pacheco está de férias
SalesforceFernanda Rodrigues
Executiva de Conta, apresentou a ROM Data Ágil v1 ao cliente
SalesforceSaulo (Superintendente)
Patrocinador executivo, aprovação concedida, também impulsiona a agenda de IA interna
DataprevContinuidade natural do Serviço na Ponta
Este projeto não parte do zero. A infraestrutura Slack + Salesforce já está sendo construída para o Serviço na Ponta. O investimento arquitetural já existe, este projeto é uma extensão estratégica para o relacionamento B2B e interno, usando a mesma base com escopo e público diferentes.
Estrutura comercial prevista
OS separada, dentro do mesmo pool de consumo existente. Entrega faseada para respeitar alçadas de aprovação. Nova equipe dedicada, o time atual precisa permanecer focado no Serviço na Ponta sem divisão de atenção.
Tecnologias e produtos no escopo
O Problema não é de processo, é de escala
A Dataprev cresceu 166× em número de clientes nos últimos 13 anos. A estrutura operacional de relacionamento não acompanhou esse crescimento. O que funcionava com 12 clientes não escala para 2.500, e menos ainda para 5.000.
O problema de escala
📈 166× mais clientes, mesma estrutura de atendimento
Pedro resumiu com precisão o que está em jogo: a Dataprev tinha cerca de 12 a 15 clientes há 13 anos. Hoje são 2.500. Com a expansão para estados e municípios, o potencial é de mais de 5.000 clientes. Não é possível operar esse volume com o mesmo modelo humano-intensivo que funcionava no passado.
"Não dá pra gente fazer o que a gente fazia com 12 clientes para 5.000 clientes. A gente teria que ter aí algumas Dataprevis e não é essa a realidade. Então, vamos à tecnologia a nosso favor."
Dores concretas identificadas
💸 Consultas financeiras diárias que travam o time comercial
Diretores financeiros dos órgãos clientes ligam diariamente para perguntar quanto devem à Dataprev, se a dívida está crescendo, quais são os valores em aberto. Cada uma dessas interações exige que alguém do time comercial pare o que está fazendo, consulte o Protheus e responda manualmente.
Exemplo real
"Muitos dos nossos clientes, eles questionam a gente diariamente com perguntas muito pontuais: 'Quanto que tá a dívida com a Dataprev? Tá aumentando?' Eles não precisam mandar um ofício, não precisam fazer uma reunião, não precisam ligar, eles iriam ali consultar e o agente retornava."
🏃 Executivos convocados sem tempo de se preparar
O time da Dataprev é constantemente convocado de forma imediata para reuniões com ministros, subsecretários e diretores, sem tempo para preparar um briefing adequado. Ir a uma reunião sem o contexto completo do projeto em pauta significa sair sem decisão, marcar nova reunião, formalizar resposta depois. Todo esse loop poderia ser eliminado com informação em tempo real.
"O Maik foi convocado para ir ao ministério tratar de um projeto. Não tem tempo de parar, não tem tempo de fazer ponto de controle. A ideia é que no caminho ele pergunte: 'Como está esse projeto?', e o agente compila as informações do CRM e entrega no Slack. Quem estiver representando a Dataprev já vai pautado, já resolve, não precisa marcar nova agenda."
🧠 RH e áreas de suporte afogados em perguntas estáticas
O time de Pessoas (RH) da Dataprev é diariamente demandado por perguntas objetivas e repetitivas: quantos dias de licença-paternidade? O que preciso apresentar? Quais são os benefícios vigentes? São informações que existem na intranet (Conexão) mas que os empregados não conseguem, ou não querem, buscar por conta própria. Um agente com acesso à base de conhecimento interna resolve isso completamente.
Informação existe, o acesso é que é o problema
A Conexão (intranet da Dataprev) tem todas as normas, comunicados e políticas. O problema não é falta de informação: é que a interface atual exige que o empregado vá buscar. Um agente inverte isso, a informação vai até o empregado no canal que ele já usa.
🚗 Tarefas operacionais simples que exigem atenção total
Pedro descreveu com precisão um cenário que todo gestor reconhece: saindo de uma reunião, precisar lembrar de agendar algo urgente sem ter como fazer naquele momento. A solução hoje é repetir mentalmente "não esquece, não esquece, não esquece" durante o caminho, e torcer para não esquecer mesmo.
"O chefe falou: 'Pedro, marca uma agenda para amanhã com essas pessoas.' Fui para casa, o caminho todo: 'Não esquece, não esquece, não esquece.' Se tivesse o Slack, eu mandava um audiozinho: 'Agenda uma reunião com essas pessoas.' Chego em casa tranquilo."
Slackbot resolve isso nativamente
Comando de voz ou texto para o Slackbot → acessa agendas dos participantes → encontra janela disponível → cria o convite → confirma. Sem abrir outro app, sem lembrar de fazer depois, sem risco de esquecer.
✍️ Alçadas de assinatura decididas na base da consulta manual
A delegação de competência define quem assina cada proposta ou contrato conforme o valor: gerente executivo, superintendente, diretor ou presidente. Esse enquadramento muda com o tempo e hoje depende do vendedor consultar o normativo na Conexão e preencher o documento na mão. Existe um double check informal de quem recebe para assinar, mas não há validação sistêmica. Colocar a alçada errada para baixo gera risco de compliance.
Exemplo real
"Tô com uma proposta comercial de R$ 2 milhões para assinar. Para quem eu preciso direcionar? Para não perder esse tempo, a gente vai ali no Slack, faz essa consulta, ele já responde." Um agente com acesso ao normativo elimina a dúvida e o retrabalho de alçada.
🎫 Fila de chamados que cresce mais rápido que o time consegue absorver
O Pronto opera com uma fila de 13.000 a 14.000 chamados só do maior cliente (INSS), e o volume total combinando clientes e demandas internas chega a algo próximo de 30.000 por mês. Hoje 80% são resolvidos pelo N1 e 20% escalam para o N2. Para zerar a fila, a Dataprev está celebrando um contrato de central de atendimento que pode levar o time de cerca de 40 atendentes de N1 para mais de mil pontos de atendimento. Escalar pessoas é caro e lento. Escalar autoatendimento e triagem inteligente é o caminho sustentável.
Síntese do diagnóstico
🔍 Padrão comum por trás de todas as dores
As quatro dores parecem diferentes na superfície, mas têm a mesma raiz:
A solução não é contratar mais pessoas
Seria necessário "ter várias Dataprevis" para manter o modelo atual com 5.000 clientes, o que não é viável nem desejável. A solução é tornar a informação autosservível e a operação rotineira invisível, liberando o time humano para o que realmente precisa de julgamento e relacionamento.
O canal importa tanto quanto o agente
A visão original da Dataprev usava WhatsApp como canal principal. Essa decisão foi pivotada para Slack, com Pedro e Maik alinhados à mudança. Aqui está o porquê técnico e estratégico dessa escolha.
🔄 O momento da pivotagem
A mudança de WhatsApp para Slack não foi imposta, emergiu naturalmente da conversa, com adesão imediata dos dois lados da Dataprev:
"A gente tá fazendo um projeto para o Serviço na Ponta levando para o Slack, que é uma interface inteligente, orquestra workflows, tem integrações com toda a Salesforce e com sistemas externos. Seria minha primeira indicação de arquitetura: que o canal principal fosse o Slack."
"Se for Slack, OK, zero bronca. Falei do WhatsApp porque já tá no contexto, mas sem problema. O Saulo inclusive já mencionou o Slack ontem."
"Vou te colocar no checkpoint de quarta-feira, Maik, para você ver a evolução de um dos fluxos que a gente tá desenvolvendo no Slack, para tangibilizar como a coisa tá sendo construída."
Alinhamento em tempo real
A pivotagem aconteceu dentro da própria reunião, sem resistência. Saulo (Superintendente) já havia mencionado Slack como direção antes mesmo do encontro, o que reforça que a decisão tem respaldo executivo.
Comparativo técnico e estratégico
⚖️ WhatsApp vs. Slack, para relacionamento B2B institucional
| Dimensão | Slack | |
|---|---|---|
| Perfil do canal | B2C, pessoal, informal | B2B, corporativo, institucional |
| Autenticação | LDAP custom, alto risco, eng. complexa | SAML / SSO nativo, zero código extra |
| Interface com o usuário | Texto puro, limitado | Block Kit: cards, forms, tabelas, botões |
| Multi-usuário por cliente | Não, um número = uma pessoa | Canais por órgão, múltiplos usuários |
| Histórico e contexto | Frágil, por número, sem contexto | Persistente por canal, contexto total |
| Integração com Salesforce | Middleware adicional obrigatório | Nativa, sem camada extra |
| Workflows e automações | Não suportado nativamente | Workflow Builder nativo |
| Modelo de custo | Por mensagem, variável e imprevisível | Por licença, previsível e controlado |
| Segurança e compliance | Dados em infra Meta, risco jurídico gov | Enterprise-grade, DLP, auditoria, LGPD |
| Manutenção | Equipe Dataprev mantém orquestrador custom | Plataforma Salesforce, zero dívida técnica |
Problemas específicos do plano original
🚨 Autenticação LDAP via WhatsApp
O item 3 do planejamento da Dataprev era "desenvolver solução de autenticação (LDAP) pelo WhatsApp", sem responsável, sem prazo, marcado como pendente. É o maior risco técnico do plano original:
- Não existe precedente robusto de autenticação corporativa LDAP via WhatsApp
- Superfície de ataque significativa, número de celular como vetor de identidade
- Manutenção contínua de uma solução completamente custom
- Nenhuma garantia de disponibilidade da API WhatsApp Business para esse uso
Slack elimina esse problema
SAML / SSO nativo. O item 3 do planejamento desaparece completamente, sem uma linha de código extra.
🚨 Custo por mensagem escala com os clientes
O item 10 do planejamento era "contratar pacotes de mensagens", sem valor, sem estimativa. Com WhatsApp Business API:
- Cobrança por conversa iniciada, escala diretamente com o volume
- Custo imprevisível: 2.500 clientes fazendo consultas diárias = variável explosiva
- Pacotes precisam ser renovados e monitorados constantemente
- Qualquer crescimento de uso = aumento proporcional de custo
Slack: custo por licença
Previsível, controlado, independente do volume de mensagens trocadas. Cresce com usuários, não com interações.
⚠️ WhatsApp é canal B2C, não B2B institucional
Os clientes da Dataprev são órgãos de governo, ministérios, secretarias estaduais, prefeituras. Esses interlocutores operam em ambiente corporativo, com ferramentas corporativas. Um número de WhatsApp pessoal não é o canal adequado para:
- Consultar dados financeiros de um órgão público
- Receber relatórios de projetos com dados sensíveis
- Abrir demandas formais com registro de auditoria
- Escalar para um atendente humano com contexto completo
⚠️ Orquestrador customizado = dívida técnica permanente
O plano original previa construir um orquestrador do zero (item 9) para coordenar os 4 agentes customizados. Isso significa:
- Engenharia contínua para manter e evoluir o orquestrador
- Equipe interna da Dataprev como responsável pela manutenção
- Risco de desalinhamento entre agentes e plataforma ao longo do tempo
- Nenhuma garantia de que o Agentforce não vai resolver isso nativamente, e vai
O papel do WhatsApp na nova arquitetura
📲 WhatsApp não é descartado, é reposicionado
Não há razão para eliminar completamente o WhatsApp. Ele tem um papel legítimo, desde que seja o correto:
❌ Não usar WhatsApp para:
- Canal principal de autosserviço B2B
- Autenticação de usuários corporativos
- Consultas com dados financeiros sensíveis
- Abertura e gestão de demandas formais
- Relatórios consolidados multi-sistema
- Interações que exigem auditoria ou rastreabilidade
✅ WhatsApp pode ser usado para:
- Notificações outbound simples, "seu chamado foi atualizado"
- Alertas de SLA próximo do vencimento
- Confirmação de protocolo de nova demanda
- Públicos externos sem acesso a Slack corporativo
- Comunicações pontuais de baixo risco
Estratégia de canal híbrida
Slack é o canal primário de interação, autosserviço e orquestração. WhatsApp é o canal secundário de notificação outbound, para avisos rápidos que não exigem autenticação nem resposta. Cada um fazendo o que faz melhor.
📱 Slack no celular, mesma experiência do WhatsApp
Uma preocupação legítima de Pedro durante a reunião era sobre a usabilidade mobile do Slack. A resposta é direta:
"O Slack também, por exemplo, se eu for colocar no meu celular, é um aplicativo que fica ali, é um app normal, igual o WhatsApp. A interface é de mensageria, você clica, responde, conversacional, igualzinho. Até parece bastante a interface do WhatsApp."
Uma plataforma, não quatro sistemas
O design correto coloca o Agentforce como cérebro central, roteando intenções, orquestrando sistemas e entregando respostas no canal onde o usuário já está. Sem orquestrador customizado. Sem agentes construídos do zero. Sem dívida técnica.
Decisão de escopo: integrar, não substituir
Juliana Brites alinhou com Pedro que, num primeiro momento, o projeto automatiza processos e simplifica a experiência integrando os sistemas que já existem. O Pronto e o Clarity permanecem como sistemas de registro. O Slack e o Agentforce entram como uma camada periférica que abre chamados, consulta status, dispara aprovações e consolida informação, usando as integrações nativas e os MCPs para conversar com cada sistema. Substituir plataformas legadas fica como avaliação futura, não como premissa da Fase 1.
"A gente tem que colocar o foco em fazer automações de processo e simplificação, realizando integrações com sistemas que já existem. Eu posso ver a atualização do Pronto no Slack e inclusive posso fazer aprovações pelo Slack, pelos famosos MCPs, que são as integrações entre os sistemas."
Diagrama de arquitetura
🗺️ Fluxo completo, da intenção à resposta
O que o Agentforce substitui no plano original
🔄 Itens 5 a 9 do planejamento, todos resolvidos nativamente
O plano original da Dataprev previa construir cinco componentes do zero, todos atribuídos à Salesforce como responsável, todos sem prazo definido. O Agentforce entrega esses componentes nativamente, sem desenvolvimento customizado:
Resultado: 5 itens eliminados do backlog de desenvolvimento
Nenhum orquestrador a construir. Nenhum agente customizado a manter. O esforço de engenharia se concentra nas integrações MuleSoft com os sistemas legados, que é onde o valor real está e onde nenhuma plataforma consegue eliminar o trabalho por você.
O loop humano, onde o agente para
🤖 O agente resolve sozinho quando:
- A pergunta tem resposta objetiva em um dos sistemas integrados
- O usuário está autenticado e tem permissão de acesso
- A ação é de leitura, consulta, relatório, status
- Existe conteúdo publicado no Conexão cobrindo o tema
- A intenção é mapeada como um Topic configurado
👤 Escalada para humano quando:
- A demanda exige julgamento ou negociação
- Envolve dados altamente sensíveis sem permissão automática
- O agente não reconhece a intenção com confiança suficiente
- O cliente solicita explicitamente falar com alguém
- Ações de escrita com alto impacto (aprovações, cancelamentos)
Dois públicos, uma plataforma
O escopo não se limita ao cliente externo. Pedro deixou claro: "quando eu falar cliente, entendam também os empregados da Dataprev." A mesma infraestrutura serve os dois públicos, com jornadas, permissões e contextos completamente diferentes.
📣 A decisão de escopo
"Isso aqui também repercute pros funcionários da Dataprev. Está no título 'autosserviço para cliente', mas depois a gente vai pensar num nome melhor, porque isso serve tanto para os clientes quanto para os empregados. A gente queria subir o nível de interação com os dois."
Implicação arquitetural importante
Dois públicos na mesma plataforma significa dois perfis de autenticação, dois conjuntos de permissões, dois escopos de dados acessíveis, e potencialmente dois ambientes Slack separados (workspace de cliente vs. workspace interno). O design precisa contemplar isso desde a fase 1.
Perfil de cada público
Quem são
Gestores e técnicos de órgãos públicos que contratam serviços da Dataprev. Interlocutores institucionais, não pessoas físicas. Um único "cliente" pode ter múltiplos usuários de diferentes áreas (financeiro, TI, jurídico).
O que precisam acessar
- Posição financeira, valores devidos, faturas, histórico
- Status de demandas e projetos em andamento
- Chamados técnicos abertos e seus SLAs
- Relatórios consolidados por frente ou eixo
- Contratos e documentos formais
Ambiente Slack
Canal dedicado por órgão/cliente. Múltiplos usuários do mesmo órgão num mesmo canal compartilham contexto. O agente é invocado via mensagem no canal ou DM com o Slackbot.
Quem são
Funcionários da Dataprev de diferentes níveis, do operacional ao executivo. Perfis que hoje navegam entre múltiplos sistemas internos e dependem de pessoas para obter informações que estão à mão nos próprios sistemas.
O que precisam acessar
- Briefings de projetos e frentes em tempo real
- Agendamento inteligente, pessoas, salas, horários
- Informações de RH, políticas, benefícios, normas
- Comunicados e notícias internas (Conexão/intranet)
- Status de backlogs e releases (ALM)
Ambiente Slack
Workspace corporativo interno. Slackbot disponível em qualquer canal ou DM, inclusive por áudio. Acesso ao calendário, diretório de pessoas e sistemas internos via integrações.
Como cada público interage com a plataforma
🔁 Fluxo de interação, diferenças e semelhanças
| Dimensão | 🏛️ Cliente Externo | 👨💼 Empregado Interno |
|---|---|---|
| Canal de acesso | Canal Slack dedicado ao órgão | Workspace interno + Slackbot |
| Autenticação | SSO via SAML, credencial do órgão | Login corporativo Dataprev |
| Input principal | Texto, perguntas sobre status e financeiro | Texto ou voz, comandos rápidos |
| Dados acessíveis | Apenas dados do próprio órgão/contrato | Dados de acordo com perfil e cargo |
| Tipo de interação | Consulta + abertura de demandas + relatórios | Consulta + ações operacionais + briefings |
| Escalada humana | Time de relacionamento comercial (DERC) | RH, TI ou gestor direto |
| Notificações proativas | Alertas de SLA, atualização de chamados, vencimentos | Confirmação de agendamentos, comunicados internos |
Casos reais de uso
🏛️ Casos, Cliente Externo
"Quanto que tá a dívida com a Dataprev? Tá aumentando?", pergunta diária de diretores financeiros de órgãos. O agente consulta o Protheus e retorna a posição atualizada no canal do órgão.
"Como está o andamento do chamado XPTO?", sem precisar ligar para o time comercial. O agente consulta Pronto! Cliente e retorna status, SLA restante e responsável.
"Estruture um relatório de pendências com a Dataprev separado por eixos.", o agente orquestra chamadas em Clarity + CRM + Protheus e entrega o consolidado formatado no canal.
👨💼 Casos, Empregado Interno
Executivo convocado para reunião no ministério sem tempo de preparar briefing. No caminho, pergunta: "Como está o projeto X?", o agente compila CRM e Clarity e entrega o resumo antes de ele chegar.
Pedro no carro: "Agenda uma reunião com o Saulo e o Maik para terça." O Slackbot acessa os calendários, encontra janela disponível, cria o convite e confirma, sem abrir nenhum outro app.
"Quantos dias de licença-paternidade eu tenho?", o agente lê a base de conhecimento da Conexão (intranet) e responde instantaneamente, sem acionar ninguém do RH.
Separação de dados e permissões
🔒 Um agente, dois escopos de acesso
A mesma engine Agentforce serve os dois públicos, mas com guardrails completamente distintos. O contexto de quem pergunta determina o que o agente pode acessar e responder:
- Dados financeiros do próprio órgão ✓
- Chamados abertos pelo próprio órgão ✓
- Demandas vinculadas ao contrato ✓
- Dados financeiros de outros órgãos ✗
- Dados internos da Dataprev ✗
- Backlogs e roadmap de produto ✗
- Dados de projetos conforme perfil ✓
- Agenda corporativa e diretório ✓
- Base de conhecimento interna ✓
- Dados financeiros de clientes (via CRM) ⚠ perfil
- Dados pessoais de outros empregados ✗
- Dados de contratos sem vínculo direto ✗
- Perfis e permissões no Salesforce (OWD + Sharing Rules)
- Topics configurados por público, o agente só vê o que o usuário pode
- Autenticação SAML garante identidade antes de qualquer consulta
- MuleSoft propaga o contexto de permissão para os sistemas legados
Decisão de discovery crítica
O mapeamento exato de permissões por sistema (Protheus, Clarity, SEI!) precisa ser feito no workshop com as equipes responsáveis de cada ferramenta. Não é decisão que cabe à Salesforce sozinha, é uma conversa de governança de dados da Dataprev.
A mesma plataforma, três formas de conversar
A liderança da Dataprev convergiu na ideia e pediu uma coisa objetiva: uma demo, uma simulação de como o Slack se comporta e traz informação em três perfis. Funcionário da Dataprev, gestor da Dataprev e cliente. Esta seção é o roteiro dessa simulação: o que cada perfil pergunta, como o agente responde e o que aparece na tela. A construção da demo em si é com o time de SE, este é o storyboard que entregamos a eles.
📣 O que foi pedido, na palavra do Pedro
"Montar uma demo, uma simulação de como isso vai funcionar em três perfis: perfil de funcionário da Dataprev, o que ele consulta e o que retorna; a mesma coisa para os gestores da Dataprev; e uma visão cliente. Três visões de como o Slack vai se comportar e trazer essas informações."
Objetivo da demo: tornar o abstrato tangível
A liderança já comprou a ideia. A demo não é para convencer da tecnologia, é para a alta gestão enxergar, na prática, a experiência de cada perfil antes de aprovar o investimento. O entregável é uma simulação navegável (vídeo ou protótipo Slack), construída com o time de SE. Aqui está o roteiro que orienta essa construção.
Simulação interativa · escolha o perfil e toque nas perguntas
Mockup ilustrativo, não é a POC
Esta simulação existe só para dar uma ideia tangível da experiência nos três perfis, com dados fictícios. Ela não substitui a prova de conceito nem a demo oficial construída pelo time de SE da Salesforce, que valida a integração real com os sistemas da Dataprev.
Como a demo será construída
🛠️ Divisão de responsabilidades
Entrega o roteiro: os três perfis, as perguntas âncora, o comportamento esperado do agente e o que aparece na tela. É a fonte para o time de SE reproduzir com fidelidade.
Monta a simulação navegável no Slack ou em vídeo, com dados fictícios realistas. Apoio articulado com o Jackson, conforme combinado no Slack.
Fictícios, mas plausíveis. Nenhum dado real de cliente ou de empregado é usado na simulação apresentada à liderança.
Ponto de atenção
A demo mostra a experiência, não a integração real. Os três perfis reforçam a mesma mensagem de arquitetura da seção anterior: um agente, escopos de acesso distintos por perfil. O que muda entre as telas é sempre o contexto de quem pergunta e o que ele pode ver.
Do conceito à primeira entrega
Jornadas priorizadas por valor de negócio, complexidade técnica e velocidade de aprovação. Quick wins entregam resultado visível rápido, fundamentais para o novo diretor e para o patrocínio executivo. As fases seguintes ampliam cobertura progressivamente.
Fase 1, Quick Wins
- Apenas leitura, sem escrita no Protheus
- Alta frequência de uso, demanda diária
- Impacto imediato e visível para clientes e gestores
- API de leitura do Protheus disponível ou mapeável
- Permissão de consulta por ID de contrato/órgão
- Autenticação SAML configurada no Slack
Bônus: notificação proativa de atualização
Quando o chamado muda de status no Pronto!, a camada de integração dispara automaticamente uma mensagem no canal do órgão no Slack, sem o cliente precisar perguntar. Mesmo esforço de integração, valor muito maior.
"O Maik foi convocado para ir ao ministério. Não tem tempo de ponto de controle. No caminho pergunta: 'Como está o projeto X?', o agente compila do CRM, manda no Slack. Ele chega na reunião pautado, já resolve, não precisa voltar depois para formalizar resposta."
"O chefe falou: 'Pedro, marca uma agenda para amanhã com essas pessoas.' Fui para casa, o caminho todo: 'Não esquece, não esquece, não esquece.' Se tivesse o Slack, eu mandava um audiozinho: 'Agenda uma reunião com essas pessoas.' Chego em casa tranquilo."
- Usuário envia áudio ou texto para o Slackbot
- Slackbot extrai participantes, data/horário desejado
- Consulta disponibilidade nos calendários via integração
- Sugere janela, usuário confirma com um clique
- Cria convite e envia para todos os participantes
- Integração Slack ↔ calendário corporativo (Teams ou Google)
- Diretório de usuários acessível via API
- Permissão de criação de eventos nos calendários dos participantes
- Conteúdo aberto a todos os colaboradores, sem regra de permissão complexa
- Só leitura: o Conexão segue como fonte de verdade e mantém o processo atual de atualização dos artigos
- Alta frequência, desonera o time de Pessoas das perguntas repetitivas
- Confirmar se o Conexão expõe API ou busca. Se sim, uma Action consulta direto em tempo real
- Se for só portal de páginas, usar crawler mais um índice de leitura (índice de busca no Data Cloud, escopado, ou serviço de busca externo via MCP)
- Sempre leitura de mão única, sem migrar para o Knowledge e sem Service Cloud na Fase 1
🔍 Como o agente lê o Conexão: caminhos técnicos
O Conexão aparenta ser um portal só de páginas, acessado pela intranet, com conteúdo aberto a todos os colaboradores. Isso levanta a pergunta de como o agente recupera esse conteúdo. Em qualquer caminho abaixo, três pontos não mudam: o Conexão continua sendo a fonte de verdade, a leitura é sempre de mão única e a curadoria dos artigos segue no processo atual. O que varia é apenas como o conteúdo chega até o agente.
Se o Conexão expõe uma API ou um endpoint de busca, uma Action do Agentforce consulta em tempo real. Não há cópia de conteúdo em lugar nenhum, e a resposta reflete sempre a versão publicada naquele momento.
Mais limpo, sempre atualizado e com menor esforço de manutenção. Depende de a API existir e estar documentada, a mesma pergunta aberta que temos para Protheus, Clarity e Pronto!.
Cenário provável hoje, já que o portal aparenta ser só de páginas. Um crawler percorre as páginas em uma cadência definida, extrai o texto limpo do artigo e alimenta um índice de busca que o agente consulta. O crawler é sempre de leitura: o conteúdo continua sendo escrito e atualizado no Conexão.
- Índice de busca no Data Cloud, escopado: caminho nativo Salesforce, com conector para indexar conteúdo web e busca semântica. Usado só como índice desta fonte, não é o Data Cloud "360 preditivo" da Fase 3.
- Busca ou RAG externo via MCP: um índice fora do Salesforce, consultado pelo agente via MCP. Faz sentido se a Dataprev preferir manter a busca no próprio ambiente ou reaproveitar infraestrutura que já tenha.
O que confirmar no discovery
Quatro pontos definem o caminho: se o Conexão tem API ou busca; a frequência de atualização que o índice precisa acompanhar, já que os atos normativos mudam semanalmente; a qualidade da extração do texto, porque página de intranet vem com menu e ruído de layout; e a credencial de serviço para leitura autorizada via intranet. Nenhum dos caminhos exige Service Cloud nem migrar o conteúdo para o Knowledge.
- Ganho imediato sobre produto que a Dataprev já opera
- A nova versão do SEI automatiza assinatura e validação
- Levantamento de tecnologia e integração já feito pelo time do Alírio
- Esforço contido: estimativa de 200 a 300 horas
- SEI! na nova versão, com assinatura eletrônica habilitada
- API ou MCP de assinatura/validação disponível ou mapeável
- Permissões por perfil e vínculo com o usuário Dataprev
- Trilha de auditoria da ação de escrita registrada
Por que Fernanda priorizou o SEI
Jornada não considerada no escopo inicial, mas de valor absurdo na leitura de Fernanda: a Dataprev já presta serviço com SEI e a nova versão traz automatização de assinatura e validação. É um addon que a Dataprev pode disponibilizar ao cliente como eixo ou serviço, ajudando a diluir o próprio investimento. Validar o detalhe com a Dataprev e incluir na proposta com estimativa de horas e valor.
Fase 2, Expansão com transação
Cliente solicita abertura de demanda via Slack. Agentforce exibe formulário inline (Block Kit), coleta dados, cria a demanda diretamente no Clarity e retorna o protocolo no canal.
O Clarity permanece como sistema de registro ou é substituído? A resposta define se a integração é bidirecional ou se o Salesforce passa a ser o sistema de origem da demanda.
"Estruture um relatório de pendências da Dataprev separado por eixos.", Agentforce orquestra chamadas paralelas nos três sistemas, consolida e entrega o relatório formatado no canal, podendo exportar para PDF ou Google Doc.
Orquestração paralela de múltiplos sistemas pelo Agentforce, o cliente recebe uma visão unificada que hoje exige horas de trabalho manual de alguém do time comercial.
"Quantas demandas foram entregues em 2026?", consulta ao ALM via MuleSoft retorna métricas de entrega por frente, período e status. Relevante tanto para clientes que acompanham entregas quanto para o time interno de produto.
Depende da maturidade da API do ALM. A ser avaliado no discovery, pode ser integração simples de leitura ou exigir transformação de dados mais elaborada.
Fase 3, Proativo e preditivo
Agentforce, apoiado pela camada de integração, monitora os SLAs próximos do vencimento nos sistemas atuais. Antes de estourar, o canal do órgão recebe alerta automático com status, responsável e ação necessária, sem o cliente precisar perguntar.
Data Cloud unifica o histórico de todos os sistemas em um perfil único de cliente. O agente passa a responder com contexto histórico completo, tendências de inadimplência, padrões de demanda, saúde do relacionamento, não apenas dados pontuais.
Matriz de priorização
🎯 Matriz de priorização · Impacto × Esforço
As jornadas plotadas por impacto para o negócio e o cliente (eixo vertical) e esforço de implementação (eixo horizontal), no estilo de um quadrante de decisão. Cada bolha é uma jornada, a cor indica a fase e o dourado destaca o SEI, a jornada de alto valor levantada por Fernanda que ainda não estava no escopo inicial. Serve de base para a diretoria mover as apostas conforme impacto, retorno e tempo.
Quick WinsAlto impacto · baixo esforço · fazer primeiro
Apostas EstratégicasAlto impacto · alto esforço · núcleo
IncrementaisImpacto médio · baixo esforço
Fase 2 / DependentesDependem de base pronta ou escritaLeitura da matriz
O canto de quick wins concentra as jornadas de leitura com maior volumetria: J2 (240 mil chamados, 170 mil usuários) e J1, mais o FAQ da Conexão (300 mil visualizações mensais). O SEI entra como aposta de alto impacto e esforço contido (estimativa de 200 a 300 horas sobre produto já existente), o que o torna candidato natural a antecipar. As apostas estratégicas (J6 e J10) têm alto impacto mas dependem de integração mais profunda e base organizada, então seguem para as fases seguintes.
Visão geral do roadmap
🗓️ Priorização consolidada
| Jornada | Público | Sistemas | Complexidade | Fase |
|---|---|---|---|---|
| J1 · Consulta Financeira | 🏛️ Externo | Protheus | Baixa | F1 |
| J2 · Status de Chamado | 🏛️ Externo | Pronto! Cliente | Baixa | F1 |
| J3 · Briefing de Projeto | 👨💼 Interno | CRM + Clarity | Baixa | F1 |
| J4 · Agendamento por Voz | 👨💼 Interno | Agenda Corporativa | Média | F2 |
| J5 · Abertura de Demanda | 🏛️ Externo | Clarity | Média | F2 |
| J6 · Relatório Multi-sistema | 🏛️ Externo | CRM + Clarity + Protheus | Alta | F2 |
| J7 · FAQ Interno via Conexão | 👨💼 Interno | Conexão (leitura) | Baixa | F1 |
| ⭐ SEI · Assinatura e Validação | Ambos | SEI! (nova versão) | Média | Nova · F1 |
| J8 · Status de Backlog | Ambos | ALM | A avaliar | F2 |
| J9 · Alertas Proativos de SLA | 🏛️ Externo | Pronto! / Clarity | Média | F3 |
| J10 · Visão 360° Data Cloud | Ambos | Data Cloud + todos | Alta | F3 |
Os sistemas por dentro, com número e escopo
O mapeamento percorreu a mandala de sistemas da Dataprev sistema por sistema. Aqui está o que cada plataforma faz, o volume que movimenta e a decisão de escopo para a Fase 1. A leitura fria: o valor de curto prazo está em dar mais um caminho para o que já existe, não em reconstruir o que já funciona.
WhatsApp saiu da mandala, entrou o conceito de canal
Pedro concordou em remover o WhatsApp da mandala e trabalhar com a ideia de canal, adotando o Slack como plataforma de comunicação. A substituição já está refletida no desenho: onde antes se lia WhatsApp, agora se lê canal, com o Slack no centro da interação interna e externa.
Volumetrias enviadas pelo cliente
Os números que a Dataprev confirmou
A Dataprev enviou as volumetrias de acesso e uso dos sistemas que estavam pendentes. Os dados dão escala real a cada caso de uso e reforçam a priorização: os maiores volumes estão em Pronto! e Conexão, exatamente os quick wins de leitura da Fase 1, enquanto o CRM tem poucos usuários mas alto valor estratégico.
| Sistema / canal | Volumetria informada | Caso de uso relacionado |
|---|---|---|
| Pronto! Cliente | +240 mil chamados · 170 mil usuários | J2, status de chamado |
| Conexão (intranet) | +3.500 usuários · 300 mil visualizações/mês | J7, FAQ interno |
| Microsoft Teams | +3.500 usuários por dia | J4, agendamento inteligente |
| CRM (Totvs) | 50 usuários · 60 oportunidades cadastradas | J3, briefing executivo |
| Clarity | Volumetria não informada nesta rodada | J3 e consulta de demandas |
O detalhamento por menu mostra onde o autoatendimento tem mais tração e ajuda a definir quais artigos o FAQ interno (J7) deve cobrir primeiro. Serviços e Comunicação concentram a maior parte das visualizações.
O que a volumetria diz sobre a priorização
Os números confirmam a leitura já feita: o valor de curto prazo está em dar mais um caminho para o que já tem alto volume. Pronto! (240 mil chamados, 170 mil usuários) e Conexão (300 mil visualizações mensais) sustentam os quick wins de leitura J2 e J7, com público amplo e impacto visível cedo. O CRM tem só 50 usuários e 60 oportunidades, volume baixo mas de altíssimo valor estratégico, o que reforça a decisão de trazê-lo logo após os quick wins, condicionado à organização prévia da base. O Teams, com 3.500 usuários diários, dá massa crítica ao agendamento (J4) quando a escrita em calendário entrar na Fase 2.
Os cinco sistemas da mandala
Ferramenta central de comunicação e agenda do dia a dia. Login pelo AD da Microsoft, acesso via app ou web. O caso de uso levantado é o agendamento: montar uma janela entre pessoas, com o Slack integrado ao Teams para criar a reunião, comunicar os participantes e refletir na agenda de todos.
Integração de agenda. O Slack aciona o Teams via integração para agendamento inteligente (jornada J4). Nenhuma substituição prevista.
O portal interno da Dataprev, antes chamado DTPNET e redesenhado como Conexão há cerca de cinco ou seis anos. Concentra notícias, mudanças de estrutura, atos normativos semanais, normas de pessoas, delegação de competência, contatos, aniversariantes e o plano estratégico. É totalmente consultivo: não executa transações, apenas direciona para outros portais quando alguma ação é necessária. A volumetria enviada confirma a escala: mais de 3.500 usuários e uma média de 300 mil visualizações mensais, concentradas em Serviços e Comunicação.
Autoatendimento via Slack para consultas administrativas (licença, férias, abonos, normas, quem assina o quê), desonerando o time de Pessoas. A informação vai até o empregado no canal que ele já usa.
Consumo de leitura na Fase 1 (quick win J7). A curadoria e a atualização dos artigos continuam no Conexão, que segue como fonte de verdade. A definir no discovery: consulta via API ou busca, se existir, ou crawler mais índice de leitura. Não migra para o Knowledge nem exige Service Cloud na F1.
Plataforma de abertura de chamados técnicos e de serviços, com base em ServiceNow. Tem login de cliente e login interno na mesma solução. O catálogo de serviços é estruturado por cliente: cada contrato celebrado já inclui, como cláusula, o acesso à plataforma de chamados, e cada serviço do contrato é replicado no Pronto. A triagem inicial é do N1, que lê, categoriza e resolve, escalando ao N2 (time de produto) quando exige intervenção no sistema.
O departamento de atendimento já está implementando bases de conhecimento com agentes de IA para resolver os chamados mais padronizados. Há convergência direta com a proposta.
Mantido. O Slack vira mais um caminho até o Pronto: consulta de status, quantidade de chamados abertos e abertura assistida via integração. A tratativa do chamado continua no Pronto.
Plataforma de gestão de demandas e evoluções de sistemas. É de onde nascem os novos sistemas e as correções. O cliente registra uma ideia, que passa por aprovação nas instâncias superiores dele, chega à Dataprev e vira proposta de atendimento (especificação, prazo e custo). Aprovada, a demanda é executada, homologada e encerrada. No fim, integra com a solução Totvs para o faturamento. Também aceita demandas internas, como a extração de dados que Pedro abriu para uma ação intermediada pela Casa Civil.
Mantido, mesma estratégia do Pronto. O Slack consulta quantas demandas existem, quais exigem aprovação, quantas foram canceladas no mês e quanto foi gasto no ano em evolutivas. Camada periférica sobre o Clarity.
A visão macro de pipeline e contratos, focada no time comercial, com cerca de 50 usuários ativos. Diferente do Clarity, que olha demanda a demanda, o CRM olha o contrato inteiro. No exemplo do INSS: no CRM aparecem dois contratos totalizando valor de teto por cinco anos, enquanto no Clarity há milhares de demandas executadas por baixo desse mesmo teto. Como os contratos tendem a não ter mais ponto de função, muitas demandas não geram custo adicional, já estão dentro do serviço contratado.
Marcos Alirio, que ajudou a gerir o projeto de CRM, e Pedro apontam o CRM como a frente de maior valor: o executivo convocado consulta o Slackbot e chega pautado na reunião com ministério ou Casa Civil, sem passar número ou status errado.
Maior valor, mas os dados ainda não estão bem estruturados. Recebe peso alto na priorização, porém depende de organização prévia da base. Entra logo após os quick wins de leitura.
Decisão de escopo por sistema
🎯 O que fica, o que integra, o que se consome
| Sistema | Base / fornecedor | Papel na Fase 1 | Substitui? |
|---|---|---|---|
| Microsoft Teams | Microsoft | Integração de agenda para agendamento | Não |
| Conexão | Intranet própria | Consumo de leitura para FAQ (Fase 1) | Não |
| Pronto! Cliente | ServiceNow | Consulta de status e abertura assistida | Não |
| Clarity | Broadcom | Consulta de demandas e aprovações | Não |
| CRM | Totvs | Briefing estratégico via Slackbot | Não |
Implicação para a proposta
Nenhuma substituição na Fase 1 significa que o esforço técnico se concentra em integração, via MCPs e APIs, e não em migração de dados ou reescrita de processos. Isso reduz risco, encurta o time to value e cria menos atrito com as áreas donas de cada sistema. A pergunta crítica de discovery passa a ser a maturidade das APIs de Pronto, Clarity e do CRM.
Métricas para provar valor
📐 KPIs a acompanhar
Nelson trouxe a pergunta certa cedo: qual métrica prova o sucesso da automação. A resposta orienta a priorização, porque um caso de uso simples só vira prioridade se mexer em um indicador que a diretoria enxerga. Estes são os KPIs candidatos:
KPI principal para consumo de informação. Existe um baseline provável da transição DTPNET para Conexão, que pode servir de comparativo com a experiência pós Slackbot.
Menos ligações, e-mails e chamados diretos ao time de Pessoas e ao comercial para perguntas repetitivas. Reduzir de X para Y os acionamentos manuais.
Incidência de aprovações fora da alçada correta, que expõe risco de compliance. Meta de reduzir a zero com a consulta assistida ao normativo.
Referência de mercado: o Slack economiza cerca de 97 minutos por pessoa por dia. Traduzir isso em horas devolvidas ao time interno.
Volumetrias recebidas (Dataprev)
As volumetrias que estavam pendentes chegaram e já estão refletidas na análise: acesso do portal Conexão (3.500 usuários e 300 mil visualizações mensais, com detalhamento por menu), volume do Pronto (240 mil chamados e 170 mil usuários), uso do CRM (50 usuários e 60 oportunidades) e do Teams (3.500 usuários diários). O painel de volumetrias no início desta seção consolida os números e liga cada um ao caso de uso correspondente. Fica pendente apenas a volumetria do Clarity, que não veio nesta rodada.
O processo administrativo vem até o servidor
O SEI concentra a tramitação de documentos e processos de mais de 200 órgãos federais, mas não avisa ninguém quando algo muda: o servidor precisa entrar, procurar e conferir. Levar prazos, andamentos e assinaturas para o Slack, com o Agentforce interpretando linguagem natural, elimina a verificação manual e ataca a maior dor do sistema, que é a perda de prazo por falta de aviso. Esta é a frente SEI do Data Ágil, agora priorizada.
🔎 De onde veio e por que entra agora
O aprofundamento do SEI veio do Nelson, depois do contato com o time de SE do Jackson, responsável pela venda de Slack, que tinha mais informação sobre o sistema. A superfície de integração está ancorada no código-fonte oficial do módulo pengovbr/mod-wssei. Como o SEI é um serviço que a Dataprev já oferece a órgãos públicos, e o Pedro pediu para explicar a jornada SEI que já roda na Prodesp para replicar aqui, esta frente casa com a lógica de produtização do projeto: cada jornada vira um produto que a Dataprev revende e embute em contratos.
SEI incorporado ao escopo: 10 das 15 jornadas da ROM
Na versão da ROM compartilhada com o cliente, o SEI deixou de ser tratado como expansão à parte e entrou no escopo principal: das 15 jornadas, 10 são do SEI (SEI-J1 a SEI-J10), distribuídas nas 3 ondas e já dentro do teto de R$ 5 milhões. As jornadas de leitura e alerta ficam nas Ondas 1 e 2; as de escrita e governança (ciência, tramitação, abertura) ficam na Onda 3, após a Fase 0 (bloqueador G1002). O caminho técnico ainda depende de confirmar a superfície de integração publicada na instância-alvo (G1101) e coletar a volumetria de base (G1102) para dimensionar o polling.
A realidade de integração do SEI
mod-wssei v2, código-fonte oficial pengovbrA restrição que molda toda a arquitetura: o SEI não empurra eventos
Não existe webhook nem serviço de notificação ativo no SEI. Toda jornada proativa (alerta de prazo, aviso de tramitação) depende de a camada de integração consultar o SEI em intervalos regulares (polling) e detectar a mudança comparando com o estado anterior. É totalmente viável com os endpoints de leitura, mas define o desenho técnico (agendador mais cache de estado no MuleSoft ou MCP) e precisa ser dimensionado com a volumetria de base (G1102) das 10 jornadas SEI já incluídas no escopo.
Duas superfícies para conectar
Contrato historicamente exposto pelo Web Service do SEI (consultar processo, incluir documento, enviar, atribuir, bloco de assinatura). Serve de alternativa para instâncias que ainda não publicaram o módulo REST. A confirmar qual superfície está publicada na instância-alvo.
mod-wssei v2, recomendadoSuperfície mapeada do código-fonte oficial (MdWsSeiServicosV2.php). Cobre consulta e acompanhamento (base das jornadas de leitura e polling), catálogo de tipos, blocos de assinatura e ações de escrita. Caminho primário recomendado pela riqueza e pela autenticação por token.
Regra de proteção de dados: só metadados no Slack
Processos administrativos contêm dados pessoais e, muitas vezes, informação restrita. O Slack recebe apenas metadados (número do processo, status, prazo, unidade, tipo) e um deep-link de volta ao SEI para leitura do conteúdo e para qualquer ação. Conteúdo de documento não trafega para o Slack. Isso mantém a conformidade com a LGPD e preserva a trilha de auditoria no sistema de origem.
Dez jornadas SEI em três ondas
🏁 Fila priorizada por coeficiente de ganho (Valor ÷ Esforço)
| # | Jornada | Tipo | Coef. | Onda |
|---|---|---|---|---|
| 1 | SEI-J1 · Alerta de prazo e cumprimento tácito | Proativo · leitura + polling | 2,50 | 1 |
| 2 | SEI-J2 · Consulta por linguagem natural | Reativo · leitura | 2,33 | 1 |
| 3 | SEI-J3 · Notificação de processo recebido | Proativo · leitura + polling | 2,00 | 1 |
| 4 | SEI-J4 · Meu painel de processos no Slack | Reativo · leitura | 2,00 | 1 |
| 5 | SEI-J5 · Digest de unidade para gestores | Proativo · leitura + polling | 1,75 | 2 |
| 6 | SEI-J6 · "Qual tipo eu uso?" + manuais (RAG) | Reativo · leitura + RAG | 1,67 | 2 |
| 7 | SEI-J7 · Status de assinatura + deep-link | Híbrido · leitura + deep-link | 1,33 | 2 |
| 8 | SEI-J8 · Ciência de documento via Slack | Escrita · governança | 1,00 | 3 |
| 9 | SEI-J9 · Tramitar processo via aprovação | Escrita sensível · governança | 0,75 | 3 |
| 10 | SEI-J10 · Abrir processo a partir do Slack | Escrita · governança | 0,63 | 3 |
As notas de Valor e Esforço são uma priorização relativa proposta pela equipe PS para ordenar a fila, na lógica de WSJF ou RICE simplificada. Não são horas nem preço. Corte: coef. ≥ 2,0 vai para a Onda 1; entre 1,3 e 2,0, Onda 2; abaixo de 1,3, Onda 3. Volumetria e taxa histórica de perda de prazo são as variáveis que mais deslocam o ranking.
Como o coeficiente é calculado
Coeficiente de Ganho igual a Valor dividido por Esforço. Cada jornada recebe uma nota de Valor (1 a 10), que pondera risco evitado (perda de prazo, jurídico, financeiro, com peso duplo), frequência de uso, alcance e visibilidade executiva; e uma nota de Esforço (1 a 10), que pondera leitura contra escrita (escrita puxa muito), número de endpoints, governança e LGPD, e a infraestrutura de polling. A razão ordena a fila: quanto maior, mais cedo entrega retorno por unidade de trabalho.
💬 Exemplo no Slack, a jornada de maior valor (SEI-J1)
Ilustração da experiência, não é compromisso de escopo ou prazo. Todo conteúdo sensível permanece no SEI, o Slack carrega só metadados mais o link de volta.
Dá para metrificar o ganho? Sim, com dados de base
O ganho é quantificável por fórmula, mas depende da volumetria da Dataprev
Cada jornada de topo tem uma fórmula de valor objetiva. O que falta hoje são os números de base (quantos processos, quantas perdas de prazo, quanto tempo por consulta). Sem eles, entregamos a fórmula mais os insumos a coletar, nunca um retorno fechado sem dado que o sustente.
Ganho R$/ano = Nº proc./mês com prazo × Taxa de perda evitada (%) × Custo médio por perda × 12- Nº de processos com prazo por mês, por órgão
- Taxa histórica de perda de prazo (%)
- Custo médio da perda (retrabalho mais risco jurídico)
Ganho h/ano = Consultas manuais/dia × Min. por consulta ÷ 60 × Dias úteis × Nº servidores- Consultas manuais ao SEI por servidor, por dia
- Tempo médio de uma consulta manual (min)
- Nº de servidores usuários do canal
Para atacar o SEI, o que precisa acontecer
🎯 Três movimentos, nesta ordem
Qual superfície está publicada na instância-alvo da Dataprev, REST mod-wssei ou apenas o SOAP. Define o caminho técnico e o esforço.
A volumetria de base (processos por mês, taxa de perda de prazo, consultas por servidor) que alimenta as fórmulas de ganho e o dimensionamento do polling.
Refinar a estimativa das 10 jornadas SEI, já dentro do escopo das 15 e do teto de R$ 5 milhões na ROM, e confirmar o modelo, replicando o que já roda na Prodesp.
Onde a Onda 1 começa
As quatro jornadas da Onda 1 (alerta de prazo, consulta por linguagem natural, notificação de recebimento e painel de processos) são só de leitura, com coeficiente igual ou acima de 2,0. Compartilham a mesma infraestrutura de polling, então entregam o maior retorno pelo menor esforço e são o ponto de partida natural da frente SEI, sem nenhuma escrita no sistema de origem.
Cada produto com um papel claro
Nenhum produto por status, cada cloud está aqui porque resolve um problema específico que os outros não resolvem. O stack foi montado pelo mínimo necessário para entregar o máximo de valor em cada fase.
Fase 1, Core obrigatório
O que a Fase 1 realmente exige: camada fina sobre os sistemas atuais
O núcleo da Fase 1 é Slack (canal), Agentforce (orquestração) e a camada de integração (MuleSoft, MCP ou APIs) sobre Protheus, Clarity e Pronto!. Não há migração de dados nem gestão de casos em Salesforce nesta fase: o agente consulta e escreve nos sistemas atuais em tempo real, e a escalada humana continua no fluxo de hoje. O Service Cloud deixa de ser pré-requisito e passa a ser decisão de fase futura. Uma observação técnica honesta: o Agentforce roda sobre uma base mínima de plataforma Salesforce para ser provisionado, o que não é o mesmo que implantar o produto Service Cloud.
O cérebro da plataforma. Recebe a intenção do usuário via Slack, decide qual Topic acionar, executa as Actions nos sistemas corretos via MuleSoft e devolve a resposta formatada, tudo sem orquestrador customizado, sem código de roteamento, sem manutenção.
- Topics, domínios de conhecimento
- Actions, chamadas a sistemas externos
- Reasoning Engine, roteamento automático
- Grounding por consulta em tempo real aos sistemas atuais
- Guardrails, limites de escopo por público
- Orquestrador customizado (item 9)
- Agente Clarity customizado (item 5)
- Agente Pronto! customizado (item 6)
- Agente Protheus customizado (item 7)
- Agente CRM customizado (item 8)
- Todas as jornadas F1, F2 e F3
- É a camada de inteligência central
- Sem Agentforce, não há orquestração
O canal de engajamento, onde o usuário está. Não é só mensageria: é a interface, o ponto de autenticação, o entregador de resultados e o acionador de workflows. No celular tem a mesma experiência do WhatsApp, mas com capacidades corporativas incomparáveis.
- Block Kit, cards, forms, botões inline
- Canais por órgão, contexto compartilhado
- Slackbot, comandos por texto e voz
- Workflow Builder, automações sem código
- SSO / SAML, autenticação corporativa nativa
A infraestrutura Slack já está sendo construída para o Serviço na Ponta. Este projeto aproveita o mesmo investimento com escopo diferente, aceleração real de time to value.
- Externo: workspace de clientes institucionais, canais por órgão, SSO governamental
- Interno: workspace corporativo Dataprev, Slackbot, agenda, RH
A camada que conecta o Agentforce aos sistemas legados da Dataprev. Sem MuleSoft, o agente não consegue chegar no Protheus, no Clarity ou no Pronto!, é o ponto onde o esforço real de integração acontece, e também onde mora o maior risco técnico do projeto.
- Clarity, leitura e escrita de demandas
- Protheus, leitura financeira
- Pronto! Cliente, chamados técnicos
- SEI!, documentação eletrônica
- ALM, backlog de produto
- Agenda corporativa (Teams / Google)
- Transformação de dados entre formatos
- Autenticação propagada por sistema
- Rate limiting e retry policies
- Logs de auditoria de todas as consultas
- Isolamento de falha, um sistema down não derruba os outros
A maturidade das APIs dos sistemas legados é desconhecida. Clarity, Protheus e Pronto! precisam ter APIs REST documentadas ou expostas. Esse mapeamento é a primeira tarefa do discovery técnico.
Fases 2 e 3, Expansão progressiva
Não entra na Fase 1. Passa a fazer sentido quando, e se, a Dataprev decidir consolidar em Salesforce a gestão de casos, o 360 do cliente, o controle de SLAs, um console próprio de atendimento humano ou a base de conhecimento (Knowledge). Até lá, esses papéis seguem nos sistemas atuais: casos e chamados no Pronto! e no Clarity, e o FAQ interno atendido direto do Conexão. O valor é entregue pela camada Slack mais Agentforce.
- Gestão de Cases e SLAs em Salesforce
- 360 do cliente institucional
- Console próprio para atendimento humano
- Knowledge Articles (base de FAQ)
- Reporting e dashboards comerciais
- Se a escalada humana deve viver em Salesforce
- Se o relacionamento vira sistema de registro em CRM
- Se SLAs e entitlements forem geridos em Salesforce
- Se a gestão comercial pedir dashboards nativos
Definir quais processos, se algum, deixam os sistemas atuais e passam a ter o Salesforce como origem. É uma decisão de negócio e de dono de sistema, não uma imposição técnica.
Unifica o histórico de todos os sistemas em um perfil único do cliente. Com Data Cloud, o Agentforce passa de reativo (responde o que é perguntado) para preditivo, identifica tendências de inadimplência, padrões de demanda, saúde do relacionamento.
Só faz sentido após F1 e F2 estarem estabilizados e os sistemas integrados via MuleSoft. O valor é proporcional à qualidade e volume de dados já acumulados.
Visão consolidada do stack
📦 Stack completo por fase
| Produto | Papel na solução | Fase | Prioridade |
|---|---|---|---|
| 💬 Slack | Canal de engajamento, SSO, Block Kit, Slackbot, Workflows | F1 | Obrigatório |
| 🧠 Agentforce | Orquestrador nativo de IA (base mínima de plataforma Salesforce), Topics, Actions, Reasoning | F1 | Obrigatório |
| 🔌 MuleSoft / MCP | Integration layer, Clarity, Protheus, Pronto!, SEI!, ALM | F1 | Obrigatório |
| ☁️ Service Cloud | Gestão de casos, 360, SLA e console humano em Salesforce, só se houver decisão de consolidar | F2+ | Condicional |
| 🔮 Data Cloud | Perfil 360° unificado, contexto histórico para o agente | F3 | Estratégico |
Decisão de licenciamento a definir no escopo comercial
O modelo de licenciamento Agentforce (por conversa, por usuário, por capacidade) precisa ser validado com base no volume estimado de interações mensais e no número de usuários ativos. Essa definição é insumo crítico para a proposta comercial que Juliana Brites irá estruturar após o workshop de discovery.
Dependências entre produtos
🔗 Quem depende de quem
Cada camada depende da anterior para funcionar. A ordem de implementação não é arbitrária, é técnica.
Tecnologia é metade. A outra metade é adoção
Juliana Brites foi direta: não adianta definir ferramentas e implementar se não houver um trabalho forte com as pessoas que precisam usar. Change Management deixa de ser acessório e entra como pilar formal do escopo, ao lado da tecnologia e do esforço de implementação.
Os três escopos do projeto
1. Plataforma e ferramentas
Definição do stack: Slack, Agentforce e a camada de integração (MuleSoft/MCP) sobre os sistemas atuais. Service Cloud e Data Cloud ficam como avaliação de fase futura. É o escopo inicial de tecnologia.
2. Esforço de implementação
O trabalho de configurar, integrar e entregar as jornadas. Concentra-se nas integrações com os sistemas legados via MCP e API.
3. Change Management
Capacitação, treinamento e suporte à adoção. A Salesforce tem um time exclusivo para isso, que trabalha junto com a Dataprev na definição dos treinamentos e das pessoas envolvidas.
"Não adianta a gente definir as ferramentas, fazer a implementação e não fazer um trabalho forte com as pessoas que realmente têm que usar. A gente vai incluir esse escopo dentro do nosso serviço, porque ele é super importante."
Cultura de dados como fator de sucesso
📈 O CRM só entrega valor se o dado estiver atualizado
Pedro reconheceu o risco: no dia a dia corrido, a atualização de informações no Clarity e no CRM fica para depois, e o dado desatualizado contamina qualquer análise. O propósito do Data Ágil inclui fomentar a atualização contínua desses dados, porque é isso que faz a informação surtir efeito. O Slackbot vira o incentivo, atualizar por conversa é mais leve que abrir o sistema.
🧪 A experiência de Customer Zero da Salesforce
A Salesforce viveu exatamente essa dor internamente. Quando se tornou Customer Zero e passou a usar o Slackbot para tudo, a adoção do CRM pelo time comercial em campo subiu de forma expressiva. O vendedor relata a reunião por mensagem e o Slackbot direciona para todas as camadas de categorização e processo do CRM, sem fricção. É um caso real de que a interface conversacional destrava adoção.
A Dataprev já está em movimento com IA
🤖 Iniciativas internas de inteligência artificial
O projeto não chega num terreno virgem. A Dataprev já tem iniciativas internas de IA em curso, o que reduz a resistência cultural e cria terreno fértil para a adoção:
Saulo gerou bots, com base em ChatGPT, para validar se a proposta comercial está aderente ao termo de referência e ao contrato. O uso já começa a se espalhar internamente.
A Dataprev criou uma superintendência de IA para fomentar o uso governado de inteligência artificial internamente. Existe patrocínio institucional para a agenda.
Além da Conexão, há provável repositório em SharePoint com documentação extensa. Entender o parque tecnológico inteiro ajuda a desenhar os ganchos de integração.
Licenciamento: o risco que já foi endereçado
🔑 Slack Enterprise+, custo por usuário previsível
Pedro levantou o ponto com cautela justificada: um contrato antigo teve interpretação dúbia de licenciamento e inviabilizou um projeto. A leitura fria da situação atual é favorável, e isso precisa ser dito com clareza na proposta.
- A Dataprev já opera Slack, hoje com 55 usuários licenciados (5 do UNA, 50 de gestão de campanhas)
- Plano da proposta é o Enterprise+, com custo por usuário previsível
- Slackbot e MCP suportados no plano proposto
- Descontos por faixa de volume já definidos: 69,98% (até 7.499), 75% (até 10.000) e 80% (acima de 10.001)
- Adição de usuários é fluida e escala com o faseamento
- Estimativa revisada de Pedro: cerca de 10.000 licenças, considerando 2.500 clientes com 2 a 3 acessos cada
- Confirmar com especialistas os termos exatos antes de iniciar
- Explicar se e quando há custo adicional, para entrar no todo
- Infraestrutura da plataforma tem que suportar a volumetria de acessos prevista
"Cachorro picado por cobra tem medo até de linguiça. A gente teve um problema grande com esse tipo de coisa, então queria saber se estamos falando de algo viável. É nossa obrigação entender a implicação do licenciamento antes de começar o projeto."
Faseamento resolve alçadas e licenciamento ao mesmo tempo
Pedro pediu proposta faseada para facilitar as aprovações internas, e Juliana confirmou. O faseamento também permite dimensionar licenças de forma incremental: começar com o volume de usuários da Fase 1 e escalar conforme cada fase é aprovada, em vez de contratar 10.000 licenças de uma vez.
Investimento, conforme a ROM enviada ao cliente
💵 Números da proposta (ROM Data Ágil v1)
Esta é a versão de números já apresentada à Dataprev no documento ROM Data Ágil v1 (Fernanda Rodrigues, Executiva de Conta). O escopo é de 15 jornadas em 3 ondas (agosto a dezembro de 2026), com teto fixo de serviços de R$ 5,0 milhões e as licenças cotadas à parte, por faixa de usuários.
Declaração não vinculativa
Os valores são estimativas para fins informativos, não baseadas em informação completa. Nem o cliente nem a Salesforce estão vinculados a elas. As estimativas finais serão determinadas na Ordem de Serviço (OS-SOW), após análise mais detalhada das necessidades da Dataprev.
Com impostos (R$ 4,69 mi sem impostos), 6.500 horas, as 15 jornadas contratadas em conjunto.
Enterprise+ por usuário/ano, com desconto de 69,98% a 80% conforme volume. Hoje a Dataprev tem 55 licenças.
3 ondas, com o go-live da Onda 1 (Quick Wins) já no fim de setembro.
Licenciamento Slack Enterprise+
Hoje a Dataprev tem 55 usuários licenciados (5 do UNA e 50 de gestão de campanhas). O desconto cresce por faixa: 1 a 7.499 usuários 69,98%; 7.500 a 10.000 75%; acima de 10.001 80%. Valores por usuário/ano já com impostos (12,15%).
| Plano | Qtde | Desconto | Usuário/ano c/imp | Total anual c/imp |
|---|---|---|---|---|
| Slack Enterprise+ | 100 | 69,98% | R$ 775 | R$ 77.502 |
| Slack Enterprise+ | 7.500 | 75% | R$ 645 | R$ 4.840.637 |
| Slack Enterprise+ | 10.001 | 80% | R$ 516 | R$ 5.163.863 |
Produtos no licenciamento
Slack Enterprise+ (front conversacional, dual-workspace, por usuário/mês). Agentforce Public Sector (agentes especialistas; a Data Library cobre o RAG). MuleSoft Anypoint Titanium (integração mais MCP, suporta o polling do SEI). Data Cloud é condicional, fora do escopo base: o RAG das jornadas J7 e SEI-J6 usa a Data Library do Agentforce, e Data Cloud só entra se a volumetria (G1102) exigir indexação em escala, decisão na Fase 0.
Arquitetura de custo: o que é fixo e o que é consumo
O MuleSoft (Anypoint Titanium) já entra na proposta como plataforma de integração: quando o sistema de destino já expõe MCP, a conexão é direta; quando não expõe, o MuleSoft cria o MCP Server, e aí entra o esforço de professional services (horas dos serviços). O Agentforce, porém, é consumo, não é ilimitado: o Public Sector roda com créditos debitados por ação ou conversa do agente, então o consumo precisa ser modelado com o número real de interações por mês antes da proposta final. O insumo crítico é duplo: o mapa de integrações e a volumetria de conversas agênticas.
Investimento por jornada e por perfil
🧾 As 15 jornadas que compõem os R$ 5 milhões
O escopo consolidado na ROM tem 15 jornadas em 3 ondas, e o SEI entra dentro dele (10 das 15 jornadas são do SEI). Os valores por jornada são referenciais e pressupõem a contratação conjunta das 15, pois consideram o reaproveitamento da mesma equipe entre as ondas. Contratação parcial ou individual altera essa premissa e implica revisão dos valores.
| Onda | Jornada | Tipo | Investimento c/imp* |
|---|---|---|---|
| 1 | J1 · Consulta Financeira | Leitura | R$ 263.158 |
| 1 | J2 · Status de Chamado | Leitura | R$ 263.158 |
| 1 | SEI-J1 · Alerta de Prazo/tácito | Leitura | R$ 350.877 |
| 1 | SEI-J2 · Consulta linguagem natural | Leitura | R$ 350.877 |
| 1 | SEI-J3 · Notif. recebido/tramitado | Leitura | R$ 263.158 |
| 2 | J3 · Briefing de Projeto | Leitura | R$ 263.158 |
| 2 | J7 · FAQ Interno via Conexão | Leitura | R$ 263.158 |
| 2 | SEI-J4 · Meu painel de processos | Leitura | R$ 263.158 |
| 2 | SEI-J5 · Digest de unidade | Leitura | R$ 263.158 |
| 2 | SEI-J6 · 'Qual tipo uso?' + RAG | Leitura | R$ 350.877 |
| 2 | SEI-J7 · Status assinatura + deep-link | Leitura | R$ 263.158 |
| 3 | J4 · Agendamento por Voz | Escrita | R$ 438.596 |
| 3 | SEI-J8 · Ciência de documento | Escrita leve | R$ 350.877 |
| 3 | SEI-J9 · Tramitar via aprovação | Escrita+Gov | R$ 526.316 |
| 3 | SEI-J10 · Abrir processo | Escrita+Gov | R$ 526.316 |
| Total, 15 jornadas | R$ 5 milhões | ||
* Valores por jornada com caráter informativo e referencial, conforme a ROM Data Ágil v1. Só se sustentam na contratação conjunta das 15 jornadas.
👥 Composição por perfil (6.500 horas)
O mesmo teto de R$ 5,02 milhões, aberto por perfil de entrega. É esta composição que sustenta as 6.500 horas e o valor total dos serviços profissionais.
| Perfil | Horas | Investimento c/imp |
|---|---|---|
| Project Manager | 680 | R$ 574.766 |
| Solution Architect | 480 | R$ 405.717 |
| Technical Architect | 480 | R$ 421.953 |
| Developer | 1.440 | R$ 1.030.544 |
| Quality Assurance Consultant | 480 | R$ 294.821 |
| Experience Architect | 360 | R$ 304.288 |
| Slack · Technical Consultant | 980 | R$ 701.342 |
| MuleSoft · Technical Architect | 200 | R$ 175.814 |
| MuleSoft · Technical Consultant | 720 | R$ 512.272 |
| Senior Human Centered Change Consultant | 240 | R$ 227.205 |
| Human Centered Change Consultant | 440 | R$ 371.907 |
| TOTAL | 6.500 | R$ 5.023.628 |
Serviços profissionais Salesforce: R$ 4.694.580,80 sem impostos, R$ 5.023.628,46 com impostos.
Modelo de retorno e produtização
📈 De custo a produto: como o investimento se paga
A leitura de Fernanda foi clara: não se trata só de profissionalizar a comunicação, e sim de aproveitar a plataforma para criar produtos que a Dataprev revende e embute em contratos existentes, reduzindo o próprio investimento. O retorno vem por três caminhos.
A camada de comunicação do Slack pode reduzir contratos de ITSM já existentes, hoje na casa de R$ 2 mil a 3 mil por ano por contrato, aproveitando algo que a plataforma já entrega.
Hoje uma solicitação do cliente aciona várias áreas em cascata até a resposta voltar. Centralizar isso no Slack reduz o tempo de resposta e o custo interno de cada acionamento.
Cada jornada vira produto ou addon que a Dataprev oferece ao cliente como eixo ou serviço (por exemplo o SEI), permitindo diluir o investimento e agregar valor aos contratos existentes.
ROI: investimento inicial da Dataprev que se paga e depois fatura
No curto prazo, o investimento entra como custo indireto diluído nos contratos ao longo do tempo, sem repasse imediato ao cliente. À medida que o valor fica visível, fica mais fácil estruturar serviços agregados. Na leitura da reunião, é um investimento que se paga em cerca de um ano e, a partir daí, passa a gerar faturamento nos novos contratos, com o custo já embutido pela Dataprev para manter o controle.
Visão executiva: Dataprev como empresa agêntica
O Slackbot posiciona a Dataprev como camada agêntica de interação do governo federal: a partir das conversas dos times, o agente responde onde focar, quantos chamados estão abertos, quais as dificuldades por cliente. A instância é da Dataprev, com administração centralizada; os clientes interagem via Slackbot sem tocar na instância. É a narrativa que sustenta a escalada de patrocínio até a presidência.
Alavancas de valor e KPIs (da ROM)
📊 Quatro alavancas de valor mensuráveis
O retorno foi estruturado na ROM por quatro alavancas, cada uma com KPI e driver de monetização. ROI = (ganho recorrente anual − investimento) ÷ investimento, com os valores finais entrando com a volumetria real da Dataprev. Metas ilustrativas, nada comprometido nesta fase.
| Alavanca de valor | Jornadas | KPI-chave | Meta ref. | Driver de ROI |
|---|---|---|---|---|
| Autoatendimento & deflection | J1 · J2 · J7 | % resolvido sem humano | 40–70% | consultas desviadas/mês × custo por atendimento |
| Produtividade do servidor | J3 · SEI-J2 · SEI-J4 · SEI-J5 | tempo de consulta/preparação | −60 a −70% | horas economizadas/mês × custo-hora |
| Risco & conformidade | SEI-J1 · SEI-J9 · SEI-J10 | prazos perdidos · trilha | −80% / 100% | multas, retrabalho e exposição evitados |
| Velocidade de ciclo & experiência | J4 · SEI-J7 · SEI-J8 | tempo de ciclo · adoção | −50% / ≥70% | capacidade recuperada + adesão |
Como levar à aprovação
Inserir os volumes reais por processo na coluna de metas, converter em reais pelos drivers de cada alavanca e comparar o ganho anual recorrente com o investimento único para chegar ao payback. É o mesmo raciocínio do business case por jornada: nada de payback global chutado, e sim retorno construído alavanca por alavanca com o dado da Dataprev.
🎯 KPIs propostos
% consultas self-service → 70%
deflection de status → 40%
tempo de preparação −60%
deflection RH/suporte → 50%
perdas por decurso tácito −80%
tempo de consulta processual −70%
tempo de tramitação/abertura −50%
usuários ativos e satisfeitos ≥ 70%
jornadas sem escalar a humano ≥ 65%
O que precisa acontecer agora
Ficou definida uma cadência curta e objetiva: desenho macro com ordem de grandeza, prévia de validação na segunda 20 e proposta consolidada na quarta 22. Cada etapa tem dono e entregável claro. A sequência foi definida coletivamente, é compromisso, não proposta.
Etapas acordadas
Juliane junta o levantamento prévio com o detalhamento mais recente e monta um desenho macro da solução com uma ordem de grandeza (o ballpark). No dia seguinte, refina com Nelson para calibrar as estimativas de esforço antes da prévia.
Juliane Lopes, com refino de estimativas junto a Nelson
Desenho macro da solução mais ordem de grandeza de esforço
A prévia de validação de escopo com Pedro, Maik e Marcos
"Eu vou juntar o levantamento que eu já tinha criado, adicionar essas informações, fazer um desenho prévio, e a gente já consegue trazer um ballpark, uma ordem de grandeza para validar."
Reunião de prévia para validar o escopo antes da proposta final. A Salesforce apresenta a visão da plataforma tecnológica, o cronograma macro do projeto e o dimensionamento de volumetria de usuários. Terça fica reservada para ajustes, de modo que na quarta a versão final já esteja alinhada.
Juliane Lopes e Nelson · Salesforce PS Brasil
Visão de plataforma, cronograma macro e volumetria de usuários
Escopo validado e ajustes mapeados para consolidar a proposta
Workshop presencial de discovery segue recomendado
Para a Fase 1 detalhada, um workshop presencial em Brasília com os responsáveis de Clarity, Pronto, CRM, TI e segurança continua sendo a forma mais rápida de fechar o mapa de integrações e permissões. Vale posicioná-lo logo após a aprovação da proposta.
Com o escopo validado na prévia, Juliana Brites estrutura a proposta comercial com estimativa de esforço, licenciamento e cronograma por fase. O faseamento foi pedido por Pedro e confirmado por Juliana: entregáveis menores facilitam a aprovação nas alçadas internas. Saulo tem teto de alçada, acima disso vai para a diretoria.
Juliana Brites · Salesforce PS Brasil, relacionamento comercial
Escopo validado na prévia, licenciamento analisado com especialistas, volumetrias de Pedro
OS separada, mesmo pool de consumo, entregas faseadas para respeitar alçadas
Janela de aprovação: agir antes do fim do defeso
O defeso eleitoral reduz o volume de demandas operacionais, é o momento ideal para estruturar, aprovar e iniciar o projeto. Quando o volume voltar ao normal, o time estará engolido pelas demandas do dia a dia. A urgência não é artificial, é real e contextual.
Ação adicional: apresentar ao novo diretor
O novo diretor chegou há menos de duas semanas, é a janela mais favorável para posicionar este projeto como uma vitória estratégica imediata. A proposta de Fase 1 deve caber na alçada de aprovação do Saulo, mas o novo diretor precisa ser apresentado ao projeto antes disso, de preferência ainda durante o defeso, quando o ritmo permite uma conversa de visão, não de operação.
Novos entregáveis pedidos pela liderança (áudio de 23 Jul)
🆕 Dois pedidos que entraram depois da reunião de 14 Jul
A liderança da Dataprev convergiu na ideia e pediu duas coisas objetivas para sustentar a aprovação. Ambas já estão refletidas neste racional: a demo na seção Demo · 3 Perfis e a abertura dos R$ 5 milhões na seção Adoção & Change · Investimento por jornada e por perfil.
Simulação de como o Slack se comporta para funcionário, gestor e cliente. O racional entrega o roteiro; o time de SE monta a simulação navegável, com articulação do Jackson.
Time de SE, apoio de Jackson · roteiro por Juliane
Demo navegável ou vídeo, três perfis, dados fictícios
Abertura dos R$ 5 milhões em estimativa por jornada e por perfil, conforme a ROM Data Ágil v1, para justificar a composição do valor e acompanhá-lo ao longo do tempo.
Juliana Brites e Nelson · calibrar os valores por jornada
Tabela das 15 jornadas e da composição por perfil validada, somando R$ 5 milhões, com plano de acompanhamento
Decisões críticas a resolver no discovery
❓ O que ainda não sabemos, e precisa ser respondido antes do escopo
Essas questões não têm resposta hoje. Cada uma pode mudar o esforço de implementação significativamente, por isso precisam ser respondidas antes de qualquer estimativa de custo.
Clarity, Protheus e Pronto! têm APIs REST disponíveis?
A existência e maturidade das APIs determina o esforço MuleSoft. Sem API, é necessário desenvolver conectores, muda o prazo e o custo da F1.
O Clarity permanece como sistema de registro ou é substituído?
Se o Salesforce passa a ser o sistema de origem das demandas, o Clarity vira um sistema legado de consulta. Se permanecer, a integração é bidirecional. Decisão de arquitetura que muda o modelo de dados.
Quem autoriza acesso aos dados financeiros por sistema?
Dados do Protheus são sensíveis. Definir quem autoriza acesso por perfil de usuário é uma decisão de governança da Dataprev, não da Salesforce. Precisa envolver TI, jurídico e DPO.
Workspace único ou separado para clientes externos e internos?
Separar em workspaces distintos aumenta o controle de segurança mas multiplica o esforço de configuração. Workspace único com canais segregados é mais simples mas exige políticas de acesso mais detalhadas.
Quem será o ponto focal interno da Dataprev neste projeto?
Pedro sugeriu ser ele mesmo ou indicar outro colega. A definição é urgente, o projeto precisa de um dono do lado do cliente que não seja engolido pelas demandas do dia a dia quando o defeso terminar.
Qual o volume estimado de interações mensais?
O modelo de licenciamento Agentforce é sensível ao volume de conversas. Com 2.500 clientes ativos e consultas diárias sobre valores e chamados, o baseline de interações pode ser alto. Essa estimativa define o custo de licença da plataforma.
Estrutura de equipe para o projeto
🏛️ Lado Dataprev
Pedro propôs, e Maik concordou, que este projeto deve ter uma equipe dedicada separada do time do Serviço na Ponta, para não comprometer a qualidade de nenhuma das duas frentes.
☁️ Lado Salesforce
Nova equipe dedicada, separada do time atual do Serviço na Ponta. OS separada dentro do mesmo pool de consumo, conforme alinhamento com Juliana Brites.
Linha do tempo macro
📅 Sequência esperada de eventos
Visão geral apresentada, Slack confirmado como canal, próximos passos acordados.
Mandala percorrida sistema a sistema, volumetrias levantadas, escopo de integração definido, Change Management incluído e cadência das próximas reuniões marcada.
Salesforce apresenta visão de plataforma, cronograma macro e volumetria de usuários. Terça reservada para ajustes.
Estimativa de esforço, licenciamento e cronograma por fase. Estrutura que respeita as alçadas: Saulo na Fase 1, diretoria da Fase 2 em diante.
Quick wins priorizados: consulta financeira, status de chamado, briefing de projeto e agendamento por voz. Entregas incrementais, cada jornada validada antes de a próxima iniciar.
Patrocínio executivo conquistado de baixo para cima. Infraestrutura Slack já em construção. Time motivado dos dois lados. Janela temporal favorável. O que falta é apenas o detalhe, e o detalhe se resolve no workshop.
"Esse projeto, como é nós mesmos, interesse nosso, tem tudo para ir pra frente."
Dez épicas, um escopo, dois modelos de entrega
O escopo e a complexidade são os mesmos independentemente de como se entrega. Esta é a base validada sobre a qual as duas lanes, Tradicional e IA-Native, projetam prazo, equipe e esforço. Tamanhos em camisetas (XS–XL) expressam complexidade relativa, não esforço.
Como esta visão interna se relaciona com a ROM enviada ao cliente
Esta seção de 10 épicas, o comparativo dual-track e a linha do tempo de 4 fases são a análise interna de esforço (ordem de grandeza). Na ROM já compartilhada com a Dataprev, o escopo foi consolidado em 15 jornadas em 3 ondas (ago a dez de 2026), com 6.500 horas de serviços e teto de R$ 5,02 milhões com impostos, e o SEI entrou dentro desse escopo. Os valores por jornada e por perfil estão na seção Adoção & Investimento. Os números internos de bandas de esforço sustentam a estimativa, mas não substituem os valores da ROM.
As 10 épicas e seus tamanhos
| # | Épica | Tamanho | Confiança | Produto principal |
|---|---|---|---|---|
| E01 | Consultas Financeiras Self-Service | L | Assumed | Agentforce + MuleSoft (Protheus) |
| E02 | Autoatendimento Chamados Técnicos | M | Assumed | Agentforce + Slack |
| E03 | Intelligence Executiva Mobile | M | Assumed | Agentforce + Analytics |
| E04 | Knowledge Base Normativas RH | L | Assumed | Agentforce (RAG) |
| E05 | Agendamento Automatizado | S | Confirmed | Agentforce + Slack |
| E06 | Adoção CRM via Conversação | L | Assumed | Agentforce + CRM Totvs |
| E07 | Abertura de Chamados Assistida | M | Assumed | Agentforce |
| E08 | Gestão de Demandas Evolutivas | XL | Unknown | Agentforce + MuleSoft |
| E09 | Intelligence Preditiva e Recomendações | XL | Assumed | Data Cloud + Einstein |
| E10 | Governança, Compliance e Change Management | XL | Assumed | Transversal (todas as fases) |
O que os tamanhos são, e o que não são
Os tamanhos em camisetas (XS a XL) expressam complexidade relativa, não esforço. Não são hora-conversíveis diretamente. As horas nas tabelas de perfis são derivadas top-down do shape do engajamento (roster × semanas de fase), nunca somando horas-por-tamanho. Arquitetura de alto nível: Slack (conversação) → Agentforce (orquestração, RAG, NLP) → MuleSoft/MCP (hub dos 6 legados, com enforcement de perfil de acesso) → Data Cloud + Einstein (F3, camada preditiva). Governança LGPD/TCU é transversal (E10).
Faixa benchmark: 29–54 semanas (Tradicional) · 25–49 (IA-Native)
Derivada do shape do engajamento contra tabelas paramétricas de benchmark, não de uma soma bottom-up de chutes por épica. A lane IA-Native comprime essa faixa pela banda realizada de eficiência de IA. Nenhum número aqui é compromisso de prazo: é decision-support para planejamento.
Como a faixa foi derivada
Linha Multi-Cloud High (10 épicas, predominância L/XL, 6 sistemas legados, baseline 26–40 sem) + adders: +15% indústria regulada (LGPD Art. 48 + trilha TCU + governança de perfil de acesso TI+Jurídico+DPO), +10% cliente novo (primeira vez Dataprev, bloqueador G1002 Protheus não resolvido), +10% alargamento de confiança (68 gaps, volumetrias pendentes). Total +35%, sob o teto de +50%.
As 4 fases (working-point Tradicional: 40 sem)
Discovery & Architecture Refinement
Resolução do bloqueador G1002 (governança Protheus TI+Jurídico+DPO); auditoria de volumetrias; validação da API Clarity; segregação de Workspace Slack; RACI + charter de governança.
Aceite: bloqueadores resolvidos · arquitetura assinada · confiança ≥70%.
Foundation / Quick Wins
E01, E02, E03, E04, E05, E10 (read-only); 5 agentes de Fase 1 (J1, J2, J5, J7, J8) em fase inicial; piloto com 20–50 early adopters.
Aceite: jornadas read-only em produção · piloto validado.
Expansion / Controlled Writes
E06, E07, E10; escritas controladas; conectores MuleSoft dos 6 legados; integração CRM Totvs; hardening.
Aceite: escritas governadas em produção · scale do piloto.
Proactive Intelligence
E08, E09, E10; Data Cloud (Pronto! + CRM Totvs CDC); modelos Einstein (SLA breach, churn de pipeline); hypercare.
Aceite: camada preditiva ativa · handoff de sustentação.
Disclaimer de Benchmark (Duração & Capacidade)
Faixas de timeline e de equipe derivadas de dados históricos de engajamentos Salesforce PS (model-training-data) via classificação paramétrica do shape do engajamento. Decision-support, não compromisso. Duração real depende de capacidade do lado cliente (aprovações Fase 0, provisionamento de acesso a APIs, velocidade da auditoria de volumetrias), mudanças de escopo e bloqueadores imprevistos. Dimensionamento final requer avaliação de capacidade da Salesforce PS.
O que é feito e o que é entregue nas 16 primeiras semanas
Discovery & Foundation, o bloco inicial que resolve os bloqueadores, assina a arquitetura e coloca as primeiras jornadas read-only em produção. Macro atividades por fase, entregáveis e milestones numa linha do tempo gráfica. Working-point Tradicional (F0=6 + F1=10 sem); a lane IA-Native comprime para 14 sem (F0=5 + F1=9).
Linha do tempo gráfica · macro entregas & milestones
arquitetura assinada
piloto validado
Fase 0 · Discovery & Architecture Refinement (6 sem)
- Resolução de bloqueadores de governança, condução da aprovação tri-party do G1002 (Protheus: TI + Jurídico + DPO); desenho do modelo de perfil de acesso.
- Auditoria de volumetrias, levantamento de G0102 / G0201 / G0302 / G0701; baseline de capacidade por jornada.
- Discovery técnico & arquitetura, validação da API Clarity; desenho de arquitetura de alto nível (Slack → Agentforce → MuleSoft/MCP → Data Cloud).
- Setup de fundação Slack, segregação de Workspace / Enterprise Grid (G0101).
- Governança de programa, workshop RACI + charter de governança; elevação de confiança de 45% → ≥70%.
- 📄 Aprovação tri-party do G1002 registrada (bloqueador resolvido)
- 📄 Relatório de auditoria de volumetrias
- 📄 Documento de arquitetura de alto nível assinado
- 📄 Workspace Slack / Enterprise Grid segregado e provisionado
- 📄 RACI + charter de governança publicados
Milestone M0, Gate de arquitetura
Bloqueadores resolvidos · arquitetura assinada · confiança ≥70%. Sem M0, a Fase 1 não abre.
Fase 1 · Foundation / Quick Wins (10 sem)
- Exposição de APIs read-only, conectores MuleSoft de leitura sobre os legados de Fase 1 (Protheus, Pronto/ServiceNow, CRM Totvs, Conexão/SharePoint, Microsoft Teams), com enforcement de perfil de acesso.
- Configuração de agentes Agentforce, as 5 jornadas de Fase 1: J1 (E01 financeiro), J2 (E02 chamados), J5 (E03 intelligence), J7 (E04 knowledge RH), J8 (E05 agendamento).
- Base de conhecimento (RAG), ingestão e indexação das normativas de RH (E04).
- Design conversacional, fluxos de diálogo, tom, fallback e loop humano por jornada.
- Piloto & usability testing, rollout controlado com 20–50 early adopters; coleta de métricas de deflexão.
- Change Management inicial (E10), comunicação, treinamento e trilha de auditoria read-only.
- 🚀 Jornadas E01, E02, E03, E04, E05 (read-only) em produção
- 🚀 E10 governança / trilha de auditoria read-only ativa
- 🚀 5 agentes de Fase 1 (J1, J2, J5, J7, J8) em operação inicial
- 🚀 Piloto com 20–50 early adopters validado + baseline de métricas
- 🚀 Playbook de Change & primeiro ciclo de treinamento
Milestone M1, Fundação validada
Jornadas read-only em produção · piloto validado. Base para a Fase 2 (escritas controladas) abrir com segurança.
Detalhamento Fase 1 · integrações & agentes (o que faz e a qual legado conecta)
Como ler esta tabela
Na Fase 1, cada jornada é um agente Agentforce (a superfície de conversa é o Slack) apoiado por uma integração MuleSoft read-only que expõe um sistema legado sem reescrevê-lo. Nesta fase o acesso é somente leitura, nenhuma escrita nos legados (as escritas controladas entram na Fase 2). O objetivo é validar as jornadas de maior valor com risco mínimo.
| Épica · agente | Objetivo (o que resolve) | Legado conectado · integração F1 (read-only) | Superfície |
|---|---|---|---|
| E01 · Consultas Financeiras Agente financeiro (J1) |
Cliente B2B (ministério/ente) consulta em linguagem natural títulos em aberto, faturas e situação financeira, sem abrir chamado nem esperar N1. | Protheus (ERP financeiro) via MuleSoft, leitura de títulos/faturas. 🔴 depende do G1002 | Slack |
| E02 · Autoatendimento de Chamados Agente de chamados (J2) |
Usuário consulta status, histórico e andamento de chamados técnicos por conversa, deslocando consultas de status do N1 humano. | Pronto (ServiceNow) (sistema de chamados) via MuleSoft, leitura de status/histórico/SLA. | Slack |
| E03 · Intelligence Executiva Agente executivo (J5) |
Executivo consulta briefing comercial (pipeline, forecast, contratos macro) em linguagem natural, no celular, antes de reunião urgente, sem depender de relatório manual. | CRM Totvs (pipeline / forecast / contratos) via MuleSoft, leitura read-only (viabilidade de API validada na Fase 0). | Slack / mobile |
| E04 · Knowledge Base Normativas RH Agente normativo (J7) · RAG |
Servidor pergunta sobre normas/regras de RH (incl. alçadas de aprovação) e recebe resposta fundamentada, com citação da fonte normativa (LGPD/TCU-friendly). | Portal Conexão (SharePoint), normativas de RH; ingestão e indexação (RAG); não é integração transacional, é base de conhecimento. | Slack |
| E05 · Agendamento Automatizado Agente de agenda (J8) Confirmed |
Usuário organiza agendamentos por comando de voz/texto no Slack, reduzindo idas e vindas de e-mail/telefone. | Microsoft Teams (calendário corporativo) via Graph API, leitura de disponibilidade; escrita de agendamento entra na Fase 2. | Slack |
| E10 · Governança & Compliance Transversal (todas as jornadas) |
Trilha de auditoria LGPD/TCU nativa em cada interação, enforcement de perfil de acesso e observabilidade, pré-condição, não opcional. | Camada de enforcement de perfil de acesso no MuleSoft + registro de auditoria sobre todas as integrações read-only acima. | – |
Dependência crítica de Fase 1
A jornada E01 (Consultas Financeiras / Protheus) só é viável com o bloqueador G1002 resolvido na Fase 0 (aprovação tri-party TI + Jurídico + DPO). Se G1002 não fechar no M0, E01 sai da Fase 1 e as demais jornadas seguem sem ela.
Mapa de jornadas J1–J10 · programa completo (5 delas entram na Fase 1)
10 jornadas no programa · 5 na Fase 1
O discovery identificou 10 jornadas de agente (J1–J10) distribuídas pelas 9 épicas funcionais. A Fase 1 entrega 5 delas, as de maior valor com menor risco, todas read-only: J1, J2, J5, J7 e J8. As demais entram nas Fases 2 (escritas controladas) e 3 (preditivo). E10 (governança) é transversal e não é uma jornada de agente.
| Jornada | Épica · o que o agente faz | Legado / dado conectado | Fase |
|---|---|---|---|
| J1 | E01 · consulta financeira self-service (títulos, faturas) | Protheus (ERP financeiro) | F1 |
| J2 | E02 · autoatendimento de chamados (status/SLA) | Pronto (ServiceNow) | F1 |
| J3 | E07 · abertura de chamados assistida (escrita) | Pronto (ServiceNow) | F2 |
| J4 | E06 · adoção de CRM via conversação (escrita) | CRM Totvs | F2 |
| J5 | E03 · intelligence executiva (pipeline/forecast, mobile) | CRM Totvs | F1 |
| J6 | E08 · gestão de demandas evolutivas (escrita) | Clarity (Broadcom) | F3 |
| J7 | E04 · knowledge base de normativas de RH (RAG) | Portal Conexão (SharePoint) | F1 |
| J8 | E05 · agendamento por voz/texto | Microsoft Teams (calendário) | F1 |
| J9 | E09 · alerta preditivo de risco de SLA | Pronto + Data Cloud / Einstein | F3 |
| J10 | E09 · recomendações comerciais proativas | CRM Totvs + Data Cloud / Einstein | F3 |
Itens G* · gaps de discovery que gateiam a Fase 1
68 gaps no total · estes gateiam a Fase 1
O discovery levantou 68 gaps (G*), o que dispara a Fase 0 obrigatória. Abaixo, os itens diretamente ligados às 5 jornadas de Fase 1 (E01–E05), à fundação e ao bloqueador crítico. Os demais (E06–E09, cross-cutting) são resolvidos ao longo das Fases 0–2.
- G1002 🔴 bloqueador, governança Protheus (aprovação tri-party TI + Jurídico + DPO); sem ela, J1/E01 é inviável.
- G1001, modelo de governança das APIs MuleSoft/MCP (quem aprova quais queries).
- G0101, segregação de Workspace Slack / Enterprise Grid (clientes B2B externos × internos).
- G9902, decisão MuleSoft × MCP (protocolo de integração).
- G0102, volumetria Protheus (consultas/mês, clientes B2B ativos).
- G0103, fluxo de aprovação de acesso ao financeiro.
- G0104, Experience Design / onboarding de clientes B2B no Slack.
- G0105, retenção de audit logs LGPD/TCU (prazo, armazenamento).
- G0106, autenticação B2B externa (SSO/SAML).
- G0107, risco de read-only × demanda transacional.
- G0201, volumetria Pronto (~30k tickets/mês, ~13–14k INSS).
- G0202, ownership Pronto (Dataprev × INSS) e acesso à API.
- G0204, SLA exposto via API estruturada?
- G0205, histórico/audit trail (comments, anexos, reatribuições).
- G0206, concentração de 46% em um cliente (INSS).
- G0301, qual produto Totvs (CRM, Fluig, RM) e disponibilidade de API.
- G0302, base de executivos-alvo (~50 usuários ativos).
- G0305, dados CRM atualizados/completos ou stale?
- G0307, autenticação mobile de executivos (SSO/SAML).
- G0401, mecanismo de integração/indexação do portal Conexão (SharePoint).
- G0403, regras de alçada (limiar R$ 2M), complexidade da regra de negócio.
- G0405, risco LGPD: normativas com PII de servidores.
- G0406, caminho de fallback/escalação quando a KB não resolve.
- G0501, mecanismo de integração Slack → Teams (calendário).
- G0502, entrada por voz (transcrição nativa Slack × speech-to-text).
- G0504, permissão de tenant Microsoft 365 (OAuth + Graph API).
- G0506, leitura de calendário para checar conflitos antes de agendar.
Onze funções, esforço por perfil (Fases 0 + 1)
As 11 funções do projeto e o esforço em horas por perfil, derivado top-down (roster × semanas de fase) e detalhado apenas para as Fases 0 e 1 (Discovery + Foundation), Fases 2 e 3 permanecem em faixa indicativa até o fim da Fase 0. Foco desta página: escopo e estimativa de esforço, não preço.
Horas-por-perfil detalhadas apenas para Fases 0 + 1 (Discovery + Foundation)
As tabelas abaixo quantificam o esforço por perfil somente das Fases 0 e 1, o escopo de compromisso de curto prazo (Discovery & Architecture + Foundation / Quick Wins). As Fases 2 (Expansion) e 3 (Proactive Intelligence) permanecem na faixa indicativa top-down (ver Timeline & Comparativo) e serão detalhadas por perfil ao término da Fase 0, quando a confiança sobe para 70–80%. Perfis ativos apenas em F3 (R05 Data Cloud, R09 Einstein) não aparecem aqui.
Lane Tradicional · Fases 0 + 1 (Discovery + Foundation · 16 sem: F0=6 + F1=10)
| Perfil | Fases | h/sem | Total (h) |
|---|---|---|---|
| R01, Senior Technical Architect | F0–F1 | 40 | 640 |
| R03, MuleSoft Technical Architect | F0–F1 | 40 | 640 |
| R06, Solution Architect | F1 | 40 | 400 |
| R07, Change Management Lead | F0–F1 | 20 | 320 |
| R02, Agentforce Technical Consultant | F1 | 40 | 400 |
| R04, MuleSoft Technical Consultant | F1 | 40 | 400 |
| R08, UX Researcher / Service Designer | F0–F1 | 20 | 320 |
| R10, Solution Consultant (BA) | F0–F1 | 40 | 640 |
| R11, Quality Assurance Consultant | F1 | 40 | 400 |
| Offshore build pod (5 dev + 2 QA) | F1 | – | 2.800 |
| Program Manager (regra 15%) | F0–F1 | – | 1.044 |
| TOTAL F0+F1 | – | – | 8.004 h |
Lane IA-Native / Quantum Leap · Fases 0 + 1 (Discovery + Foundation · 14 sem: F0=5 + F1=9 · offshore=0)
| Perfil | Fases | h/sem | Total (h) |
|---|---|---|---|
| R01, Senior Technical Architect | F0–F1 | 40 | 560 |
| R03, MuleSoft Technical Architect | F0–F1 | 40 | 560 |
| R06, Solution Architect | F1 | 40 | 360 |
| R07, Change Management Lead | F0–F1 | 20 | 280 |
| R02, Agentforce Consultant (agent director) | F1 | 40 | 360 |
| R04, MuleSoft Consultant (agent director) | F1 | 40 | 360 |
| R08, UX Researcher / Service Designer | F0–F1 | 20 | 280 |
| R10, Solution Consultant (BA) | F0–F1 | 40 | 560 |
| R11, Quality Assurance Consultant | F1 | 40 | 360 |
| Offshore | – | – | 0 |
| Program Manager (regra 15%) | F0–F1 | – | 552 |
| TOTAL F0+F1 | – | – | 4.232 h |
Verificações obrigatórias FASE 10
Aplicadas ao escopo F0+F1. · Mín. 20h/semana: nenhum recurso abaixo de 20h/sem (R07 e R08 part-time a 20h; demais 40h). · Ratio QA: R11 onshore + QA do pod offshore cobrem os recursos de build de F1 (ratio ~1:2); na IA-Native R11 é agent-amplified e faz surge nas janelas de hardening. · PM ≥15%: PM = 15% das horas técnicas em ambas as lanes (Tradicional 1.044h; IA-Native 552h). · Ganho de IA ≥25%: em F0+F1, a IA-Native usa ~47% menos horas (4.232 h vs 8.004 h) que a Tradicional.
Três itens a validar na composição de esforço
1. Program Manager fora do roster nomeado: a função não consta nos 11 perfis; a linha PM (15% das horas técnicas) é adição obrigatória FASE 10, validar como função dedicada. · 2. Pod offshore de build (5 dev + 2 QA): é uma premissa de composição de equipe (nearshore Brasil), validar aplicabilidade e residência de dados. · 3. Horas derivadas top-down (roster × semanas de fase), não somadas por tamanho de camiseta, o detalhe por perfil de F2/F3 fecha ao término da Fase 0.
IA-Native entrega o mesmo escopo com ~49% menos horas
A vantagem da lane IA-Native não é atalho de escopo, é um modelo de entrega diferente. Duração comprimida pela eficiência de IA + o volume de build absorvido por agentes sob supervisão de um núcleo sênior (pod offshore eliminado). Menos horas totais, equipe menor e prazo mais curto para o mesmo resultado. Foco deste comparativo: esforço e prazo, não preço.
Lado a lado
| Dimensão | Tradicional | IA-Native / Quantum Leap | Delta |
|---|---|---|---|
| Duração | 29–54 sem | 25–49 sem | ~9–14% + rápido |
| Equipe no pico | 12–15 pessoas | 10–11 pessoas | ~17–27% menos |
| Esforço total (working-point) | ≈ 25.254 h | ≈ 12.949 h | ~49% menos horas |
| Esforço bloco F0+F1 | 8.004 h | 4.232 h | ~47% menos horas |
Por que a IA-Native usa menos horas, três vetores, não um atalho
Duração comprimida
25–49 sem vs 29–54 sem: ganho task-level de IA ~30–40% × fator de realização 0,40–0,45 = ~12–18% project-level; readiness 2/8 reduz para a banda Low ~10–14%. O tempo é a moeda de comparação.
Derivada à necessidade
10–11 vs 12–15 pessoas: núcleo sênior contínuo (6, F0–F3) + especialistas fracionais (5, consumidos quando necessário) + 0 offshore. Agentes absorvem o volume de build (6 conectores de API, 10 jornadas J1–J10, config Data Cloud, execução de testes) sob supervisão sênior; R02/R04 atuam como agent directors.
100% onshore sênior
O pod offshore de build (5 dev + 2 QA) desaparece, o volume que ele absorveria é feito por agentes sob supervisão do núcleo sênior. Mesmo headcount sênior onshore, sem a camada offshore de execução.
Internamente consistente
As horas por perfil (bottom-up) caem dentro das faixas de esforço derivadas top-down e reproduzem o mesmo delta de ~47–49% menos horas, a estimativa de esforço fecha por dois caminhos independentes.
KPI de eficiência de IA (mandato Dataprev ≥25%)
Atendido com folga na dimensão esforço (~49% menos horas no programa; ~47% no bloco F0+F1). Na dimensão duração isolada, a compressão é de ~10–14% (readiness atual 2/8, Low). Chegar a ≥25% de compressão de prazo exige 5 desbloqueios: aprovação de ferramentas de IA para o time PS, resolução do G1002 Protheus, política de entrega assistida por IA conforme LGPD/TCU, auditoria de volumetrias, e plano de reconciliação do modelo de dados dos 6 legados.
Disclaimer de esforço & benchmark
Faixas de esforço (horas), duração e equipe derivadas top-down do shape do engajamento por classificação paramétrica contra dados históricos de engajamentos Salesforce PS (model-training-data). Isto é decision-support para planejamento e validação de escopo, não é compromisso de prazo, dimensionamento final de equipe, nem estimativa de preço. O foco desta apresentação é validar escopo e esforço; a estimativa de preço é objeto de etapa comercial separada. Dimensionamento final e termos comerciais estão sujeitos à avaliação de capacidade da Salesforce PS e negociação comercial formal.