# HPI Pro — Full Knowledge Base Website: https://hpi.pro/pt Language: Portuguese (pt-BR) Hebrew edition: https://hpi.pro Contact: https://hpi.pro/pt/contact > Consultoria, arquitetura e implementação de Salesforce e CRM para empresas e organizações. ## Core pages - https://hpi.pro/pt/services - https://hpi.pro/pt/consulting-discovery - https://hpi.pro/pt/crm-architecture - https://hpi.pro/pt/salesforce-implementation - https://hpi.pro/pt/salesforce-health-check - https://hpi.pro/pt/salesforce-development-automation - CI/CD e DevOps para Salesforce: https://hpi.pro/pt/salesforce-cicd-devops - https://hpi.pro/pt/agentforce-ai - https://hpi.pro/pt/integrations-data - https://hpi.pro/pt/support - https://hpi.pro/pt/salesforce-expert-staffing - https://hpi.pro/pt/solutions - https://hpi.pro/pt/methodology - https://hpi.pro/pt/about - https://hpi.pro/pt/insights - https://hpi.pro/pt/contact --- # Knowledge Base ## Quanto Custa Implementar o Salesforce em uma Organização? Componentes de Custo e um Modelo para Estimativa Confiável URL: https://hpi.pro/pt/insights/salesforce-implementation-cost O custo de implementação do Salesforce é composto por sete elementos de comportamento distintos — desde licenciamento, passando por integrações, até custos internos ocultos. Aqueles que aprovam um orçamento baseado em um único número geralmente se deparam com um estouro de orçamento na segunda fase. ## A Resposta Curta Não existe uma resposta única para quanto custa implementar o Salesforce, pois envolve uma soma de sete componentes que se comportam de maneira diferente: o licenciamento é pago por usuário e nível de edição, os serviços de implementação são pagos pelo escopo do trabalho, enquanto o custo interno oculto – as horas da sua equipe – nem aparece na proposta do fornecedor. Uma organização que orça apenas o que está no contrato enfrentará um estouro já no segundo mês. A maneira correta de abordar a questão não é procurar um "preço para implementação do Salesforce" como um número único, mas sim construir um modelo de estimativa que separe componentes de alta certeza (licenciamento) de componentes que dependem do escopo e da complexidade (implementação, integrações, migração). Quem está em um estágio inicial de seleção encontrará informações complementares em [Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company), enquanto quem já está comparando propostas pode usar o artigo sobre [RFP para Salesforce](/pt/insights/salesforce-rfp-guide). ## Os Sete Componentes de Custo O custo de implementação do Salesforce não é uma única linha no orçamento, mas sim sete componentes separados, cada um precificado de uma forma diferente e com comportamentos distintos ao longo do tempo: 1. **Licenciamento (Licensing)** - Custo anual ou mensal por usuário, dependendo da edição (Professional, Enterprise, Unlimited) e produtos adicionais como Sales Cloud, Service Cloud ou Data Cloud. 2. **Serviços de Implementação (Implementation Services)** - Trabalho de análise de requisitos, configuração, desenvolvimento customizado e testes, geralmente precificado por horas ou por Preço Fixo com base em um escopo definido. 3. **Integrações** - Conexão entre o Salesforce e sistemas existentes (ERP, sistema de pagamento, sistema de telefonia, ferramentas de marketing), um custo que depende do número de sistemas e da complexidade do mapeamento de dados entre eles. 4. **Migração** - Limpeza, mapeamento e transferência de dados históricos de um sistema anterior, frequentemente subestimado porque a qualidade dos dados originais não foi verificada previamente. 5. **Treinamento** - Capacitação de usuários finais e gerentes, um custo fácil de ser negligenciado no orçamento, mas que determina a taxa de adoção real. 6. **Suporte Contínuo** - Manutenção, correção de bugs, pequenas alterações e atualizações de versão após o Go-Live, geralmente em um contrato separado da implementação. 7. **Custo Interno Oculto** - Horas da equipe da organização: proprietários de processo, gerente de projeto interno, testes de aceitação e comunicação de mudanças, que não aparecem na proposta do fornecedor, mas consomem recursos reais. ## Tabela de Fatores de Custo | Componente | O que move o preço | Como minimizar | Sinal de Alerta | |---|---|---|---| | Licenciamento | Número de usuários, edição, produtos adicionais | Analisar o uso real antes da renovação e não adicionar licenças "apenas por segurança" | O fornecedor recomenda uma edição superior sem justificar a necessidade de negócio específica | | Serviços de Implementação | Número de processos, complexidade da automação, quantidade de objetos personalizados | Começar com um "Vertical Slice" pequeno e expandir gradualmente em vez de um "Big Bang" | Proposta sem WBS detalhada por processo ou "Workstream" | | Integrações | Número de sistemas, formato de dados, necessidade de Middleware | Mapear dependências antecipadamente e escolher entre iPaaS de baixo custo e API personalizada de alto custo com base no volume real | Não há definição de quem é responsável pela manutenção da integração após o Go-Live | | Migração | Volume de registros, duplicatas, número de fontes históricas | Realizar uma pesquisa de qualidade de dados antes da estimativa, não depois | A proposta assume "dados limpos" sem verificação real | | Treinamento | Número de perfis de usuário, complexidade do processo, dispersão geográfica | Treinar por função e cenário, não treinamento de tela geral | Item de treinamento limitado a um workshop de duas horas para toda a organização | | Suporte Contínuo | SLA, horas de disponibilidade, volume de mudanças mensais | Definir o nível de SLA com base na criticidade do processo e não uniformemente | Sem distinção entre "bug" e "mudança" no contrato de suporte | | Custo Interno Oculto | Disponibilidade dos proprietários do processo, qualidade dos testes de aceitação, gestão da mudança | Alocar uma porcentagem fixa da função do gerente de projeto interno desde o início | A proposta assume que a equipe interna "estará disponível" sem estimativa de horas | ## Modelo de Estimativa: Faixas de Esforço, Não Preços Fixos Em vez de depender de uma tabela de preços fixos que se torna rapidamente obsoleta e varia entre fornecedores, é aconselhável pensar em termos de Faixas de Esforço (Effort Bands) para cada componente e traduzi-los em preço com o fornecedor específico: - **Esforço Baixo** - Um único processo de negócio, sem integrações complexas, menos de 20 usuários, dados históricos limitados. Típico para pequenas empresas B2B que implementam o Sales Cloud básico. - **Esforço Médio** - Dois a quatro processos de negócio, uma a três integrações com sistemas existentes, 20-100 usuários, migração de um CRM anterior. Esta é a faixa mais comum no mercado brasileiro. - **Esforço Alto** - Múltiplas unidades de negócio ou países, múltiplas integrações com sistemas legados, modelo de permissões complexo, mais de 100 usuários, requisitos específicos de Compliance para o setor. Para cada faixa de esforço, uma tradução separada deve ser feita para cada um dos sete componentes, sem assumir que todos os componentes crescem na mesma proporção. As integrações, por exemplo, podem saltar de esforço baixo para alto mesmo em um projeto relativamente pequeno, se o sistema existente não expuser uma API funcional. ## Como Traduzir uma Faixa de Esforço em uma Proposta Real Depois que a faixa de esforço esperada for definida, o próximo passo é solicitar a pelo menos três fornecedores uma discriminação de horas por componente, e não apenas um valor total. Tal detalhamento dá à organização uma capacidade real de comparação: expandimos sobre isso em [Consultor Salesforce](/pt/insights/salesforce-consulting-guide), onde também é explicado como identificar uma proposta que artificialmente minimiza a fase de testes para parecer mais barata. ### Três Cenários Típicos de Preço **Cenário A - Implementação inicial pequena**: Um processo de vendas, sem integração, 10-15 usuários. A maior parte do custo está concentrada nos serviços de implementação e treinamento; o licenciamento e o suporte contínuo representam uma parcela relativamente pequena no primeiro ano. **Cenário B - Substituição de um sistema CRM existente**: Migração de milhares de registros, 40-60 usuários, uma integração com o sistema contábil. Neste caso, migração e integrações podem representar um terço do orçamento total, e é precisamente esse componente que as estimativas iniciais tendem a subestimar. **Cenário C - Expansão multi-anual para uma grande organização**: Múltiplas unidades de negócio, Salesforce já existente e necessidade de adicionar Service Cloud ou Data Cloud. O custo interno oculto – tempo dos proprietários de processo e gerentes de TI – torna-se o componente mais significativo, e às vezes maior que o custo do licenciamento. ## Exemplo de Cenário Organizacional Suponhamos um fabricante multi-site que solicita propostas de três integradores para implementar o Salesforce. A proposta mais barata é 35% menor que as outras, mas na inspeção, verifica-se que ela inclui apenas 40 horas de migração, apesar de a organização ter cerca de 60 mil registros de clientes históricos em um sistema antigo com muitas duplicatas. A equipe solicita ao fornecedor que detalhe as premissas de trabalho e descobre que a proposta assumia "dados limpos e prontos para transferência" – uma premissa não verificada com a realidade. A organização decide realizar uma breve pesquisa de qualidade de dados antes de assinar o contrato. A pesquisa revela que 18% dos registros são duplicados e 30% carecem de um campo obrigatório para o novo processo. Consequentemente, a organização solicita que os três fornecedores refaçam a precificação da fase de migração com base nas descobertas e adiciona ao contrato uma cláusula que separa o custo de migração única da manutenção contínua da qualidade dos dados – conforme detalhado em [SOW Projeto Salesforce](/pt/insights/salesforce-sow-contract-clauses). O resultado: a proposta final selecionada não foi a mais barata, mas foi a única que incluiu todos os sete componentes de custo em detalhe real, incluindo a estimativa de horas internas da própria organização. Mudar essa ordem – primeiro mapear o custo real e depois comparar propostas – foi o que evitou um estouro de orçamento de cerca de 25% que só seria descoberto no quarto mês por um dos concorrentes que optou pela proposta mais barata. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | |---|---|---| | Proposta “redonda” demais | Um único valor total sem detalhamento por componente | Exigir a discriminação de horas e custos para cada um dos sete componentes | | Ignorar o custo interno | A organização não orça tempo de gerenciamento interno e testes de aceitação | Estimar previamente horas/homem internas separadamente do custo do fornecedor | | Migração subestimada | Assunção de que "os dados estão em ordem" sem verificação | Realizar uma pesquisa de qualidade de dados antes da estimativa final | | Treinamento como item marginal | Orçamento de treinamento limitado a um dia para toda a organização | Orçar o treinamento por função e cenário real | | Suporte sem definição de SLA | Contrato de suporte vago quanto aos tempos de resposta e correção | Estabelecer SLA escalonado por criticidade e precificar de acordo | No nível de gestão do orçamento de implementação do Salesforce, esta tabela é um ponto de partida e não uma lista fechada. Para CEOs, departamentos de compras e CIOs, é aconselhável atualizá-la a cada rodada de propostas e verificar quais riscos se concretizaram em projetos anteriores no mesmo setor antes de aprovar um orçamento final. ## Como Verificar a Razoabilidade da Estimativa | Área de Verificação | O que verificar | Frequência de Verificação | |---|---|---| | Adequação da licença ao uso | Porcentagem de usuários ativos em relação ao número de licenças adquiridas | Trimestral | | Desvio nos serviços de implementação | Desvio das horas reais em relação às horas orçadas na proposta | Em cada marco | | Carga de integração | Frequência de falhas ou atrasos na transferência de dados entre sistemas | Mensal | | Qualidade da migração | Porcentagem de registros com erro ou duplicidade após a transferência | Única após o Go-Live | | Custo de suporte versus SLA | Se os tempos de resposta reais correspondem ao pago | Mensal | Para uma estimativa orçamentária responsável, é aconselhável selecionar apenas três a cinco métricas desta tabela para acompanhamento contínuo no primeiro ano. Uma boa métrica pode ser calculada antes e depois da assinatura do contrato, permitindo comparar o que foi prometido com o que realmente aconteceu – e não apenas confiar na sensação de que o projeto "correu bem". A implementação prática do modelo de estimativa pode ser realizada através do [Serviço de Consultoria e Descoberta](/pt/consulting-discovery). ## Checklist Antes da Aprovação do Orçamento - ☐ Cada um dos sete componentes de custo está precificado separadamente e não em um montante total. - ☐ Foi realizada uma pesquisa de qualidade de dados antes da avaliação do custo de migração. - ☐ Uma faixa de esforço (baixa, média, alta) foi definida antes de solicitar propostas. - ☐ As horas de trabalho internas foram estimadas separadamente do custo do fornecedor. - ☐ O orçamento de treinamento está detalhado por função e não como um item geral. - ☐ Um SLA claro foi definido para o contrato de suporte contínuo. - ☐ Existe uma reserva de 10-20% para mudanças de escopo. - ☐ Pelo menos três fornecedores detalharam as horas por componente e não apenas um valor total. - ☐ O custo de licenciamento foi verificado para 24-36 meses e não apenas para o primeiro ano. - ☐ As métricas de verificação pós-Go-Live foram definidas e não apenas o critério de "o sistema foi implementado". ## Recursos Profissionais - HPI Pro – Consultoria e Descoberta — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Serviços Salesforce — https://hpi.pro/services ### Perguntas e respostas **Por que duas propostas de orçamento para implementação do Salesforce podem ser o dobro uma da outra?** Geralmente, trata-se de um escopo de trabalho diferente, e não de um 'desconto'. Uma proposta mais barata pode omitir testes de carga, migração de dados históricos ou treinamento de usuários finais, que são adicionados como extras após a assinatura. É essencial comparar com base na mesma EAP (Estrutura Analítica do Projeto) e nas mesmas premissas, não apenas no valor final. **É preferível pagar por licenças premium para economizar no custo de implementação?** Às vezes, sim: uma licença com recursos de Flow e Automação integrados pode economizar desenvolvimento personalizado. Mas esta não é uma fórmula fixa — o custo de licenciamento por três anos é muitas vezes superior à economia na implementação. É aconselhável calcular o custo total para 24-36 meses, não apenas o preço de implementação inicial. **Quanto do orçamento deve ser reservado para mudanças durante o projeto?** Em projetos de médio a grande porte, é comum reservar 10-15% do custo dos serviços de implementação como reserva para mudanças de escopo. Se a organização também estiver passando por uma mudança significativa de processo, e não apenas pela digitalização de um processo existente, é aconselhável elevar esta porcentagem para cerca de 20%. **Qual a diferença entre o custo de migração única e o custo de manutenção contínua de dados?** A migração é um projeto com tempo limitado: limpeza, mapeamento e transferência pontuais. A manutenção de dados é um processo contínuo — desduplicação, controle de qualidade e atualização de permissões. Organizações que orçam apenas a migração percebem em um ano que a qualidade dos dados está novamente comprometida. **Como identificar se uma proposta de orçamento esconde um custo interno oculto?** Se a proposta não especifica quantas horas de gerenciamento interno, testes de aceitação e envolvimento de proprietários de processo são exigidos de sua equipe, é provável que esse custo exista, mas não tenha sido considerado. Solicite uma estimativa separada das horas-homem internas à sua equipe, além do custo do provedor. --- ## Como Escolher a Melhor Consultoria Salesforce: Guia Profissional para Decisões Estratégicas URL: https://hpi.pro/pt/insights/choose-salesforce-implementation-company A escolha de uma consultoria Salesforce frequentemente oscila entre o impacto de uma demonstração impressionante ou a mera comparação de preços. Um processo de seleção adequado prioriza a profundidade técnica, recomendações autênticas e o modelo de engajamento, antes de focar nos valores finais da proposta. ## A Resposta Curta A escolha de uma empresa para implementar o Salesforce geralmente se encontra entre dois polos arriscados: a impressão causada por uma demonstração em uma reunião de vendas, ou a mera comparação de preços entre propostas que parecem semelhantes no papel. Nenhum desses métodos avalia o que realmente determina o sucesso — se o fornecedor compreende o processo de negócio, como ele lida com exceções, e o que acontece quando algo dá errado na terceira semana do projeto. Um processo de seleção maduro avalia quatro pontos em sequência: a definição da necessidade interna antes de buscar o mercado, o tipo de fornecedor adequado para o escopo e o risco, a profundidade profissional verificada para além da demonstração, e um modelo de contrato que distribua o risco de forma justa. O quadro de comparação entre orçamentos e termos foi detalhado em [Comparando Propostas Salesforce](/pt/insights/compare-salesforce-proposals), e aqui o foco é na fase anterior a essa — como chegar a uma lista de candidatos qualificados. ## Primeira Etapa: O que é Necessário Antes de Consultar o Mercado O erro mais comum é abordar fornecedores com a pergunta "quanto custa" antes de definir o que é realmente necessário. Uma empresa que inicia um processo de compra sem um escopo escrito recebe propostas que não podem ser comparadas, pois cada fornecedor preenche as lacunas com suas próprias suposições. Antes da primeira reunião, é recomendável ter um breve documento com: o processo de negócio que requer mudança, quem são os usuários, quais sistemas existem atualmente e o que será considerado sucesso em seis meses. A extensão dessa necessidade determina diretamente o modelo de precificação adequado — um projeto com escopo claro é mais adequado para um preço fixo, enquanto um projeto exploratório se encaixa melhor em Time & Material. Isso foi detalhado em [Modelos de Precificação para Projetos Salesforce](/pt/insights/salesforce-project-pricing-models). Uma organização que pula a etapa de definição quase sempre paga o dobro: uma vez em uma proposta inflacionada que cobre a incerteza, e outra em mudanças de escopo no meio do trabalho. ## Tipos de Fornecedores: Boutique, Global e Freelancer O mercado de serviços Salesforce é amplamente dividido em três categorias, e cada uma se adapta a um perfil de risco diferente. **Empresas boutique** geralmente têm entre 5 e 30 funcionários, são especializadas em uma ou duas áreas (Vendas, Serviço, Marketing Cloud) e oferecem acesso direto ao arquiteto sênior ao longo do projeto. A vantagem é agilidade e preço competitivo; a desvantagem é a capacidade limitada — um projeto grande que exige cinco pessoas simultaneamente pode ficar parado. **Integradores globais** trazem metodologia documentada, capacidade rápida de recrutar pessoal adicional e experiência em setores semelhantes em todo o mundo. O preço é 30-60% mais alto em comparação com boutiques, e frequentemente há uma camada de gerenciamento de projeto que separa o cliente da equipe de execução real — o que pode atrasar a comunicação em momentos de crise. **Freelancers** oferecem a menor taxa horária, mas expõem a dependência de uma única pessoa. Se o freelancer fica doente, viaja para o exterior ou muda para outro projeto, o trabalho para. É mais adequado para manutenção contínua ou projetos pequenos com escopo definido e fechado. ## Verificação Aprofundada da Profissionalismo Além da Demonstração Uma demonstração impressionante prova que o fornecedor sabe apresentar o Salesforce, não que ele sabe resolver o problema específico da organização. Uma verificação aprofundada exige três camadas: primeiro, pedir que a equipe que realmente executará o projeto (não apenas o vendedor) participe da reunião e responda a perguntas técnicas. Segundo, solicitar um exemplo concreto de um projeto semelhante em escopo e indústria, incluindo capturas de tela reais e não slides de marketing. Terceiro, examinar como o fornecedor responde a uma pergunta-armadilha — por exemplo, "o que acontece se no meio do projeto for descoberto que os dados de origem não são confiáveis?" Um fornecedor experiente responderá com um exemplo, não um slogan. Quem lidera a arquitetura na prática determina a qualidade da solução muito mais do que o logotipo na fatura. É importante garantir que o arquiteto apresentado na reunião de vendas seja de fato quem estará envolvido no projeto, e não um "rosto" que é mostrado aos clientes e, após a assinatura, é substituído por uma equipe mais júnior. ## Verificação de Referências Reais Uma boa conversa com referências não se limita a "você recomendaria?" — ela entra em detalhes operacionais. Três perguntas que fornecem informações reais: o projeto foi concluído dentro do orçamento e cronograma original, e se não, qual foi o desvio e qual a razão; o que aconteceu quando um erro ou bug foi descoberto em produção, e quanto tempo levou para corrigir; e se a equipe que executou o projeto ainda trabalha para o fornecedor hoje. Uma alta rotatividade de funcionários em uma empresa de implementação é um sinal de que o conhecimento adquirido no projeto anterior não está mais disponível. É aconselhável pedir pelo menos duas referências: uma de um projeto bem-sucedido e outra de um projeto que teve dificuldades. Um fornecedor que se recusa a fornecer uma referência "problemática" ou alega que todos os seus projetos foram bem-sucedidos sem falhas, está escondendo algo. ## Modelo de Contrato: Como Compartilhar o Risco O modelo de contrato define quem assume o risco quando a realidade se desvia do planejado — e isso acontece quase sempre. | Modelo | Quando é Adequado | Risco Principal | | --- | --- | --- | | Time & Material Aberto | Escopo imaturo, fase de Discovery | Excesso de horas sem limite | | T&M com Limite (Cap) | Escopo parcial, primeiro projeto com fornecedor | Requer controle contínuo contra o limite | | Preço Fixo | Escopo bem definido e documentado | Fornecedor pode cortar custos para manter a margem | | Retainer Mensal | Manutenção e suporte contínuo | O volume de trabalho real nem sempre corresponde ao pagamento | Para um primeiro projeto com um novo fornecedor, o modelo T&M com limite é geralmente a escolha mais equilibrada: ele evita surpresas orçamentárias, mas não incentiva o fornecedor a economizar em testes. Mudar para um preço fixo deve ser considerado apenas depois que o escopo já foi validado contra cenários End-to-End reais, conforme descrito em [Escolhendo um Fornecedor Salesforce](/pt/insights/salesforce-vendor-scorecard). ## Scorecard para Pontuação de Fornecedores Uma tabela de pontuação ponderada transforma uma comparação subjetiva em um processo que pode ser defendido perante a gerência. Pesos sugeridos para um projeto típico: | Critério | Peso | O Que Avaliar na Prática | | --- | --- | --- | | Adequação da experiência à indústria e processo | 25% | Projetos semelhantes em escopo e setor, não apenas logotipos conhecidos | | Profundidade da equipe proposta | 20% | Antiguidade e função real do arquiteto e dos desenvolvedores | | Qualidade da proposta e do escopo | 20% | Detalhamento do WBS, suposições, exceções e entregáveis de aceitação escritos | | Referências e rotatividade de funcionários | 15% | Conversas diretas com clientes anteriores | | Modelo de contrato e equidade contratual | 10% | Distribuição razoável de riscos, não apenas preço baixo | | Adequação cultural e disponibilidade de comunicação | 10% | Tempo de resposta, idioma, fuso horário e frequência de atualizações | Cada fornecedor recebe uma pontuação de 1 a 5 em cada linha, multiplicada pelo peso. A diferença entre o fornecedor líder e o segundo colocado no resultado geral é tão importante quanto a própria pontuação — uma diferença de menos de 5 pontos geralmente justifica uma reunião de esclarecimento adicional antes de uma decisão final. ## Bandeiras Vermelhas a Identificar Cedo - Orçamento sem detalhamento de horas por tópico, apenas um "total" global. - Promessa de "solução completa no Salesforce" para uma necessidade que nunca foi investigada a fundo. - Recusa em divulgar quem da equipe realmente fará o trabalho. - Pressão para assinar rapidamente "porque este preço só é válido esta semana". - Ausência de referência a um caso de falha ou projeto que teve dificuldades. - Contrato que não define o que é considerado "conclusão" do projeto e aceitação final. ## O Que Pedir Para Ver na Reunião: Um Checklist Rápido - ☐ Presença da equipe de execução real, não apenas do vendedor. - ☐ Exemplo concreto de projeto similar com capturas de tela reais. - ☐ Detalhamento inicial do WBS com suposições e exceções escritas. - ☐ Nome e detalhes de contato de pelo menos duas referências. - ☐ Proposta de modelo de contrato com explicação de por que é adequado ao escopo. - ☐ Descrição do processo de tratamento de mudanças de escopo e bugs após o lançamento. ## Cenário Organizacional de Exemplo Uma empresa de serviços financeiros de médio porte avaliou três propostas para o Salesforce Sales Cloud: uma boutique local, um integrador global e um freelancer recomendado. A gerência inicialmente inclinou-se para o freelancer devido ao preço 40% menor, até que uma conversa com referências revelou que seu projeto anterior ficou parado por três semanas quando ele adoeceu. A organização finalmente optou pela boutique, depois que o Scorecard mostrou uma vantagem de 12 pontos na categoria de profundidade da equipe e baixa rotatividade de funcionários. O projeto de fato encontrou uma mudança de requisito no meio do caminho — uma nova necessidade de integração com um sistema interno de faturamento que não havia sido mencionada na fase da proposta. Graças ao modelo T&M com limite, a mudança foi tratada como uma adição previamente acordada, e não como uma renegociação de todo o contrato. Organizações que estão em dúvida entre fornecedores semelhantes e desejam um quadro de perguntas adicional podem usar [Perguntas Antes de Escolher um Integrador Salesforce](/pt/insights/questions-before-choosing-salesforce-integrator). ## Como Medir Se a Escolha Foi Correta | Métrica | O que Avaliar | Quando Avaliar | | --- | --- | --- | | Cumprimento do cronograma | Desvio em dias entre o planejado e o executado | Em cada marco | | Estabilidade da equipe | As mesmas pessoas acompanharam o projeto até o fim | Ao final de cada etapa | | Tratamento de exceções | Tempo de resposta a um bug ou mudança de requisito | Ao longo do projeto | | Qualidade da documentação | A manutenção pode ser transferida para outra equipe sem dependência | Na entrega | Uma métrica que não pode ser verificada na prática não é uma métrica. Se o contrato não inclui uma definição clara do que é considerado "conclusão" do projeto, é quase impossível saber se a escolha foi correta até que seja tarde demais para corrigir. Uma organização que deseja acompanhamento externo na construção do próprio processo de seleção pode iniciar com [Serviço de Consultoria e Descoberta](/pt/consulting-discovery), que ajuda a definir o escopo e construir um Scorecard personalizado antes mesmo de buscar o mercado. ## Recursos Profissionais - HPI Pro – Consultoria e Descoberta — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Serviços Salesforce — https://hpi.pro/services ### Perguntas e respostas **Qual a diferença prática entre uma consultoria boutique e uma integradora global em um projeto Salesforce?** Uma boutique geralmente oferece acesso direto ao arquiteto e desenvolvedor sênior, ciclos de trabalho mais curtos e um custo horário mais baixo, mas tem capacidade limitada para projetos de grande porte. Uma integradora global traz metodologia estruturada e capacidade de escala, por um preço mais elevado e, geralmente, com camadas adicionais de gestão entre o cliente e o executor real. **Qual é o custo médio de um freelancer Salesforce versus uma empresa?** Um bom freelancer custa em torno de R$ 250-450 por hora, sem custos administrativos, mas expõe a organização ao risco de dependência de um único indivíduo. Uma empresa cobra, em média, 20-40% a mais, mas oferece backup, seguro profissional e continuidade do trabalho, mesmo que um funcionário saia no meio do projeto. **Que perguntas devo fazer às referências de uma consultoria antes de assinar o contrato?** Pergunte sobre o cumprimento real dos cronogramas versus o planejado, a qualidade da documentação entregue, como o fornecedor agiu quando um erro foi descoberto e se a equipe que executou o projeto ainda trabalha na empresa. Uma resposta evasiva a qualquer uma dessas perguntas é um sinal de alerta significativo. **Qual é o modelo de contratação recomendado para um primeiro projeto Salesforce em uma organização?** Geralmente, recomenda-se o modelo de Time & Material (T&M) com um teto (Cap) para a fase inicial, e só depois migrar para um preço fixo, quando o escopo tiver sido estabilizado em torno de cenários End-to-End bem definidos. Um preço fixo para um escopo ambíguo incentiva o fornecedor a cortar atalhos para proteger sua lucratividade. **Qual o tamanho mínimo de equipe de um fornecedor necessário para um projeto Salesforce de médio porte?** Para um projeto com duração de 3 a 6 meses, é aconselhável garantir que haja pelo menos duas pessoas com conhecimento suficiente para se substituírem: um arquiteto ou líder e um desenvolvedor adicional. Uma equipe de uma única pessoa funciona bem até o momento em que ela fica doente, de férias ou sai da empresa. --- ## Quanto tempo dura um Projeto Salesforce? Prazos, Dependências e Fatores de Atraso Reais URL: https://hpi.pro/pt/insights/salesforce-project-timeline Um projeto Salesforce médio dura entre seis semanas e nove meses, mas o prazo no orçamento raramente se deve apenas ao escopo do desenvolvimento. Ele é influenciado principalmente pelo ritmo das decisões, a prontidão dos dados e a disponibilidade dos profissionais da organização. ## A Resposta Curta Não existe uma resposta única para quanto tempo dura um projeto Salesforce, mas há intervalos realistas que devem ser considerados antes de assinar um contrato. Um projeto focado em "Quick Win" – uma automação específica, um objeto personalizado, um relatório avançado – pode ser concluído em 3-4 semanas. Uma implementação completa do Sales Cloud para uma equipe de vendas de porte médio varia de 8 a 14 semanas. Um projeto Multi-Cloud com integrações a ERP e sistemas externos pode levar de 6 a 9 meses, e às vezes mais, quando envolve diversas unidades de negócio. O fator que determina o prazo real não é o volume de código, mas o ritmo da tomada de decisões na organização: quem é o Owner de cada processo, quanto tempo leva para aprovar o escopo e quando os dados estão realmente prontos para testes. Antes de definir uma data de Go Live, é recomendável ler o guia completo para [implementação do Salesforce em uma organização](/pt/insights/salesforce-implementation-guide), que detalha as etapas de trabalho por trás de cada semana do cronograma. ## Por Que os Prazos Variam Tanto Entre Projetos Aparentemente Similares Duas organizações que solicitam "implementação do Sales Cloud para uma equipe de vendas de 20 pessoas" podem receber propostas com uma diferença de até três vezes no tempo de execução, e ambas podem estar corretas. A diferença quase sempre reside no que não está escrito no documento de requisitos: quantas fontes de dados existem, quão complexos são os processos internos de aprovação e com que rapidez a organização toma decisões que afetam mais de um departamento. Um projeto com um único Product Owner que possui autoridade para aprovar o escopo avança significativamente mais rápido do que um projeto onde cada mudança requer a aprovação de um comitê diretor. Esta não é uma diferença técnica – é uma diferença organizacional que impacta diretamente o cronograma, às vezes mais do que qualquer decisão de arquitetura. ## Prazos por Tipo de Projeto A tabela a seguir apresenta estimativas de semanas de trabalho efetivas (Elapsed, não Effort) por fase e tipo de projeto. Estes são intervalos médios baseados na experiência prática, não um compromisso – cada projeto concreto requer uma avaliação separada. | Fase | Quick Win / Adição Pontual | Implementação Padrão (Um Cloud) | Projeto Multi-Cloud com Integrações | | --- | --- | --- | --- | | Descoberta e Detalhamento | 3-5 dias | 1.5-3 semanas | 3-6 semanas | | Arquitetura e Modelo de Dados | 2-3 dias | 1-2 semanas | 3-5 semanas | | Construção e Configurações | 1-2 semanas | 3-6 semanas | 8-16 semanas | | Migração de Dados | Geralmente não necessário | 1-2 semanas | 3-6 semanas | | Integrações | Geralmente não necessário | 1-3 semanas | 4-10 semanas | | UAT e Correções | 2-4 dias | 2-3 semanas | 3-5 semanas | | Go Live e Hypercare | 2-3 dias | 1-2 semanas | 2-4 semanas | | **Duração Total Global** | **3-4 semanas** | **8-14 semanas** | **24-40 semanas** | É importante lembrar que os números da tabela assumem disponibilidade razoável das partes interessadas e dados de ordem de grandeza aceitável. Qualquer uma dessas premissas, quando não atendida, pode adicionar semanas inteiras a cada fase. ## O Que Realmente Atrasa os Projetos – Não o Que Se Pensa Quando um projeto Salesforce excede o cronograma, a causa mais comum não é a complexidade técnica, mas sim um dos cinco fatores a seguir: - **Decisões interdependentes que não são tomadas a tempo** - Uma questão de negócio que permanece aberta por duas semanas porque não há quem esteja autorizado a respondê-la, enquanto a equipe técnica aguarda. - **Dados que não estão realmente prontos** - Uma fonte de dados "existente e pronta" revela conter duplicidades, campos ausentes ou duas fontes conflitantes. - **Disponibilidade de especialistas de conteúdo e proprietários de processo** - Os profissionais de vendas ou serviço que deveriam testar e aprovar estão ocupados com o trabalho diário e não foram previamente liberados. - **Integrações com terceiros** - Dependência de um fornecedor externo, de uma API com limitações ou de uma equipe de TI interna que não opera no mesmo ritmo. - **UAT que se arrasta** - Porque os testes só começam quando o sistema está "quase pronto" e não em paralelo com a construção. Entre todos esses, as decisões interdependentes são o fator mais fácil de prevenir e o mais comum na prática. Uma organização que define antecipadamente quem aprova o quê, e dentro de quantos dias uma resposta é considerada "atraso", economiza em média duas a três semanas em um projeto médio. Este tópico é amplamente discutido no [MVP Salesforce](/pt/insights/salesforce-mvp-scope), que explica como reduzir o número de decisões interdependentes desde o início, delimitando uma primeira versão menor. ## O Caminho Crítico: O Que Determina a Data Final Em todo projeto existe uma cadeia de atividades que determina o prazo mínimo para conclusão — este é o caminho crítico. Em um projeto Salesforce típico, o caminho crítico quase sempre passa por três gargalos: 1. **Aprovação do modelo de dados e permissões** - Enquanto isso não estiver fechado, não é possível iniciar a integração ou migração com segurança. 2. **Prontidão da fonte de dados para migração** - Mesmo que o desenvolvimento esteja pronto, não é possível ir para produção sem dados limpos e verificados. 3. **Disponibilidade dos proprietários de processo para UAT** - Este é geralmente o gargalo mais estreito, pois se trata de pessoas com uma função integral na organização e não apenas o tempo da equipe do projeto. Um atraso de uma semana em qualquer um desses três se reflete diretamente na data de Go Live, mesmo que o resto da equipe esteja cumprindo os prazos. Por isso, um bom PMO monitora especialmente os itens no caminho crítico e não apenas a porcentagem geral de conclusão do projeto. Essa ideia é expressa na prática no processo de [UAT para Salesforce](/pt/insights/salesforce-uat-guide), que detalha como planejar a etapa de testes para que ela própria não se torne um gargalo adicional. ## Phased vs. Big Bang: Como a Escolha Afeta o Cronograma A decisão de entrar em produção em uma única etapa (Big Bang) ou em ondas (Phased) é uma das mais significativas para o cronograma, e não apenas para o risco operacional. **Big Bang** é adequado quando o escopo é relativamente pequeno, quando há uma dependência estreita entre os componentes (por exemplo, um processo unificado de Lead-to-Cash que não pode ser dividido) e quando a organização prefere um investimento de tempo concentrado em vez de um longo período de transição. Vantagem no cronograma: uma única data de entrega clara. Desvantagem: qualquer atraso em um componente paralisa a data toda. **Phased** é adequado quando o escopo é amplo, quando há várias divisões ou processos que podem ser separados, e quando a organização deseja obter valor antecipado e aprender com uma onda antes de avançar para a próxima. Vantagem: a primeira onda entra em produção mais rapidamente, e as lições aprendidas são aplicadas nas ondas seguintes. Desvantagem: duração total mais longa e, às vezes, um custo maior de coordenação entre as ondas. Como regra geral, se o projeto for exceder 4 meses ou incluir mais de dois departamentos independentes, a abordagem Phased quase sempre encurta o tempo até o primeiro valor de negócio, mesmo que a duração total do projeto seja semelhante ou maior. ## Como Reduzir o Cronograma Sem Comprometer a Qualidade Existem maneiras reais de encurtar o prazo, e existem atalhos que parecem economizar tempo, mas na verdade apenas adiam o custo para o Hypercare ou para o ano seguinte. **O que realmente encurta:** - Delimitação rigorosa do escopo para a primeira versão, com uma lista explícita e pré-aprovada de "não para agora". - Nomeação de um único Product Owner com autoridade real para aprovar ou rejeitar, a fim de eliminar atrasos de comitê. - Início do trabalho de limpeza de dados em paralelo com o detalhamento, e não depois. - Liberação de tempo na agenda dos proprietários de processo para UAT com antecedência, não apenas quando a etapa chega. - Uso de componentes padrão do Salesforce em vez de desenvolvimento personalizado, sempre que possível. **O que parece encurtar, mas não realmente:** - Pular o UAT completo e ir direto para "teste de desenvolvedores" - economiza uma semana e gera um mês de correções em produção. - Migração de dados sem limpeza, com a intenção de "limpar depois" - os dados sujos se tornam um problema de adoção. - Concentrar o treinamento em um único dia antes do Go Live - leva à contornar o sistema nas primeiras semanas. Quando se trata de um projeto em que o cronograma é realmente crítico para o negócio, o acompanhamento profissional através do [serviço de implementação Salesforce](/pt/salesforce-implementation) foca exatamente nesta combinação – quais atalhos são seguros e quais apenas adiam o custo. ## Cenário Organizacional de Exemplo Uma empresa de logística planejou a implementação do Service Cloud em 10 semanas, para estar pronta antes da alta temporada. Na segunda semana, descobriu-se que o sistema ERP existente não estava pronto para expor uma API estável, e que a equipe de TI interna estava disponível apenas meio período para o projeto. Em vez de empurrar todo o projeto para frente, a equipe adotou uma abordagem Phased: a primeira fase incluiu roteamento básico de chamados e SLA, sem a integração com o ERP, e entrou em produção em 7 semanas – três semanas antes da temporada. A integração completa foi adiada para a segunda fase, que ocorreu simultaneamente com a própria alta temporada e entrou em produção dois meses depois. A lição central: quando um obstáculo real é descoberto no caminho crítico, a pergunta correta não é "como compactar o tempo restante", mas sim "o que pode ser separado em uma fase distinta sem prejudicar o valor imediato". O planejamento do Hypercare após cada onda é detalhado no [Salesforce Hypercare](/pt/insights/salesforce-hypercare-plan), que mostra como estabilizar cada onda antes de avançar para a próxima. ## Checklist para um Planejamento de Cronograma Realista - ☐ Escopo da primeira versão definido, incluindo uma lista de "não para agora". - ☐ Product Owner único com autoridade de aprovação nomeado. - ☐ Qualidade dos dados na fonte verificada, não apenas assumida como "pronta". - ☐ Proprietários de processo liberados antecipadamente para os tempos de UAT planejados. - ☐ Integrações com terceiros verificadas em relação à API e disponibilidade do fornecedor. - ☐ Decisão explícita de Phased ou Big Bang, e por que. - ☐ Caminho crítico identificado e monitorado separadamente da porcentagem geral de conclusão. - ☐ Buffer embutido de 10-15% no cronograma, não uma promessa de "tudo no prazo". - ☐ Usuários finais treinados antes do Go Live, não no dia anterior. - ☐ Plano de Hypercare definido antecipadamente com critérios de saída. ## Recursos Profissionais - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Implementação Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology ### Perguntas e respostas **Qual a diferença na duração de um projeto entre um Sales Cloud básico e um Service Cloud com integrações?** Um Sales Cloud básico para uma única equipe de vendas, sem integrações complexas, geralmente é concluído em 6 a 10 semanas. Já um Service Cloud com roteamento, SLA e 2-3 integrações (ERP, telefonia, sistema de faturamento) normalmente exige de 12 a 20 semanas, devido ao mapeamento de processos de serviço e permissões mais complexos. **Quanto tempo da duração total do projeto é consumido pela fase de dados?** Em projetos com uma única fonte de dados limpa, a limpeza e migração levam aproximadamente 10% do tempo total. Quando há duas ou mais fontes com duplicidades, essa proporção aumenta para 25-30%, pois cada rodada de verificação de qualidade revela novas exceções que exigem decisões de negócio, e não apenas correções técnicas. **É preferível um cronograma fixo predefinido ou uma estimativa que é atualizada ao longo do projeto?** Um cronograma fixo é adequado apenas quando o escopo está completamente fechado e não há dependência de integração externa. Na maioria dos projetos, é apresentada uma faixa de tempo (por exemplo, 10-14 semanas), que é atualizada ao final de cada Sprint. Isso ocorre porque fixar um prazo muito cedo geralmente gera um desvio silencioso posteriormente, em vez de um cumprimento real do objetivo. **O que acontece com o cronograma quando uma necessidade de integração não planejada é identificada no meio do projeto?** Em um projeto com abordagem faseada, é possível adiar a integração para a próxima fase sem interromper o restante do trabalho, geralmente com um acréscimo de 2-4 semanas para uma fase separada. Em uma abordagem 'Big Bang', essa descoberta tende a paralisar todo o processo, pois todos os componentes devem ser lançados simultaneamente. **Quanto tempo deve ser alocado para o UAT (Teste de Aceitação do Usuário) para que não se torne um gargalo no projeto?** Para um projeto de médio porte, recomenda-se alocar 2-3 semanas para o UAT, incluindo uma rodada de correções. O problema comum não é a duração do próprio UAT, mas a disponibilidade dos proprietários do processo. Se eles não forem liberados das suas tarefas diárias com antecedência, uma etapa que deveria levar duas semanas pode se estender por um mês e meio. --- ## Implantação Salesforce em Grandes Empresas: Princípios, Governança e Riscos URL: https://hpi.pro/pt/insights/enterprise-salesforce-implementation Acima de 500 usuários, o desafio não é mais 'como construir', mas sim quem decide, quem aprova as mudanças e como os planos paralelos são coordenados. O artigo apresenta um modelo de Governança, a escolha entre Single-org e Multi-org e padrões de falha comuns. ## A Resposta Concisa Em uma organização com dezenas de usuários, a implementação do Salesforce é, principalmente, um trabalho de configuração e adoção. Em uma organização com 500 ou mais usuários, distribuídos por várias unidades de negócio e, por vezes, em diversos países, o desafio central se desloca: quem aprova as mudanças, como garantir que equipes paralelas não se sobreponham, e se a estrutura da Org é propícia ao próximo crescimento ou se o impede. Sem uma Governança organizada, qualquer melhoria pontual se transforma em um risco à estabilidade de toda a organização. Este artigo aborda a camada de gestão acima do projeto individual: a estrutura das decisões, a escolha entre uma Single-org e múltiplas Orgs separadas, a coordenação de lançamentos, segurança e regulamentação, localização global e a interdependência entre programas paralelos no PMO. A base completa para as etapas de implementação fundamentais está em [Implementação do Salesforce em uma organização](/pt/insights/salesforce-implementation-guide), e o presente artigo se constrói sobre ela, a nível de escala organizacional. ## Por Que a Escala Muda as Regras do Jogo Em um projeto com 50 usuários, as mudanças podem ser gerenciadas por meio de uma conversa entre duas pessoas. Com 500 ou mais usuários, geralmente já existem várias equipes de desenvolvimento, diversas unidades de negócio com prioridades distintas e, por vezes, vários fornecedores de aplicativos paralelos. Uma pequena alteração em um Objeto compartilhado — a adição de um campo obrigatório, a modificação de uma Regra de Validação — pode comprometer um processo em outra unidade que não estava ciente da mudança. Portanto, em escala organizacional, três perguntas precedem qualquer discussão técnica: quem possui cada Objeto e processo central, qual mecanismo verifica o impacto entre equipes antes do Deploy, e quem está autorizado a interromper um lançamento se um risco for identificado. Organizações que ignoram essas questões "constroem rápido" no início e pagam o preço com interrupções frequentes e Rollbacks não planejados após um ou dois anos. ## Governança e Comitê Consultivo de Mudanças (Change Advisory Board - CAB) Um Comitê Consultivo de Mudanças não é um comitê burocrático — é um mecanismo que previne que uma mudança, que parece pequena para uma unidade, prejudique outra. A estrutura recomendada inclui três níveis de aprovação: uma mudança de configuração rotineira (baixo risco) que é aprovada no nível da equipe; uma mudança que afeta um modelo de dados compartilhado ou uma integração (risco médio) que é encaminhada para o CAB semanal; e uma mudança arquitetônica (por exemplo, a alteração de um Modelo de Compartilhamento ou a transição para Multi-org) que requer a aprovação de um Comitê Diretor (Steering Committee) no nível de CIO. Na prática, o CAB mais eficaz que observamos não é aquele com a maior documentação ou transparência, mas sim aquele com um SLA claro: uma solicitação de mudança de risco médio recebe uma resposta em 3 a 5 dias úteis, e não "na próxima reunião que acontecer, quando for". Quando o SLA não é cumprido, as equipes aprendem a contornar o processo, e é exatamente nesse momento que a Governança colapsa na prática, mesmo que exista no papel. ### Tabela de Responsabilidades (RACI) para Governança Organizacional | Área de Decisão | Business Sponsor | Enterprise Architect | Release/DevOps Lead | Security & Compliance | PMO | | --- | --- | --- | --- | --- | --- | | Estrutura da Org (Single/Multi-org) | Consultado | Responsável | Informado | Consultado | Informado | | Aprovação de mudança em Objeto compartilhado | Informado | Responsável | Consultado | Consultado | Informado | | Cronograma de Lançamentos e Release Train | Informado | Consultado | Responsável | Informado | Responsável | | Política de Permissões e Compliance | Consultado | Consultado | Informado | Responsável | Informado | | Interdependência entre programas paralelos | Responsável | Consultado | Informado | Informado | Responsável | | Localização para novo mercado | Responsável | Responsável | Informado | Consultado | Responsável | Esta tabela não é um modelo fixo; ela deve se adaptar à estrutura organizacional real. O ponto crucial é que "Responsável" aparece apenas uma vez em cada linha — quando duas partes têm total propriedade sobre a mesma decisão, este é o primeiro sinal de que a estrutura causará atrasos. ## Single-org Versus Multi-org Esta é uma das decisões mais caras para corrigir retroativamente. Uma Single-org com separação de permissões precisa (Profiles, Permission Sets, Record Types e Sharing Rules) permite um único relatório sobre toda a organização, menos manutenção de integrações e menor custo de licenciamento. O problema começa quando diferentes unidades de negócio exigem uma frequência de lançamento completamente distinta, ou quando existe uma exigência regulatória que obriga a separação física de dados. A Multi-org resolve o problema da separação, mas cria um novo: qualquer relatório cross-org requer uma camada de BI separada ou uma solução como o Data Cloud, e todo processo global (por exemplo, Lead-to-Cash) precisa ser construído duas vezes ou gerenciado via MuleSoft/mecanismo de sincronização. Em organizações que avaliaram ambos os caminhos, a transição de Single-org para Multi-org depois que a organização já está grande tende a levar de 9 a 14 meses e incluir uma migração de dados complexa — portanto, é preferível tomar a decisão cedo, mesmo que isso signifique conviver com um comprometimento temporário na separação de permissões. ## Release Train e DevOps em Escala Organizacional Quando várias equipes trabalham na mesma Org, o lançamento "quando estiver pronto" deixa de funcionar. O modelo que funciona em escala organizacional é o Release Train: uma frequência fixa (quinzenal a mensal), uma única Source of Truth em Version Control, e um Pipeline que identifica conflitos de Metadata entre equipes antes do dia do Deploy, e não no próprio dia. Componentes práticos a serem incluídos: - Um ambiente de Integração comum onde todas as equipes fazem o merge antes de subir para UAT. - Uma janela de Code Freeze fixa (geralmente 48-72 horas) antes de cada lançamento. - Testes de regressão automatizados que abrangem os cenários de negócios essenciais de cada unidade, não apenas as novas mudanças. - Política clara: uma equipe que não cumpriu o prazo de Merge embarca no próximo Release Train e não impede o progresso de todos. Uma expansão sobre a infraestrutura de Sandbox e os processos de Pipeline está detalhada em [Salesforce DevOps Sandboxes](/pt/insights/salesforce-sandbox-devops-strategy), onde também é apresentada a estrutura recomendada para ambientes entre Dev e Production. ## Segurança e Compliance em Escala Organizacional Acima de 500 usuários, o modelo de permissões se torna um ativo crítico por si só. Um erro comum é criar um novo Profile para cada pequena mudança, o que resulta em centenas de Perfis em um ou dois anos, cujo propósito ninguém se lembra. A abordagem que funciona melhor: um Profile restrito de acordo com uma função ampla, e Permission Sets modulares que são adicionados conforme a necessidade específica. Em organizações globais, uma camada adicional de Compliance é necessária: o GDPR na Europa exige a capacidade de exclusão e o registro de consentimento, regulamentações de privacidade do Brasil exigem o registro de dados, e organizações de saúde ou financeiras nos EUA podem ser obrigadas a cumprir HIPAA ou SOX. O significado prático: criptografia em nível de campo para dados sensíveis, logs de acesso a registros (Field Audit Trail ou Shield), e um processo de documentação que mostra quem acessou o quê e quando — não apenas quem está autorizado a acessar. ## Globalização e Localização Uma implementação que opera em vários países enfrenta três problemas recorrentes: moedas e datas (Multi-Currency e formato de data por Locale), idioma na interface e nos relatórios (Translation Workbench nem sempre cobre campos personalizados), e processos de aprovação que entram em conflito com a legislação trabalhista ou tributária local. Uma equipe que planeja a localização como um "add-on" ao final do projeto geralmente descobre que ela requer uma mudança no próprio modelo de dados, e não apenas na tradução de strings. ## PMO e a Interdependência entre Programas Paralelos Em uma grande organização, um projeto Salesforce quase nunca opera isoladamente. Paralelamente, programas de ERP, projetos de Data Warehouse e, por vezes, a fusão de duas empresas estão em andamento. Um PMO que não mapeia a interdependência entre os programas descobre em um estágio avançado que ele e o ERP estão construindo, ao mesmo tempo, duas fontes de verdade diferentes para o mesmo dado de cliente. A ferramenta prática é uma matriz de dependência atualizada mensalmente: para cada programa, quais dados ele "lidera" (Source of Truth), e quais dados ele apenas consome. Quando dois programas reivindicam a propriedade do mesmo campo, o PMO é a entidade que deve decidir — não permitir que isso seja resolvido "no campo" entre dois desenvolvedores. ## Padrões de Falha Típicos Acima de 500 Usuários | Padrão de Falha | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Proliferação de Perfis | Centenas de Perfis quase idênticos, ninguém tem certeza do que quem pode fazer | Transição gradual para Permission Sets modulares | | Lançamento "privado" da equipe | Uma equipe entra em produção sem passar pelo CAB, interrompendo outro processo | Release Train obrigatório com Code Freeze compartilhado | | Duas fontes de verdade para o mesmo dado | ERP e CRM cada um "possuindo" dados de clientes | PMO define uma única Source of Truth para cada domínio de dados | | Permissões muito amplas "para não bloquear" | Vazamento de informações sensíveis entre unidades de negócio | Menor privilégio por função, auditoria trimestral | | Localização como um add-on tardio | Tradução parcial, formato de data incorreto, relatórios quebrados em uma região | Planejar Locale e moeda no modelo de dados desde o primeiro dia | | Sandbox não sincronizado | Testes passam em Sandbox e falham em Production devido a diferença de configuração | Refreshes agendados e política de Seed Data unificada | ## Processo de Trabalho Recomendado para Implementação em Escala Organizacional ### 1. Estableça um Comitê Diretor (Steering Committee) e um Comitê Consultivo de Mudanças (CAB) antes de iniciar a construção Antes de escrever a primeira linha de código, um Patrocinador em nível de gerência deve ser nomeado, os três níveis de aprovação para mudanças devem ser definidos e um SLA de resposta deve ser acordado. Sem isso, as primeiras equipes que começam a trabalhar estabelecerão, de fato, o precedente para todos que vierem depois. ### 2. Decida entre Single-org e Multi-org antecipadamente e documente a justificativa Esta decisão deve ser baseada em requisitos regulatórios reais e na frequência de lançamento exigida, não em preferência técnica. A alternativa rejeitada e a condição que levará a uma reavaliação (por exemplo, a aquisição de uma nova empresa) devem ser documentadas. ### 3. Construa o Release Train antes de ter mais de uma equipe Frequência fixa, ambiente de Integração comum e processo de identificação de conflitos antes do dia do lançamento. A equipe do projeto principal é definida em [Funções da Equipe de Projeto Salesforce](/pt/insights/salesforce-project-team-roles), mas em escala organizacional, uma função dedicada de Release Manager também é necessária. ### 4. Mapeie o modelo de permissões e os requisitos de Compliance por região de operação Identifique antecipadamente quais regulamentações se aplicam em cada país de operação e planeje a criptografia, logs e processo de exclusão de acordo, e não como um acréscimo após uma reclamação ou auditoria. ### 5. Documente as dependências entre programas no PMO e atualize-as mensalmente Uma matriz de dependência viva, não um documento escrito apenas uma vez no início do projeto. Qualquer mudança no cronograma de um programa é verificada em relação ao impacto em outros programas. ### 6. Execute um piloto em uma unidade de negócio antes de um Rollout organizacional completo Um Vertical Slice completo, incluindo permissões e integrações reais, permite identificar problemas de Governança e Release antes que eles sejam multiplicados em dezenas de unidades. A compreensão dos blocos de construção no nível de User Story é apresentada em [Salesforce User Stories](/pt/insights/salesforce-user-stories-backlog). ### 7. Expanda em ondas controladas com medição entre cada onda Cada onda de Rollout é medida em relação a uma baseline antes da expansão para a próxima onda. Se a primeira onda revelou um problema de Governança, corrija-o antes de continuar — não expanda enquanto corrige. ## Cenário Organizacional de Exemplo Uma seguradora com 1.200 usuários em três países tentou implementar o Salesforce com duas equipes de desenvolvimento paralelas — uma para vendas e outra para serviço — sem um CAB ativo. Após cinco meses, as duas equipes alteravam o mesmo Objeto de cliente semanalmente, e os processos de teste falhavam intermitentemente sem que ninguém soubesse o motivo. A solução não foi técnica: a organização estabeleceu um CAB semanal com um SLA de 3 dias, definiu um único Object Owner para cada entidade central e adotou um Release Train quinzenal com um ambiente de Integração comum. Em dois meses, o número de conflitos entre as equipes diminuiu significativamente, e o cronograma de lançamento nas três regiões se estabilizou. A lição principal: a escala organizacional não falha devido à tecnologia, mas sim pela falta de gerenciamento claro sobre dados compartilhados. ## Checklist Antes da Expansão em Escala Organizacional - ☐ Existe um Comitê Consultivo de Mudanças (CAB) com um SLA definido e não apenas no papel. - ☐ A decisão entre Single-org e Multi-org está documentada com condições para reavaliação. - ☐ Existe um Release Train com frequência fixa e ambiente de Integração comum. - ☐ O modelo de permissões é baseado em Permission Sets e não em um novo Profile para cada mudança. - ☐ Os requisitos de Compliance foram verificados para cada país de operação. - ☐ Existe uma matriz de dependência entre programas paralelos, atualizada mensalmente. - ☐ Um único Object Owner foi definido para cada entidade de dados comum. - ☐ Um projeto piloto foi executado em uma unidade de negócio antes do Rollout completo. - ☐ Existe um plano de localização que vai além da tradução de strings. - ☐ Métricas de sucesso separadas foram definidas para cada onda de expansão. ## Recursos Profissionais - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Implementação Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology ### Perguntas e respostas **Quando a necessidade de Multi-org se torna realmente relevante?** Quando unidades de negócio operam com modelos de vendas, regulamentação ou idiomas completamente diferentes, e quando a frequência de mudanças em uma unidade pode prejudicar a estabilidade de outra. Na maioria das organizações, até 3.000-5.000 usuários, um Single-org com separação precisa de permissões ainda é preferível, pois o custo de manutenção de um Multi-org é significativamente maior. **Quanto tempo leva para construir uma Change Advisory Board (CAB) que realmente funcione?** Em média, seis a oito semanas até que o processo se estabilize: definição dos tipos de mudança, limites de aprovação, cronograma de reuniões fixo e modelo de solicitação. A verdadeira dificuldade não é definir o processo, mas sim aplicá-lo quando a pressão dos negócios leva a contorná-lo. **Como planejar um Release train quando existem 6-8 equipes paralelas?** Defina uma frequência regular (por exemplo, quinzenal ou mensal), uma janela de Code Freeze compartilhada e um mecanismo de Merge que identifica conflitos entre Metadados antes do Deploy. As equipes que não estão prontas para o prazo passam para o próximo trem — o que significa que o grupo inteiro não irá atrasar. **O que muda nos requisitos de Compliance quando a organização opera em vários países?** É necessário mapeamento por região: GDPR na Europa, Lei Geral de Proteção de Dados (LGPD) no Brasil, e U.S. HIPAA ou SOX para organizações de saúde e finanças americanas. A diferença prática está na retenção de dados, criptografia de campos e logs de acesso, e não apenas nas permissões de Perfil. **O que acontece quando os cronogramas de um projeto de CRM e um projeto de ERP colidem?** Geralmente, uma dependência de integração ou uma única fonte de verdade comum (por exemplo, dados do cliente) é descoberta apenas em um estágio avançado. O PMO deve mapear as dependências entre os projetos desde o primeiro dia e determinar qual projeto 'lidera' em cada domínio de dados para evitar que duas decisões conflitantes sejam tomadas para o mesmo campo. --- ## Migração de CRM para Salesforce: Planejando a Transição sem Perda de Processos ou Dados URL: https://hpi.pro/pt/insights/replace-crm-with-salesforce A migração de sistemas CRM frequentemente falha não devido ao Salesforce, mas sim à decisão de transferir dados históricos sem a devida análise. Este artigo detalha como mapear processos existentes, selecionar o que será mantido e quando desativar o sistema antigo com segurança. ## A Resposta Curta Substituir um sistema de CRM pelo Salesforce não é um projeto técnico de "migração de dados" — é uma decisão organizacional sobre o que vale a pena reter, o que deve ser deixado para trás e como continuar operando o negócio enquanto a transição ocorre. A falha mais comum não reside no design do próprio Salesforce, mas na suposição tácita de que tudo o que existe no sistema antigo deve ser transferido exatamente como está. A abordagem correta começa com o mapeamento de processos, e não com a exportação de tabelas. Em seguida, um novo modelo de dados é construído, alinhado à forma como a organização opera hoje, e não à estrutura definida há dez anos em outro sistema. Um período de paralelismo controlado e, por fim, a desativação organizada do sistema antigo com documentação para conformidade regulatória, completam o processo. Organizações que lidam com essas questões encontram um contexto complementar em [Implementação do Salesforce em uma Organização](/pt/insights/salesforce-implementation-guide), onde o processo abrangente de tomada de decisões em um projeto Salesforce é detalhado. ## Mapeamento de Processos Existentes: Não Exportação, Mas Compreensão O primeiro passo em qualquer transição de sistemas CRM não é usar a função "Exportar", mas sim sentar-se com os proprietários dos processos e entender o que realmente acontece entre a abertura de um lead e o fechamento de um negócio, ou entre o registro de uma solicitação e o encerramento de um caso de serviço. Um documento de processo antigo, se é que existe, está quase sempre desatualizado em relação ao que ocorre na prática. Nas reuniões de mapeamento, é recomendável documentar não apenas os passos formais, mas também os "processos ocultos" — planilhas Excel paralelas, campos que ninguém preenche, aprovações que ocorrem via WhatsApp em vez de no sistema. São exatamente esses pontos que, se não forem considerados, podem levar ao fracasso da adoção de um novo sistema, mesmo que ele tenha sido construído corretamente. O resultado do mapeamento deve incluir uma tabela dos processos essenciais, o proprietário do processo, a frequência de uso e o grau de dependência do sistema antigo. Um processo acionado uma vez por trimestre que gera um relatório crítico para o regulador exige uma abordagem diferente de um processo diário de alto volume. Essa categorização também determina a ordem da migração e o nível de testes necessário para cada processo. ## O Que Não Migrar: Uma Decisão Que Economiza Metade do Trabalho Uma das decisões mais significativas em um projeto de migração de CRM não é o que migrar, mas o que **não** migrar. Na maioria dos sistemas antigos que se acumularam ao longo dos anos, há camadas de campos duplicados, status obsoletos e processos definidos para um projeto pontual que já foi concluído. Uma regra prática: qualquer objeto ou campo que não tenha sido acessado nos últimos dois anos é, por padrão, movido para a lista de "não migrar", a menos que um proprietário de processo específico solicite uma exceção justificada. Essa lista é construída com base nos logs de uso reais do sistema antigo, e não na memória dos usuários, pois, em geral, a memória humana descreve o sistema como ele deveria funcionar, e não como realmente funciona. É importante distinguir entre três categorias de informações: - **Dados Vivos** – Devem ser movidos para o novo sistema como registros ativos com todas as suas associações. - **Dados Históricos Relevantes** – Migram como arquivo para consulta, geralmente sem necessidade de edição ou automação. - **Dados Mortos** – Não são migrados de forma alguma, sendo mantidos apenas em backup externo para fins de auditoria, se necessário. Mais detalhes sobre a gestão dos limites entre as fases de planejamento e construção podem ser encontrados em [Scope Creep no Salesforce](/pt/insights/salesforce-scope-creep-change-control), pois a tendência de adicionar "apenas mais alguns dados antigos" é uma das fontes mais comuns de desvio de escopo nesse tipo de projeto. ## Modelo de Dados Novo versus Antigo: Não Tradução, Mas Design Um erro comum é abordar o modelo de dados como uma tradução 1:1 — cada tabela do sistema antigo se torna um objeto no Salesforce, cada coluna um campo. Essa abordagem preserva todas as fraquezas do sistema antigo dentro de uma nova plataforma e perde o principal benefício do Salesforce: a capacidade de construir relacionamentos flexíveis entre objetos, automação integrada e uma rica camada de permissões. Uma comparação entre as duas principais abordagens de transição ajuda a tomar uma decisão consciente: | Aspecto | Lift-and-Shift (Migração "como está") | Redesign (Redesenho) | | --- | --- | --- | | Tempo do Projeto | Relativamente curto, geralmente 6-10 semanas | Mais longo, geralmente 3-5 meses | | Adequação ao Processo de Negócio | Baixa — preserva limitações antigas | Alta — construído em torno do processo atual | | Risco de Débito Técnico | Alto, manifesta-se após um ou dois anos | Menor, porque a estrutura é planejada antecipadamente | | Custo de Manutenção Futura | Aumenta com o tempo | Relativamente estável | | Indicado para | Organizações com pressão de tempo extrema ou escopo muito limitado | A maioria das organizações que migram de um sistema com mais de três anos | | Risco Principal | "Sistema novo, problemas antigos" | Desvio de cronograma se o escopo não for delimitado | Na prática, a maioria das organizações opta por uma abordagem intermediária: Redesign para o modelo de dados central (contas, contatos, oportunidades ou casos de serviço) e Lift-and-Shift controlado para entidades secundárias que não têm impacto processual significativo. Essa decisão deve ser tomada explicitamente na fase de planejamento, e não surgir aleatoriamente durante a construção. ## Período de Paralelismo: Como Manter a Continuidade dos Negócios O período de paralelismo é a janela de tempo em que os dois sistemas operam lado a lado — geralmente entre quatro e oito semanas. Seu objetivo é expor lacunas em tempo real, antes que se tornem um problema irreversível. Uma venda fechada, uma solicitação de serviço aberta ou um relatório de comissões gerado — tudo isso deve ser verificado simultaneamente em ambos os sistemas e apresentar um resultado idêntico ou explicável. Uma pergunta que surge em quase todos os projetos: qual sistema é considerado a "fonte da verdade" durante esse período? A resposta deve ser única e predefinida, geralmente o Salesforce desde o primeiro dia, com o sistema antigo servindo apenas para validação e não para trabalho diário. O trabalho duplicado dos usuários em ambos os sistemas é uma receita para o cansaço e o abandono efetivo do novo sistema. Ferramentas práticas para gerenciar o período: - Relatório comparativo diário ou semanal entre os dados-chave dos dois sistemas (número de leads, valor de negócios, chamados abertos). - Lista de exceções viva, atualizada assim que uma lacuna é detectada, com um proprietário responsável por resolvê-la dentro de um período definido. - Grupo de "usuários âncora" de cada departamento que relatam diariamente falhas de uso, e não apenas falhas técnicas. Grande parte dos insights coletados durante esse período é relevante também para o processo de testes formal, detalhado no [Guia de UAT para Salesforce](/pt/insights/salesforce-uat-guide), e para o período pós-lançamento, descrito no [Plano de Hypercare para Salesforce](/pt/insights/salesforce-hypercare-plan). ## Desativação do Sistema Antigo: Não um Evento Único, Mas uma Sequência de Decisões A desativação do sistema antigo é realizada em etapas, não com um único clique no dia do cutover. A regra geral é: o sistema é desconectado do trabalho diário imediatamente após o Go Live, mas permanece acessível apenas para leitura por um curto período de graça, geralmente 30-60 dias, caso um dado ausente ou uma pergunta da equipe financeira seja detectada. ### Lista de Verificação para Decisão de Cutover Antes de emitir um aviso oficial de que o sistema antigo será desconectado, é aconselhável verificar: - ☐ Todos os relatórios gerados regularmente do sistema antigo foram replicados com sucesso no Salesforce ou no arquivo - ☐ Um ciclo de negócios completo (por exemplo, um mês de fechamento completo) foi concluído inteiramente no novo sistema - ☐ As lacunas de dados entre os sistemas caíram abaixo de um limite predefinido (por exemplo, menos de 1% dos registros) - ☐ Há uma confirmação por escrito da área jurídica ou financeira de que o arquivo atende aos requisitos de retenção - ☐ Foi definido quem é responsável pelo acesso de leitura durante o período de graça e quando ele será encerrado permanentemente - ☐ Foi feito um backup completo e verificado de todos os dados do sistema antigo antes do cancelamento da licença - ☐ Foi enviado um aviso a todos os proprietários de processos sobre a data final de desconexão e a forma de acesso ao arquivo Pular um desses itens é a razão mais comum pela qual, meses após o projeto, descobre-se que não há acesso a informações subitamente necessárias para uma auditoria fiscal ou processo judicial. ## Arquivo e Regulamentação: O Que É Preciso Guardar e Por Quanto Tempo Os requisitos de retenção de dados variam entre os setores, mas quase sempre há a obrigação de reter dados financeiros, contratuais ou relacionados a reclamações de clientes por um período de sete anos ou mais. O erro comum é tentar "empurrar" todo esse histórico para o Salesforce como registros ativos, o que sobrecarrega o desempenho e confunde os usuários que veem transações de uma década atrás em suas listas diárias. A solução comum é a separação entre duas camadas: | Camada | Conteúdo | Localização | Acessibilidade | | --- | --- | --- | --- | | Dados Operacionais Ativos | Últimos 24-36 meses | Salesforce | Total, incluindo edição e automação | | Arquivo Regulatório | Histórico completo conforme exigido por lei | Data warehouse externo ou Salesforce Archive | Somente leitura, com capacidade de busca | É crucial documentar a política de arquivamento por escrito e obter aprovação da área jurídica antes de desativar o acesso ao sistema antigo, pois, uma vez que a licença é cancelada, não há como voltar atrás se um dado ausente for detectado. ## Cenário Organizacional de Exemplo Uma empresa de serviços financeiros fez a transição de um sistema CRM local de 12 anos para o Salesforce. Durante a fase de mapeamento, a equipe identificou que aproximadamente 40% dos campos existentes não haviam sido tocados por dois anos ou mais e decidiu excluí-los da migração. Isso economizou cerca de um mês de trabalho em construção e testes. Durante o período de paralelismo, que durou seis semanas, foi descoberta uma discrepância no cálculo de comissões devido a uma diferença no arredondamento de números entre os sistemas — um problema que não teria sido detectado sem um relatório comparativo diário. A equipe corrigiu a fórmula antes que ela afetasse um contracheque real. O sistema antigo foi desconectado do trabalho diário no dia do Go Live, mas o acesso de leitura foi mantido por mais 45 dias para fins de validação de um relatório trimestral que já estava em andamento. O resultado: três meses após a desconexão final, nenhum acesso adicional ao sistema antigo foi necessário, e a economia nos custos de licenciamento cobriu uma parte significativa do custo do próprio projeto de migração. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Migrar "tudo" sem filtragem | O novo sistema fica sobrecarregado com dados mortos e dificulta a adoção | Definir critérios de filtragem com base no uso real nos últimos dois anos | | Modelo de dados copiado | As mesmas limitações do sistema antigo reaparecem no Salesforce | Projetar um novo modelo em torno do processo atual, não das tabelas antigas | | Paralelismo sem Proprietário | Lacunas entre os sistemas são descobertas tardiamente ou não são descobertas | Relatório comparativo periódico com um responsável definido para cada exceção | | Desconexão muito apressada | Um dado ausente é descoberto depois que a licença já foi cancelada | Período de carência de acesso apenas para leitura antes do cancelamento final | | Ignorar requisitos de arquivo | Auditoria regulatória revela que informações necessárias não foram retidas adequadamente | Obter aprovação legal por escrito da política de arquivo antes do cutover | ## Como Medir o Sucesso da Transição | Área | O que Medir | Frequência de Verificação | | --- | --- | --- | | Integridade dos Dados | Taxa de registros migrados com sucesso sem erro | Antes e depois de cada execução de migração | | Conformidade entre Sistemas | Lacunas nos relatórios-chave entre o sistema antigo e o novo | Diariamente durante o período de paralelismo | | Adoção pelos Usuários | Taxa de trabalho no novo sistema versus retorno ao antigo | Semanalmente no primeiro mês | | Custo Operacional | Economia em licenciamento e manutenção após a desconexão | Mensal a partir de três meses após o Go Live | Para a substituição de um sistema CRM pelo Salesforce, é aconselhável escolher apenas três a cinco métricas com antecedência e medi-las tanto antes quanto depois do projeto – caso contrário, é difícil provar que a transição realmente melhorou o processo e não apenas o transferiu para outra plataforma. A execução prática desse processo pode ser realizada com o apoio de [serviços de implementação do Salesforce](/pt/salesforce-implementation), que acompanham as organizações desde a fase de mapeamento até a desconexão do sistema antigo. ## Fontes Profissionais - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Implementação do Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology ### Perguntas e respostas **Quantos dados históricos devem ser migrados do sistema antigo?** Uma regra prática que funciona: os últimos 24 a 36 meses de dados devem ser migrados para o novo sistema como registros ativos. O restante deve ir para um arquivo acessível. Migrar dez anos de histórico 'porque é possível' encarece a migração e prejudica o desempenho sem benefício comercial comprovado. **O que fazer com campos que não têm um equivalente no novo modelo de dados?** Primeiro, verifique se o campo ainda é utilizado em um processo ativo ou se é um resquício histórico. Um campo ativo recebe um mapeamento explícito ou um novo campo personalizado (Custom Field); um campo obsoleto é preservado apenas no arquivo externo, sem ser arrastado para o Salesforce como um 'campo de texto livre' que ninguém entenderá em um ano. **Quanto tempo deve durar o período de paralelismo entre os sistemas?** Em média, de quatro a oito semanas para uma organização de porte médio, dependendo da complexidade do ciclo de vendas ou serviço. Um período muito curto não revela exceções sazonais; um período muito longo mantém nos usuários o hábito de trabalhar em ambos os sistemas e atrasa a adoção. **Quando é permitido desativar permanentemente o sistema antigo?** Somente após três condições serem cumpridas: reconciliação de dados entre os sistemas sem lacunas significativas, pelo menos um ciclo de negócios completo executado integralmente no Salesforce, e todos os relatórios regulatórios ou de auditoria baseados no sistema antigo foram reproduzidos com sucesso a partir do arquivo. **É necessário manter o acesso ativo ao sistema antigo após a migração?** Geralmente, o acesso ativo não é necessário além de um curto período de carência de 30 a 60 dias para verificações excepcionais. Após isso, um backup apenas para fins regulatórios e de auditoria é suficiente na maioria dos setores, mantendo os custos de licenciamento e manutenção significativamente mais baixos do que manter o sistema antigo ativo. --- ## Integração Salesforce-ERP: Guia de Arquitetura, Padrões e Riscos URL: https://hpi.pro/pt/insights/salesforce-erp-integration Em toda integração entre Salesforce e ERP, há um momento em que dois números entram em conflito – estoque, saldo devedor ou status do pedido – e alguém precisa decidir qual é o correto. Este guia foca a decisão na fonte da verdade, nos padrões de sincronização e no planejamento de falhas, em vez de apenas uma lista de integrações via API. ## A Resposta Breve A integração do Salesforce com o ERP geralmente falha, não por um problema técnico na conexão em si, mas por uma pergunta não feita de antemão: qual sistema é a fonte da verdade para cada entidade, e o que acontece quando a mensagem entre os sistemas se perde, chega duplicada ou em ordem incorreta? Este guia estrutura a decisão em três camadas — fonte da verdade, padrão de sincronização e tratamento de falhas — e mostra como escolhê-las com base em cenários de negócios reais, e não apenas no que a API permite. A abordagem recomendada é começar pelas entidades (cliente, produto, pedido, fatura) e não pela ferramenta. Para cada entidade, define-se um proprietário, uma taxa de atualização razoável e quem está autorizado a modificar. A partir daí, derivam-se o padrão de sincronização, o tratamento de erros e o nível de monitoramento necessário. Uma continuação natural da discussão sobre a integração do Salesforce com o ERP aparece em [Arquitetura Salesforce](/pt/insights/crm-architecture-guide). ## Fonte da Verdade para Cada Entidade: A Pergunta que Precede Qualquer API Antes de escolher um protocolo ou ferramenta de integração, é preciso responder a uma pergunta para cada entidade: qual sistema decide o que é verdadeiro em caso de conflito? Geralmente, o ERP é a fonte da verdade para estoque, lista de preços, faturas e transações financeiras, enquanto o Salesforce é a fonte da verdade para relacionamentos com clientes, oportunidades e atividades de vendas. O problema começa quando alguém assume tacitamente que as duas direções "se resolverão sozinhas" — e então surgem situações em que um representante de vendas altera o endereço de entrega no Salesforce enquanto o ERP já enviou a mercadoria para o endereço antigo. A solução prática é um documento de mapeamento de entidades: para cada entidade (Account, Product, Order, Invoice), são especificados a fonte da verdade, a direção da sincronização (unidirecional ou bidirecional) e a frequência de atualização necessária. Quando há uma necessidade real de sincronização bidirecional — por exemplo, a atualização do status de pagamento que retorna do ERP para o registro da oportunidade — estabelece-se uma regra explícita para a resolução de conflitos, como "a última atualização com base no timestamp prevalece" ou "campo financeiro sempre segundo o ERP". |Entidade|Fonte da Verdade|Direção da Sincronização|Frequência Típica| |---|---|---|---| |Cliente (Account)|Salesforce|Bidirecional com regra de conflito|Quase Imediata| |Produto e Lista de Preços|ERP|Unidirecional para Salesforce|Diária ou conforme alteração| |Pedido (Order)|Criado no Salesforce, gerenciado no ERP|Bidirecional, etapas separadas|Imediata na etapa de criação| |Fatura e Pagamento|ERP|Unidirecional para Salesforce|Diária ou Near Real-Time| |Estoque Disponível|ERP|Unidirecional para Salesforce|A cada poucos minutos a cada hora| ## Padrões de Sincronização: Request-Reply, Batch e Event-Driven Três padrões cobrem a maioria dos cenários reais. **Request-Reply (Síncrono)** é adequado quando um usuário do Salesforce aguarda uma resposta imediata — por exemplo, a verificação da disponibilidade de estoque antes da confirmação de um pedido. A vantagem é a simplicidade e a resposta imediata; a desvantagem é a dependência total da disponibilidade do ERP naquele momento e o impacto na experiência do usuário se a resposta for lenta. **Batch (Lote)** é adequado para atualizações de grande volume que não são urgentes, como a sincronização noturna de uma lista de preços ou a importação de faturas do dia anterior. O padrão é mais resistente a falhas temporárias, mas significa uma latência de horas a um dia entre os sistemas — uma lacuna que deve ser aceitável para o negócio, não apenas para a equipe técnica. **Event-Driven** (via Platform Events, Change Data Capture ou fila de mensagens externa) é adequado quando é necessária uma resposta quase imediata sem exigir dependência síncrona. Uma mudança de status de pedido no ERP emite um evento, e o Salesforce se atualiza quando estiver pronto — incluindo retry automático se estiver temporariamente indisponível. Este é o padrão mais flexível, mas também o mais complexo de configurar e monitorar. ### Tabela de Seleção de Padrão por Cenário |Cenário|Padrão Recomendado|Latência Típica|Risco Principal| |---|---|---|---| |Verificação de estoque antes da aprovação do pedido|Request-Reply|Poucos segundos|Dependência total da disponibilidade do ERP; Timeout impacta a experiência do usuário| |Sincronização de lista de preços e produtos|Batch Noturno|Horas a 24 horas|Dados desatualizados entre execuções; requer coordenação com campanhas e promoções| |Atualização do status de pagamento|Event-Driven|Segundos a minutos|Complexidade operacional; requer monitoramento da fila de mensagens e Dead Letter Queue| |Criação de novo pedido no ERP|Request-Reply com Retry|Segundos a um minuto|Falha parcial - pedido criado no ERP, mas a resposta perdida, risco de duplicidade| |Atualização de estoque disponível para venda|Batch frequente (a cada 15-60 minutos)|Minutos|Venda baseada em estoque já esgotado entre as execuções| |Alerta sobre excedente de limite de crédito|Event-Driven|Quase Imediato|Evento perdido causa aprovação de transação que não deveria ocorrer| Nesse contexto, a decisão sobre o tipo de sincronização está ligada também ao modelo de permissões e à propriedade dos dados — uma expansão sobre isso aparece em [Salesforce Sharing and Visibility](/pt/insights/salesforce-sharing-visibility-design). ## Middleware vs. Point-to-Point Quando há apenas uma conexão entre o Salesforce e o ERP, uma conexão direta (Point-to-Point) usando REST API ou Named Credentials pode ser a solução mais rápida e barata. O problema começa quando um terceiro sistema se junta — um data warehouse, um sistema de transporte ou uma plataforma de pagamento — e então cada novo sistema requer a construção de sua própria lógica de transformação e tratamento de erros, duplicando o que já existe na conexão anterior. Uma camada de Middleware (como MuleSoft, Boomi ou Workato) resolve isso centralizando a lógica: cada sistema se conecta uma vez ao Middleware, e o Middleware é responsável pela transformação, Retry, fila de mensagens e monitoramento centralizado. O custo é um componente de infraestrutura adicional que requer licença, manutenção e expertise especializada. Regra prática: até duas ou três conexões estáveis e sem lógica complexa — Point-to-Point é razoável. A partir de três sistemas ou mais, ou quando há uma demanda de Governança centralizada (como monitoramento uniforme para todas as integrações na organização), o custo do Middleware se justifica quase sempre em um a dois anos. ## Tratamento de Erros e Idempotência O cenário mais perigoso na integração não é uma falha completa, mas uma **falha parcial**: a mensagem foi enviada, o ERP criou um pedido, mas a resposta para o Salesforce foi perdida devido a um Timeout. Se o sistema remetente tentar novamente de forma ingênua, um pedido duplicado é criado. A solução é uma Idempotency Key — um identificador único criado no lado remetente e anexado a cada solicitação. O lado recebedor mantém um registro de identificadores já processados e recusa (ou retorna o resultado existente) se o identificador já existir. Princípios práticos adicionais: - Cada integração crítica recebe um mecanismo de Retry com Backoff gradual, não uma tentativa imediata e repetida - Mensagens que falharam repetidamente vão para uma Dead Letter Queue para revisão manual e não desaparecem silenciosamente - O log de erros inclui a carga útil completa (Payload) da mensagem que falhou, para permitir a recuperação manual - Um processo de Reconciliação diário ou semanal compara os sistemas e identifica lacunas que a sincronização "perdeu" Sem uma Idempotency Key e um processo de Reconciliação robusto, qualquer problema de rede transitório se torna um problema de dados persistente, difícil de rastrear semanas depois. ## Limitações de API, Segurança e Monitoramento O Salesforce impõe limites diários ao número de chamadas de API (dependendo da licença e edição), e limites no tamanho da resposta e tempo de execução. Uma organização que sincroniza dezenas de milhares de registros por dia via REST comum, chamada por chamada, atingirá o limite rapidamente. A solução é o Bulk API 2.0 para atualizações de volume, e o Composite API para reduzir o número de chamadas em processos síncronos de várias etapas. No lado da segurança, três princípios se repetem em cada projeto bem-sucedido: 1. O uso de Named Credentials e Connected Apps com OAuth, e não nomes de usuário e senhas fixos no código. 2. A permissão do "usuário técnico" da integração é restrita exatamente aos objetos e campos que precisa — não um Profile de administrador de sistema. 3. O tráfego sensível (números de cartão de crédito, detalhes de conta bancária) passa por uma camada de Middleware ou Tokenization, e não é armazenado como texto claro no Salesforce. Para o monitoramento, é necessário configurar um Dashboard que apresente pelo menos três dados: taxa de mensagens bem-sucedidas versus falhas, tempo médio e mediano de resposta, e número de registros na Dead Letter Queue. Um alerta automático quando a taxa de falhas ultrapassa um limite definido (por exemplo, acima de 2% das mensagens por dia) impede que um problema acumulativo seja descoberto apenas quando um cliente reclama. Essas decisões geralmente se baseiam em um trabalho fundamental anterior no campo da informação e permissões, descrito em [Dívida Técnica Salesforce](/pt/insights/salesforce-flow-apex-technical-debt). ## Processo de Trabalho Recomendado ### 1. Mapeie Entidades e Defina a Fonte da Verdade Para cada entidade (cliente, produto, pedido, fatura), determine qual sistema é o decisivo em caso de conflito. Sem essa decisão, qualquer discussão sobre "qual a forma correta de sincronizar" ocorre no vácuo. ### 2. Escolha um Padrão de Sincronização com Base na Latência Real Necessária Nem todo processo precisa de resposta imediata. A verificação de estoque antes da venda sim; a atualização noturna da lista de preços não. Adaptar o padrão à necessidade real economiza custos desnecessários de infraestrutura. ### 3. Decida entre Middleware e Point-to-Point A decisão depende do número de sistemas conectados e da necessidade de Governança centralizada, não de uma preferência tecnológica pura. ### 4. Planeje Idempotency, Retry e Reconciação desde o Início Estes não são "melhorias futuras", mas parte da Definição de Concluído (Definition of Done) para qualquer integração que lide com dinheiro, estoque ou pedidos. ### 5. Defina Permissões Mínimas para o Usuário Técnico Um Profile dedicado, não uma permissão genérica de administrador de sistema. Qualquer alteração na permissão requer aprovação separada da alteração funcional. ### 6. Teste Cenários de Falha, Não Apenas o Caminho Feliz (Happy Path) Executar um teste onde o ERP "cai" no meio de um processo e medir o tempo de recuperação e se ocorrem duplicações, revela problemas que não são visíveis em um ambiente de desenvolvimento tranquilo. ### 7. Estabeleça um Dashboard e um Processo de Reconciliação Periódico O monitoramento técnico (o servidor está ativo) não é suficiente; é necessário monitoramento de negócios (o número de pedidos é igual em ambos os sistemas). ## Cenário Organizacional de Exemplo Uma empresa de comércio com cerca de 40 mil pedidos por mês conectou o Salesforce ao ERP usando chamadas REST síncronas diretas, sem Middleware. Durante um período de pico de vendas, a taxa de falhas nas chamadas de API aumentou drasticamente devido ao limite de chamadas diárias, e os pedidos que não puderam ser registrados no ERP simplesmente "desapareceram" — porque não havia Dead Letter Queue e nenhum alerta. Após a análise, descobriu-se que faltavam três coisas: não havia Idempotency Key definida, resultando em tentativas repetidas que às vezes criavam pedidos duplicados; não havia transição para o Bulk API para atualizações de volume; e não havia um processo de Reconciliação que comparasse o número de pedidos em ambos os sistemas. A solução incluiu a transição para uma camada de Middleware com uma fila de mensagens, a substituição de parte das chamadas síncronas por Batch frequente e a adição de um Dashboard diário que mostrava as discrepâncias. O resultado não foi "صفر falhas" — isso é um objetivo irreal — mas sim um tempo de identificação de falha que diminuiu de semanas para horas, e um processo que permite corrigir uma discrepância no mesmo dia, e não depois que um cliente reclama. ## Riscos Comuns e Ações Preventivas |Risco|Como se manifesta na prática|Ação Preventiva| |---|---|---| |Nenhuma fonte da verdade definida|Dois lados "corretos" simultaneamente, e ninguém sabe em quem confiar|Documento de mapeamento de entidades com proprietário definido para cada campo crítico| |Falta de Idempotency|Pedidos duplicados após qualquer falha temporária de rede|Idempotency Key e verificação de duplicidade no lado receptor| |Point-to-Point sem Governança|Qualquer mudança em um sistema quebra outras conexões silenciosamente|Camada de Middleware, contratos documentados e propriedade clara| |Ignorar limites de API|Chamadas falham no pico de carga, sem aviso prévio|Transição para Bulk API, monitoramento do consumo diário da cota| |Permissões amplas para o usuário técnico|Exposição de informações sensíveis além da necessidade da integração|Profile restrito e revisão periódica de permissões| Quem está em uma fase anterior ao planejamento da conexão pode encontrar informações complementares em [Salesforce Flow ou Apex](/pt/insights/salesforce-flow-vs-apex), principalmente na decisão sobre onde realmente reside a lógica de transformação. ## Como Medir o Sucesso |Área|O Que Medir|Frequência de Verificação| |---|---|---| |Confiabilidade|Taxa de mensagens concluídas versus falhas|Contínuo, com alerta sobre exceder o limite| |Latência|Tempo de ponta a ponta para cada cenário separadamente|Contínuo| |Consistência de Dados|Número de discrepâncias na verificação de Reconciliação|Diário ou semanal| |Custo Operacional|Horas de suporte dedicadas a falhas de integração|Mensal| É aconselhável escolher apenas três a quatro métricas para a primeira versão e medi-las também antes do lançamento para ter uma linha de base real para comparação, e não uma estimativa de memória. ## Checklist Antes de Entrar em Produção - ☐ Para cada entidade, uma fonte da verdade e uma regra para resolução de conflitos são definidas - ☐ Um padrão de sincronização (Request-Reply, Batch ou Event-Driven) é escolhido para cada processo separadamente - ☐ Foi decidido se é necessário Middleware ou se uma conexão direta é suficiente - ☐ Existe uma Idempotency Key para cada operação que cria um registro financeiro - ☐ Retry com Backoff e Dead Letter Queue são definidos para mensagens que falharam - ☐ O consumo diário da cota de API foi verificado em relação ao volume esperado - ☐ A permissão do usuário técnico é restrita apenas aos objetos e campos necessários - ☐ Foi realizado um teste de falha parcial, não apenas o Happy Path - ☐ Existe um Dashboard para monitoramento de negócios, não apenas técnico - ☐ Um processo de Reconciliação periódico e um responsável são definidos ## Notas Aprofundadas para Implementação e Manutenção ### Nota do Arquiteto: Quando Alterar um Padrão Existente Se um padrão Batch noturno foi escolhido inicialmente por simplicidade, mas o negócio começa a exigir uma atualização de estoque quase imediata, não há necessidade de "explodir" toda a arquitetura — pode-se aumentar a frequência para 15 minutos como estágio intermediário e mudar para Event-Driven somente quando ficar claro que isso também não é suficiente. Uma mudança gradual, acompanhada da medição da latência real, é preferível a uma decisão abrangente e prematura. De uma perspectiva gerencial, o verdadeiro teste da integração do Salesforce com o ERP não é apenas que "funciona hoje", mas que se pode explicar em cinco minutos por que cada padrão foi escolhido e quem é responsável por corrigi-lo quando algo dá errado. Uma solução que exige uma longa investigação para cada falha cria um custo operacional oculto que aumenta com o tempo. Quando falta capacidade interna para planejar ou implementar tal conexão, o [serviço de arquitetura de CRM](/pt/crm-architecture) é o caminho prático a seguir. ## Recursos Profissionais - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitetura de CRM — https://hpi.pro/crm-architecture - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **O que fazer quando o ERP e o Salesforce divergem sobre o status de um cliente?** Primeiro, defina qual sistema é a fonte da verdade para cada entidade – geralmente o ERP para faturamento e estoque, e o Salesforce para o relacionamento com o cliente. Em seguida, estabeleça uma regra diária de reconciliação que destaque as divergências, ao invés de presumir que um 'sync verde' significa que os dados estão realmente consistentes. **Quando o Point-to-Point é suficiente e quando o Middleware é indispensável?** Para até duas ou três conexões estáveis, Point-to-Point pode ser suficiente. Contudo, a partir de três ou mais sistemas, lógica de transformação comum ou a necessidade de retentativas e monitoramento centralizado, uma camada de Middleware, como MuleSoft, evita a proliferação de múltiplas versões da mesma lógica em cada extremidade. **Como manter a Idempotência quando uma mensagem é enviada duas vezes?** Cada mensagem recebe um identificador único (Idempotency Key). No lado receptor, verifica-se se o identificador já foi processado antes de criar um novo registro. Na prática, isso é armazenado em um campo externo dedicado no registro ou em uma tabela de log separada, para que uma execução duplicada não crie um pedido duplicado. **O que acontece ao atingir o limite diário de chamadas de API do Salesforce?** É necessário migrar de chamadas síncronas frequentes para processamento em massa (Bulk API) ou reduzir a frequência de Polling. Uma organização com dezenas de milhares de atualizações de pedidos por dia quase sempre encontrará o limite se usar REST comum em vez de Bulk API 2.0. **Como testar uma integração com o ERP antes de colocá-la em produção?** Configure um ambiente de Staging com uma cópia representativa dos dados, execute um cenário completo, incluindo falhas parciais (ERP indisponível, mensagem corrompida, duplicidade), e meça o tempo de recuperação da consistência. A aprovação de negócio só deve ser concedida após a apresentação dos cenários de falha, e não apenas do 'Happy Path'. --- ## Migração de Dados para Salesforce: Guia Completo para Planejamento, Limpeza e Cutover URL: https://hpi.pro/pt/insights/salesforce-data-migration-guide A maioria das falhas na migração não se deve à ferramenta, mas sim à ordem de carregamento incorreta, mapeamento de campos apressado e falta de reconciliação. Este guia estabelece um processo completo: perfil de dados, limpeza, External IDs, Dry Run e correções pós-Go Live. ## A Resposta Concisa A migração de dados para o Salesforce frequentemente falha, não devido à ferramenta, mas sim a um fluxo de trabalho deficiente: iniciar o carregamento antes de compreender a qualidade da fonte, mapear campos em uma única planilha sem verificar valores discrepantes e carregar sem respeitar as dependências entre objetos. Um processo adequado é construído como um ciclo iterativo: perfil (profiling), mapeamento, limpeza, carregamento controlado, teste e reconciliação — e somente então o Cutover. O objetivo deste artigo é detalhar este ciclo de vida em etapas claras, com uma tabela de ordem de carregamento e um checklist de reconciliação que podem ser utilizados na prática. Na maioria dos projetos, a diferença entre uma migração tranquila e uma migração que requer retrabalho é determinada já na primeira semana, na fase de perfil da fonte. O trabalho de limpeza antecipada evita danos posteriores, e vale a pena ler mais sobre isso em [Limpeza de Dados Duplicados no Salesforce](/pt/insights/salesforce-data-deduplication). ## Perfil da Fonte: Conhecendo os Dados Antes de Intervir Antes de mapear qualquer campo, é essencial realizar um perfil da fonte de dados: quantas entradas existem em cada tabela, quais campos estão realmente vazios (não apenas no esquema, mas nos próprios dados), qual a faixa de valores em campos numéricos e de data, e onde há valores de texto livre que deveriam ser uma lista de seleção fechada. Em um projeto que acompanhamos, o campo "status do cliente" continha 47 formulações diferentes na origem — "ativo", "Active", "ativo " com espaço, "A" — todos deveriam ser mapeados para um único valor no Salesforce. Ferramentas como OpenRefine, consultas SQL simples ou até mesmo uma Tabela Dinâmica no Excel sobre uma amostra dos dados são suficientes para a maioria dos projetos. O objetivo é criar um documento de perfil que mostre: número total de registros, porcentagem de campos obrigatórios vazios, número de valores únicos para cada campo categórico e uma identificação inicial de possíveis duplicatas por nome, telefone ou e-mail. Nesta etapa, também se identifica se há várias fontes para informações sobrepostas — por exemplo, o mesmo cliente existe tanto no CRM antigo quanto no sistema de contabilidade — e se decide qual fonte é a "Source of Truth" para cada campo. Tal decisão deve ser documentada, não implícita, pois afeta todas as etapas subsequentes. ## Mapeamento de Campos: Além da Planilha do Excel Um bom mapeamento de campos não é apenas "coluna A da origem = campo B do destino". Ele também inclui a direção da transformação: formato de data, conversão de unidades, divisão de um campo de endereço em rua/cidade/CEP e a resolução para valores que não existem na lista de seleção fechada de destino. O melhor documento de mapeamento que vimos incluía cinco colunas: campo de origem, campo de destino, tipo de transformação, regra para tratamento de valor ausente e exemplo de entrada/saída. Campos de Lookup e Master-Detail devem ser tratados separadamente: eles não contêm um valor direto, mas uma referência a outro registro. Portanto, seu mapeamento depende de o registro vinculado já ter sido carregado e possuir um identificador ao qual se possa apontar. Esta é a razão pela qual a ordem de carregamento (discutida posteriormente) e o mapeamento de campos são dois lados da mesma decisão. Uma visão mais aprofundada sobre a gestão da qualidade dos campos ao longo do tempo, não apenas em uma fase única, pode ser encontrada em [Qualidade de Dados Salesforce](/pt/insights/salesforce-data-quality-metrics). ## Limpeza e Duplicatas: Antes do Carregamento, Não Depois Uma limpeza de dados realizada após a informação já estar no ambiente de produção é muito mais cara: ela envolve a atualização de registros ativos, o risco de quebrar automações e processos de aprovação, e às vezes, até mesmo danos a relatórios que já foram distribuídos à gerência. Portanto, a fase de limpeza deve ocorrer na camada intermediária (Staging), antes que os dados entrem no Salesforce. Principais regras de limpeza a serem definidas antecipadamente: - Normalização de telefone e e-mail (remoção de espaços, formato internacional consistente) - Identificação de duplicatas por combinação de campos (nome + telefone, ou apenas CPF/CNPJ para empresas) - Regra de seleção do registro "Master" ao mesclar duplicatas — por exemplo, o registro mais atualizado ou o mais completo - Tratamento de valores nulos versus strings vazias, para evitar "duplicatas fantasmas" Em um projeto típico com cerca de 80.000 registros de clientes, uma limpeza razoável identificará entre 3% e 8% de duplicatas reais. Um número significativamente maior sugere que a própria fonte não foi mantida, justificando uma discussão com os proprietários do processo de negócio antes de prosseguir. ## External IDs e Ordem de Carregamento Um External ID é um campo único do sistema de origem que também é armazenado no Salesforce, permitindo o carregamento repetitivo (Upsert) sem criar duplicatas a cada vez que um arquivo é executado novamente. Sem um External ID, cada execução repetida do Data Loader pode criar uma cópia adicional do mesmo registro, pois o sistema não consegue "identificar" um registro existente. A ordem de carregamento é determinada pelas dependências entre os objetos: não é possível carregar um Contato antes que a Conta à qual está associado exista, e não é possível carregar um Item de Linha de Oportunidade antes da Oportunidade em si. | Etapa | Objeto | Dependência | Observação sobre External ID | | --- | --- | --- | --- | | 1 | Account | Sem dependência | ID do cliente do sistema de origem (ERP/CRM antigo) | | 2 | Contact | Dependente de Account | ID do contato + Lookup para o External ID da Account | | 3 | Opportunity | Dependente de Account, Contact | ID da oportunidade do sistema de origem | | 4 | Product / PriceBook Entry | Sem dependência (carregar em paralelo com etapas 1-2) | SKU como External ID | | 5 | Opportunity Line Item | Dependente de Opportunity, Product | Combinação de ID da oportunidade + linha | | 6 | Case / Activity History | Dependente de Account, Contact | ID do caso do sistema de origem | Desviar-se desta ordem é um dos erros mais comuns em projetos de migração: uma equipe que tenta "economizar tempo" carregando todos os arquivos em paralelo descobre milhares de erros de Lookup que são difíceis de depurar posteriormente, pois não está claro se o erro resulta de dados ausentes ou de uma ordem de carregamento incorreta. ## Ambientes e Testes A migração não é carregada diretamente para produção. Uma estrutura de ambientes recomendada inclui um Sandbox dedicado à migração (separado do Sandbox de desenvolvimento contínuo), onde o mesmo volume de dados e a mesma configuração de Validation Rules e Triggers são carregados, para expor problemas antes que afetem usuários reais. Os testes nesta fase incluem teste de volume (se o carregamento é concluído em um tempo razoável), teste de erros (qual porcentagem de registros é rejeitada e por quê) e teste do comportamento das automações — um Flow ou Trigger que é executado na criação de um registro pode enviar um e-mail real para um cliente se não for desativado temporariamente no ambiente de teste. A negligência deste detalhe causou, em um projeto, o envio de milhares de e-mails de "boas-vindas" duplicados para clientes existentes. ## Dry Run: Execução Completa Repetida Um Dry Run é uma execução completa do processo de carregamento em condições o mais próximas possível da produção — o mesmo volume, os mesmos arquivos, a mesma ordem — mas em um ambiente Sandbox. O objetivo é medir duas coisas: o tempo de execução real (para planejar a janela de Cutover de forma realista) e a porcentagem de erros em cada etapa. É recomendável realizar pelo menos dois Dry Runs completos: o primeiro expõe a maioria dos problemas, o segundo verifica se as correções os resolveram e não criaram novos. Se um segundo Dry Run ainda apresentar mais de 1%-2% de erros em objetos críticos, geralmente é preferível adiar a data do Cutover a comprometer a qualidade. ## Cutover e Reconciliação de Dados O Cutover é a janela real em que o sistema antigo é congelado (Freeze), as informações mais atualizadas são carregadas no Salesforce, e os usuários começam a trabalhar no novo sistema. O sucesso nesta etapa é medido não apenas se "o carregamento foi concluído", mas pela Reconciliação — uma comparação sistemática entre a origem e o destino. Checklist de Reconciliação a ser executado no final de cada Cutover: - ☐ Contagem de registros idêntica (ou explicada por uma diferença conhecida) em cada objeto principal - ☐ Soma de campos financeiros (por exemplo, o valor total de oportunidades abertas) corresponde entre as fontes - ☐ Amostra aleatória de 30-50 registros verificada manualmente campo a campo - ☐ Verificação de relacionamentos — cada Contato tem uma Conta válida, cada Item de Linha de Oportunidade tem uma Oportunidade - ☐ Verificação de registros "órfãos" — carregados sem uma referência válida - ☐ Comparação da contagem de duplicatas antes e depois em relação ao objetivo estabelecido na fase de limpeza - ☐ Aprovação do proprietário do processo de negócio de que sua amostra de dados parece correta Discrepâncias comuns de Reconciliação incluem: contagem de registros correspondente, mas totais incorretos porque um campo numérico foi carregado em formato errado; ou relacionamentos ausentes porque um Lookup foi carregado por valor de texto e não por External ID. A documentação completa do processo de reconciliação, incluindo um exemplo de Baseline, também pode ser encontrada em [Gestão de Dados Mestre Salesforce](/pt/insights/salesforce-master-data-management). ## Correções Pós Go Live Mesmo um Cutover bem-sucedido deixa um "vestígio" de correções: registros individuais que foram rejeitados no carregamento, usuários que relatam dados ausentes e lacunas que só são descobertas quando usuários reais trabalham com o sistema e não apenas o testam. Uma janela de duas a quatro semanas deve ser alocada antecipadamente para correções pontuais, com um relatório diário de exceções na primeira semana e semanalmente depois. É importante distinguir entre uma correção pontual (um único registro atualizado manualmente) e uma correção sistêmica (um erro de mapeamento que se repete em milhares de registros e requer correção na própria ferramenta de carregamento e uma nova execução). A confusão entre os dois leva as equipes a corrigir manualmente um problema que é, na verdade, sistemático, e a perder muito tempo. ## Cenário Organizacional de Exemplo Uma empresa de distribuição com cerca de 120.000 clientes em um CRM antigo e uma lista separada de clientes em seu sistema de contabilidade solicitou a migração de ambas as fontes para um único Salesforce. Um perfil inicial revelou que 11% dos clientes apareciam em ambas as fontes com informações de contato diferentes, e o campo "ramo de atividade" continha 340 valores livres que deveriam ser cerca de 25 categorias. A equipe construiu um mapeamento de campos detalhado, estabeleceu uma regra de mesclagem combinando CPF/CNPJ e telefone, e definiu o sistema de contabilidade como a "Source of Truth" para informações de faturamento e o CRM antigo como a "Source of Truth" para informações de contato. Um primeiro Dry Run revelou que 4% dos registros foram rejeitados devido a um formato de data inválido — uma correção que foi considerada no segundo Dry Run. O Cutover foi realizado no final de semana, com Reconciliação completa na manhã de segunda-feira antes da abertura do sistema para os usuários. O resultado: menos de 0,3% dos registros exigiram correção manual após o Go Live, em comparação com uma estimativa inicial da equipe que esperava cerca de 5% de exceções. A diferença resultou quase inteiramente dos dois Dry Runs realizados antes da data oficial. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação preventiva | | --- | --- | --- | | Identidades não unificadas | O mesmo cliente aciona processos duplicados | Regra de unificação por External ID e Golden Record | | Carregamento sem External ID | Reexecução cria novas duplicatas | Definir External ID antes da primeira execução | | Ordem de carregamento incorreta | Erros massivos de Lookup difíceis de depurar | Carregamento conforme tabela de dependências predefinida | | Omissão do Dry Run | Janela de Cutover se estende e surpresas são descobertas em tempo real | Pelo menos duas execuções completas no ambiente de teste | | Sem Reconciliação | Contagem de registros correta, mas totais e relacionamentos errados | Testes de contagem, soma, relacionamento e amostragem em cada Cutover | No nível de gestão da migração de dados para o Salesforce, esta tabela de riscos é apenas um ponto de partida. Uma extensão sobre a gestão contínua da qualidade, incluindo a diferença entre limpeza pontual e governança de dados contínua, pode ser encontrada em [Data 360 Zero Copy](/pt/insights/data-360-zero-copy-federation). ## Como Medir o Sucesso | Área | O que medir | Frequência de verificação | | --- | --- | --- | | Completude | Taxa de campos obrigatórios e informações críticas preenchidos | Antes e depois de cada carregamento | | Unicidade | Taxa de duplicatas por entidade | Antes do Dry Run e após o Cutover | | Validade | Valores que correspondem às regras de formato e negócio | Em cada Batch de carregamento | | Reconciliação | Conformidade de contagens, somas e relacionamentos com a origem | Em cada Rehearsal e no Cutover | | Tempo de Execução | Duração real do carregamento vs. janela de Cutover planejada | Em cada execução de Dry Run | Para a maioria dos projetos, de três a cinco métricas são suficientes para a primeira versão. Uma boa métrica pode ser calculada antes e depois da mudança, está relacionada a um proprietário de processo de negócio e não pode ser artificialmente melhorada pela inserção parcial de dados. Quando não há uma linha de base documentada do sistema antigo, é aconselhável investir um ou dois dias na medição do estado atual antes de relatar melhorias. ## Checklist Antes do Go Live - ☐ Perfil da fonte realizado, incluindo porcentagens de campos vazios e duplicatas - ☐ Documento de mapeamento de campos completo, incluindo transformações e tratamento de valores ausentes - ☐ External ID definido para cada objeto que requer carregamento repetitivo - ☐ Ordem de carregamento documentada e acordada pela equipe técnica - ☐ Dois Dry Runs realizados e os erros reduzidos abaixo do limite estabelecido - ☐ Cenário de Rollback documentado para o caso de falha no Cutover - ☐ Checklist de Reconciliação pronto e quem irá executá-lo é conhecido antecipadamente - ☐ Janela de correções após o Go Live alocada no cronograma - ☐ Automações que possam enviar comunicações a clientes verificadas e desativadas durante o carregamento - ☐ Proprietário do processo de negócio aprovou uma amostra final de dados ## Notas aprofundadas para Implementação e Manutenção ### Nota do Arquiteto: Migração Não é um Evento Único Mesmo após um Go Live bem-sucedido, mudanças no sistema de origem (se ele continuar operando temporariamente em paralelo) ou correções manuais criam desvio entre os dados. Portanto, é aconselhável manter um relatório de Reconciliação regular — semanal no primeiro mês, mensal depois — que compare uma amostra de dados entre os relatórios antigos e novos e identifique desvios precocemente. Um projeto que trata a migração como uma linha de chegada ignora que a qualidade dos dados é um processo contínuo. Do ponto de vista gerencial, o verdadeiro teste de uma migração de dados para o Salesforce não é apenas se os registros foram carregados, mas se os gerentes de Dados, CRM e Projetos podem confiar nos relatórios do dia seguinte sem verificar manualmente cada número. Organizações que buscam apoio profissional para tal processo podem utilizar o [serviço de integrações e dados](/pt/integrations-data), que acompanha tanto a fase de planejamento quanto a própria janela de Cutover. ## Fontes Profissionais - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integrações e Dados — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Perguntas e respostas **Com quanto tempo de antecedência antes do Cutover deve ser realizada a primeira execução do Dry Run?** É altamente recomendável executar um Dry Run completo pelo menos três a quatro semanas antes da data de Go Live, e uma segunda execução uma a duas semanas antes. Isso permite tempo para corrigir exceções, medir a duração real do carregamento e garantir que a janela alocada para o Cutover seja suficiente, mesmo com uma margem de segurança. **O que fazer quando a duplicação de clientes é descoberta apenas após o sistema já estar em uso?** Execute uma regra de unificação baseada em um identificador comercial (por exemplo, ID fiscal ou e-mail normalizado), selecione um registro Mestre com base na atualidade e integridade dos dados e mescle usando uma ferramenta de mesclagem ou um processo controlado que atualiza relacionamentos antes de excluir o duplicado. Tal ação requer um backup completo antes da execução. **É possível pular os External IDs e confiar apenas nos nomes para fazer a correspondência dos registros?** Não é recomendável. Nomes se repetem, mudam entre sistemas e contêm espaços ou caracteres diferentes. Um External ID exclusivo do sistema de origem garante um mapeamento unívoco, permite o carregamento repetido (Upsert) sem duplicatas e reduz significativamente o tempo de resolução de problemas. **Qual é a ordem de carregamento correta quando há um único arquivo com todos os tipos de registros misturados?** É preciso dividir o arquivo por objeto e carregar primeiro as entidades sem dependências (contas), depois as entidades dependentes (contatos, oportunidades) e, finalmente, os relacionamentos e itens detalhados. Um carregamento misto sem ordem cria erros de Lookup e registros órfãos que são difíceis de rastrear posteriormente. **Quanto tempo deve ser reservado para correções pós-Go Live antes de fechar o projeto?** Em um projeto de migração de médio porte, é aconselhável alocar de duas a quatro semanas de monitoramento rigoroso, durante as quais relatórios diários de exceções, disparidades de reconciliação e reclamações de usuários são verificados. Somente após dois ciclos de relatórios limpos (duas semanas) pode-se declarar o encerramento da fase de correções. --- ## Agentforce para Organizações: Quando é a Escolha Certa e Quando Ainda Não URL: https://hpi.pro/pt/insights/agentforce-for-enterprises Nem todo processo se beneficia de um agente de IA autônomo. Este guia oferece uma estrutura operacional de decisão – abrangendo maturidade de dados, Grounding, permissões e Human-in-the-loop – que distingue casos de uso prontos para Agentforce daqueles mais adequados à automação clássica. ## A Resposta Curta Para organizações, a implementação do Agentforce não é uma questão de "se o Salesforce suporta", mas sim de maturidade: existe uma fonte confiável de dados, está claro quem aprova uma ação sensível e qual linha de base distinguirá sucesso de fracasso? Uma organização que pula essas perguntas e corre direto para construir um agente descobrirá a lacuna no segundo mês, quando o custo aumenta e os resultados não são consistentes. A abordagem correta começa com a filtragem de processos, continua verificando a prontidão e as permissões dos dados e termina com um piloto medido com critérios claros para prosseguir ou parar. Quem ainda está construindo uma fundação pode começar na [Prontidão para Agentforce](/pt/insights/agentforce-salesforce-ai-guide), onde a diferença entre Copilot, Flow e o Agentforce em si é explicada. ## Seis Focos de Prontidão Antes de escolher o primeiro caso de uso, vale a pena mapear a organização em seis áreas. Qualquer área que permaneça no nível de "não sabemos" é um risco que será descoberto no projeto piloto e não antes. | Área de Prontidão | Pergunta Central | Sinal de Alerta Comum | | --- | --- | --- | | Maturidade de Dados e Conhecimento | Existe uma única fonte de dados, atualizada e aprovada? | Knowledge Base antigo, contradições entre documentos | | Grounding | O agente recupera informações reais ou está adivinhando? | Respostas convincentes, mas factualmente incorretas | | Tópicos e Ações | Cada Tópico é definido dentro de limites estreitos? | Um único agente que deve "responder a tudo" | | Permissões e Segurança | O agente atua de acordo com as permissões reais do usuário? | Permissão de Sistema que retorna informações a qualquer um | | Human-in-the-loop | Quem aprova uma ação irreversível? | Ação financeira ou legal sem supervisão | | Medição e Custo | Existe uma linha de base para comparação? | "Parece impressionante" sem um número para comparar | ### Maturidade de Dados e Conhecimento Um bom agente de IA é tão bom quanto as informações que o alimentam. Em uma organização de serviços com três sistemas de Knowledge Base não sincronizados, o agente aprenderá com a primeira fonte que encontrar – mesmo que seja a menos precisa. Antes de qualquer trabalho técnico, é aconselhável verificar: quando cada documento foi atualizado pela última vez, quem é o responsável por ele e o que acontece quando há dois documentos contraditórios. Organizações que ignoram essa etapa chegam ao piloto com um agente que gera respostas confiantes, mas incorretas, o que é pior do que "não sei". ### Grounding Grounding é o mecanismo de busca que alimenta o agente com informações reais antes de formular uma resposta, em vez de depender do conhecimento geral do modelo. A profundidade do tópico, incluindo considerações de Chunking, Vector Search e separação entre fontes internas e externas, é detalhada em [Agentforce Grounding](/pt/insights/agentforce-grounding-rag). No nível da decisão gerencial, basta saber que, sem um Grounding sólido, todo o resto do investimento – design de conversa, Ações, interface – é construído sobre uma base fraca. ### Tópicos e Ações O erro mais comum é construir um único agente com um Tópico amplo como "atendimento ao cliente" em vez de vários Tópicos estreitos como "verificar status do pedido" ou "atualizar informações de faturamento". Um Tópico estreito é mais fácil de testar, mais fácil de explicar ao usuário por que o agente não respondeu e mais fácil de adicionar Ações gradualmente. A própria Ação deve operar sob permissões restritas, passar por validação de entrada e retornar um erro claro quando algo não estiver em conformidade – não adivinhar a continuação. ### Permissões e Segurança Um agente que opera sob uma permissão de integração abrangente pode inadvertidamente expor informações que o usuário interagindo com ele não deveria ver – como o salário de outro funcionário, o pedido de outro cliente ou um comentário interno sensível. A recomendação profissional é executar o agente sob o contexto de permissões do usuário real (Run As User) sempre que possível, e documentar qualquer exceção a esse modelo como uma decisão consciente com um Proprietário. ### Human-in-the-loop Nem toda ação exige aprovação humana, mas toda ação irreversível exige. Enviar um reembolso, cancelar um pedido, alterar uma permissão de acesso – esses são os pontos em que é preferível permitir que o agente prepare a ação e pare antes da execução, pelo menos nos primeiros meses. Com o tempo, quando as métricas provarem alta precisão em um subconjunto específico, a aprovação pode ser removida gradualmente e não de uma vez. ### Medição e Custo O custo do Agentforce não é apenas licenciamento – ele inclui tokens, chamadas de API e infraestrutura para monitoramento. A questão financeira completa, incluindo exemplos de precificação e cenários de escala, está em [Preço do Agentforce](/pt/insights/agentforce-cost-tco). Sem uma linha de base de "quanto tempo leva para um representante realizar a tarefa hoje", é impossível saber se o agente está economizando dinheiro ou apenas adicionando uma camada de complexidade. ## Tabela de Adequação: Fit ou No-Fit Esta tabela não substitui uma análise aprofundada, mas é uma ferramenta de triagem rápida antes de investir semanas na verificação de um caso de uso que, de qualquer forma, não amadureceria. | Caso de Uso | Adequação | Razão | | --- | --- | --- | | Responder a FAQs de um Knowledge Base atualizado | Alto Fit | Informação estruturada, baixo risco, melhoria mensurável no tempo de resposta | | Verificação de status de pedido e atualização de detalhes de entrega | Alto Fit | Dado fechado no sistema, Ação simples, fácil de verificar | | Análise de tendência de vendas complexas multi-anuais | Fit Parcial | Exige contexto de negócios profundo; adequado apenas para estágio avançado | | Aprovação de crédito ou alteração de termos de contrato | No-Fit no estágio inicial | Alto impacto financeiro, exige aprovação humana constante | | Aconselhamento médico, jurídico ou regulatório para o cliente final | No-Fit | Risco de litígio e responsabilidade; exige controle humano completo | | Elaboração de rascunho de conteúdo de marketing para revisão humana | Alto Fit | A saída não é final, o humano sempre revisa antes da publicação | ## Plano de Piloto Realista ### Etapa 1: Seleção de um Único Caso de Uso (Semana 1) Escolhe-se um único processo da tabela que foi marcado como Alto Fit, define-se a linha de base (tempo médio de tratamento, taxa de escalonamento atual) e registra-se o que é considerado sucesso. O Patrocinador de Negócios assina o escopo. ### Etapa 2: Construção do Grounding e do Primeiro Tópico (Semanas 2-3) Conecta-se uma única e verificada fonte de dados, constrói-se um Tópico estreito com no máximo 2-3 Ações e define-se as permissões de acordo com o usuário. Cada Ação passa por um teste de entrada inválida antes de ser considerada pronta. ### Etapa 3: Execução Interna Controlada (Semanas 4-5) Um grupo restrito de usuários (5-15 pessoas) testa o agente em cenários reais, incluindo Aprovação Humana para qualquer ação significativa. Registram-se Traces e erros por gravidade. ### Etapa 4: Medição em Relação à Linha de Base (Semanas 6-8) Compara-se o tempo de tratamento, a taxa de sucesso e o custo com a primeira etapa. É aqui que entram os critérios de Go/No-Go: - **Go**: Taxa de conclusão da tarefa sem escalonamento acima de 70%, custo por tarefa inferior à alternativa humana, zero incidentes de segurança ou permissão - **Expansão Gradual**: Taxa de conclusão de 50-70% - continua, mas restringe o escopo para uma subtarefa com maior sucesso - **No-Go**: Taxa de conclusão abaixo de 50%, ou um incidente de permissão - retorna à etapa de dados e permissões antes de qualquer expansão Testes mais abrangentes, incluindo metodologia de Scorers automatizada, são descritos em [Testes do Agentforce](/pt/insights/agentforce-testing-scorers). ## Cenário Organizacional Exemplo Uma empresa de serviços com um call center de 40 agentes queria implementar o Agentforce para reduzir a carga de trabalho. A gerência pediu "um agente que responda a tudo". Na verificação de prontidão, descobriu-se que havia três bases de conhecimento não sincronizadas e que a maioria das consultas exigia acesso a dados de faturamento sensíveis. Em vez de começar amplamente, a equipe escolheu um único caso de uso: a consulta de status de pedido, que não exigia dados financeiros sensíveis. Em seis semanas, o agente tratou 62% dessas consultas sem escalonamento, a um custo significativamente menor do que um minuto de conversa de um representante humano. De acordo com o critério "Go", a empresa expandiu gradualmente para um segundo tópico – atualização do endereço de entrega – e só depois começou a considerar ações financeiras, com aprovação humana constante. A abordagem gradual evitou um fracasso total que teria ocorrido se a organização tivesse abordado diretamente o "agente que sabe tudo". ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Caso de Uso muito amplo | Impossibilidade de medir o sucesso ou prever o comportamento | Começar com um processo estreito e bem definido | | Grounding fraco | Respostas confiantes, mas factualmente incorretas | Fonte de dados única, Proprietário e processo de atualização regular | | Permissões muito amplas | O agente expõe dados que o usuário não deveria ver | Execução no contexto do usuário, não permissão de sistema | | Ignorar a Aprovação Humana | Ação financeira ou legal executada sem controle | Aprovação humana obrigatória para qualquer ação irreversível | | Ausência de Linha de Base | "Parece que funciona" sem prova numérica | Medir a situação atual antes do lançamento, não depois | ## Como Saber Quando é Hora de Expandir A expansão é justificada quando três condições são atendidas simultaneamente: a métrica principal é estável por três ciclos de medição consecutivos, não há incidentes de permissão ou segurança no período medido, e o proprietário do processo está pronto para afirmar que o resultado é equivalente ou melhor que a alternativa humana. Quando uma dessas condições está ausente, é melhor estender a fase piloto por mais duas semanas do que expandir com base apenas em uma boa sensação. ## Checklist Antes de Decidir - ☐ Um único caso de uso com limites claros foi selecionado, não um "agente geral" - ☐ Existe uma fonte de dados verificada e atualizada para a área selecionada - ☐ As permissões do agente correspondem às permissões reais do usuário - ☐ Pontos de Aprovação Humana foram definidos para ações irreversíveis - ☐ A linha de base foi medida antes do lançamento, não apenas depois - ☐ Critérios de Go/No-Go foram definidos por escrito antecipadamente - ☐ Existe um plano de monitoramento de Traces e erros - ☐ Um Proprietário responsável pela manutenção da fonte de dados foi designado ## Resumo: Quando é Apropriado e Quando Não é O Agentforce é adequado quando há um processo específico com uma fonte de dados confiável, quando o impacto de um erro é relativamente baixo e quando há uma maneira de medir o sucesso em relação a uma linha de base real. É menos adequado – pelo menos na fase inicial – para processos com alto impacto financeiro ou legal, para organizações onde os dados ainda estão dispersos e não são mantidos, ou quando a gerência espera um resultado imediato sem uma fase piloto. As organizações que respeitam essa ordem de operações – primeiro a prontidão, depois um piloto controlado e só então a expansão – alcançam um resultado muito mais estável do que aquelas que pulam direto para o desenvolvimento. A implementação real pode ser executada em conjunto com os [Serviços de Agentforce e IA](/pt/agentforce-ai), que acompanham a organização desde a verificação de adequação até a expansão controlada. ## Fontes Profissionais - Salesforce – How Agentforce Works — https://www.salesforce.com/agentforce/how-it-works/ - Salesforce – Agentforce Guardrails — https://help.salesforce.com/s/articleView?id=ai.agent_plan_risks_guardrails.htm&language=en_US&type=5 - Salesforce – Agent Testing Custom Scorers — https://developer.salesforce.com/docs/ai/agentforce/guide/testing-api-custom-scorers.html - HPI Pro – Agentforce e IA — https://hpi.pro/agentforce-ai ### Perguntas e respostas **Qual a diferença entre um caso de uso ideal para Agentforce e um que deve ser construído como um Flow regular?** Um caso de uso adequado para um agente autônomo exige tomada de decisão em tempo de execução – a escolha entre múltiplas rotas com base em linguagem natural ou contexto dinâmico. Se o processo sempre segue uma sequência fixa e predefinida, Flows ou Apex são mais econômicos, totalmente testáveis e não demandam monitoramento de Traces. **Quantos dados documentados são necessários antes de iniciar um piloto de Agentforce?** Não é preciso documentação perfeita, mas é essencial ter uma fonte de verdade clara para pelo menos uma área: artigos de Knowledge atualizados, campos de CRM precisos ou documentos de política aprovados. Se 30% das respostas exigem apuração humana por informações ausentes ou inconsistentes, o piloto falhará devido aos dados, não ao agente. **O Agentforce pode operar completamente sem aprovação humana?** Sim, para ações de baixo risco, como recuperação de informações ou atualização de campos não sensíveis. Para qualquer ação que afete finanças, permissões, clientes externos ou dados irreversíveis, é altamente recomendável uma etapa de aprovação humana, pelo menos nos primeiros três meses pós-lançamento. **Como a relação custo-benefício de um agente é medida na prática, e não apenas na teoria?** Em um piloto de 6 a 8 semanas, um Dashboard deve ser construído para comparar o custo de tokens e infraestrutura com o número de tarefas concluídas sem escalonamento. Se o custo por tarefa for superior à economia gerada – por exemplo, o tempo de trabalho de um colaborador – o agente não está pronto para escala, mesmo que esteja 'funcionando'. **O que acontece se o piloto falhar nos critérios Go/No-Go?** O projeto não é descartado – o escopo é reduzido. Geralmente, a falha decorre de um Grounding fraco ou de um caso de uso muito amplo, e não da tecnologia em si. Divida o processo em uma subtarefa única e restrita, corrija a fonte de informação e reavalie antes de investir em expansão. --- ## 15 Perguntas Essenciais Antes de Escolher um Integrador Salesforce URL: https://hpi.pro/pt/insights/questions-before-choosing-salesforce-integrator A maioria das propostas Salesforce parece semelhante no papel até serem analisadas com 15 perguntas focadas. Este guia as divide em seis tópicos — desde a equipe até a continuidade — e demonstra a diferença entre uma resposta fraca e uma confiável. ## A Resposta Curta As propostas de diferentes integradores Salesforce quase sempre parecem semelhantes: as mesmas palavras, como Discovery, Agile, Melhores Práticas (Best Practice), e a mesma promessa de "suporte próximo". A verdadeira diferença só é revelada ao confrontar cada proposta com perguntas concretas que expõem a forma de pensar do fornecedor, e não apenas o que ele oferece. O objetivo das 15 perguntas seguintes é identificar lacunas antes da assinatura, e não depois que o projeto já está travado. As perguntas são divididas em seis tópicos: Equipe, Metodologia, Arquitetura, Dados, Termos Comerciais e Continuidade. Cada pergunta é acompanhada de uma breve explicação de sua importância e de uma descrição de como soa uma resposta fraca – para facilitar sua identificação em tempo real, seja em uma reunião ou em um documento de proposta. As implicações práticas da escolha para todo o processo de implementação foram detalhadas separadamente em [Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Por que 15 Perguntas e Não uma Lista de Requisitos Técnicos Uma lista de requisitos técnicos — quantos Sandboxes, quais licenças, tempos de SLA — é importante, mas não suficiente. Ela verifica o que o fornecedor diz que fará, não como ele lidará com a situação em que o plano original se mostra impreciso. As perguntas aqui foram escolhidas porque revelam padrões de trabalho: como a equipe documenta decisões, como lida com dados inconsistentes e o que acontece quando algo não sai como planejado. ## Tabela Resumo: Resposta Forte vs. Resposta Fraca | Tópico | Resposta Forte Soa Assim | Resposta Fraca Soa Assim | | --- | --- | --- | | Equipe | "A consultora X lidera a arquitetura, o desenvolvedor Y executa. Enviaremos CV e permitiremos uma breve entrevista." | "Temos uma equipe experiente, alocaremos o mais adequado no momento do Kickoff." | | Metodologia | "Sprints de duas semanas, Demo real ao final de cada Sprint, Backlog compartilhado no Jira." | "Trabalhamos com metodologia Agile, é flexível e se adapta a qualquer projeto." | | Arquitetura | "Construiremos um ADR para cada decisão central, incluindo a alternativa rejeitada e o motivo." | "Escolheremos a melhor solução com base em nossa experiência." | | Dados | "Executaremos um Data Profiling antes da proposta final, apresentaremos a qualidade das fontes." | "Lidaremos com a limpeza dos dados durante o desenvolvimento." | | Comercial | "Preço fixo para escopo definido, horas extras conforme Change Request documentado." | "T&M flexível para não restringir vocês." | | Continuidade | "Documento de transição, treinamento para Admin interno, duas semanas de Hypercare após o Go Live." | "Estamos sempre aqui para vocês, não há necessidade de protocolo de desligamento." | ## Equipe: Quem Realmente Trabalhará no Projeto ### 1. Quem realmente acompanhará o projeto, não apenas na proposta? Esta pergunta é crucial porque muitas propostas apresentam o membro sênior da equipe na reunião de vendas e o substituem por um consultor júnior após a assinatura. Uma resposta forte inclui nomes, cargos e a porcentagem de dedicação alocada. Uma resposta fraca soa como "selecionaremos o mais adequado de acordo com a disponibilidade" — ou seja, não há alocação real até o último momento. ### 2. Quantos projetos paralelos cada consultor gerencia no mesmo período? Um consultor que gerencia cinco projetos simultaneamente não pode dedicar atenção aos detalhes. Uma resposta forte reconhecerá a limitação e apresentará um número razoável (geralmente dois a três projetos). Uma resposta fraca evade ou responde "depende da carga de trabalho", sem um número concreto. ### 3. O que acontece se o consultor líder sair no meio do projeto? Uma resposta forte descreve um processo de transição documentado, um Overlap de duas semanas e documentação contínua que permite a substituição sem perda de conhecimento. Uma resposta fraca afirma que "isso quase nunca acontece conosco" sem um plano de contingência. Mais detalhes sobre uma estrutura de trabalho eficaz com um [consultor Salesforce](/pt/insights/salesforce-consulting-guide) podem ser encontrados em nosso artigo. ## Metodologia: Como o Trabalho é De Fato Conduzido ### 4. Como é um Sprint típico? O que acontece se algo não estiver pronto a tempo? Uma resposta forte descreve o Sprint Planning, Daily Scrum, Demo e Retrospective, e também o que acontece quando uma tarefa trava — se ela é adiada para o próximo Sprint de forma transparente. Uma resposta fraca se contenta com "trabalhamos com Agile" sem detalhar um único ritual concreto. ### 5. Como é a comunicação diária? Canal, frequência e responsável. Uma resposta forte detalha o canal (Slack, Teams), reunião de status semanal fixa e um único ponto de contato para escalonamento. Uma resposta fraca diz "estaremos sempre disponíveis por e-mail", o que na prática significa que não há SLA para resposta. ### 6. Como o trabalho é testado antes de ser apresentado ao cliente como concluído? Uma resposta forte descreve um teste de QA interno, Checklist de aceitação e verificação de acessibilidade e permissões antes do Demo. Uma resposta fraca admite indiretamente que o primeiro Demo para o cliente é também o primeiro teste. ## Arquitetura: Como as Decisões São Construídas ### 7. Como as decisões arquitetônicas são documentadas e quem as aprova? Uma resposta forte apresenta um modelo de decisão conciso — problema, alternativas, escolha e razão — que é salvo e acessível ao cliente. Uma resposta fraca afirma "escolhemos a solução certa" sem documentar por que as outras alternativas foram rejeitadas. ### 8. Como a solução lidará com a carga e o crescimento em dois a três anos? Uma resposta forte se refere às limitações de Governor Limits, ao volume de dados esperado e ao planejamento para expansão. Uma resposta fraca responde "Salesforce é escalável por natureza" sem conectar isso ao caso específico. ### 9. O que acontece quando um novo requisito entra em conflito com uma decisão anterior? Uma resposta forte descreve um processo de Change Request que avalia o impacto sobre o que já foi construído. Uma resposta fraca simplesmente promete "nos adaptaremos a qualquer mudança", o que geralmente resulta em uma dívida técnica que se acumula silenciosamente. ## Dados: O Ponto Onde a Maioria dos Projetos Engasga ### 10. Como a qualidade dos dados é verificada antes de iniciar a construção? Uma resposta forte inclui uma etapa de Data Profiling precoce — duplicidades, campos vazios, formatos inconsistentes — e um cronograma para correção. Uma resposta fraca adia isso para "lidaremos com isso durante a migração", o que quase sempre prolonga o projeto. ### 11. Qual é a fonte de verdade para cada tipo de dado, e como a duplicação entre sistemas é tratada? Uma resposta forte identifica antecipadamente quais sistemas "vencem" em caso de conflito (por exemplo, ERP versus Salesforce para clientes existentes) e documenta a regra. Uma resposta fraca responde "Salesforce será a fonte de verdade" de forma abrangente, sem verificar se isso é válido para todos os objetos. ### 12. Qual é o plano de backup e recuperação, e quem é responsável por ele após a implementação? Uma resposta forte detalha ferramentas de backup, frequência e quem executa a recuperação de fato quando necessário. Uma resposta fraca presume que a Salesforce "já cuida disso" sem distinguir entre backup da plataforma e backup em nível organizacional. ## Comercial e Continuidade: O Que Acontece Após a Assinatura ### 13. Como o preço é estruturado — fixo, T&M ou combinado, e o que está realmente incluído? Uma resposta forte detalha o preço em Workflows com horas estimadas para cada um, e define o que é considerado Change Request com custo adicional. Uma resposta fraca apresenta um único número global sem detalhamento, o que dificulta a comparação entre propostas. ### 14. O que acontece se o projeto exceder o prazo — quem arca com o custo? Uma resposta forte diferencia entre um desvio causado pelo fornecedor (às suas custas) e um desvio causado por uma mudança de requisitos do cliente (pago). Uma resposta fraca é formulada de forma ambígua, permitindo que o fornecedor repasse qualquer atraso ao cliente. ### 15. O que acontece no final do projeto — qual suporte, por quanto tempo e a que custo? Uma resposta forte inclui um período de Hypercare definido (geralmente duas a quatro semanas), um documento de transição e treinamento para o Admin interno. Uma resposta fraca promete "suporte contínuo" sem um custo, escopo ou data de término claros. Mais detalhes sobre a formulação correta de cláusulas contratuais como essas podem ser encontrados em [SOW Projeto Salesforce](/pt/insights/salesforce-sow-contract-clauses). ## Cenário Organizacional de Exemplo Uma empresa de serviços financeiros recebeu três propostas para integrar dois sistemas CRM antigos em um único Salesforce. Duas das propostas tinham preços 20% a 25% mais baixos que a terceira. Quando o CIO fez a pergunta 10 (verificação da qualidade dos dados antecipadamente), os dois fornecedores mais baratos responderam "lidaremos com isso como parte da migração" — enquanto o fornecedor mais caro apresentou um plano de Data Profiling de uma semana antes que o valor final fosse acordado. A organização escolheu o fornecedor mais caro. A semana de Data Profiling revelou aproximadamente 12.000 registros duplicados e um campo de data em formato inconsistente em 3 das fontes de dados. Essa correção inicial foi incluída no preço original; nos outros dois fornecedores, ela teria sido descoberta durante a migração, como uma mudança de escopo com custo adicional. A lição aqui não é "o barato é sempre ruim" — mas sim que a diferença entre uma resposta detalhada e uma resposta geral vale dinheiro real, e isso só pode ser revelado com perguntas focadas antes da assinatura, e não depois. ## Checklist para Comparação de Propostas - ☐ Recebemos nomes e porcentagens de dedicação da equipe proposta, não apenas uma descrição geral. - ☐ Verificamos como as decisões arquitetônicas são documentadas por cada fornecedor. - ☐ Solicitamos um plano de Data Profiling antes da assinatura. - ☐ Detalhamos o preço por Workflows com horas estimadas. - ☐ Esclarecemos quem arca com o custo de desvios não causados pelo cliente. - ☐ Recebemos uma descrição explícita do período de Hypercare e suas condições. - ☐ Verificamos referências de clientes com projetos de escopo semelhante. - ☐ Confirmamos que o consultor apresentado na reunião será o que realmente trabalhará no projeto. - ☐ Verificamos quantos projetos paralelos cada consultor líder gerencia. - ☐ Definimos antecipadamente qual será a evidência de sucesso ao final do projeto. ## Observação Final: As Perguntas São uma Ferramenta, Não um Ritual O objetivo das 15 perguntas não é constranger um fornecedor ou prolongar desnecessariamente o processo de seleção. É revelar antecipadamente onde a proposta se baseia em uma suposição não documentada. Um bom fornecedor não se ofenderá com as perguntas — ele ficará feliz em respondê-las porque elas reduzem riscos para ele no futuro. Um fornecedor que as evade, ou que responde com generalidades repetitivas, oferece com isso uma resposta por si só. Quando há falta de capacidade interna para conduzir um processo de comparação como este por conta própria, o [serviço de consultoria e discovery](/pt/consulting-discovery) é o caminho prático a seguir — incluindo a construção de um Scorecard ponderado, acompanhamento nas reuniões com os proponentes e comparação das respostas com critérios objetivos. ## Fontes Profissionais - HPI Pro – Consultoria e Discovery — https://hpi.pro/consulting-discovery - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Serviços Salesforce — https://hpi.pro/services ### Perguntas e respostas **Quanto tempo leva, geralmente, para comparar diversos integradores nesse nível de detalhe?** Cerca de três a quatro semanas para um processo sério: uma semana para preparar um escopo comum, uma a duas semanas para reuniões e respostas por escrito, e uma semana para comparação e verificação de referências. Um processo mais curto tende a depender de primeiras impressões e a ignorar lacunas nas suposições. **O que fazer quando um fornecedor se recusa a responder por escrito algumas das perguntas?** Este é um sinal de alerta significativo, não uma questão técnica. Uma resposta verbal é fácil de ser esquecida ou negada posteriormente. Se um fornecedor explica que a resposta 'depende do projeto', é possível solicitar um intervalo ou uma premissa de trabalho explícita — uma recusa absoluta justifica considerar outro proponente. **É permitido fazer essas perguntas também a um fornecedor existente na renovação de contrato?** Sim, e às vezes é ainda mais importante. Um fornecedor existente, que acumulou conhecimento interno, pode, com o tempo, parar de documentar e se autoavaliar. Uma verificação a cada 12-18 meses revela desgastes na equipe, na documentação ou nos tempos de resposta antes que isso se torne uma dependência perigosa. **Qual o peso relativo que se deve dar a cada um dos seis tópicos na decisão?** Não há uma fórmula única, mas para um primeiro projeto com muitos dados de diferentes fontes, a equipe e os dados juntos devem representar cerca de 45% da pontuação, a metodologia e a arquitetura cerca de 35%, e as condições comerciais e a continuidade o restante. Em uma renovação de contrato existente, o peso se desloca para a continuidade e as condições comerciais. **O que é melhor – um fornecedor que oferece um preço baixo com respostas genéricas, ou um fornecedor mais caro com respostas detalhadas?** Uma resposta detalhada quase sempre vale mais. Uma diferença de 15-20% no preço é significativamente menor em comparação com o custo de retrabalho devido a uma suposição incorreta sobre dados ou permissões. Um preço baixo com um escopo vago é, frequentemente, o mesmo trabalho com uma surpresa adicional posteriormente. --- ## Como Resgatar um Projeto Salesforce Travado? Metodologia de Diagnóstico e Resgate URL: https://hpi.pro/pt/insights/rescue-stalled-salesforce-project Um projeto Salesforce travado pode parecer um problema de desenvolvimento, mas na maioria dos casos é uma mistura de escopo pouco claro, decisões de arquitetura não tomadas e confiança erodida. Este guia apresenta um plano de diagnóstico de 10 dias e um plano de resgate de 90 dias. ## A Resposta Curta A maioria dos projetos Salesforce que emperram não o fazem por conta de um código ruim. Eles emperram porque ninguém parou a tempo para questionar o que realmente muda na rotina dos usuários, quem é o responsável por cada decisão e o que acontece quando algo não sai conforme o planejado. O resultado são Sprints sucessivos que adicionam funcionalidades, mas sem melhoria na visão geral. Salvar um projeto Salesforce emperrado significa, em primeiro lugar, estancar o sangramento, e só então decidir o que fazer com aquilo que já foi construído. Essa ordem é crucial: muitas organizações pulam direto para a fase de correção sem antes diagnosticar por que o processo anterior falhou, repetindo o mesmo erro pela segunda vez. Quem deseja entender como priorizar a dívida acumulada no caminho, pode aprofundar-se em [Priorização de Dívida Técnica Salesforce](/pt/insights/salesforce-technical-debt-prioritization). ## Sinais de Paralisação: Como Identificar que o Projeto Não Está no Caminho Certo Há uma diferença entre um projeto que avança lentamente e um projeto que já não se move. Os seguintes sinais se repetem em quase todos os salvamentos que realizamos: - **Discussões de Status se Transformam em Explicações**: Reunião de status semanal que vira uma justificativa para algo ainda não estar pronto, sem uma nova data de entrega confiável. - **O Backlog Cresce Mais Rápido que a Taxa de Conclusão**: Novos itens são adicionados a cada semana, mas o número de itens concluídos permanece constante ou diminui. - **Nenhuma Versão Testada com um Usuário Real no Último Mês**: Apenas um Demo interno da equipe técnica, sem contato com quem realmente usará o sistema. - **Mudanças Frequentes de Requisitos Sem Documentação**: Cada conversa gera "mais uma pequena alteração" que não é incorporada a um Scope Document organizado. - **Desconfiança Explícita**: Os usuários já estão construindo planilhas Excel paralelas "para garantir", e isso é um sinal de que pararam de acreditar que o sistema funcionará a tempo. Quando quatro dos cinco sinais ocorrem simultaneamente, trata-se de um projeto paralisado e não de um projeto lento, e essa diferença muda toda a estratégia de tratamento. ## Diagnóstico em 10 Dias: O Que Verificar e em Qual Ordem Um bom diagnóstico não requer dois meses. Dez dias úteis, com alocação adequada, são suficientes para obter um panorama confiável o bastante para a tomada de decisão. Uma divisão recomendada: **Dias 1-2: Entrevistas e Mapeamento Inicial.** Conversas rápidas com o Sponsor, o proprietário do processo, dois ou três usuários finais e o chefe da equipe de desenvolvimento. O objetivo é coletar diferentes versões do "que deu errado", sem chegar a uma conclusão ainda. **Dias 3-5: Verificação Técnica Direta.** Acesso ao próprio Org: estrutura de dados, automações existentes, permissões, logs de erro e consultas lentas. Aqui se verifica se o problema é arquitetônico ou operacional. **Dias 6-7: Comparação entre o Prometido e o Construído.** Leitura dos documentos originais (SOW, User Stories, Design Docs, se existirem) em comparação com o estado atual no Sandbox ou Production. **Dias 8-10: Consolidação de Descobertas e Decisão Inicial.** Um documento conciso que classifica cada problema encontrado como Scope, arquitetura ou confiança, e apresenta uma primeira recomendação: Reset, Refactor ou continuação em ritmo corrigido. ## Três Camadas do Problema: Scope, Arquitetura e Confiança O erro mais comum é tratar cada falha como se fosse um único problema. Na prática, quase sempre é uma combinação de três camadas diferentes, cada uma exigindo uma abordagem distinta. **Problemas de Scope** manifestam-se quando ninguém realmente sabe o que entra na primeira versão. Isso ocorre quando a definição original era muito geral ("gerenciar todo o processo de vendas no Salesforce") e não foi decomposta em cenários concretos. A solução não é mais uma reunião de planejamento, mas sim a criação de uma lista clara de Must/Should/Later, com um Owner para cada item. **Problemas de Arquitetura** manifestam-se em escolhas técnicas que não se sustentam em escala: modelo de dados que não suporta o volume de registros, automações que rodam em ordem incorreta, integração que falha silenciosamente. Aqui, é necessária uma verificação técnica aprofundada e, às vezes, o envolvimento de uma [atualização do sistema Salesforce](/pt/insights/salesforce-system-upgrade-signs) como infraestrutura paralela para a correção. **Problemas de Confiança** são geralmente o resultado dos dois primeiros, mas criam vida própria: os usuários param de reportar problemas porque "não são corrigidos de qualquer forma", e a gestão para de financiar mudanças porque "já tentamos". Um problema de confiança não é resolvido com declarações, mas apenas com pequenas e repetidas provas. ### Tabela de Diagnóstico: Sintoma, Causa Raiz e Primeira Ação | Sintoma Observado | Causa Raiz Provável | Primeira Ação Recomendada | | --- | --- | --- | | Toda conversa gera um novo requisito | Scope nunca fechado, sem definição de Out of Scope | Elaborar um documento de Scope com uma seção explícita "o que não está incluído nesta versão" e obter assinatura | | Relatórios apresentam números conflitantes | Múltiplas fontes de verdade para a informação, sem um Single Source of Truth | Identificar o campo/objeto de origem oficial e eliminar duplicações de relatórios | | O sistema "trava" com carga média | Automação ineficiente ou loops de atualização | Profiling de Flow e Apex sob carga simulada, antes de qualquer correção pontual | | Usuários voltam para o Excel | Não há confiança de que o sistema refletirá a situação real | Corrigir rapidamente uma falha que incomoda diariamente e comunicar publicamente a correção | | A equipe técnica não explica suas escolhas | Falhas de comunicação entre Business e IT, não necessariamente um problema técnico | Reunião de esclarecimento rápida onde cada decisão técnica é apresentada em termos de negócio | | Cada Release atrasa a data de entrega | Scope crescente durante o trabalho sem controle | Congelamento de mudanças (Change Freeze) até a conclusão do ciclo atual | ## Reset vs. Refactor: Como Decidir Esta é a decisão central e também a mais custosa, portanto, deve ser baseada em critérios e não em pressentimentos. Três testes ajudam: 1. **Escopo da Dívida Técnica versus Escopo do que já Funciona.** Se 70% da funcionalidade funciona razoavelmente e apenas partes específicas falham, é um Refactor. Se o problema está no modelo de dados básico, um Reset parcial quase sempre é preferível. 2. **Custo de Explicação versus Custo de Reconstrução.** Se levar mais de uma semana para a nova equipe entender por que algo foi construído de uma certa maneira, é provável que o custo de manutenção futura exceda o custo de uma construção limpa. 3. **Estado de Confiança dos Usuários.** Quando a confiança é muito baixa, um Reset focado e transparente (com a declaração "estamos iniciando uma nova versão corrigida") às vezes gera mais cooperação do que uma correção silenciosa que os usuários não percebem. Na prática, a maioria dos salvamentos bem-sucedidos são híbridos: Reset para o componente central problemático (por exemplo, o modelo de Opportunity ou o processo de aprovação), juntamente com um Refactor para o restante do sistema. Uma comparação organizada entre as abordagens aparece em [Reconstruir Salesforce](/pt/insights/salesforce-rebuild-vs-refactor), que detalha os critérios para cada cenário. ## Plano de 90 Dias para Resgate | Fase | Dias | Objetivo Principal | Produto Mensurável | | --- | --- | --- | --- | | Estabilização | 1-10 | Contenção de danos, Change Freeze em áreas sensíveis | Diagnóstico completo e lista de riscos | | Decisão | 11-20 | Reset vs. Refactor, Scope final para o primeiro ciclo | Documento de decisão assinado com Owner | | Primeiro Ciclo | 21-50 | Correção do problema mais doloroso para os usuários | Cenário End-to-End funcionando e testado | | Expansão | 51-75 | Adição de capacidades de acordo com a prioridade acordada | Dois a três processos adicionais em uso | | Estabilização e Fechamento | 76-90 | Medição contra Baseline, entrega de Governança | Dashboard, documentação e plano de manutenção | É importante planejar a fase do "primeiro ciclo" em torno de um único processo que os usuários sentirão em semanas, e não em torno do componente tecnicamente mais interessante. Projetos que falham pela segunda vez geralmente falham porque retornaram ao mesmo erro: começaram pela funcionalidade impressionante em vez da dor real. Esta fase também está diretamente relacionada ao desempenho real, e quem enfrenta problemas de tempo de resposta é convidado a ler [Otimização de Desempenho do Salesforce](/pt/insights/salesforce-performance-optimization). ## Reconstruindo a Confiança com os Usuários A confiança não retorna por causa de uma apresentação; ela retorna por um padrão consistente de uma pequena promessa que é cumprida. Alguns princípios que funcionaram na prática: - **Anuncie pequenas vitórias explicitamente.** Ao corrigir um erro recorrente, envie uma mensagem concisa dizendo exatamente o que foi corrigido e quem solicitou. Essa transparência constrói mais confiança do que uma lista geral de conquistas. - **Convide usuários para testes antecipados, não apenas para UAT no final.** Quem vê uma versão provisória e sente que suas observações foram consideradas, torna-se um embaixador do projeto para o resto da equipe. - **Não prometa uma data da qual não tem certeza.** Uma data adiada pela terceira vez prejudica a confiança mais do que um cronograma realista, mas menos otimista. - **Documente falhas publicamente também.** Quando algo não funciona, uma breve explicação do que aconteceu e o que muda constrói mais credibilidade do que um silêncio ignorante. O processo de reconstrução da confiança geralmente leva mais tempo do que a correção técnica em si, por isso, é aconselhável planejá-lo como um caminho paralelo ao plano de 90 dias e não como um resultado automático dele. Organizações que desejam um acompanhamento estruturado para este processo, incluindo o acompanhamento direto da equipe e da gerência, podem utilizar o [serviço de Salesforce Health Check](/pt/salesforce-health-check) como uma estrutura de trabalho completa. ## Cenário Organizacional de Exemplo Uma empresa de serviços financeiros conduziu um projeto Salesforce por nove meses sem um Go Live. Na auditoria, verificou-se que o Scope havia aumentado três vezes em relação ao planejamento original, que a equipe técnica havia construído três versões diferentes do mesmo processo de aprovação sem documentar o porquê, e que os usuários-chave já haviam migrado para gerenciar o relatório mensal em uma planilha separada. O plano de diagnóstico de dez dias revelou que o problema principal não era técnico: a equipe técnica recebeu requisitos contraditórios de dois gerentes diferentes sem que ninguém coordenasse entre eles. A decisão foi por um Refactor parcial, não um Reset completo, porque a maior parte do código estava correta. A primeira fase focou apenas no processo de aprovação, que era a principal fonte de frustração, e em cinco semanas uma versão estável que os gerentes aprovaram em conjunto foi lançada. Somente então a expansão dos demais processos continuou. A lição principal: a paralisação não foi resultado de uma falha técnica pontual, mas da ausência de uma única entidade que detivesse o mapa completo das decisões. Esse papel, mesmo que temporário, geralmente faz a diferença entre um projeto que é bem-sucedido pela segunda vez e um que volta a estagnar. ## Checklist Antes de Tomar uma Decisão de Resgate - ☐ Diagnóstico de 10 dias realizado com entrevistas, revisão do Org e comparação com documentos originais - ☐ Problemas claramente classificados em Scope, arquitetura ou confiança - ☐ Decisão documentada de Reset/Refactor com justificativas - ☐ Um processo único selecionado para o primeiro ciclo com base em uma dor real dos usuários - ☐ Change Freeze definido para o período de diagnóstico e decisão - ☐ Métricas de Baseline estabelecidas antes do início da correção - ☐ Plano de comunicação contínua para usuários e direção existente - ☐ Um Owner único nomeado que detém o mapa de todas as decisões - ☐ O plano de 90 dias inclui marcos mensuráveis e não apenas uma data de conclusão - ☐ Processo definido para entrega de Governança e manutenção ao final do resgate ## Fontes Profissionais - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Salesforce Health Check — https://hpi.pro/salesforce-health-check - HPI Pro – Suporte e Acompanhamento — https://hpi.pro/support ### Perguntas e respostas **Qual a diferença entre um projeto 'lento' e um projeto realmente 'travado'?** Um projeto lento ainda gera decisões e progresso mensurável, mesmo que em um ritmo reduzido. Um projeto travado é aquele em que duas a três semanas se passam sem novas decisões, sem uma versão testada com um usuário real e sem nenhuma mudança no status do Backlog. Se não há uma resposta clara para 'o que aconteceu esta semana', provavelmente se trata de um travamento. **Quem deve liderar o processo de diagnóstico, um consultor externo ou alguém da equipe interna?** É aconselhável que uma parte externa lidere a fase de diagnóstico, pois ela não tem responsabilidade pelas decisões anteriores e pode fazer perguntas incômodas sem gerar defensividade. A equipe interna deve participar plenamente das entrevistas e da verificação dos dados, caso contrário, as conclusões serão vistas como críticas externas e não como base para uma ação conjunta. **É possível resgatar um projeto sem trocar de fornecedor ou integrador?** Sim, e às vezes este é o caminho correto, especialmente quando o problema é de escopo e comunicação, e não de qualidade técnica. Isso deve ser avaliado com base em três perguntas: a equipe atual toma decisões claras? Há transparência no código e na documentação? Existe uma vontade genuína de parar e corrigir? Se a resposta for negativa para os três, a substituição se torna relevante. **Quanto tempo leva para ver uma melhora inicial que os usuários sentirão?** Em projetos onde o diagnóstico foi realizado corretamente, a primeira melhoria perceptível chega em 3 a 4 semanas após o início do plano de 90 dias, geralmente através da correção de um erro recorrente ou da redução de um processo diário. Uma melhoria estrutural mais profunda, como a correção de um modelo de dados, leva entre 6 e 12 semanas, dependendo da extensão da dívida técnica. **O que acontece se o patrocinador original não acreditar mais no projeto?** Este é o indicador mais forte da necessidade de resgate, não um motivo para desistir. O primeiro passo é construir para esse patrocinador uma pequena e mensurável evidência em duas semanas, por exemplo, a correção de um erro que o incomoda pessoalmente todos os dias. A confiança é reconstruída através de pequenas e repetidas provas, não através de uma apresentação detalhada do plano. --- ## Como definir um MVP para um projeto Salesforce sem criar um sistema temporário URL: https://hpi.pro/pt/insights/salesforce-mvp-scope A diferença entre um MVP e um sistema parcialmente construído não reside na quantidade de funcionalidades, mas nas decisões que foram solidificadas. Uma primeira fase bem-sucedida estabelece o modelo de dados e as permissões de forma completa, priorizando a profundidade técnica em vez da amplitude de negócios. Este artigo apresenta um teste prático para os limites de um MVP e uma tabela de decisões que devem ou não ser adiadas. ## O Teste que Diferencia um MVP de um Sistema Temporário Dois projetos podem ir ao ar com o mesmo número de telas, mas um será a base para crescimento, enquanto o outro se tornará uma dívida tecnológica a ser desfeita. A diferença não está no escopo, mas no tipo de **concessão.** A regra prática é: **na primeira onda, reduza a amplitude de processos de negócio, não a profundidade arquitetônica.** É aceitável limitar alguns processos, algumas unidades e alguns tipos de clientes iniciais. Não é aceitável comprometer o modelo de dados central, o modelo de permissões e a definição da fonte da verdade — estes devem ser construídos corretamente desde o início, mesmo que, a princípio, atendam apenas cinquenta usuários. Quem reduz profundidade em vez de amplitude acaba com um sistema que funciona por um trimestre e depois precisa ser reconstruído. O contexto mais amplo das fases do projeto está detalhado no [Guia de Implementação de Salesforce](/pt/insights/salesforce-implementation-guide). ## Três Definições Frequentemente Confundidas | Termo | O que é na prática | Quando é apropriado | Principal risco | | --- | --- | --- | --- | | Proof of Concept (PoC) | Prova de viabilidade técnica de um componente | Quando há dúvida real se algo é possível | Tendência a promovê-lo para produção | | Pilot (Piloto) | Implementação completa para um grupo limitado | Quando a solução é conhecida e a questão é a adoção | Grupo não representativo o suficiente | | MVP | Primeira versão em produção que gera valor real | Quando se deseja aprender com o uso efetivo | Torna-se permanente sem uma decisão formal | A escolha entre os três não é semântica. Um PoC pode ser descartado, um MVP não — portanto, um MVP deve ser construído apenas com padrões de produção. ## Decisões que Não Podem Ser Adiadas Existe um conjunto de decisões cujo custo de alteração aumenta exponencialmente após a entrada de dados em produção. Essas decisões precisam ser tomadas na primeira onda, mesmo que, a princípio, abranjam apenas uma pequena parte do cenário geral: - O **objeto que suporta o processo de negócio** e sua relação com as entidades-chave. - A **chave única que identifica o cliente** em relação a sistemas externos. - O **padrão de visibilidade** em cada objeto central. - A **estrutura de propriedade dos registros** — quem é o Owner e o que acontece quando um funcionário sai. - A **definição da fonte da verdade** para cada entidade sincronizada com outro sistema. Em contraste, as decisões que podem e devem ser adiadas incluem: design de relatórios avançados, automações de conveniência, integração de canais secundários, localização para unidades não contempladas na primeira onda e integrações não essenciais para decisões em tempo real. ## Como Escolher o Processo da Primeira Onda Não se escolhe nem o processo mais simples, nem o mais problemático. Escolhe-se o processo que atende às três condições simultaneamente: possui um único Process Owner disponível, gera um resultado visível para a diretoria e representa o modelo de dados central. Um processo que atenda a duas das três condições ainda é viável; um processo que atenda apenas a uma resultará em uma primeira onda sem aprendizados significativos. Outra consideração é o volume: um processo que ocorre dez vezes por mês não gerará uso suficiente para aprendizado em um trimestre. ## Critério de Saída — O Que Sinaliza o Sucesso da Onda Um MVP sem critério de saída se torna um status permanente. O critério deve ser mensurável, conciso e pré-definido. Exemplo de estrutura: - Uma porcentagem dos processos do tipo selecionado é efetivamente executada no sistema e não fora dele. - Não há falha bloqueadora aberta por mais de um número definido de dias. - Os dados gerados no período atendem ao limite de qualidade pré-estabelecido. - O Process Owner confirma por escrito que o processo está sendo executado sem desvios permanentes. Observe que nenhum desses critérios é “o sistema foi ao ar”. Essa data é o ponto de partida da medição, não o seu fim. ## Custo do Adiamento — A Ferramenta que Decide Disputas de Escopo Ao discutir se uma funcionalidade entra na primeira onda, a pergunta útil não é quanto custa construí-la agora, mas sim quanto custa construí-la depois. A tabela a seguir serve como ferramenta de trabalho em reuniões de escopo: | Tipo de Funcionalidade | Custo de Construção na Primeira Onda | Custo de Construção na Segunda Onda | Conclusão | | --- | --- | --- | --- | | Mudança na estrutura de objeto central | Baixo | Muito alto — incluindo migração | Entra na primeira onda | | Novo modelo de permissões | Médio | Alto — exposição já ocorreu | Entra na primeira onda | | Relatório gerencial | Baixo | Baixo | Adiado | | Automação de alerta | Baixo | Baixo | Adiado | | Integração essencial para decisão em tempo real | Alto | Alto + rotina de contorno enraizada | Entra se o processo depender dela | | Integração apenas para relatórios | Médio | Médio | Adiado | ## Exemplo Ilustrativo: Empresa de Logística Internacional O cenário é hipotético e destinado à ilustração. Uma empresa de transporte com operações em três países queria lançar um MVP em onze semanas. A primeira proposta era incluir todos os três países, mas apenas a fase de cotação, sem a fase de pedido. A equipe reverteu o corte: um único país, mas o processo completo, da cotação ao pedido aprovado, incluindo a integração que extrai as tarifas. O motivo era simples — cortar o processo no meio exigiria que os usuários continuassem no sistema antigo para a fase de pedido, ou seja, inserindo dados duas vezes. Em vez de aprender se o sistema ajudava, a empresa aprenderia que o sistema atrapalhava. O escopo total em semanas permaneceu semelhante. O que mudou foi que, após a primeira onda, a empresa tinha em mãos um processo completo e funcional, e não meio processo em três países. ## Sinais de que o MVP se Tornou um Sistema Temporário - Existe um processo manual permanente que visa "cobrir até a próxima onda" e está em uso há dois meses. - Foi acordado que um campo é usado para duas coisas diferentes porque não havia tempo para dividi-lo. - Existe um grupo de usuários trabalhando simultaneamente em dois sistemas. - Não há data de decisão para a próxima onda, apenas uma lista de espera. Esses padrões, entre outras falhas comuns, são detalhados no [Guia de Erros Comuns na Implementação de CRM](/pt/insights/crm-implementation-mistakes). ## Integração com o Cronograma Geral A definição do MVP afeta diretamente a duração do projeto, e às vezes na direção oposta ao esperado: uma primeira onda muito estreita prolonga o projeto geral, pois cada onda incorre em custos fixos de testes, treinamento e lançamento. Detalhes sobre como transformar isso em um planejamento realista podem ser encontrados no [Guia de Duração de Projetos Salesforce](/pt/insights/salesforce-project-timeline) e, no caso de substituição de um sistema existente, no [Guia de Migração para Salesforce](/pt/insights/replace-crm-with-salesforce). ## Próximo Passo Escreva em uma frase qual é o processo da primeira onda, quem é o Process Owner e qual será o critério que confirmará seu sucesso em um trimestre. Se alguma das três frases não puder ser escrita no momento, esse é o ponto de partida, e não a lista de funcionalidades. ### Perguntas e respostas **Qual é um tamanho razoável para um MVP em um projeto Salesforce?** Não há um número fixo, mas há um teste prático: a primeira fase deve incluir um processo de negócio completo de ponta a ponta, para um único grupo de usuários, com os dados que o processo realmente consome. Se for necessário cortar o processo no meio para atender ao escopo, é um sinal de que você escolheu um processo muito grande, e não que o MVP é muito pequeno. **É possível adiar a integração com um sistema central para uma segunda fase?** É possível, desde que o processo da primeira fase não dependa dela para tomada de decisão. Se os vendedores precisarem abrir o ERP simultaneamente para verificar estoque ou limite de crédito, adiar a integração não economiza trabalho, mas cria uma prática paliativa que é difícil de reverter depois. **Quem decide o que fica de fora do MVP?** A decisão pertence ao Patrocinador do Negócio, por recomendação do proprietário do processo e do arquiteto, e não a um comitê. A razão é prática: remover uma funcionalidade da primeira fase é uma concessão política, e apenas uma parte com autoridade orçamentária pode sustentá-la sem que a funcionalidade retorne através de solicitações de mudança. **Como evitar que um MVP se torne permanente?** Estabeleça antecipadamente um critério de saída mensurável e uma data de decisão para a próxima fase, e não apenas uma lista de continuidade. Além disso, não permita que a primeira fase ignore decisões arquitetônicas: um sistema que permanece permanente em um modelo de dados correto é um resultado razoável, e um sistema que permanece permanente em uma solução temporária é uma dívida técnica. **Um MVP também é adequado para substituir um CRM existente?** Sim, mas o limite é definido de forma diferente. Na substituição, há pressão para transferir tudo o que o sistema antigo fazia, e, portanto, a primeira fase é definida por um grupo de usuários ou unidade de negócios, e não por um subconjunto de funcionalidades. A operação simultânea de dois sistemas para o mesmo grupo gera trabalho duplicado e prejudica a confiabilidade dos dados. --- ## Equipe de Projeto Salesforce: Funções, Responsabilidades e Modelo de Colaboração com o Fornecedor URL: https://hpi.pro/pt/insights/salesforce-project-team-roles As duas funções que determinam se um projeto Salesforce será concluído no prazo quase sempre residem no lado do cliente, e não no lado do fornecedor. Este artigo detalha as nove funções essenciais, a contribuição crítica de cada uma, quais delas não podem ser terceirizadas e como uma matriz RACI bem definida evita atrasos por falta de decisões. ## Funções que Ditigam o Ritmo do Projeto Em um projeto Salesforce, é possível contratar um excelente arquiteto, uma equipe de desenvolvimento experiente e um gerente de projeto organizado, e ainda assim atrasar o cronograma. A razão comum não é o ritmo de construção, mas sim o ritmo da tomada de decisão. O desenvolvimento aguarda uma decisão, a decisão aguarda uma reunião, e a reunião aguarda agendamento. Portanto, a divisão útil de papéis não é sobre quem faz o quê, mas sim sobre **quem decide o quê e com qual tempo de resposta**. Uma visão geral das fases em que cada função é necessária pode ser encontrada no [Guia de Implementação do Salesforce](/pt/insights/salesforce-implementation-guide). ## As Nove Funções e o Mandato de Cada Uma **Executive Sponsor** — Intermedeia decisões entre departamentos, aprova concessões de *scope* e protege a prioridade contra pressões concorrentes. Se não tiver autoridade orçamentária, não é um Sponsor, mas sim um representante. **Process Owner** — Define como o trabalho será realizado na prática após a mudança, e aprova que o processo construído está alinhado com a realidade. Um para cada processo central, e não um comitê. **Product Owner / Gerente de CRM** — Gerencia as prioridades no *backlog*, decide entre requisições concorrentes e mantém a ligação entre requisitos e valor. **Gerente de Projeto** — Cronograma, dependências, riscos, coordenação de fornecedores e relatórios. **Arquiteto de Soluções** — Decide sobre o modelo de dados, permissões, limites do sistema e método de implementação; responsável por documentar alternativas consideradas. **Salesforce Admin** — Configuração, ambientes, gerenciamento de usuários e manutenção contínua após a implantação. **Desenvolvedor** — Lógica customizada, integrações, testes automatizados. **Data Owner** — Determina qual é a fonte da verdade, o que é considerado um registro válido e quem aprova o carregamento de dados. **Líder de Adoção e Treinamento** — Comunicação, treinamento por função, gerenciamento de resistência e medição de uso. Em um projeto pequeno, uma pessoa pode desempenhar duas funções, mas existem dois pares que não devem ser unificados: Arquiteto e Gerente de Projeto (conflito entre precisão e velocidade), e Process Owner e Líder de Testes (testar a si mesmo). ## Quem Deve Ser Interno | Função | Pode ser Externo | Explicação | |---|---|---| | Executive Sponsor | Não | Requer autoridade organizacional | | Process Owner | Não | Requer propriedade do trabalho na prática | | Data Owner | Não | Requer responsabilidade regulatória e de negócio | | Product Owner | Parcialmente | É possível ter consultoria, mas não substituição | | Gerente de Projeto | Sim | Comum e aceitável | | Arquiteto de Soluções | Sim | Recomenda-se acompanhamento interno para conhecimento | | Admin | Sim, temporariamente | Preferível transferir para interno antes do Go Live | | Desenvolvedor | Sim | Padrão | | Líder de Adoção | Parcialmente | A mensagem interna deve vir da organização | ## Matriz RACI para Pontos de Decisão Centrais | Decisão | Accountable | Consulted | Tempo de Resposta Necessário | |---|---|---|---| | Estrutura do Modelo de Dados | Arquiteto | Process Owner, Data Owner | Até uma semana | | Mudança de Scope | Sponsor | Product Owner, Gerente de Projeto | Até uma semana | | Prioridade no Backlog | Product Owner | Process Owners | Até dois dias | | Definição de Campo Obrigatório | Process Owner | Admin | Até dois dias | | Aprovação de Carga de Dados | Data Owner | Arquiteto | Até três dias | | Aprovação de Go Live | Sponsor | Gerente de Projeto, Process Owner | Conforme marco definido | | Resolução de Bloqueio Crítico | Gerente de Projeto | Arquiteto, Admin | No mesmo dia | A coluna de tempo de resposta é a parte interessante da tabela. RACI sem um SLA para decisão é uma descrição agradável que não muda o ritmo. ## Disponibilidade Real – O Erro Reincidente no Planejamento | Função | Levantamento de Requisitos | Construção | Testes | Go Live e Semanas Pós-Go Live | |---|---|---|---|---| | Sponsor | Baixa, constante | Baixa | Média | Média | | Process Owner | Alta | Média | Muito Alta | Alta | | Product Owner | Alta | Alta | Alta | Média | | Admin | Média | Alta | Alta | Muito Alta | | Data Owner | Média | Baixa | Alta | Média | | Líder de Adoção | Baixa | Média | Média | Muito Alta | O planejamento falho comum é a suposição de que a carga do Process Owner diminui após o levantamento de requisitos. Na prática, ela aumenta novamente na fase de testes, justamente quando o funcionário retorna ao seu trabalho rotineiro. ## Exemplo Ilustrativo: Faculdade Acadêmica O cenário é hipotético e destinado à ilustração. Uma faculdade implementou um sistema de gerenciamento de candidatos. A equipe foi definida corretamente no papel, mas o "Process Owner" era o chefe do departamento de admissões que dedicava duas horas semanais ao projeto. Qualquer pergunta sobre o status do candidato aguardava até a terça-feira de manhã. Após dois meses, foi medido que o atraso acumulado na espera por decisões superou o atraso por qualquer outra razão combinada. A solução não foi contratar mais desenvolvedores. A faculdade nomeou um vice-diretor que recebeu um mandato explícito para tomar decisões diárias até um nível de influência definido, deixando para o chefe do departamento apenas as decisões que alteravam a política. O ritmo de desenvolvimento aumentou sem mudança na equipe do fornecedor. ## Modelo de Engajamento com o Fornecedor Três mecanismos são suficientes para a maioria dos projetos: - **Diário de Decisões Conjunto** — Cada decisão com data, responsável, justificativa e alternativas rejeitadas. Esta é a única documentação que permanece útil dois anos depois. - **Ponto de Contato Único de Ambos os Lados** — Múltiplos contatos diretos de vários participantes com os desenvolvedores são a maneira mais segura de perder o controle. - **Ciclo de Demonstração Regular** — O Process Owner vê um produto funcionando, não uma apresentação. A diferença entre a expectativa e a entrega é revelada em duas semanas, e não em dois meses. Em grandes organizações, uma camada adicional de governança entre unidades de negócio é necessária, conforme descrito no [Guia de Implementação do Salesforce em Organizações Enterprise](/pt/insights/enterprise-salesforce-implementation). ## Pontos de Encontro com Outras Fases A composição da equipe é derivada diretamente de duas coisas: os produtos que são necessários na fase de levantamento de requisitos, detalhados no [Guia de Descoberta de CRM](/pt/insights/crm-discovery-guide), e a amplitude da primeira onda, definida pelas regras no [Guia de Definição de MVP do Salesforce](/pt/insights/salesforce-mvp-scope). Uma primeira onda mais restrita exige menos Process Owners simultaneamente, e essa é uma razão independente para limitar a amplitude. ## Verificação Rápida Antes de Iniciar um Projeto Responda a quatro perguntas com nome e sobrenome, não com o nome do departamento: Quem decide quando Vendas e Operações não concordam? Quem aprova que o processo construído corresponde à realidade? Quem diz quais dados são confiáveis? E quem manterá o sistema daqui a um ano? Uma resposta ausente para qualquer uma delas é o maior risco no projeto, e também a única que não é resolvida com dinheiro. ### Perguntas e respostas **Quanto tempo um Proprietário de Processo deve dedicar a um projeto Salesforce?** Na fase de levantamento de requisitos, geralmente entre um terço e meio período. Nas fases de testes e lançamento, por vezes, mais. A suposição comum de que uma reunião semanal é suficiente é a causa frequente de atrasos: as pequenas decisões diárias são insignificantes para justificar uma reunião, mas bloqueiam o desenvolvimento quando não há quem decida no mesmo dia. **Quais funções não podem ser delegadas a um fornecedor?** Três: um Sponsor que tem autoridade para arbitrar entre departamentos, um Proprietário de Processo que define como o trabalho será realizado e um Proprietário de Dados que determina o que é considerado confiável. Um fornecedor pode fornecer arquitetura, desenvolvimento, gerenciamento de projetos e até gerenciamento de mudanças, mas não pode decidir pela organização o que é certo para ela. **É necessário ter um Salesforce Admin interno já durante o projeto?** É preferível que sim, e não apenas perto do fim. Um Admin que entra na fase de levantamento de requisitos conhece as razões das decisões, não apenas o resultado, e, portanto, é capaz de manter e modificar o sistema depois. Um Admin que recebe o sistema na semana de lançamento é forçado a aprender a arquitetura a partir da configuração, o que é lento e propenso a erros. **Qual a diferença entre Product Owner e Gerente de Projeto no contexto Salesforce?** O Gerente de Projeto é responsável por cronograma, dependências, riscos e orçamento. O Product Owner é responsável pela prioridade do conteúdo: o que é construído primeiro e o que é adiado. Quando as funções são combinadas em uma única pessoa, geralmente uma das duas responsabilidades é negligenciada — geralmente a prioridade do conteúdo é preterida em favor do cumprimento de prazos. **Como trabalhar eficazmente com uma equipe de fornecedores remotos e externos?** Com três mecanismos: um ponto de contato único de ambos os lados, decisões registradas em um diário de decisões compartilhado (em vez de e-mails) e uma rodada de demonstração curta e regular onde o Proprietário de Processo vê um produto funcionando. Barreiras linguísticas e fusos horários são toleráveis; o que não é tolerável é uma decisão dita verbalmente e não registrada por ninguém. --- ## UAT em Projetos Salesforce: Como Testar Processos de Negócio, Não Apenas Telas URL: https://hpi.pro/pt/insights/salesforce-uat-guide Um UAT que se assemelha a um tour guiado por telas não identificará as falhas que comprometerão a entrada em produção. O teste deve ser executado em cenários completos, com dados que simulam a realidade e por aqueles que realmente utilizarão o sistema. Este guia apresenta um método para construir roteiros de teste, um modelo de classificação de defeitos e critérios claros para a aprovação. ## Por que a UAT Falha Mesmo Quando Parece Bem-Sucedida Em muitas rodadas de UAT (User Acceptance Testing), todos os cenários são marcados como aprovados e, duas semanas após o lançamento, dezenas de chamados são abertos. Isso não é um paradoxo. É um resultado direto de testes construídos em torno de telas. Um teste focado em telas pergunta "É possível criar um registro?". Um teste focado em processos pergunta "Um agente pode receber um chamado, identificar que o cliente existe sob outro nome, verificar sua elegibilidade no sistema principal, abrir um caso, encaminhá-lo a outra parte e fechá-lo — mesmo com o cliente duplicado no sistema?". O segundo cenário encontra o que o primeiro perde. Este guia apresenta a estrutura de UAT que visa a segunda pergunta. A relação com outras fases do projeto é detalhada no [Guia de Implementação do Salesforce](/pt/insights/salesforce-implementation-guide). ## O Que Deve Estar Pronto Antes de Começar - **Um ambiente estável** que não receba implantações no meio da rodada, exceto para correções de bloqueadores aprovadas. - **Dados de teste** com escopo e complexidade semelhantes aos de produção. - **Usuários com permissões reais** — não Admin para todos. Metade das falhas de permissão são descobertas apenas quando o testador possui o perfil correto. - **Critérios de aceitação** definidos para cada processo central. - **Um mecanismo de relatório único** para bugs, com campos obrigatórios mínimos. O item mais frequentemente ignorado é o terceiro, e é ele que gera os bugs mais embaraçosos no dia do lançamento. ## Como Construir um Cenário que Encontra Problemas Um bom cenário começa com uma persona e um estado inicial, não com um clique. Uma estrutura eficaz: 1. **Quem** — Função e permissão exatas. 2. **Estado inicial** — Quais informações existem no sistema antes do início do cenário. 3. **O que acontece** — O evento de negócio que aciona o processo. 4. **O que o testador faz** — Em nível de ação de negócio, não em nível de clique. 5. **Resultado esperado** — Incluindo o que aconteceu em outros sistemas. 6. **O que não deveria acontecer** — O registro não é exposto a quem não deveria, a notificação não é enviada duas vezes. O sexto item é o que separa uma lista de verificação de um teste profissional. ## Seis Famílias de Cenários Que Devem Ser Incluídas | Família | Exemplo de Cenário | O Que Ela Revela | | --- | --- | --- | | Fluxo Padrão | Um processo completo de ponta a ponta | Se o processo é sequer executável | | Exceção de Negócio | Cancelamento, crédito, retorno a uma etapa anterior | Lógica construída apenas em uma direção | | Dados Problemáticos | Cliente duplicado, nome em hebraico e inglês, campo vazio | Mapeamento e limpeza insuficientes | | Permissões | Usuário tentando acessar registro de outra unidade | Falhas no modelo de exposição | | Falha de Integração | Sistema de destino indisponível | Tratamento de erros, loops, duplicação | | Volume | Ação em massa em grande número de registros | Limitações de desempenho e automação | A ausência de uma família inteira na lista é um sinal de que o teste fornecerá uma segurança enganosa. ## Classificação de Gravidade — A Condição Para Gerenciar a Rodada Sem uma classificação acordada, todo bug parece urgente e a decisão de ir ao ar se torna uma discussão. Um modelo de quatro níveis é suficiente: | Nível | Definição | Impacto no Lançamento | | --- | --- | --- | | Bloqueador | Processo central não pode ser concluído, sem *workaround* | Bloqueia | | Grave | O processo é possível com um *workaround* pesado ou dados incorretos são salvos | Bloqueia, a menos que aprovado explicitamente | | Médio | Inconveniente significativo, *workaround* razoável | Não bloqueia, entra no plano de correção | | Baixo | Texto, ordem de campos, melhoria | Coletado para a próxima onda | A regra importante: a classificação é definida pelo proprietário do processo junto com a equipe técnica, e não por quem relatou o bug. ## Condições para o Go-Live Elas são definidas antes do início da rodada, e não no final: - Zero bugs bloqueadores abertos. - Todo bug grave foi fechado ou aprovado por escrito com *workaround* e tempo de correção. - Todos os processos centrais foram executados na segunda rodada sem novas falhas. - Os proprietários do processo aprovaram por escrito. - Existe um plano de contingência testado, não apenas escrito. ## Exemplo Ilustrativo: Fundo de Pensão O cenário é hipotético e serve para ilustração. Um fundo de pensão testou o processo de tratamento de chamados de participantes. A primeira rodada de UAT foi quase totalmente aprovada. A equipe notou que todos os testadores usaram um perfil ampliado, pois a atribuição dos perfis exatos estava atrasada. Na segunda rodada, com os perfis reais, foram encontrados onze bugs: agentes não viam registros de participantes transferidos entre planos, um botão de aprovação de exceção aparecia para quem não era qualificado, e um relatório de carga retornou resultados parciais para líderes de equipe. Nenhum dos bugs estava relacionado à funcionalidade testada na primeira rodada — todos estavam no modelo de exposição. A conclusão prática adotada lá: não se inicia uma rodada de UAT antes que todos os participantes estejam com o perfil que usarão em produção. ## Erros Gerenciais Que Encarecem a Rodada - Implantação de versões no meio da rodada, o que invalida os testes já realizados. - Testadores que relatam via WhatsApp e e-mail em paralelo ao sistema de rastreamento. - Cenários escritos no nível do clique, o que transforma cada mudança na interface em uma atualização de documentação. - Encurtar a segunda rodada devido à pressão do cronograma — esta é a rodada que descobre regressões. Esses padrões aparecem ao lado de outras falhas no [Guia de Erros Comuns de Implementação de CRM](/pt/insights/crm-implementation-mistakes), e a responsabilidade por cada um deles é definida no [Guia de Funções da Equipe de Projeto Salesforce](/pt/insights/salesforce-project-team-roles). ## Ao Substituir um Sistema Existente Em um projeto de substituição, o UAT assume uma segunda função: comparação. Os mesmos dez cenários são executados em ambos os sistemas, e os resultados são comparados campo por campo. Esta é a ferramenta mais eficaz para descobrir lacunas de mapeamento antes que se tornem lacunas de confiança. A ordem das operações em tal transição é detalhada no [Guia de Substituição de CRM pelo Salesforce](/pt/insights/replace-crm-with-salesforce). ## O Que Resta Após a Rodada Os cenários de UAT não são um documento único. Eles são a base para os testes de regressão em cada lançamento futuro e a melhor fonte para materiais de treinamento — pois são escritos na linguagem do processo, e não na linguagem do sistema. Mantê-los em um formato que possa ser executado novamente é o investimento mais barato que se pode fazer para o próximo ano. ### Perguntas e respostas **Quanto tempo dedicar ao UAT em um projeto Salesforce?** Um período prático varia de duas a quatro semanas para uma fase média, mas a variável determinante não é o número de cenários, mas sim o número de ciclos de correção. Planeje no mínimo dois ciclos: o primeiro para descoberta de falhas, o segundo para garantir que a correção não introduziu novos problemas. Um UAT de uma semana quase sempre resulta em descobertas emergenciais em produção. **O UAT deve ser executado com dados reais?** Devem ser utilizados dados que se assemelham à realidade em volume e complexidade, porém adaptados às restrições de privacidade. Testar com dez registros 'limpos' não revelará duplicidades, nomes problemáticos, clientes com hierarquia profunda ou registros históricos ausentes — e são precisamente esses casos que geram falhas na primeira semana de produção. **Quem elabora os roteiros de teste?** Os proprietários dos processos, com o auxílio de quem conhece o sistema. Quando os desenvolvedores escrevem os roteiros, eles refletem o que foi construído, e não o que o negócio realmente precisa. O papel da equipe técnica é adicionar cenários de 'edge cases', e não definir o processo a ser testado. **Qual a diferença entre UAT e testes de integração?** Testes de integração verificam se os sistemas se comunicam corretamente: formato, campos, tratamento de erros, desempenho. O UAT garante que o usuário final pode realizar suas tarefas e que o resultado é comercialmente correto. É possível passar por todos os testes de integração e falhar no UAT, porque os dados foram transferidos, mas o processo não é executável. **É possível entrar em produção com falhas abertas?** Sim, desde que sejam classificadas e aprovadas. Uma falha sem 'workaround' (solução alternativa) provavelmente levará a um atraso; uma falha com 'workaround' documentado e um prazo de correção acordado pode ser aprovada. O que é inadmissível é entrar em produção com uma lista de falhas não classificadas, pois a decisão final será tomada na prática, na primeira semana de produção, pelos próprios usuários. --- ## Precificação de Projeto Salesforce: Preço Fixo, Horas Trabalhadas ou Retainer? URL: https://hpi.pro/pt/insights/salesforce-project-pricing-models A escolha do modelo de precificação reside principalmente na definição de quem assume o risco da incerteza. Preço Fixo não é inerentemente mais barato, e Horas Trabalhadas não é necessariamente mais arriscado — cada um se adequa a um nível distinto de maturidade na definição do escopo. Explore nosso guia de alinhamento, mecanismos de proteção para cada modelo e estratégias híbridas comprovadamente eficazes. ## Preço Não é Questão de Custo, Mas Sim de Risco Quando uma organização pondera entre preço fixo e Time & Materials (T&M), geralmente questiona qual modelo é mais barato. Esta é a pergunta errada. Ambos os modelos representam o mesmo trabalho; a diferença é **quem absorve o custo quando a realidade difere da premissa**. No preço fixo, o fornecedor absorve o risco — por isso ele precifica uma margem de risco inicial e se protege através de uma definição precisa do que está incluído. No T&M, a organização absorve o risco — portanto, necessita de mecanismos de controle. No Retainer, ambos os lados obtêm estabilidade em troca de flexibilidade reduzida. A regra simples: **quanto mais madura a definição do Scope, mais vantajoso é o preço fixo.** Quanto mais incertezas reais existirem, um T&M com um teto máximo é preferível. ## Comparativo Rápido dos Três Modelos | Aspecto | Preço Fixo | Time & Materials | Retainer | | :------ | :--------- | :--------------- | :------- | | Quem assume o risco do escopo | Fornecedor | Organização | Compartilhado dentro do escopo acordado | | Condições de Sucesso | Scope bem definido | Transparência e gerenciamento próximo | Demanda estável e previsível | | Flexibilidade para Mudanças | Baixa, via solicitações de mudança | Alta | Média | | Carga Administrativa para a Organização | Média, focada na definição | Alta, contínua | Baixa | | Falha Típica | Conflito de Escopo | Aumento de horas | Horas não utilizadas ou absorvidas | | Melhor Adequado Para | Onda de implementação definida | Integração, migração, pesquisa | Manutenção e melhoria contínua | ## Preço Fixo — Quando Sim e o que Evitar Adequado quando há especificação com critérios de aceitação, quando as integrações são conhecidas e documentadas, e quando a qualidade dos dados foi verificada. Em tal situação, o fornecedor pode precificar com confiança razoável e a organização obtém verdadeira previsibilidade orçamentária. Mecanismos de proteção a serem exigidos: - Definição de "Concluído" para cada entrega, não apenas o nome da entrega. - Lista explícita de premissas nas quais o preço se baseia. - Tarifa pré-acordada para solicitações de mudança, para que não seja definida em momentos de urgência. - Cronograma de pagamentos vinculado à aceitação e não a datas. Sinal de alerta: Preço fixo fornecido sem nenhuma pergunta sobre volume de dados, número de usuários ou sistemas fonte. Tal preço mudará; a questão é apenas quando. ## Time & Materials — Quando Sim e Como Controlar Adequado quando há incertezas que não podem ser removidas a baixo custo: um sistema legado central sem documentação, dados históricos de qualidade desconhecida, ou um processo de negócio que ainda está em mudança. Mecanismos de controle que o tornam seguro: - **Teto para cada marco** com alerta ao atingir uma porcentagem acordada do mesmo. - **Relatório por tarefa** — nome da tarefa, horas, status. - **Pontos de saída** ao final de cada marco, sem penalidade. - **Composição de equipe acordada** — quantas horas de sênior e quantas de júnior, para que não mude silenciosamente. O último item é o que tende a ser esquecido, e ele afeta o custo mais do que a própria tarifa. ## Retainer — Quando se Torna Desperdício O Retainer funciona bem após o Go-Live, quando há um fluxo constante de solicitações. Ele falha em duas situações opostas: quando a demanda é baixa e a organização paga por horas não utilizadas, e quando um desenvolvimento significativo é impulsionado e esgota a capacidade de suporte. Duas correções simples: separação explícita entre suporte e desenvolvimento, e uma cláusula de rolagem parcial de horas não utilizadas para o mês seguinte, com um teto. A combinação de ambos estabiliza o modelo. ## Modelos Híbridos Que Funcionam na Prática | Fase do Projeto | Modelo Recomendado | Justificativa | | :-------------- | :----------------- | :------------ | | Consultoria e Análise | Preço Fixo Curto | Escopo conhecido, resultado definido | | Migração de Dados | T&M com Teto | Qualidade dos dados é revelada no processo | | Integrações com Sistemas Legados | T&M com Teto | Depende da outra parte | | Onda de Implementação Definida | Preço Fixo | Critérios de aceitação existentes | | Período de Estabilização | Incluído no custo da onda | Evita discussões sobre o que é falha e o que é mudança | | Manutenção Contínua | Retainer | Demanda consistente | Essa divisão pode parecer mais complexa do que um único contrato, mas ela reduz precisamente as discussões que atrasam os projetos. ## Exemplo Ilustrativo: Importador de Equipamentos Médicos O cenário é hipotético e serve para ilustração. Um importador solicitou uma cotação de preço fixo para um projeto que incluía integração com um sistema de gestão de estoque de quinze anos, sem documentação de API. As três propostas recebidas variaram amplamente, e a mais barata incluía uma pequena frase: "Assumindo a existência de uma interface REST disponível". A organização realizou um breve estudo de viabilidade de uma semana antes da assinatura. Descobriu-se que não havia tal interface e que uma camada intermediária era necessária. O estudo mudou o cenário: a integração passou para o modelo T&M com teto, e o restante do projeto permaneceu em preço fixo. O que o estudo curto evitou não foi um custo adicional — que teria surgido de qualquer forma — mas sim uma disputa contratual no meio do projeto sobre quem era responsável por uma premissa não investigada. ## O Que Afeta o Preço Mais do Que o Modelo de Precificação - **Maturidade da definição** — uma especificação parcial encarece qualquer modelo. - **Número de sistemas fonte** e nível de documentação deles. - **Qualidade dos dados** existentes. - **Disponibilidade dos proprietários do processo** na organização — atrasos nas decisões são um custo direto. - **Número de unidades de negócio** que precisam concordar. Quatro dos cinco fatores estão sob o controle da organização e não do fornecedor. Esta é a razão pela qual o investimento em preparação barateia um projeto mais do que qualquer negociação sobre tarifas. ## Do Modelo ao Contrato Após a escolha do modelo, o que importa é a redação: o que será considerado um produto concluído, quem aprova e o que acontece quando a outra parte atrasa. As cláusulas que devem constar no contrato estão detalhadas no [Guia de Contratos e SOW para Projetos Salesforce](/pt/insights/salesforce-sow-contract-clauses), e a forma de redigir a solicitação para que as propostas sejam comparáveis está detalhada no [Guia de RFP](/pt/insights/salesforce-rfp-guide). A escolha do tipo de serviço a ser precificado inicialmente está detalhada no [Guia de Serviços Salesforce](/pt/insights/salesforce-services-guide), e a verificação do próprio fornecedor no [Guia para Escolher uma Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Próximo Passo Antes de solicitar uma precificação, classifique as três maiores fontes de incerteza em seu projeto. Se você puder nomeá-las, estará pronto para um preço fixo para parte do trabalho. Se não puder — a primeira coisa a adquirir é uma breve avaliação para removê-las, não uma cotação para o projeto inteiro. ### Perguntas e respostas **O Preço Fixo realmente protege o orçamento em um projeto Salesforce?** Ele fixa o preço do escopo definido, não o preço total do projeto. Quando a definição é parcial, a lacuna é preenchida por solicitações de mudança que são precificadas separadamente e, às vezes, com uma taxa mais alta. O Preço Fixo protege o orçamento apenas quando o documento de escopo é detalhado o suficiente para que as partes concordem sobre o que está incluído e o que não está. **Quando a precificação por Horas Trabalhadas é preferível ao Preço Fixo?** Quando há uma incerteza genuína que não pode ser eliminada antes do início do trabalho – integrações com sistemas legados sem documentação, dados de qualidade desconhecida ou um processo de negócios em constante mudança. Em tais cenários, o Preço Fixo simplesmente transfere a incerteza para uma margem de risco que você paga, independentemente de ela se concretizar ou não. **O que é razoável incluir em um Retainer mensal para um ambiente Salesforce?** Normalmente, manutenção, suporte, pequenas alterações de configuração, gerenciamento de lançamentos e monitoramento. O desenvolvimento de novas funcionalidades deve ser excluído do Retainer ou limitado por um teto definido, caso contrário, ele consome as horas destinadas ao suporte, criando a percepção de que o fornecedor não está disponível. **Como evitar o inflacionamento de horas no modelo de Horas Trabalhadas?** Com três mecanismos: um teto acordado para cada marco, com aviso prévio ao se aproximar dele; relatórios de horas no nível da tarefa, e não no nível mensal; e o direito da organização de interromper ao final de cada marco. Juntos, esses três mecanismos oferecem um controle superior ao Preço Fixo, pois permitem ajustes em tempo real. **É possível combinar diferentes modelos no mesmo projeto?** Sim, e essa é frequentemente a escolha mais acertada. Um padrão comum é Preço Fixo para a fase de análise, Horas Trabalhadas com teto para integrações e migração, Preço Fixo para ondas de implementação já definidas, e Retainer após o go-live. Essa divisão alinha cada parte do projeto com o modelo mais adequado ao seu nível de incerteza. --- ## Salesforce Flow ou Apex? Uma Estrutura de Decisão para Automações Corporativas URL: https://hpi.pro/pt/insights/salesforce-flow-vs-apex A escolha entre Flow e Apex não depende da proficiência da equipe, mas da natureza da lógica: número de registros por transação, dependência de Governor Limits, necessidade de Transaction Control e complexidade das condições. Este artigo apresenta um teste de decisão operacional, transcendendo comparações genéricas de capacidades. ## A Resposta Curta A pergunta "Flow ou Apex" recebe uma resposta incorreta quando analisada pela conveniência de escrita ou pela disponibilidade de desenvolvedores. A resposta certa depende de quatro fatores técnicos: quantas transações são processadas por vez, se a lógica exige atomicidade completa, a complexidade das condições e ramificações, e quem fará a manutenção do componente daqui a um ano. O Flow é a escolha _declarative_ padrão para a maioria das automações de negócios – mas há pontos de transição claros onde continuar com o Flow cria um risco operacional, e não apenas um "código menos elegante". Este artigo aborda a decisão de escolha em si: como identificar antecipadamente se a lógica justifica o uso de Apex e como evitar que a escolha seja feita por padrão, e não por discernimento. A questão da limpeza de Flows e processos de automação existentes que já se acumularam como dívida técnica é discutida em um artigo separado e não faz parte desta discussão. ## O que de Fato Distingue os Dois no Nível da Plataforma Flow é um _declarative engine_ que é traduzido em tempo de execução para instruções que realizam DML e SOQL em nome do usuário, enquanto Apex é um código compilado que roda sob os mesmos _Governor Limits_, mas com controle direto da ordem das operações. A primeira diferença prática é a _Bulkification_: um desenvolvedor Apex constrói explicitamente um _loop_ que coleta todos os registros em um único _array_ e executa um DML único, enquanto no Flow é fácil construir um _Loop_ que executa uma operação DML ou uma consulta em cada iteração separadamente — um padrão que atinge o limite de 101 consultas permitidas muito mais rapidamente. A segunda diferença é o controle transacional. O Apex permite `Savepoint` e `Database.rollback` para cancelamento parcial, tratamento de `DmlException` no nível de registro individual via `Database.insert(list, false)`, e lógica condicional complexa sem limite de profundidade de ramificações. No Flow, o tratamento de erros é definido no nível de _Fault Path_ para cada elemento, e isso funciona bem para cenários lineares, mas se torna difícil de rastrear quando há mais do que algumas rotas de falha paralelas. ## Estrutura de Decisão: Quatro Testes Antes de Escolher uma Ferramenta ### Teste de Volume Regra prática: se o processo roda em um único registro como resultado de uma ação do usuário (criação de um _Lead_, mudança de _status_ de oportunidade), o Flow é quase sempre suficiente. Se o processo roda em dezenas a milhares de registros de uma vez — atualização periódica, processamento de um lote vindo de uma integração, limpeza de dados agendada — Apex com `Batchable` ou `Queueable` é a escolha segura, pois oferece controle total sobre a _Bulkification_ e gerenciamento de _Governor Limits_ frente a um volume variável. ### Teste de Atomicidade Deve-se perguntar: se parte da atualização falhar, a outra parte pode permanecer salva? Se a resposta for "não" — por exemplo, atualização de um pedido e criação de um registro de fatura que devem ocorrer juntos — Apex com `Savepoint` é a maneira correta de garantir isso. O Flow não oferece um _rollback_ completo entre elementos sem a construção manual e complexa de lógica de compensação. ### Teste de Complexidade das Ramificações Um Flow com mais de 6-8 _Decision Elements_ aninhados torna-se difícil de ler e caro de testar, mesmo que cada ramificação individual seja simples. Quando a complexidade da lógica de negócios excede isso, escrever essa mesma lógica como uma função Apex documentada com testes de unidade (`@isTest`) geralmente é mais barato de manter, mesmo que o tempo inicial de escrita seja maior. ### Teste de Manutenção e Propriedade Deve-se perguntar quem fará a manutenção do componente daqui a um ano, não quem o está construindo agora. Se a equipe de Admin for a responsável por atualizar as regras de negócios de forma contínua — como a alteração de condições de desconto ou valores limite — o Flow é preferível, mesmo que o Apex seja tecnicamente "mais limpo", pois é acessível para atualização sem um ciclo de implantação. Se as alterações exigem conhecimento do esquema de dados e testes de regressão, o Apex é a escolha certa, mesmo que haja apenas uma pequena equipe de desenvolvimento para mantê-lo. ## Tabela de Decisão | Critério | Escolha Flow | Escolha Apex | |---|---|---| | Volume de registros em uma única transação | Até algumas dezenas | Centenas a milhares | | Exigência de Atomicidade entre vários objetos | Não crítica | Crítica — _Rollback_ completo necessário | | Número de ramificações de decisão | Até aproximadamente 6-8 | Acima disso, ou lógica recursiva | | Frequência de mudança das regras de negócios | Frequente, por Admin | Rara, exige testes de regressão | | Necessidade de chamar API externa complexa | Chamada única simples (HTTP Callout) | Lógica de _Retry_, autenticação complexa ou _Batch_ | | Exigência de testes automatizados (CI) | Limitada | Completa, `@isTest` com _Coverage_ | | Integração com _Scheduled Job_ regular | Não diretamente adequado | Natural via `Schedulable` | ## Cenário de Exemplo: Empresa de Equipamentos Médicos com Processo de Aprovação de Pedidos Uma empresa de equipamentos médicos de médio porte com cerca de 40 representantes de vendas operava um Flow para o processo de aprovação de pedidos: verificação de estoque, cálculo de desconto, criação de registro de aprovação e envio de notificação ao gerente. No início, funcionou bem para um único pedido. Após seis meses, um novo cenário foi adicionado — importação em lote de pedidos de um arquivo de integração com o ERP, que cria entre 200 e 800 pedidos simultaneamente. O Flow, que era acionado por um _Record-Triggered Flow_ no nível "para cada registro", executava uma consulta de verificação de estoque dentro de cada execução separadamente. Com a importação de 500 pedidos, o sistema excedeu o limite de 100 consultas em uma única transação, e os pedidos falharam sem uma mensagem de erro clara para o usuário. A equipe identificou que o problema não era no Flow em si, mas na adequação entre um processo projetado para um único registro e um cenário de volume que não existia no momento da construção. A solução não foi abandonar o Flow. A equipe dividiu a lógica: o Flow permaneceu responsável pelo processo manual de um único pedido (teste de baixo volume, necessidade de atualização frequente das regras de desconto pelo Admin), enquanto o processo de importação em lote foi transferido para um _Apex Batch Job_ que realiza _Bulkification_ completa, verifica o estoque em uma única consulta concentrada e executa um DML único para todos os registros. Os dois mecanismos chamam a mesma camada de lógica de negócios compartilhada (uma única _Apex Class_ que o Flow também chama via _Invocable Method_), para que a regra de desconto não seja mantida duas vezes. ## Riscos Comuns e Ações Preventivas | Risco | Como isso se manifesta na prática | Ação preventiva | |---|---|---| | Flow sobre volume que cresce gradualmente | O processo funcionou por seis meses e então falhou silenciosamente por _Governor Limits_ | Avaliar o volume esperado antecipadamente e planejar um ponto de transição para Apex antes de atingir o limite | | Duplicidade de lógica de negócios em Flow e Apex | Dois locais calculam o desconto de forma diferente | Centralizar o cálculo de negócios em uma camada Apex comum que o Flow também chame | | _Trigger Order_ inesperado | Vários Flows e Triggers no mesmo objeto entram em conflito | Um _Trigger Handler_ centralizado em Apex para cada objeto crítico | | Tratamento parcial de erros em Flow complexo | Parte dos registros é atualizada e parte não, sem visibilidade | Transferir processos que exigem Atomicidade para Apex com `Savepoint` | | Apex sem testes suficientes | Uma pequena alteração quebra um processo crítico na próxima implantação | Exigir _Coverage_ real e não apenas uma porcentagem formal, incluindo cenários de falha | ## Checklist para Decisão Antes da Construção - [ ] Volume esperado avaliado para o período de um ano, não apenas o estado atual - [ ] Definido se o processo requer Atomicidade entre vários objetos - [ ] Contadas as ramificações de decisão esperadas na lógica - [ ] Confirmado quem fará a manutenção do componente e com que frequência as regras mudarão - [ ] Verificado se já existe lógica semelhante em Apex ou em outro Flow no mesmo objeto - [ ] Definido o _Trigger Order_ se houver vários mecanismos de automação no objeto - [ ] Se Apex for escolhido — cenários de teste definidos, incluindo falha parcial - [ ] Se Flow for escolhido — _Fault Path_ definido para cada elemento crítico ## Como Isso se Conecta à Arquitetura Mais Ampla A escolha da ferramenta certa para uma automação individual é apenas uma camada em uma imagem mais ampla da [arquitetura de CRM](/pt/insights/crm-architecture-guide), na qual tanto o modelo de dados quanto as permissões afetam o que o Flow ou o Apex podem tocar. Quando a automação cruza a fronteira para uma organização externa — por exemplo, verificação de estoque com o ERP em tempo real — a escolha entre Flow e Apex também se encaixa nas considerações sobre [padrões de integração](/pt/insights/salesforce-integration-patterns) e na questão de como [Salesforce se conecta ao ERP](/pt/insights/salesforce-erp-integration) em termos de latência e tratamento de falhas. Em organizações que operam vários _Orgs_, também é necessário verificar se a lógica de negócios é idêntica em todos eles — um tópico discutido no [guia Single Org vs. Multi Org](/pt/insights/salesforce-single-org-vs-multi-org) e que afeta a questão de valer a pena centralizar a lógica em um _Apex Package_ compartilhado. ## Resumo A escolha entre Flow e Apex não é uma questão de habilidade da equipe ou gosto pessoal, mas sim o resultado de quatro testes técnicos: volume, atomicidade, complexidade das ramificações e frequência de mudança. O Flow é o _declarative default_ para a maioria das automações que interagem com um único registro e mudam com alta frequência. O Apex é necessário quando há um volume significativo, quando é preciso controle total da transação ou quando a complexidade lógica excede o limite que ainda pode ser mantido por meio de uma interface declarativa. Uma organização que estabelece esses testes como parte de seu processo de trabalho — e não os deixa para o julgamento _ad-hoc_ de cada desenvolvedor — economiza a maioria dos casos em que uma automação que funcionou bem no início se quebra silenciosamente quando o volume cresce. ### Perguntas e respostas **É possível iniciar com Flow e migrar para Apex posteriormente sem interromper o processo?** Geralmente sim, se o Flow for construído em torno de um evento de negócio claro, e não de uma tela específica. Quando o Flow invoca um processo através de um Invocable Action ou Subflow, é possível substituir a implementação interna por Apex sem modificar o gatilho, permissões ou interface. O problema surge quando o Flow e a lógica de negócio estão intrinsecamente ligados — nesse caso, qualquer alteração exige uma reconstrução completa, não apenas um refactoring. **O Flow pode manipular a atualização de milhares de registros de uma só vez?** Tecnicamente, sim, mas na prática isso depende da carga da lógica dentro do loop. Um Flow que executa uma consulta SOQL ou DML dentro de um loop para cada registro pode atingir os Governor Limits muito antes de um Apex equivalente, pois o Flow Engine nem sempre realiza o Bulkification automático com a mesma eficiência. Para atualizações massivas recorrentes, e não pontuais, Apex com Batch ou Queueable é a escolha mais segura. **O que acontece quando há múltiplos Flows e Triggers no mesmo objeto?** A ordem de execução é determinada pelas configurações do Salesforce e nem sempre corresponde à intenção da equipe, tornando fácil obter um resultado inesperado quando múltiplos mecanismos interagem com o mesmo registro. A solução é consolidar toda a lógica de automação de um objeto central em torno de um único Trigger Handler em Apex e usar Flows apenas para processos que não conflitam com a lógica crítica. **Quando se deve escrever Apex, mesmo que o Flow seja tecnicamente suficiente?** Quando a lógica envolve uma única transação que deve ter sucesso ou falhar por completo — por exemplo, a atualização de dois objetos relacionados que não podem permanecer dessincronizados. O Flow lida com erros no nível do elemento individual e nem sempre garante atomicidade completa, enquanto o Apex permite Savepoints e Rollbacks controlados. **O Apex é sempre mais caro de manter do que o Flow?** Não necessariamente. Um Flow complexo, com dezenas de ramificações de decisão, Subflows aninhados e lógica oculta em campos de fórmula, pode ser mais difícil de depurar do que um Apex bem documentado com testes unitários. O custo depende da extensão da lógica e da qualidade da documentação, e não da ferramenta em si. --- ## Tempo Real, Batch ou Orientado a Eventos? Escolhendo um Padrão de Integração para Salesforce URL: https://hpi.pro/pt/insights/salesforce-integration-patterns A escolha errada de um padrão de integração não se revela em uma demonstração - ela emerge quando a carga de trabalho aumenta, quando um sistema externo fica inoperante por um minuto, ou quando dois usuários atualizam o mesmo cliente simultaneamente. Este guia oferece uma estrutura de decisão baseada em apenas três perguntas: qual a velocidade necessária para a informação, quem é o proprietário da verdade, e o que acontece quando algo falha. ## Três Perguntas Que Definem o Padrão, Não a Ferramenta O erro comum na escolha de uma integração com o Salesforce é começar pela ferramenta: MuleSoft, Platform Events, Bulk API ou um Webhook simples. A ferramenta é um resultado, não um ponto de partida. Três perguntas definem o padrão correto: 1. **Em quanto tempo o outro lado precisa saber?** Segundos, minutos, horas ou um dia — a diferença entre Real-Time e Batch. 2. **Quem é o proprietário dos dados a qualquer momento?** Se a resposta não for clara, nenhum padrão técnico resolverá o problema. 3. **O que acontece se o outro lado não estiver disponível?** A resposta "esperamos novamente" não é uma resposta — é preciso ter um comportamento definido: Retry, fila ou falha explícita. Quem responde a essas três perguntas antes de escolher uma tecnologia quase sempre chega à mesma conclusão que um arquiteto experiente — mas sem pagar por tentativa e erro em produção. Uma expansão sobre a conexão entre esta decisão e a arquitetura geral pode ser encontrada no [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide). ## Mapa de Padrões: Quando Cada Um se Encaixa | Padrão | Tempo de Resposta Típico | Exemplo de Uso Típico | Custo de Manutenção | Risco Principal | |---|---|---|---|---| | Request-Reply Síncrono | Milissegundos a Segundos | Verificação de crédito antes da aprovação de uma transação na tela | Médio | Timeout trava o usuário | | Fire-and-Forget | Imediato no envio, sem esperar resultado | Envio de evento para criar uma Task em outro sistema | Baixo-Médio | Falha silenciosa sem monitoramento | | Batch Periódico | Horas a Um Dia | Sincronização diária de catálogo de produtos de um ERP | Baixo | Discrepâncias de tempo entre os sistemas | | CDC (Change Data Capture) | Segundos a Minutos | Atualização de status de pedido que afeta o suporte | Médio-Alto | Carga no Event Bus em caso de muitas mudanças | | Event-Driven (Platform Events / Pub-Sub) | Segundos | Notificação de evento de negócio para vários consumidores em paralelo | Alto na implantação, Baixo na manutenção | Exige disciplina de Schema e Versioning | A tabela é um ponto de partida para discussão, não um veredito final. Um único sistema pode, e às vezes deve, usar vários padrões simultaneamente, dependendo do tipo de dado. ## Por Que a Latência Não é Suficiente Para Decidir O segundo erro comum: decidir apenas pela latência e ignorar a consistência. Um padrão rápido que atualiza apenas um lado e deixa o outro "quase sincronizado" cria um problema mais grave do que um padrão lento, mas consistente—porque os usuários aprendem a não confiar nos dados e, então, contornam o sistema. A pergunta correta é dupla: quão rápida a resposta é necessária, **e quão grave** é uma situação em que os dois lados não estão sincronizados por um momento. Um processo de precificação apresentado ao cliente exige tanto velocidade quanto consistência total — nesse caso, é necessário um Request-Reply síncrono com um Timeout definido e tratamento explícito de falhas. Uma atualização de "número de visualizações em um artigo" pode conviver tranquilamente com um atraso de minutos — nesse caso, Fire-and-Forget ou CDC são suficientes. ## Propriedade dos Dados: Uma Decisão Que Precede Qualquer Padrão Antes de escolher como os dados transitam entre os sistemas, é preciso decidir onde eles são "verdadeiros". Um campo que é atualizado em dois sistemas sem um proprietário definido cria um loop de sincronização: A envia para B, B atualiza e envia de volta para A, A envia novamente. Isso não é um cenário extremo — é o resultado esperado da sincronização bidirecional sem uma regra de decisão. Uma regra prática de trabalho: para cada campo compartilhado, define-se um único Owner. Se houver uma necessidade de negócio real para edição de ambos os lados (por exemplo, o atendimento ao cliente atualiza o endereço tanto no Salesforce quanto no ERP), adiciona-se uma regra explícita de Conflict Resolution — último Timestamp ganha, ou um campo define e o outro é apenas para exibição. A gestão de permissões para esses campos sensíveis é discutida no [Guia de Modelo de Permissões no Salesforce](/pt/insights/salesforce-permission-model). ## Tratamento de Falhas: O Teste Que a Maioria dos Projetos Pula Quase toda integração passa por um teste de Happy Path. Poucas passam por um teste sistemático dos três cenários de falha a seguir: - **O segundo sistema não está disponível no momento do envio** – A mensagem é salva em uma fila e enviada novamente, ou é perdida? - **A mensagem chega duas vezes** (problema comum em Retry automático e Event Bus) – O lado receptor cria um registro duplicado? - **A mensagem chega em ordem errada** – A atualização de status "cancelado" que chega antes de "aprovado" causa um resultado incorreto? Um sistema que não é construído como Idempotente (identificador único para cada mensagem + verificação se já foi processada) falhará precisamente nos dois primeiros cenários, e geralmente sob carga — ou seja, exatamente quando o negócio mais depende dele. As limitações da API e a lida com Throttling neste contexto são detalhadas no [Guia de Limites de API Salesforce](/pt/insights/salesforce-api-limits-resilience). ## Estrutura de Decisão: Da Questão de Negócio ao Padrão | Pergunta feita primeiro | Se a resposta for "sim" | Se a resposta for "não" | |---|---|---| | O usuário está esperando na tela pelo resultado da integração? | Request-Reply síncrono com Timeout definido | Continuamos para a próxima pergunta | | É necessária uma atualização em poucos minutos de uma única mudança? | CDC ou Platform Event | Continuamos para a próxima pergunta | | Vários consumidores diferentes precisam saber sobre o mesmo evento? | Event-Driven com Pub-Sub | Continuamos para a próxima pergunta | | É conveniente processar um grande volume em uma janela de tempo fixa? | Batch periódico | Avaliar Fire-and-Forget com fila | Este é um ponto de partida para discussão em reunião de arquitetura, não uma fórmula exaustiva — sempre há casos de fronteira (por exemplo, volume enorme que exige CDC mas também Reconciliação Batch diária como rede de segurança). ## Cenário Ilustrativo: Rede de Clínicas Particulares com Vinte Unidades Suponhamos uma rede de clínicas que utiliza o Salesforce para gerenciar consultas de pacientes e um sistema de faturamento separado (Billing) que, nesta fase, não pode ser substituído. A demanda: quando um paciente conclui uma consulta, o sistema de faturamento deve ser atualizado imediatamente, e quando um faturamento é atualizado (por exemplo, pagamento recebido), o Salesforce precisa refletir essa mudança para que o agente de serviço não solicite um pagamento duplicado. A escolha inicial da equipe foi um Batch noturno bidirecional — simples de implementar, mas criou uma lacuna de até 24 horas em que os agentes viam informações desatualizadas e causava reclamações. A solução escolhida na prática: o sentido único (conclusão de consulta do Salesforce para o faturamento) mudou para Fire-and-Forget com fila de mensagens e Retry automático, pois não é necessário que o usuário espere. O sentido inverso (confirmação de pagamento do faturamento para o Salesforce) mudou para CDC, pois se trata de uma mudança pontual que precisa chegar em minutos. O Batch noturno permaneceu apenas como um mecanismo de Reconciliação — uma comparação diária que detecta lacunas e alerta, não como o principal canal de atualização. O resultado: o tempo de atualização diminuiu de horas para minutos, e o mecanismo de Reconciliação capturou dois casos de mensagens perdidas no primeiro mês — exatamente sua função. ## Riscos e Ações Preventivas Específicas para Integração | Risco | Como se manifesta na prática | Ação preventiva | |---|---|---| | Falta de Idempotência | Registros duplicados após Retry ou falha de rede | Identificador único para mensagem + verificação de existência antes da criação | | Fonte de verdade indefinida | Loop de sincronização ou atualização "vencedora" aleatória | Owner definido para cada campo + regra de Conflict Resolution | | Point-to-Point sem camada de integração | Qualquer mudança de esquema em um sistema quebra outra conexão | Camada de Middleware/API com contrato de versionamento explícito | | Monitoramento apenas técnico | A integração está "verde" mas os pedidos estão faltando na prática | Métrica de Reconciliação de negócio, não apenas Uptime técnico | | Ignorar Governor Limits | A integração falha justamente sob carga máxima | Planejamento de Bulkification e Backoff antecipados, não como reação | ## Checklist para Seleção de Padrão de Integração - ☐ Tempo de resposta necessário definido em números, não na palavra "rápido" - ☐ Owner único definido para cada campo compartilhado entre os sistemas - ☐ Verificado o que acontece quando o outro lado não está disponível — e documentado - ☐ Verificado o que acontece quando uma mensagem chega duas vezes - ☐ Verificado o que acontece quando as mensagens chegam fora de ordem - ☐ Existe um mecanismo de Reconciliação mesmo que o padrão principal seja assíncrono - ☐ Limites de API e Governor Limits verificados em relação ao volume esperado em carga máxima - ☐ Métricas de sucesso de negócio definidas, e não apenas técnicas ## Métricas para Validação Contínua da Integração Após o lançamento, é recomendável acompanhar apenas três a quatro métricas: taxa de mensagens bem-sucedidas na primeira tentativa, tempo de ponta a ponta real versus o SLA definido, diferenças diárias de Reconciliação entre os sistemas e proximidade dos limites da API. Um aumento consistente em qualquer uma delas — e não apenas um desvio pontual — é o sinal para considerar a transição para outro padrão, antes que o sistema falhe em produção. Considerações sobre identidade e permissões de acesso entre sistemas são detalhadas no [Guia de SSO e Identidade no Salesforce](/pt/insights/salesforce-sso-identity-architecture). ## Resumo A escolha correta do padrão de integração não começa com a pergunta "qual ferramenta", mas com três questões: quão rápida a resposta é necessária, quem é o proprietário dos dados e o que acontece quando algo falha. Real-Time é adequado quando o usuário espera por um resultado; CDC e Event-Driven são adequados para atualização rápida de uma única mudança ou para distribuição a vários consumidores; Batch é adequado para grandes volumes em uma janela de tempo fixa. Em qualquer padrão, Idempotência, propriedade de dados definida e um mecanismo de Reconciliação não são "bom ter" — são a condição para que a integração resista a uma carga real e não apenas a uma demonstração. ## Fontes Profissionais - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitetura de CRM — https://hpi.pro/crm-architecture - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Qual a diferença prática entre Fire-and-Forget e Request-Reply em uma integração Salesforce?** Em Request-Reply, o solicitante aguarda uma resposta e recebe confirmação imediata de sucesso ou falha da operação – ideal quando um usuário está em frente à tela e precisa do resultado para prosseguir. Em Fire-and-Forget, o remetente continua imediatamente e a resposta, se houver, chega assincronamente – adequado para atualizações que não bloqueiam um processo humano. A escolha errada faz os usuários esperarem por um sistema que não foi projetado para esperar, ou perder falhas silenciosas. **Quando o CDC é preferível ao Batch periódico para sincronização de dados?** O CDC (Change Data Capture) é preferível quando o volume de alterações em relação ao volume total é pequeno e quando é necessário refletir uma mudança em minutos, não em horas – por exemplo, a atualização de status de um pedido que afeta o atendimento ao cliente. O Batch é preferível quando é conveniente processar um grande volume em uma janela de tempo fixa, quando a fonte não suporta um Event Stream, ou quando o próprio processamento requer um cálculo sobre um conjunto completo de registros, e não apenas uma única alteração. **Como lidar com a duplicação de mensagens em uma integração baseada em eventos?** Assuma que toda mensagem pode chegar mais de uma vez e projete o lado receptor como Idempotente: um identificador exclusivo para cada mensagem, verificação se já foi processada antes de executar a ação, e salvamento do resultado para que uma execução repetida não crie um registro duplicado ou atualize duas vezes. Contar com a premissa de 'a mensagem chegará uma vez' é a suposição que primeiro falha sob carga ou falha de rede. **Quem é responsável pela fonte da verdade quando o mesmo campo é atualizado tanto no Salesforce quanto em um sistema externo?** É preciso decidir antecipadamente qual sistema é o proprietário do campo, e documentar isso no contrato de integração, não apenas na memória da equipe. A atualização bidirecional sem um proprietário definido cria loops de sincronização e um resultado final dependente do tempo. Quando há uma necessidade real de edição de ambos os lados, é necessária uma regra explícita de Resolução de Conflitos – por exemplo, 'a última atualização vence' baseada no Timestamp – e não a suposição de que essa situação não acontecerá. **Como saber se um padrão de integração escolhido ainda é adequado depois que a carga aumenta dez vezes?** Verifique três coisas: se o tempo de processamento ainda atende ao SLA (Service Level Agreement) definido, se a taxa de falhas e retentativas aumentou além de um limite pré-estabelecido, e se os limites da API do Salesforce (como Governor Limits ou API Calls) estão se aproximando do teto. Um aumento em qualquer um desses indicadores é um sinal para considerar a transição de Batch para CDC, a adição de Queueing, ou a divisão em processos paralelos – antes que o sistema falhe em produção. --- ## Modelo de Permissões Salesforce: Como Planejar o Acesso Sem Exposição Excessiva URL: https://hpi.pro/pt/insights/salesforce-permission-model A maioria das organizações constrói modelos de permissões de cima para baixo – primeiro, um Profile abrangente, depois correções pontuais até que ninguém se lembre por que um usuário tem determinado acesso. O caminho correto é o oposto: um Profile restrito para acesso básico e Permission Set Groups que constroem a capacidade de trabalho por função. Este artigo apresenta uma estrutura de trabalho operacional para isso. ## A Pergunta Fundamental: O Que Determina o Acesso de um Usuário? Quando alguém pergunta "como um usuário obteve acesso a este campo", a resposta correta é quase sempre uma combinação: o **Profile** estabelece o acesso básico, os **Permission Set Groups** atribuídos adicionam capacidades por função, e, ocasionalmente, um **Permission Set** individual trata de uma exceção específica. O problema na prática é que a maioria das organizações constrói essa combinação de forma inversa – começam com um Profile abrangente que contém quase tudo e, em seguida, "corrigem" problemas pontuais com permissões individuais que ninguém se lembra de remover. Um modelo de permissões saudável é construído na direção oposta: um Profile o mais restrito possível, que define principalmente licenciamento, acesso padrão a aplicativos e características de login; e toda a capacidade de trabalho real – quais objetos, quais campos, quais ações – é transferida para **Permission Sets** e **Permission Set Groups**. É importante esclarecer: este artigo aborda apenas os níveis de Object, Field e System Permissions. Questões de visibilidade de registros entre usuários – OWD, Role Hierarchy, Sharing Rules – são discutidas no [Guia de Visibilidade e Compartilhamento](/pt/insights/crm-architecture-guide), pois representam uma camada de decisão separada com suas próprias compensações (trade-offs). ## As Três Unidades e Suas Funções | Unidade | O Que Ela Determina | Quantas um Usuário Pode Ter | Quando Utilizá-la | | --- | --- | --- | --- | | Profile | Licenciamento, visibilidade padrão de aplicativo, Page Layout, Login Hours/IP | Exatamente um | Diferenças de infraestrutura entre tipos de usuário | | Permission Set | Permissões de Objeto, Campo, Apex Class, Guia (Tab) - apenas adiciona | Quantas forem necessárias | Uma capacidade única e relevante para algumas funções | | Permission Set Group | Empacotamento de vários Permission Sets sob um único nome, com a opção Muting | Quantos forem necessários | Uma combinação fixa de permissões que representa uma função de trabalho completa | A diferença entre um Permission Set e um Permission Set Group não é apenas técnica – é organizacional. Um Permission Set individual é adequado para uma única capacidade focada ("acesso a relatórios financeiros"). Um Permission Set Group é adequado quando se deseja atribuir um "pacote de trabalho" completo a um departamento ou função, e mantê-lo em um único local quando ele muda. ## Estrutura de Decisão: Onde uma Nova Permissão Deve Pertencer Quando surge uma solicitação para adicionar acesso, a primeira pergunta não é "a qual Profile adicionar", mas sim a qual unidade a permissão pertence estruturalmente: 1. **Esta permissão caracteriza todos os usuários com o mesmo tipo de licença?** Se sim, este é um lugar para o Profile, desde que se refira a todos os titulares da licença e não a um subconjunto. 2. **Esta é uma capacidade de trabalho que um grupo de funções específico sempre precisa junto com permissões adicionais?** Se sim, este é um lugar para o Permission Set Group, mesmo que precise primeiro ser dividido em vários Permission Sets separados para permitir uma combinação flexível. 3. **Esta é uma permissão pontual e temporária para um único usuário ou uma exceção?** Se sim, um Permission Set autônomo, atribuído manualmente e verificado na auditoria periódica. 4. **A permissão deve negar algo a um usuário específico dentro de um grupo amplo?** Aqui entra o Muting Permission Set dentro de um Permission Set Group – a única ferramenta no Salesforce que permite reduzir uma permissão sem tocar no Profile ou desmontar o grupo. A regra que previne a maior parte da "deriva" (drift): nunca edite um Profile para resolver um problema de um único usuário. Se a correção for definida como uma exceção, ela passa por um Permission Set que é documentado e tem uma data de revisão. ## Lista de Verificação (Checklist) para Construir um Modelo de Permissões do Zero - ☐ As funções de trabalho reais (e não os departamentos organizacionais) foram mapeadas e cada função recebeu um nome claro. - ☐ Para cada função, foi definida uma lista de capacidades necessárias nos níveis de objeto, campo e Apex Class. - ☐ Foram construídos Permission Sets focados em uma única capacidade, não um "monte de permissões" genéricas. - ☐ Cada função recebeu um Permission Set Group que agrupa as capacidades relevantes. - ☐ Os Profiles foram reduzidos para abranger apenas diferenças de licenciamento e infraestrutura. - ☐ Foi definido um processo para casos excepcionais: quem aprova um Permission Set pontual e por quanto tempo. - ☐ Foi estabelecida uma frequência de auditoria (pelo menos trimestral) que compara permissões ativas com a função atual. - ☐ Foi definido um único Responsável (Owner) pela manutenção do modelo de permissões frente às mudanças na estrutura organizacional. ## Cenário Organizacional: Uma Seguradora com Três Unidades de Vendas Suponhamos uma seguradora de médio porte com cerca de trezentos usuários Salesforce, divididos em três unidades: vendas diretas, vendas através de agentes e sinistros. Antes do projeto, a empresa tinha doze Profiles diferentes, alguns deles cópias quase idênticas criadas para "corrigir" uma única permissão para um pequeno grupo. Um resultado típico: quando um novo agente era contratado, ninguém sabia ao certo qual Profile dos doze era o mais adequado para ele, e a resposta na prática era "copie de alguém semelhante". A equipe de arquitetura reconstruiu o modelo: apenas três Profiles, de acordo com o tipo de licença (Sales Cloud completo, Community para agentes externos, Service Cloud para sinistros). Acima disso, sete Permission Set Groups por função de trabalho real – representante de vendas, gerente de equipe de vendas, agente externo, gerente de agentes, avaliador de sinistros, gerente de sinistros e uma função de mediação que lida tanto com vendas quanto com sinistros. Cada Permission Set Group foi composto por Permission Sets focados, como "acesso a apólices ativas" ou "aprovação de reembolso até um limite definido", de modo que pudessem ser recombinados quando uma nova função fosse criada sem precisar construir a permissão do zero. O resultado mensurável: o tempo de configuração de um novo usuário diminuiu de vários dias (que incluíam verificação manual de qual Profile era adequado) para algumas horas, e o número de solicitações de suporte do tipo "não tenho acesso ao campo X" caiu pela metade no trimestre seguinte à transição, porque a maioria dessas solicitações resultava de um Profile que não incluía a capacidade e não estava claro a quem recorrer para correção. ## Riscos Comuns e Ações Preventivas | Risco | Como se Manifesta na Prática | Ação de Prevenção | | --- | --- | --- | | Profile se torna uma ferramenta de correção pontual | Multiplicidade de Profiles quase idênticos, cada um para um pequeno grupo | Transferir cada permissão pontual para um Permission Set e reduzir Profiles apenas para licenciamento | | Field-Level Security inconsistente | O mesmo campo exposto em um lugar e restrito em um lugar comparável | Documentar uma matriz centralizada de FLS para cada campo sensível e verificá-la em cada Release | | Permissões "pegajosas" após mudança de função | Usuário que mudou de função mantém permissões da função anterior | Processo de desvinculação da função (offboarding) que remove o Permission Set Group antigo antes de adicionar um novo | | System Permissions muito amplas (View All Data, Modify All) | Concedidas "para economizar tempo" e não removidas posteriormente | Aprovação dedicada e data de expiração para cada permissão de sistema ampla | | Ausência de responsável pelo modelo de permissões | Cada equipe adiciona permissões sem uma visão geral | Um único Responsável (Owner) que aprova cada novo Permission Set ou Group antes da implantação | ## Métricas para Avaliar a Saúde do Modelo | Área | O Que Medir | Frequência de Verificação | | --- | --- | --- | | Redundância Desnecessária | Número de Profiles ativos em relação ao número de tipos de licença reais | Trimestral | | Precisão da Permissão | Percentual de usuários cujas permissões correspondem à função registrada no RH | Trimestral | | Exceções Abertas | Número de Permission Sets pontuais sem data de revisão | Mensal | | Permissões Amplas | Número de usuários com View All Data / Modify All Data sem justificativa documentada | Mensal | | Tempo de Configuração | Tempo médio desde a solicitação de novo acesso até a atribuição completa | Contínuo | Na primeira versão do monitoramento, é aconselhável limitar-se a três das cinco métricas e expandir somente após ter uma linha de base confiável. Uma métrica sem um responsável e uma data de verificação tende a desaparecer do relatório após o primeiro mês. ## Como Isso se Integra à Arquitetura Mais Ampla Um bom modelo de permissões é uma condição prévia, não um substituto, para o planejamento da visibilidade de registros (OWD, Role Hierarchy, Sharing Rules) – os dois tópicos se complementam, mas são resolvidos separadamente. Uma organização que tenta resolver um problema de visibilidade expandindo o Profile, ou vice-versa, geralmente descobre que a solução é frágil assim que a estrutura organizacional muda. Quando a organização transita entre múltiplos Orgs e um único Org, o modelo de permissões é uma das coisas que precisam ser remapeadas – uma expansão sobre o assunto aparece no [Guia Single Org vs. Multi Org do Salesforce](/pt/insights/salesforce-single-org-vs-multi-org). E quando a permissão em si depende de uma lógica condicional complexa, é aconselhável avaliar se a implementação pertence a um Flow ou a um Apex, conforme detalhado no [Guia Flow vs. Apex do Salesforce](/pt/insights/salesforce-flow-vs-apex). Em organizações que executam processos orientados a eventos entre sistemas, é essencial garantir que as permissões dos usuários de serviço (Integration Users) sejam construídas de acordo com o mesmo princípio – um Permission Set focado e não um Profile amplo com "System Administrator" como padrão conveniente. Este tópico se conecta ao planejamento mais amplo da comunicação entre sistemas, descrito no [Guia de Arquitetura Orientada a Eventos para Salesforce](/pt/insights/salesforce-event-driven-architecture). ## Conclusão Um modelo de permissões que resiste ao teste do tempo é construído de baixo para cima: capacidades focadas em Permission Sets, agrupamento delas por função de trabalho real em Permission Set Groups, e um Profile que mantém um papel mínimo de licenciamento e infraestrutura apenas. A indicação clara de falha é a proliferação de Profiles criados para resolver problemas pontuais – cada Profile adicional desse tipo é uma dívida que se acumula até que ninguém se lembre por que ele existe. Quando a capacidade interna para construir ou limpar um modelo existente é insuficiente, [serviços de arquitetura de CRM](/pt/crm-architecture) oferecem um caminho prático para um início focado. ### Perguntas e respostas **Qual a diferença prática entre Profile e Permission Set?** Cada usuário possui exatamente um Profile, que também define aspectos que não são permissões no sentido estrito – visibilidade padrão de aplicativos, atribuição de Page Layout, horário de login e faixas de IP. Um Permission Set é um complemento que apenas adiciona acesso e nunca o restringe. A conclusão de planejamento é: mantenha o Profile com um papel mínimo, e construa a maioria das diferenças entre usuários com Permission Sets. **Quando transformar vários Permission Sets em um único Permission Set Group?** Quando um grupo de usuários – por exemplo, um 'Agente de Atendimento Sênior' – sempre precisa da mesma combinação fixa de permissões provenientes de vários Permission Sets separados (acesso a casos, acesso a reembolsos, acesso à base de conhecimento). A união em um grupo economiza atribuições manuais repetitivas e reduz erros onde o usuário recebe apenas parte da combinação necessária para a função. **Um Permission Set pode revogar uma permissão existente no Profile?** Não. As permissões no Salesforce são apenas aditivas – um Permission Set adiciona, nunca restringe. Se for necessário revogar o acesso de um usuário específico sem afetar outros, a solução é um Muting Permission Set dentro de um Permission Set Group, e não a edição do Profile dele. **Quantos Profiles seriam ideais para uma organização de porte médio?** Não há um número único, mas uma regra prática útil: o número de Profiles deve refletir as diferenças de licenciamento e infraestrutura (tipo de licença, acesso padrão a aplicativos), não as diferenças de permissão entre funções. Uma organização com dezenas de Profiles quase sempre os usa para compensar a falta de Permission Set Groups organizados. **Como verificar se uma permissão adicionada não permaneceu ativa além do necessário?** Usando um Permission Set direcionado para um período limitado (Permission Set License com data de expiração, quando relevante, ou um processo de auditoria trimestral) e não uma permissão permanente. Além disso, execute relatórios periódicos que comparem permissões ativas com a função atual na tabela de RH, marcando desvios para investigação. --- ## Salesforce Org Único ou Multi-Org? Considerações para uma Arquitetura Empresarial URL: https://hpi.pro/pt/insights/salesforce-single-org-vs-multi-org A arquitetura Multi-Org não surge de uma única decisão, mas da acumulação de unidades de negócio, regulamentação e modelos de dados que não se encaixam no mesmo espaço. Este artigo apresenta um teste de três perguntas para avaliar a real necessidade, uma matriz de comparação custo-benefício e um roteiro gradual para quem já está no caminho da separação. ## As Três Perguntas Que Determinam a Necessidade de Multi-Org O erro comum é abordar a questão "um Org ou vários?" como uma questão técnica de capacidade ou performance. Na maioria dos casos, a resposta técnica existe dentro de um único Org: Record Types, Profiles, Permission Sets e Sharing Rules são suficientes para separar unidades de negócios sem dividir o ambiente em si. O Salesforce suporta dezenas de milhares de usuários e milhões de registros em um único Org — a capacidade quase nunca é a verdadeira razão para a divisão. A questão que realmente importa é uma questão de independência organizacional, e se desdobra em três testes: 1. **Independência Regulatória Genuína** — Existe um requisito legal ou contratual para a separação física dos dados (por exemplo, uma entidade legal separada com regulamentação local que proíbe o compartilhamento de infraestrutura), diferentemente da separação lógica que pode ser alcançada com o Sharing Model. 2. **Ritmo de Mudança Incompatível** — Uma unidade de negócios precisa de ciclos de Release frequentes e rápidos, enquanto outra exige máxima estabilidade e auditoria rigorosa, de modo que cada Release compartilhado se torne um ponto constante de atrito entre as equipes. 3. **Modelo de Dados Conflitante no Núcleo**, e não apenas diferente — Quando uma mesma entidade (por exemplo, "Cliente" ou "Pedido") possui uma definição de campo obrigatório, um fluxo de aprovação ou uma estrutura de relacionamentos que é fisicamente contraditória entre as unidades, e não apenas diferente na exibição. Se nenhuma das três condições for claramente atendida, a solução correta é um único Org com separação lógica. A divisão "por segurança" cria um custo operacional fixo — duplicação na gestão de usuários, duplicação de licenciamento e duplicação na manutenção de integração — em troca de um problema que poderia ser resolvido com configuração. ## Matriz de Decisão: Um Org versus Vários Orgs | Dimensão | Um Org com Separação Lógica | Vários Orgs Separados | | :---------------------------------- | :--------------------------------------------- | :-------------------------------------------------- | | Custo de Licenciamento e Manutenção | Mais baixo — uma licença, gestão centralizada | Mais alto — duplicação de licenças, duplicação na gestão de Release | | Customer 360 e Visão Unificada | Natural — todos os dados no mesmo espaço | Requer camada de BI ou integração dedicada | | Independência Operacional por Unidade | Limitada — cada Release afeta todos | Completa — cada unidade controla seu ritmo | | Conformidade Regulatória Estrita | Não aplicável se a exigência for física | A única opção que atende ao requisito | | Complexidade da Integração Interna | Baixa | Alta — exige Middleware ou ETL | | Risco em Fusões/Cisões Futuras | Baixo — apenas alteração de permissões | Alto — projeto de migração completo | Conclusão: a opção padrão deve ser um único Org, e a divisão só deve ser escolhida quando houver uma resposta positiva e clara para uma das três perguntas acima, e não como uma reação a um atrito organizacional temporário. ## O Que Acontece na Prática ao Dividir Sem Razão Suficiente Quando uma organização divide um Org por razões políticas (uma unidade que busca "seu próprio controle") e não por razões técnicas reais, três coisas acontecem dentro de um ou dois anos: primeiro, ocorre a duplicação de registros de clientes em cada Org onde a mesma entidade de negócios aparece, sem uma chave de identificação compartilhada. Segundo, cada mudança em nível organizacional (como a atualização de um processo de segurança ou a implementação de uma nova ferramenta) se torna um projeto separado em cada Org, o que dobra o custo de qualquer mudança futura. Terceiro, o reporting em nível de empresa exige uma camada de integração que não era necessária inicialmente, e muitas vezes é construída sob pressão após a descoberta do problema, em vez de fazer parte do planejamento. Portanto, um dos princípios orientadores na [arquitetura Salesforce](/pt/insights/crm-architecture-guide) é primeiro verificar se a necessidade organizacional pode ser atendida com permissões e Sharing Rules dentro de um único Org, e só então considerar a divisão. ## Roteiro Gradual para Quem Já Precisa Dividir Quando uma das três condições realmente ocorre, a divisão deve ser realizada em uma ordem que minimize o risco: ### 1. Defina Uma Chave de Identificação Global Antes da Divisão Antes de criar um segundo Org, estabeleça um campo identificador unificado (número de CNPJ, Customer ID global ou código similar) que permitirá, no futuro, a correspondência de registros entre os ambientes. Sem isso, qualquer tentativa futura de unificar a visão do cliente será baseada na correspondência de nome e endereço, o que gera erros em grande escala. ### 2. Escolha um Padrão de Integração de Acordo com a Direção e o Ritmo dos Dados Se o objetivo for apenas atualizações periódicas para fins de reporting, um ETL agendado é suficiente. Se for necessária uma visão em tempo real (por exemplo, para verificação de crédito entre unidades), uma API síncrona com tratamento de falhas e retries será indispensável. A escolha do padrão inadequado é a principal causa de falhas em integrações Cross-Org sob carga — mais detalhes sobre o tema em [Padrões de Integração Salesforce](/pt/insights/salesforce-integration-patterns). ### 3. Planeje Credenciais e Permissões de Acesso Antecipadamente Usuários que trabalham em ambos os Orgs (por exemplo, gerentes de contas globais) exigem uma solução de Identity gerenciada uma única vez, e não dois usuários separados com duas senhas. O planejamento de SSO entre Orgs evita que cada alteração nas permissões de um usuário seja realizada manualmente em dois ambientes — o tópico é detalhado em [Arquitetura de SSO e Identity no Salesforce](/pt/insights/salesforce-sso-identity-architecture). ### 4. Teste os Limites da API Antes que a Integração Entre em Produção Toda chamada entre dois Orgs é contabilizada na cota da API de ambos os lados. Um tráfego planejado sem teste de volume pode exceder os limites diários justamente em picos de demanda, ou seja, precisamente quando a integração é mais necessária. Isso deve ser verificado antecipadamente com os [Limites e Resiliência da API Salesforce](/pt/insights/salesforce-api-limits-resilience). ### 5. Defina um Owner e um Processo de Governança Comum para Ambos os Orgs Alguém precisa ser responsável pela consistência das decisões arquitetônicas entre os ambientes — estrutura de campos, convenções de nomenclatura e políticas de mudança. Sem uma propriedade centralizada, os dois Orgs se desviarão também em nível de padrões dentro de um ano, tornando qualquer integração futura mais cara. ## Cenário Ilustrativo: Um Grupo Segurador com Duas Divisões Este é um cenário hipotético e destina-se apenas a fins ilustrativos. Um grupo segurador possuía uma divisão de seguros gerais e uma divisão de seguros de vida, ambas operando sob a mesma entidade legal, mas com reguladores diferentes e ciclos de aprovação de produtos significativamente distintos. A divisão de seguros de vida exigia controle de mudanças rigoroso com aprovação regulatória para cada Release, enquanto a divisão de seguros gerais desejava lançar melhorias em ritmo semanal. A proposta inicial era dividir para um Org separado para cada divisão, mas a análise com base nas três perguntas revelou que apenas o ritmo regulatório (teste 2) era realmente aplicável — o modelo de cliente e produto não conflitava (teste 3 negativo), e não havia exigência de separação física de dados (teste 1 negativo). A solução escolhida foi um único Org com dois "caminhos de Release" separados dentro do mesmo ambiente — um Sandbox dedicado e um processo de aprovação separado para a divisão de seguros de vida, utilizando um modelo de dados comum para um único Customer 360. A divisão completa foi evitada, assim como os custos de manutenção duplicados que teriam de ser arcados por anos. ## Riscos Comuns e Como Evitá-los - **Divisão "Temporária" que se Torna Permanente** — Um Sandbox que se transforma em ambiente de produção sem passar por auditoria de segurança. Previne-se garantindo que todo Org com dados reais de clientes passe por um processo formal de aprovação de Governança, sem exceções. - **Registros Duplicados Sem Chave Comum** — Ocorre quando a divisão acontece antes da definição de um identificador global. Previne-se estabelecendo o campo comum como pré-requisito para a divisão, e não como uma etapa posterior. - **Cota da API Atingida em Picos de Carga** — Acontece quando a integração entre Orgs é planejada com base no volume médio, e não no volume de pico. Prevene-se com testes de carga antes da entrada em produção e a construção de um mecanismo de Backoff. - **Desvio de Padrões entre Orgs** — Ocorre quando não há um único Owner para a arquitetura compartilhada. Prevene-se definindo um pequeno comitê de Governança que aprova mudanças na estrutura de dados em ambos os lados. - **Relatórios Gerenciais Não Confiáveis** — Acontece quando se tenta calcular KPIs inter-organizações diretamente do Salesforce sem uma camada de unificação. Prevene-se estabelecendo uma camada de BI dedicada desde o primeiro dia da divisão, e não como um projeto de correção tardio. ## Conclusão A opção padrão é um único Org; a divisão é uma exceção que requer justificativa concreta em um dos três testes — independência regulatória genuína, ritmo de mudança incompatível ou modelo de dados fisicamente conflitante. Quando a justificativa existe, o sucesso da transição é medido pela preparação feita antes da divisão: chave de identificação global, padrão de integração adequado, identidade compartilhada, teste de limites da API e ownership claro sobre padrões comuns. Uma organização que salta essa preparação não economiza trabalho — apenas o adia para um momento em que a correção será muito mais cara. ### Perguntas e respostas **Uma fusão de empresas é suficiente para justificar a transição para Multi-Org?** Não automaticamente. Se as duas empresas continuarem a operar sob marcas e processos de vendas separados por anos, há uma base para considerar Orgs separados. Se o plano for unificar processos em um a dois anos, geralmente é melhor integrar temporariamente em um único Org com separação de permissões e evitar o custo de uma fusão reversa no futuro. **Como lidar com a Geração de Relatórios unificada quando há múltiplos Orgs?** Geralmente, por meio de uma camada de BI externa (como Data Cloud, Snowflake ou Tableau) que extrai dados de cada Org separadamente e os unifica em um único modelo de relatório. Tentar construir relatórios Cross-Org dentro do próprio Salesforce quase sempre exige um trabalho de integração caro que não compensa o valor que oferece. **O que acontece com um cliente que aparece em dois Orgs diferentes?** Sem um processo de correspondência definido, o mesmo cliente será duplicado em cada Org, com histórico parcial em cada lado. É necessário definir uma chave de identificação externa comum (como um CNPJ ou ID de Cliente global) e um processo de sincronização ou, no mínimo, um relatório de correspondência periódico, antes mesmo que a separação ocorra de fato. **É possível reverter a união de dois Orgs para um único Org?** Sim, mas isso é um projeto completo de migração e não uma configuração. É preciso adaptar o Modelo de Objeto, Tipos de Registro, Fluxos de Aprovação, dados históricos e integrações entre os dois ambientes, e geralmente será necessária uma ferramenta de migração dedicada. Portanto, é aconselhável considerar a separação como um passo difícil de reverter, e não como uma experiência reversível. **O que significa 'Multi-Org na prática sem decisão'?** É uma situação comum em que uma unidade de negócios abre um Sandbox ou Org separado para um teste temporário, e ele se torna um ambiente de produção real sem que ninguém tenha tomado uma decisão consciente. O sinal identificador é a existência de dados reais de clientes em um Org que não passou por um processo completo de Governança, segurança e controle de acesso. --- ## Data Mapping para Migração Salesforce: Como Evitar Erros Antes do Carregamento URL: https://hpi.pro/pt/insights/salesforce-data-mapping A maioria das falhas na conversão para Salesforce não são falhas de ferramenta, mas sim falhas de significado: um campo com o mesmo nome em dois sistemas pode descrever coisas diferentes. Este guia mostra como construir um documento de Mapeamento que registra significado de negócio, regras de Transformação, valores padrão e responsabilidades - antes de executar o primeiro carregamento. ## A Resposta Breve O Data Mapping não é uma simples planilha de tradução de campos, mas sim o documento que estabelece o significado de cada dado que a organização levará para o Salesforce. Quase todos os erros de carregamento que parecem técnicos – formato de data, Picklist não reconhecido, relacionamento quebrado – nascem de uma decisão de negócio não tomada. A ordem que funciona: primeiro, definem-se quais entidades serão migradas; em seguida, quem é o proprietário de negócio de cada entidade; depois, quais campos têm um consumidor real; e só depois, escrevem-se as regras de conversão. Quando se começa na direção oposta, a equipe técnica toma decisões de negócio silenciosamente – e isso é descoberto três meses após o Go Live, quando um relatório de receita não fecha. Mais informações sobre o planejamento completo da conversão estão disponíveis em [Migração de Dados para Salesforce](/pt/insights/salesforce-data-migration-guide). ## Os Três Tipos de Lacunas Reveladas pelo Mapping | Tipo de Lacuna | Exemplo Comum | Quem Decide | |---|---|---| | Lacuna Semântica | "Cliente ativo" = fez uma compra este ano em um sistema, = não foi bloqueado em outro sistema | Proprietário do processo de negócio | | Lacuna Estrutural | Um cliente com cinco endereços versus o modelo Account/Contact | Arquiteto de Dados | | Lacuna de Qualidade | 18% dos registros sem ID de empresa válido | Data Owner + Regulação | A lacuna semântica é a mais dispendiosa, pois não causa erro no carregamento. O dado é inserido com sucesso, a automação é executada sobre ele, e o relatório exibe um número incorreto que parece plausível. Lacunas estruturais resultam em erros de carregamento e, portanto, são detectadas precocemente. Lacunas de qualidade são detectadas se – e somente se – limites de aceitação forem definidos antecipadamente. ## A Camada de Significado: Data Dictionary Antes da Planilha de Mapping Antes de mapear campo a campo, escreve-se uma definição do glossário para cada entidade central: o que é uma Account, o que distingue um Lead de um Contact nesta organização, quando uma Opportunity é fechada. Essas definições são curtas – duas linhas por entidade – mas são o que permite resolver disputas em vez de apenas apontá-las. O teste simples: peça a três pessoas de três departamentos que definam "cliente" separadamente. Se as definições forem diferentes, a migração transferirá três verdades distintas para a mesma tabela. ## Anatomia de uma Linha de Mapping Correta Cada linha na planilha deve responder a sete perguntas: de qual objeto e campo na origem, para qual objeto e campo no Salesforce, qual o tipo e comprimento do dado, qual a regra de conversão, o que acontece com um valor vazio, qual o valor padrão, e quem aprovou. Uma linha que faltar uma dessas colunas voltará como uma pergunta no meio de um carregamento noturno durante o Cutover. Três regras de trabalho que evitam problemas: - **Sem conversão silenciosa.** Qualquer valor que o sistema "corrige" automaticamente deve ser registrado em um log de exceções. - **O valor padrão é uma decisão de negócio.** Quem define `Country = IL` como padrão deve ser o responsável pelos relatórios por região. - **IDs Externos antes de tudo.** Para cada entidade, guarda-se um External ID do sistema de origem. Sem ele, não há Reconciliation e não há segunda execução. ## Transformações: Onde Erros Acontecem As conversões que causam mais danos são, ironicamente, as mais simples. Datas sem fuso horário movem registros em um dia; nomes que passam por Trim e Upper sem uma regra uniforme criam novas duplicidades logo após termos limpado as antigas; valores monetários convertidos para uma moeda única com taxa diária geram discrepâncias nos relatórios em comparação com o ERP. A regra: toda conversão numérica ou monetária é verificada comparando somas, não comparando registros. Uma contagem idêntica não é evidência de correção. Quem ainda não resolveu a questão da Fonte da Verdade encontrará informações em [Fonte da Verdade na Organização](/pt/insights/salesforce-source-of-truth), e sobre a janela de transferência em [Cutover e Reconciliation](/pt/insights/salesforce-migration-cutover-reconciliation). ## Cenário: Empresa de Serviços com Dois Sistemas de Origem Uma organização de serviços com 90 mil clientes abordou uma conversão a partir de dois sistemas: um sistema de cobrança legado e um sistema de serviço adquirido com uma subsidiária. A primeira planilha de Mapping foi marcada como "pronta" em duas semanas – 340 campos mapeados. Na primeira execução do Rehearsal, 97% dos registros foram carregados. O problema foi descoberto no Reconciliation: o total dos saldos no Salesforce era 4,1% menor que no ERP. A razão não foi um carregamento mal sucedido, mas sim que todos os registros com saldo negativo (créditos) foram mapeados para um campo com uma Validation Rule que impede valores negativos – e foram silenciosamente definidos como zero. A correção foi em dois níveis: uma regra de conversão explícita para créditos, e também uma mudança de política – toda regra que zera ou encurta um valor deve gerar uma linha de exceção. Na segunda execução, o número de exceções subiu para 1.900, e isso foi um progresso: as exceções estavam visíveis em vez de ocultas. A terceira execução baixou para 40 exceções documentadas, e só então foi definida a data do Cutover. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | |---|---|---| | Transferir todo o histórico | Volume, duplicidades e informações sem valor migram para o novo sistema | Definir políticas de Retention e limites de qualidade | | Mapping apenas técnico | Campos são transferidos sem entender o significado de negócio | Data Dictionary e proprietários de negócios | | Conversões silenciosas | Valores são corrigidos automaticamente e ninguém sabe | Log de exceções obrigatório para cada regra de conversão | | Sem Rehearsal | A janela de inatividade se estende e surgem surpresas | Pelo menos duas execuções completas | | Sem External ID | Impossibilidade de verificar, corrigir ou reexecutar | Manter a chave de origem para cada entidade | ## Como Medir o Sucesso | Área | O que Medir | Frequência de Verificação | |---|---|---| | Completeness | Taxa de campos obrigatórios preenchidos no destino | Antes e depois de cada carregamento | | Reconciliation | Correspondência de contagens, somas e relacionamentos com a origem | Em cada Rehearsal e no Cutover | | Exceções | Número de linhas de exceção abertas por gravidade | Diariamente durante o período de conversão | | Campos sem consumidor | Quantos campos migrados não foram lidos em 90 dias | Uma vez após o Go Live | O último indicador é uma preparação para o próximo ciclo: ele mostra quanto do trabalho foi desnecessário e direciona o escopo da próxima conversão. Organizações que preferem acompanhamento profissional na construção do Mapping o fazem no âmbito do [serviço de Integrações e Dados](/pt/integrations-data). ## Checklist Antes do Primeiro Carregamento - ☐ Um Data Dictionary conciso para cada entidade central, aprovado pelo negócio - ☐ Lista de campos com consumidor definido; o restante para arquivo - ☐ External ID para cada entidade que será transferida - ☐ Tabela de Value Mapping completa, incluindo valores para valores não reconhecidos - ☐ Regra explícita para cada valor vazio e para cada valor padrão - ☐ Cada regra de conversão gera uma linha de exceção em vez de uma correção silenciosa - ☐ Cenário de Reconciliation: contagem, soma, relacionamento, amostragem manual - ☐ Limite de exceções acordado acima do qual não se realiza o Cutover - ☐ Versão e assinatura na planilha de Mapping - ☐ Plano de Rollback e reexecução ## Recursos Profissionais - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integrações e Dados — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Perguntas e respostas **Qual a diferença entre Mapeamento técnico e Mapeamento de negócio?** O Mapeamento técnico responde à pergunta 'Em qual campo isso será inserido?'. O Mapeamento de negócio responde 'O que este campo significa, quem o atualiza e o que acontece quando está vazio?'. Dois sistemas podem ter um campo chamado 'Status' que descreve uma fase de vendas em um lugar e um status de cobrança em outro; apenas o Mapeamento de negócio revela essa lacuna antes do carregamento. **Quantos campos realmente precisam ser migrados?** Em projetos que acompanhamos, entre 40% e 60% dos campos no sistema de origem não estão em uso ativo ou podem ser derivados novamente. A regra prática é migrar um campo apenas se ele tiver um consumidor definido: um processo, um relatório, uma automação ou uma exigência regulatória. Um campo sem consumidor permanece no arquivo, não no Salesforce. **Onde as regras de Transformação são documentadas?** Em uma única tabela de Mapeamento versionada, onde cada linha possui: origem, destino, tipo, regra de transformação, valor padrão, tratamento de valor nulo e proprietário de negócio que aprovou. Se a regra existe apenas no script ETL, ninguém na empresa pode aprová-la e não pode ser verificada na Reconciliação. **O que fazer com valores de Picklist que não correspondem?** Crie uma tabela de Mapeamento de Valores separada com mapeamento completo, incluindo um valor padrão para valores desconhecidos. A regra: nenhum valor na origem permanece sem destino, e nenhum valor desconhecido é carregado silenciosamente – ele entra em um relatório de exceções que alguém resolve antes do Cutover. **Quando o Mapeamento é considerado pronto?** Quando um ensaio completo foi executado com Reconciliação que valida contagens, somas e relações pai-filho, e a lista de exceções restantes é menor do que o limite previamente acordado e aprovada por escrito pelos proprietários do processo. --- ## Limpeza de Duplicidades Pré-Salesforce: Uma Estratégia de Deduplicação Prática URL: https://hpi.pro/pt/insights/salesforce-data-deduplication A duplicação não é uma falha de dados, mas uma falha de identidade: a organização não definiu o que torna dois registros o mesmo cliente. Este guia apresenta como estabelecer regras de correspondência (Matching Rules), construir um Golden Record, decidir o que deve ser excluído e o que deve ser preservado no histórico, e como evitar que as duplicidades retornem semanas após a migração. ## A Resposta Curta A desduplicação falha quando é tratada como uma ação de limpeza única. Na verdade, ela envolve três decisões: o que define uma identidade, quem prevalece em caso de conflito, e como evitar que o problema se repita. A ferramenta técnica é a parte mais fácil. O erro comum é aplicar Fuzzy Matching a nomes, obter uma lista de 12 mil correspondências possíveis e tentar resolvê-las manualmente sob pressão de prazos. O que funciona é o oposto: primeiro, você reduz o espaço de decisão usando chaves fortes e deixa para a revisão humana apenas a "zona cinzenta". O planejamento mais amplo da migração de dados é descrito em [Migração de Dados para Salesforce](/pt/insights/salesforce-data-migration-guide). ## Três Camadas de Correspondência | Camada | Dependência | Ação | |---|---|---| | Chave Forte | CPF, CNPJ, ID de sistema de origem, e-mail verificado | Mesclagem automática | | Chave Composta | Nome normalizado + cidade + telefone normalizado | Mesclagem automática com alta pontuação | | Similaridade Textual | Apenas nome, endereço livre | Somente revisão humana | A proporção que caracteriza um projeto bem gerenciado: cerca de 70% das duplicidades são resolvidas na primeira camada, 20% na segunda, e 10% chegam à revisão humana. Se a maioria das correspondências chega à terceira camada, é um sinal de que não houve investimento em normalização – e não que os dados sejam particularmente ruins. ## Normalização Antes da Comparação Antes de qualquer comparação, colunas auxiliares normalizadas são criadas sem alterar o dado original: remoção de sufixos corporativos (S.A., Ltda.), padronização de espaços e apóstrofos, telefone no formato E.164, e-mail em minúsculas com remoção de rótulos após o sinal de mais, e endereço dividido em rua/número/cidade. A normalização, por si só, geralmente reduz de um terço a metade das duplicidades "difíceis" antes mesmo da aplicação de qualquer algoritmo de similaridade. ## Golden Record em Nível de Campo A decisão "qual registro sobrevive" não é a mais importante. A mais importante é "qual valor de cada campo sobrevive". Define-se uma política concisa: dados de faturamento do ERP, detalhes de contato do sistema onde a última atividade foi registrada, status do cliente do sistema operacional. Para cada campo, há uma fonte preferencial, e os valores rejeitados são documentados. Sem essa política, cada mesclagem é uma decisão de quem a realizou naquele momento – e mais tarde será impossível explicar por que um endereço desapareceu. ## O que Acontece com Relacionamentos e Histórico A mesclagem de registros afeta atividades, oportunidades, Cases, arquivos e permissões. Antes de uma execução em massa, defina explicitamente: para onde as atividades são movidas, o que acontece com oportunidades abertas para o mesmo cliente de dois registros, e quem é o proprietário após a mesclagem – pois a alteração do Proprietário muda tanto a visibilidade quanto os relatórios de comissões. A regra prática: nenhuma mesclagem antes de um relatório de "o que mudou" que possa ser reproduzido, e os IDs de origem são mantidos em um campo separado para permitir investigação meses depois. ## Cenário: Importador com 210 Mil Contatos Um importador B2B iniciou uma migração com 210 mil Contatos de três sistemas. A primeira execução de uma ferramenta de similaridade retornou 31 mil pares suspeitos – um número que ninguém poderia revisar. A equipe parou e inverteu a ordem. Primeiro, e-mail e telefone foram normalizados: 14 mil pares foram mesclados automaticamente por chave forte. Em seguida, foi definido que a unidade de negócio era o local do cliente e não a corporação, o que removeu da lista 6 mil pares que eram legítimos – filiais separadas da mesma rede. Restaram 4.200 pares para a camada intermediária, dos quais 3.800 foram mesclados com alta pontuação. Para revisão humana, chegaram 400 pares, e duas pessoas os resolveram em três dias. A lição não foi a escolha da ferramenta. Foi que a definição da unidade de negócio – local versus corporação – reduziu mais "ruído" do que qualquer aprimoramento algorítmico. ## Prevenção: Por que as Duplicidades Retornam Três fontes principais reintroduzem duplicidades após o Go Live: entrada manual sem Matching Rules ativas, integrações que criam um registro em vez de atualizar (Upsert em External ID resolve a maioria), e formulários Web-to-Lead sem verificação de existência. Se esses três pontos não forem abordados, a taxa de duplicação retorna ao seu nível original em um a dois anos. ## Riscos Comuns e Ações de Prevenção | Risco | Como se manifesta na prática | Ação de Prevenção | |---|---|---| | Mesclagem agressiva | Clientes diferentes foram unificados e não podem ser separados | Alto limiar de pontuação + revisão na área cinzenta | | Ausência de definição de identidade | Discussão recorrente sobre o que é considerado o mesmo cliente | Decisão documentada no nível da entidade | | Perda de histórico | Atividades e oportunidades desapareceram na mesclagem | Relatório "o que mudou" e salvamento de IDs de origem | | Limpeza sem prevenção | A duplicidade retorna em meses | Matching Rules, Upsert e formulários protegidos | | Limpeza após carga | Qualquer mesclagem afeta relacionamentos ativos | Limpar na fase de Staging | ## Como Medir o Sucesso | Área | O que Medir | Frequência de Verificação | |---|---|---| | Unicidade | Taxa estimada de duplicidade por entidade | Semanal na migração, trimestral depois | | Precisão da Mesclagem | Porcentagem de mesclagens desfeitas ou corrigidas manualmente | Em cada onda de mesclagem | | Prevenção | Novos registros bloqueados como duplicidades na entrada | Mensal | | Impacto Comercial | Retornos duplicados ao cliente, precisão dos relatórios de cliente | Trimestral | Suporte profissional na construção de regras de identidade e prevenção é oferecido no [serviço de Integrações e Dados](/pt/integrations-data). ## Checklist Antes de Executar a Mesclagem - ☐ A unidade de negócio foi definida: corporação, local ou contrato - ☐ Colunas de normalização foram construídas sem alterar a fonte - ☐ Três camadas de Matching com limiares numéricos documentados - ☐ Política de Golden Record em nível de campo, aprovada pelo negócio - ☐ Decidido o que acontece com atividades, oportunidades e propriedade - ☐ IDs de origem são mantidos após a mesclagem - ☐ Relatório "o que mudou" pode ser gerado e recuperado - ☐ Execução de teste em uma amostra com verificação manual - ☐ Matching Rules e Upsert ativos para prevenção - ☐ Proprietário permanente para o processo após o Go Live ## Recursos Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **O que é considerado uma duplicidade e o que não é?** Esta é uma decisão de negócio, não técnica. Duas filiais da mesma corporação podem ser dois registros legítimos para vendas e um único registro para cobrança. Antes de executar uma ferramenta de Deduplicação, é preciso decidir, no nível da entidade: se a unidade de negócio é uma corporação, um local ou um contrato. **A limpeza deve ser feita antes ou depois do carregamento dos dados?** A limpeza deve ser feita antes. Um registro duplicado que já foi carregado gera relacionamentos – atividades, Casos, oportunidades – e qualquer ''Merge'' tardio se torna uma operação arriscada com perda de histórico. Após o carregamento, resta apenas a fiscalização contínua, não uma limpeza em massa. **O que fazer quando dois registros contêm informações diferentes, mas ambos estão corretos?** Construa um Golden Record ao nível do campo, não ao nível do registro: para cada campo, defina uma regra de precedência – sistema de origem preferencial, o mais recente, ou o valor validado. Assim, você não perde um endereço correto apenas porque o segundo registro foi escolhido como o vencedor. **As "Matching Rules" do Salesforce são suficientes?** Elas são suficientes para prevenção contínua em entradas manuais, mas não para limpeza em massa antes da conversão. Para uma limpeza inicial, é necessária uma ferramenta ou script que realize "Fuzzy Matching" na normalização de texto, e que permita uma revisão humana da área cinzenta antes da fusão. **Quantas duplicidades são consideradas 'normais'?** Em bancos de dados antigos e não gerenciados, geralmente observa-se 8%-20% de duplicidade no nível de Contato e 3%-10% no nível de Conta. O objetivo prático não é zero, mas um limite acordado – por exemplo, abaixo de 2% – com um processo que evite a deterioração de volta. --- ## Fonte da Verdade na Organização: Quem é Responsável por Cliente, Produto, Pedido e Pagamento? URL: https://hpi.pro/pt/insights/salesforce-source-of-truth Quando não há um consenso sobre quem está autorizado a alterar um dado, cada integração se transforma em uma negociação e, no final, dois sistemas se sobrescrevem mutuamente. Este guia apresenta como decidir a fonte da verdade para cada entidade no nível do campo, como diferenciar entre um sistema que exibe e um sistema que tem autoridade, e como aplicar a decisão no código, e não em um documento. ## A Resposta Curta *Source of Truth* (Fonte da Verdade) não é uma questão técnica, mas sim de autoridade: quem na organização está autorizado a determinar que um determinado valor é correto. Quando essa decisão não é feita explicitamente, ela é tomada tacitamente – por quem escreveu a última integração. A regra fundamental: a propriedade é definida no nível do campo, não no nível do sistema. A tentativa de declarar "o ERP é a fonte da verdade para o cliente" é invalidada no momento em que o departamento de serviço atualiza um número de telefone no Salesforce e a sincronização noturna apaga a atualização. ## Três Perguntas que Definem a Propriedade Para cada entidade, e subsequentemente para cada grupo de campos, questiona-se: onde o dado foi **criado** pela primeira vez, quem está **autorizado** a alterá-lo do ponto de vista do negócio, e quem **assume a responsabilidade** quando ele está incorreto. Em todos os três casos, a resposta deve ser o nome de uma função, não o nome de um sistema. O sistema é uma derivação da função. Quando as respostas apontam para duas funções diferentes, isso quase sempre é um sinal de que dois campos distintos foram compactados em um. ## Matriz de Propriedade de Exemplo | Entidade / Campo | Fonte da Verdade | Salesforce | Direção da Sincronização | | --- | --- | --- | --- | | Razão Social, CNPJ, Condições de Pagamento | ERP | Somente leitura | ERP ← Salesforce | | Contato, Cargo, Preferências | Salesforce | Edição | Salesforce ← Sistemas de Marketing | | Catálogo de Produtos e Tabela de Preços Base | ERP / PIM | Somente leitura | ERP ← Salesforce | | Proposta e Desconto Aprovado | Salesforce | Edição | Salesforce ← ERP | | Pedido Aprovado e Status de Entrega | ERP | Somente leitura | ERP ← Salesforce | | Saldo Devedor e Status de Cobrança | Sistema Financeiro | Somente leitura | Financeiro ← Salesforce | | Atividade, Casos e Comunicação | Salesforce | Edição | Sem sincronização externa | Esta tabela é o resultado. É concisa, está em um único documento, e toda nova integração é verificada contra ela antes de ser escrita. ## Separação entre Apresentação e Autoridade Muitas das tensões entre sistemas desaparecem quando se compreende que a apresentação de um dado não exige sua cópia. Um saldo devedor exibido para o vendedor não precisa ser um campo no Salesforce que é atualizado todas as noites; pode ser uma exibição remota ou uma camada de federação. Todo campo copiado é um compromisso operacional: sincronização, falha, lacuna e tempo. Antes de copiar, pergunta-se se é necessária automação ou relatórios históricos sobre ele. Se não for, é preferível exibir do que copiar. Uma expansão sobre essa abordagem pode ser encontrada em [Zero Copy e Federação na Data 360](/pt/insights/data-360-zero-copy-federation). ## Conflitos: Decidir com Antecedência, Não em Tempo Real Mesmo quando a propriedade é clara, surgem situações de atualização paralela. Três regras possíveis: precedência do sistema (o proprietário sempre vence), carimbo de data/hora da última modificação, ou sinalização para tratamento manual. A terceira regra é a mais segura para campos sensíveis – desde que exista uma fila de tratamento com proprietário, e não um registro de log que se acumula. ## Cenário: Organização com Duas Verdades para um Endereço Único Uma empresa de serviços de infraestrutura gerenciava o endereço do cliente em dois sistemas: ERP para fins de faturamento e um sistema de serviço de campo para o deslocamento de técnicos. Ambos eram sincronizados bidirecionalmente com o Salesforce. O resultado: um endereço que alternava constantemente, e técnicos que chegavam ao endereço de faturamento. A solução não foi corrigir a sincronização, mas sim desagregar a entidade. Dois campos separados foram definidos – endereço de faturamento sob a propriedade do ERP, endereço de serviço sob a propriedade do sistema de campo – e ambos como somente leitura no Salesforce, com um link para solicitar uma alteração que é roteada para o proprietário correto. O número de chamados de serviço encerrados como "endereço incorreto" diminuiu significativamente no trimestre seguinte. A lição: quando os sistemas "brigam" por um campo, na maioria das vezes se trata de dois dados de negócio diferentes que receberam o mesmo nome. ## Aplicação: Do Documento à Realidade Uma matriz de propriedade só funciona se for implementada em três pontos: segurança em nível de campo (Field-Level Security) que impede a edição no lado que não é o proprietário, um usuário de integração com permissões limitadas apenas aos campos de sua propriedade, e um relatório mensal que mostra campos que foram atualizados em desacordo com a política. O terceiro relatório é o que expõe integrações antigas que ninguém mais lembra. A documentação do significado de cada campo se conecta diretamente ao [Data Mapping para Migração](/pt/insights/salesforce-data-mapping). ## Riscos Comuns e Ações Preventivas | Risco | Como se Manifesta na Prática | Ação Preventiva | | --- | --- | --- | | Propriedade em Nível de Sistema | Contradições dentro da mesma entidade | Decisão em nível de campo ou grupo de campos | | Sincronização Bidirecional como Padrão | Valores que se alternam constantemente | Direção única + leitura no outro lado | | Cópia Desnecessária | Dezenas de campos sincronizados sem consumidor | Exibir em vez de copiar | | Documento Sem Fiscalização | A política se desgasta em meses | Permissões de campo + monitoramento de exceções | | Sem Fila de Conflitos | Contradições se acumulam silenciosamente | Fila de tratamento com proprietário e SLA | ## Como Medir o Sucesso | Área | O Que Medir | Frequência de Verificação | | --- | --- | --- | | Consistência | Taxa de inconsistência em campos chave entre sistemas | Mensal | | Exceções à Política | Gravações em campos fora do proprietário definido | Mensal | | Conflitos | Número e tempo de resolução de itens na fila | Semanal | | Impacto Operacional | Falhas causadas por dados incorretos | Trimestral | A construção e aplicação de uma matriz de propriedade são realizadas no âmbito do [serviço de Integrações e Dados](/pt/integrations-data). ## Checklist para Decisão da Fonte da Verdade - ☐ Lista das entidades principais na organização - ☐ Para cada entidade: onde foi criada, quem está autorizado, quem é responsável pelo erro - ☐ Propriedade definida em nível de campo ou grupo de campos - ☐ Direção de sincronização explícita para cada grupo - ☐ Todo campo copiado passa no teste "tem um consumidor" - ☐ Regra de resolução de conflitos escolhida e documentada - ☐ Existe uma fila de tratamento manual com proprietário e SLA - ☐ Field-Level Security em conformidade com a matriz - ☐ Usuário de integração restrito aos campos de sua propriedade - ☐ Relatório mensal para exceções à política ## Fontes Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Pode haver dois sistemas de fonte da verdade para a mesma entidade?** Para a mesma entidade, sim; para o mesmo campo, não. Detalhes de faturamento podem ser de propriedade do ERP, enquanto dados de contato e atividade são de propriedade do Salesforce – para o mesmo cliente. O que é proibido é que ambas as partes possam gravar no mesmo campo sem uma regra de desempate. **Qual a diferença entre System of Record e System of Engagement?** Um System of Record é o local autorizado a determinar o valor; um System of Engagement é o local onde as pessoas interagem com ele. O Salesforce é geralmente um System of Engagement para o cliente, e também um System of Record para o pipeline de vendas e para a atividade com o cliente. A confusão entre os dois é uma causa comum de sincronização bidirecional desnecessária. **Quando a sincronização bidirecional é justificada?** Somente quando ambas as partes realmente criam valor no mesmo campo, e há uma regra de desempate inequívoca – por exemplo, um carimbo de data/hora ou prioridade do sistema. Em qualquer outro caso, é preferível uma direção única com uma tela de somente leitura no outro lado. A sincronização bidirecional duplica o número de estados de falha. **Como a propriedade é efetivamente aplicada?** Em três camadas: permissões de campo que impedem a edição pelo lado que não é o proprietário, integração que escreve apenas nos campos de sua propriedade, e monitoramento que reporta escrita fora da política. Um documento de propriedade sem aplicação técnica se dissolve em meses. **O que fazer quando não há um sistema adequado para ser a fonte da verdade?** Este é um sinal de que a entidade está definida de forma muito ampla. Desmembrá-la: 'Produto' pode ser dividido em catálogo (ERP), oferta comercial (CRM) e permissão de uso (sistema operacional). Cada parte terá uma fonte da verdade clara. --- ## Métricas de Qualidade de Dados no Salesforce: O Que Medir e Como Definir Limiares URL: https://hpi.pro/pt/insights/salesforce-data-quality-metrics A qualidade dos dados torna-se gerenciável apenas quando possui um indicador numérico, um limiar e um responsável. Este guia explica quais dimensões realmente valem a pena monitorar no Salesforce, como estabelecer limiares não arbitrários, como vincular cada métrica a um impacto de negócio e como construir um Scorecard que seja verdadeiramente útil e consultado regularmente. ## A Resposta Curta A qualidade dos dados não é uma característica intrínseca da informação, mas sim o resultado de processos bem definidos. Por isso, uma métrica que não está vinculada a um impacto de negócio e não possui um responsável não tem valor real: ela gera um relatório que alguém abre uma vez por trimestre e aprova sem reflexão. Um Scorecard eficaz possui entre quatro e seis métricas, cada uma com um limite, um proprietário e uma ação corretiva definida. A diferença entre um Scorecard e um relatório é que, no primeiro, qualquer número em vermelho aciona uma pessoa para agir. ## As Cinco Dimensões — E O Que Realmente Medem | Dimensão | O que avalia | Quando é crítico | | --- | --- | --- | | **Completeness** | Taxa de preenchimento de campos que guiam decisões | Sempre | | **Validity** | Conformidade com regras de formato e valores válidos | Integrações, regulamentação | | **Uniqueness** | Duplicação a nível de entidade | Antes da migração e após fusões | | **Timeliness** | Quão atualizado o dado está em relação à realidade | Previsão, serviço, cobrança | | **Consistency** | Se o mesmo dado é idêntico entre sistemas | Múltiplos sistemas e relatórios financeiros | Organizações geralmente começam pelas três primeiras dimensões. **Timeliness** e **Consistency** se tornam relevantes quando sistemas adicionais dependem do CRM — e é exatamente nesse ponto que falhas nessas dimensões geram os maiores custos. ## Completeness: Nem Todo Campo Merece Medição Medir a taxa de preenchimento de 300 campos gera um número sem significado. A abordagem correta é definir para cada processo principal um "pacote de campos" pequeno — de cinco a oito campos essenciais para o funcionamento do processo — e medir apenas isso. É crucial adicionar uma verificação de preenchimento artificial: a porcentagem de registros onde o campo foi preenchido com um valor que se repete de forma suspeita (um ponto, um hífen, "não informado"). Este é geralmente o primeiro sinal de que a regra definida está dificultando o trabalho em vez de melhorá-lo. ## Timeliness: A Dimensão Ignorada Por Muitos Um dado pode estar completo, válido e único — mas simplesmente não ser mais verdadeiro. Um campo de status de cliente que não foi alterado por 14 meses não é um dado, é uma memória. A medição é simples: a distribuição do tempo desde a última atualização para campos essenciais, comparada com a velocidade com que a realidade muda. Para oportunidades de vendas, isso se traduz diretamente na qualidade da previsão: a porcentagem de oportunidades abertas cuja data de fechamento já passou é um dos indicadores mais poderosos e rápidos de calcular. ## Do Limite à Ação: O Que Acontece Quando a Métrica Está Vermelha Para cada métrica, definem-se três níveis — verde, âmbar, vermelho — e uma ação para cada nível. Âmbar aciona uma verificação pela equipe; vermelho aciona uma correção com prazo. Sem essa definição, a métrica se torna informação, não gestão. As ações devem ser variadas: às vezes a correção é uma limpeza única, às vezes uma mudança no processo de trabalho, e muitas vezes a solução correta é remover o campo — porque ele não é demandado por ninguém. Contexto adicional sobre duplicações em [Limpeza de Dados Duplicados no Salesforce](/pt/insights/salesforce-data-deduplication), e sobre uma estrutura que gera qualidade em [Design de Modelo de Dados no Salesforce](/pt/insights/salesforce-data-model-design). ## Cenário: Uma Seguradora Que Mediu Tudo e Não Melhorou Nada Uma seguradora construiu um dashboard de qualidade com 34 métricas. Ele funcionou por um ano. Nenhuma métrica melhorou significativamente por falta de responsabilidade: o dashboard era da equipe de BI, e os campos eram dos agentes. Na segunda etapa, o dashboard foi reduzido para quatro métricas: taxa de preenchimento do pacote de campos de subscrição, porcentagem de apólices com data de renovação vencida, taxa de duplicação por segurado e porcentagem de e-mails com falha no envio. A cada métrica foi atribuído um gerente regional com uma meta trimestral, e o dashboard foi apresentado na reunião de vendas, não na reunião de TI. Em dois trimestres, duas métricas ultrapassaram o limite. A terceira métrica não se moveu — e uma investigação revelou que o campo era exigido em um formulário preenchido pelos agentes após o fechamento do negócio, ou seja, em um momento em que eles não tinham incentivo. A solução foi mudar a posição do campo no processo, não adicionar uma regra de validação. ## Riscos Comuns e Ações de Prevenção | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Muitas métricas | Dashboard que ninguém age sobre | Quatro a seis métricas com responsáveis | | Métrica sem limite | Discussão sobre "se 78% é bom" | Limite definido por impacto de negócio | | Responsabilidade na TI | Nenhuma mudança de comportamento em campo | Responsável de negócio para cada métrica | | Validação sem medição | Campos preenchidos com valores fictícios | Medição de preenchimento artificial | | Medição única | Melhoria temporária que regride | Scorecard periódico e constante | ## Como Medir o Sucesso | Área | O que medir | Frequência de verificação | | --- | --- | --- | | **Completeness** | Taxa de preenchimento do pacote de campos para o processo | Mensal | | **Timeliness** | Mediana do tempo desde a última atualização | Mensal | | **Uniqueness** | Taxa de duplicação estimada | Trimestral | | **Impacto** | Reclamações, falhas de integração, precisão da previsão | Trimestral | A construção de um Scorecard e do processo operacional é realizada no âmbito dos [Serviços de Integrações e Dados](/pt/integrations-data). ## Checklist para Implementar a Medição - ☐ Foram selecionadas no máximo seis métricas - ☐ Cada métrica possui um pacote de campos definido, não o objeto completo - ☐ Cada métrica possui um limite definido pelo impacto de negócio - ☐ Cada métrica possui um proprietário de negócio com nome completo - ☐ Uma ação foi definida para o nível âmbar e para o nível vermelho - ☐ O preenchimento artificial é medido, não apenas o preenchimento - ☐ Existe uma linha de base antes do início da melhoria - ☐ O relatório é apresentado em um fórum de negócios, não técnico - ☐ Foi verificado se um campo problemático é realmente necessário - ☐ Foi definida uma revisão periódica da própria lista de métricas ## Referências Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Por qual dimensão devo começar?** Comece pela Completude em um pequeno conjunto de campos que impulsionam decisões, não em todos os campos. A taxa de preenchimento é a dimensão mais fácil de calcular, a mais simples de explicar à liderança, e geralmente a que revela rapidamente os processos ineficazes. **Como definir um limiar que não seja arbitrário?** Derive o limiar do impacto. Se 5% dos e-mails estão incorretos e uma campanha gera 200 leads por mês, isso pode ser traduzido em uma perda esperada. O limiar é definido onde o custo da correção começa a exceder o dano, e não em um número redondo que soa bem. **Quem é responsável por uma métrica de qualidade?** O proprietário do processo que gera o dado, não a equipe de Dados. A equipe de Dados mede e fornece ferramentas; quem vende, cobra ou atende é quem pode alterar o comportamento que gera a lacuna. Uma métrica sem um proprietário de negócio não melhora. **As Regras de Validação resolvem a qualidade dos dados?** Parcialmente. Elas evitam valores incorretos na entrada manual, mas podem levar os usuários a preencher qualquer valor apenas para prosseguir. Uma regra de validação deve ser acompanhada por uma métrica que verifique se o campo foi realmente preenchido ou se foi preenchido artificialmente. **Qual a frequência de medição adequada?** Durante a conversão de dados, semanalmente. Em operações rotineiras, mensalmente para a maioria das métricas e trimestralmente para revisão da liderança. A medição diária da qualidade de dados quase sempre gera ruído e raramente leva a ações efetivas. --- ## Agentforce para Atendimento ao Cliente: Casos de Uso para Começar URL: https://hpi.pro/pt/insights/agentforce-customer-service-use-cases Nem todo contato é adequado para um agente, e a ordem de implementação define o sucesso ou o insucesso do projeto. Este guia classifica casos de uso comuns de atendimento por complexidade, explica o que é necessário para cada um e mostra quais casos parecem promissores, mas que, na verdade, podem comprometer a confiança inicial. ## A Resposta Curta No atendimento ao cliente, a diferença entre um piloto que se expande e um piloto que é descontinuado é quase sempre determinada pela escolha do cenário inicial. Um cenário maduro é aquele que se apoia em uma única fonte de informação confiável, não executa uma ação irreversível e possui um volume que justifique sua manutenção. Os cenários mais tentadores – tratamento de reclamações, retenção de clientes, decisão de reembolso – são precisamente aqueles que exigem discernimento, sensibilidade e informações de múltiplos sistemas. Eles chegam na terceira fase, não na primeira. A estrutura geral de decisão para a adaptação de um Caso de Uso aparece em [Agentforce para Empresas](/pt/insights/agentforce-for-enterprises). ## Classificação de Cenários por Maturidade | Cenário | Maturidade | O que é Necessário | Risco Principal | |---|---|---|---| | Consultas de Status | Alta | Um campo confiável no CRM | Quase nenhum; erro reversível | | Perguntas Frequentes (FAQs) | Alta | Artigos de Knowledge atualizados para cenários comuns | Citação de política desatualizada | | Suporte ao Agente Durante a Chamada | Alta | Knowledge e Histórico de Casos | O agente adota uma resposta incorreta | | Direcionamento e Classificação de Solicitações | Média | Taxonomia consistente de tipos de solicitação | Classificação errada que prolonga o atendimento | | Atualização de Detalhes e Ações Simples | Média | Permissões precisas e Ações limitadas | Atualização incorreta no registro do cliente | | Agendamento, Cancelamento e Reagendamento | Média | Integração estável com o sistema operacional | Falha de integração com o cliente | | Reembolsos e Compensações | Baixa | Política escrita, autoridade e aprovação humana | Exposição financeira e precedente para o cliente | | Tratamento de Reclamações e Retenção | Baixa | Compreensão do contexto, sensibilidade e histórico completo | Dano à marca e à confiança | ## Os Três Cenários para Começar Consultas de status são o melhor ponto de partida. O cliente pergunta onde está o pedido, qual o status da solicitação, quando o técnico chegará. A resposta se baseia em um único campo, não há ação de gravação, e o volume geralmente é alto. O sucesso também é fácil de medir: o cliente recebeu uma resposta e não entrou em contato novamente. Perguntas frequentes (FAQs) são o segundo cenário. Aqui, o desafio não é o agente, mas o conteúdo, por isso o trabalho começa verificando as vinte perguntas mais comuns e garantindo que cada uma tenha um artigo aprovado e atualizado. O suporte ao agente é o cenário mais recomendado para começar quando há receio. O Agente oferece uma resposta, o colaborador aprova ou corrige. Cada correção é um dado de aprendizado, e o risco externo é mínimo. Organizações que começam aqui chegam à exposição externa com um conjunto de testes reais, em vez de suposições. O que é necessário para que a base de conhecimento suporte a carga é detalhado em [Gerenciamento de Conhecimento para Agentforce](/pt/insights/agentforce-knowledge-readiness). ## O que é Adiado para Etapas Posteriores Reembolsos e compensações exigem uma política escrita que, na maioria das organizações, não existe completamente — ela vive no discernimento dos gerentes de equipe. Antes que o Agente entre nesse campo, a política precisa ser escrita, e então se descobre que isso é um trabalho organizacional por si só. O tratamento de reclamações exige compreensão emocional do contexto e um histórico completo. Mesmo quando a resposta técnica está correta, a formulação é crucial. Esta é a área onde a escalada rápida é quase sempre preferível à tentativa de resolução. Cenários cross-sistemas, onde a informação está espalhada por três sistemas sem uma única fonte de verdade — não por uma limitação da IA, mas porque a lacuna nos dados será revelada aqui primeiro e será considerada uma falha do Agente. ## Regras de Escalada Essenciais Quatro gatilhos rígidos: pedido explícito para falar com uma pessoa, identificação de tom negativo ou palavras de escalada, duas tentativas falhas de responder à mesma pergunta, e qualquer solicitação que trate de um assunto sensível predefinido. A transferência deve preservar o contexto. Um cliente que precisa repetir tudo para um agente vê o Agente como um obstáculo, e é isso que ele lembrará. Um resumo da conversa, o que foi verificado e o que foi encontrado devem ser transferidos automaticamente para o agente. O desenho dos fluxos de escalada dentro do sistema de canais é detalhado em [Omni-Channel e SLA no Service Cloud](/pt/insights/service-cloud-omnichannel-sla). ## Cenário: Um Call Center que Mudou o Piloto Após Duas Semanas Uma empresa de bens de consumo planejava iniciar com um Agente para lidar com solicitações de devolução – o cenário com mais reclamações. Nas duas primeiras semanas, ficou claro que cada solicitação exigia verificação das condições de garantia no sistema ERP, verificação de estoque e uma decisão que, na prática, era tomada a critério de um gerente. O piloto foi transferido para outro cenário: responder ao status de uma devolução existente. Os mesmos clientes, a mesma área, mas com base em um único campo de status. O volume era alto, a taxa de escalada baixa, e o call center registrou uma queda imediata nas chamadas repetidas. Seis meses depois, após a política de devoluções ter sido escrita como um documento aprovado, o cenário original voltou ao planejamento – desta vez com aprovação humana para cada autorização de devolução. A ordem, e não a tecnologia, foi o que possibilitou isso. ## Riscos e Ações Preventivas | Risco | Como Aparece no Call Center | Ação Preventiva | |---|---|---| | Início em cenário emocional | Reclamações que chegam à diretoria na primeira semana | Começar com cenário de informação e não de resolução | | Não há rota para interagir com um humano | Cliente preso em um loop de perguntas | Botão de transferência para agente em todas as etapas e gatilhos rígidos | | Perda de contexto na escalada | Cliente repete a história para o agente | Transferência automática de resumo da conversa | | Política não escrita | Respostas inconsistentes entre casos | Escrever a política antes de introduzir o cenário | | Muitos cenários simultâneos | Sem capacidade de manutenção e qualidade em declínio | Até três cenários ativos no primeiro ano | ## Métricas no Atendimento ao Cliente | Métrica | Definição | Frequência | |---|---|---| | Contenção | Percentual de solicitações encerradas sem agente e sem contato repetido | Semanal | | Taxa de Re-Contato | Clientes que voltaram com o mesmo problema em uma semana | Semanal | | Tempo de Escalada | Quanto tempo demora até a transferência para um humano quando necessário | Semanal | | Satisfação no Canal | Comparação com um canal humano equivalente | Mensal | | Tempo de Atendimento do Agente | Se o suporte realmente encurtou a chamada | Mensal | A Contenção sem a taxa de re-contato é uma métrica enganosa. Uma chamada que foi rapidamente encerrada porque o cliente desistiu é contada como sucesso, por isso as duas métricas são sempre lidas em conjunto. Quando é necessário suporte na escolha dos cenários e na configuração dos fluxos de escalada, [Serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist para a Escolha do Primeiro Cenário - ☐ O cenário depende de uma única fonte de informação confiável - ☐ Não inclui uma ação irreversível na primeira versão - ☐ O volume mensal justifica a manutenção contínua - ☐ Existem artigos aprovados para os cenários comuns - ☐ Os quatro gatilhos de escalada foram definidos - ☐ A transferência para o agente inclui um resumo da conversa - ☐ O Agente declara não ser um humano na abertura - ☐ Um *Baseline* de Contenção e re-contatos foi medido - ☐ Um número máximo de cenários ativos simultaneamente foi estabelecido ### Perguntas e respostas **Qual o melhor caso de uso para começar?** Consultas de status. Elas possuem alto volume, dependem de um ou dois campos no CRM, não exigem escrita e seu sucesso é facilmente mensurável. As consultas de status também são o caso em que o cliente é mais tolerante, pois ele espera informação, e não uma solução complexa. **Devemos começar com um agente interno para colaboradores ou um agente para o cliente?** Interno, quase sempre. Um atendente humano identifica uma resposta incorreta e a corrige, de modo que um erro no estágio de aprendizado custa pouco. O mesmo erro para um cliente externo prejudica a confiança e chega à alta administração. De três a seis meses de uso interno criam o conjunto de testes necessário para a exposição externa. **O que fazer com um cliente insatisfeito que interage com o agente?** Identifique e escale imediatamente. A detecção de tom negativo ou palavras que indiquem insatisfação deve ser uma regra rígida que encaminha o contato para um atendente humano sem mais hesitação. Um agente que tenta acalmar um cliente irritado gera exatamente o tipo de problema que pode paralisar projetos. **O agente deve declarar que não é uma pessoa?** Sim, e em muitos casos, é uma exigência regulatória. Além disso, é uma decisão prática: um cliente que descobre durante a interação que estava falando com um sistema se sente enganado. Uma breve declaração no início, juntamente com uma forma clara de ser transferido para um atendente humano, reduz as reclamações. **Quantos casos de uso devem ser implementados simultaneamente no primeiro ano?** De um a três. Cada caso de uso exige conteúdo, testes e monitoramento próprios, e uma organização que opera seis casos simultaneamente descobre que não tem capacidade para mantê-los adequadamente. Uma expansão estratégica ocorre depois que o primeiro caso de uso se estabiliza por um trimestre. --- ## Grounding e RAG no Agentforce: Conectando seu Agente ao Conhecimento Confiável URL: https://hpi.pro/pt/insights/agentforce-grounding-rag Um agente não "alucina" respostas por má-fé; ele o faz quando a fonte de informação é parcial, contraditória ou não autorizada. Este guia detalha a camada de Grounding em seus componentes: quais fontes conectar, como fatiar e rotular o conteúdo, como as permissões são mantidas na recuperação e como medir a precisão antes de permitir que o agente interaja com um cliente. ## A Resposta Curta O Grounding diferencia um agente que cita uma política aprovada de um que gera algo que soa correto. No Agentforce, a camada de Grounding é composta por quatro componentes construídos em ordem: quais fontes são declaradas como fonte da verdade, como o conteúdo é dividido em “chunks” e taggeado para recuperação, como as permissões do usuário são mantidas no momento da recuperação e o que acontece quando nenhuma fonte adequada é encontrada. A maioria das falhas que observamos em pilotos não são falhas do modelo. São falhas de uma base de conhecimento que ninguém gerencia há dois anos, de documentos divididos no meio de uma tabela e da ausência de um caminho de Fallback. Portanto, o trabalho começa com a avaliação da prontidão do conteúdo, e não com a elaboração de instruções. O contexto mais amplo para a seleção de casos de uso é abordado em [Agentforce para Empresas](/pt/insights/agentforce-for-enterprises). ## As Quatro Camadas de Grounding | Camada | O que é definido nela | Sinal de que está quebrada | Evidência de que funciona | | --- | --- | --- | --- | | Fontes | Quais bases de dados são declaradas como fonte da verdade e quem as possui | Duas respostas contraditórias para a mesma pergunta | Lista de fontes com Proprietário e data de revisão | | Representação | Chunking, Metadata e tagueamento por produto, idioma e versão | O trecho recuperado não está relacionado à pergunta | Recall medido em um conjunto de perguntas conhecidas | | Permissões | Como o contexto do usuário restringe a recuperação | Conteúdo interno aparece na resposta ao cliente | Teste de Persona para cada nível de permissão | | Transparência | Citations, Freshness e caminho de Fallback | Resposta sem fonte e sem reconhecimento de falta de conhecimento | Porcentagem de respostas com citação válida | ## Camada 1: Declaração de Fontes da Verdade O primeiro passo não é técnico. Pega-se as vinte perguntas mais frequentes no processo selecionado e, para cada pergunta, identifica-se onde a resposta correta está atualmente localizada. O resultado é quase sempre surpreendente: algumas respostas estão em um artigo de Knowledge, algumas em um campo de CRM, algumas em um documento em posse de um gerente de equipe e algumas na mente de dois funcionários experientes. Cada fonte inserida deve ter um proprietário nomeado, uma frequência de atualização acordada e uma data da última revisão. Uma fonte sem proprietário, em questão de meses, torna-se uma fonte de informações desatualizadas, e o agente continuará a citá-la com confiança. Fontes sem proprietário ficam de fora, mesmo que sejam ricas em conteúdo. A decisão difícil é o que não conectar. Bases de e-mails, canais de chat e apresentações de vendas parecem minas de ouro, mas acabam sendo uma fonte primária de respostas incorretas, pois não distinguem entre rascunho, proposta rejeitada e política aprovada. Os fundamentos da limpeza e preparação da base de conhecimento são detalhados em [Prontidão de Knowledge para Agentforce](/pt/insights/agentforce-knowledge-readiness). ## Camada 2: Chunking, Metadata e Relevância Uma boa recuperação depende menos do modelo e mais da forma como o conteúdo é fragmentado. A divisão por um número fixo de caracteres destrói tabelas, listas de etapas e critérios de elegibilidade – exatamente o tipo de conteúdo do qual derivam respostas precisas. É preferível dividir por estrutura: um subtítulo, uma etapa de processo ou uma linha de tabela que é mantida intacta com seu contexto. Metadata é o que permite reduzir o espaço de busca antes mesmo que o modelo entre em ação. Tagueamento mínimo a ser exigido: produto ou linha de serviço, mercado ou país, idioma, público-alvo (cliente ou interno), data de validade e status de aprovação. Sem tagueamento de mercado e idioma, um agente em uma organização global misturará políticas de dois países na mesma resposta. A verificação de relevância é quantitativa e não subjetiva: constrói-se um conjunto de 50 a 100 perguntas reais com a resposta correta e a fonte certa, e mede-se em quantos casos o trecho correto apareceu na recuperação. Uma baixa pontuação de Recall indica um problema de representação, e tratá-lo é muito mais barato do que substituir o modelo ou reescrever as instruções. ## Camada 3: Permissões no Momento da Recuperação Esta é a camada que causa falhas em pilotos durante auditorias de segurança. A regra é simples: a recuperação deve ocorrer no contexto das permissões do usuário, não no contexto de uma conta de integração ampla. Se um trecho de informação estivesse oculto do usuário na interface, ele também deve estar oculto na resposta do agente. Na prática, são necessárias três verificações. Primeiro, o mapeamento entre os níveis de classificação na fonte externa e os Profiles e Permission Sets no Salesforce. Segundo, o teste de Persona: executa-se as mesmas dez perguntas na identidade de um representante, gerente e cliente externo e compara-se as respostas. Terceiro, o tratamento de conteúdo misto – um documento que é em sua maioria público e tem um parágrafo sensível deve ser dividido ou não incluído. Em um canal público, o padrão seguro é uma lista de permissão (whitelist): apenas o conteúdo explicitamente marcado como aprovado para o cliente é incluído no índice disponível para o agente externo. Uma abordagem de lista de bloqueio (blacklist) sempre deixará passar um documento. O modelo de responsabilidade entre a organização, a Salesforce e o provedor do modelo é detalhado em [Segurança e Responsabilidade Compartilhada do Agentforce](/pt/insights/agentforce-security-shared-responsibility). ## Camada 4: Citations, Freshness e Fallback Esses três mecanismos transformam um agente de um sistema opaco em um sistema auditável. Uma citação verdadeira aponta para o trecho efetivamente recuperado, não para um artigo que o modelo menciona no texto – essa é a diferença entre evidência e ornamento. A porcentagem de respostas com citação válida é uma das poucas métricas que um gerente não técnico pode ler e entender. Freshness exige um SLA escrito: políticas de preços revisadas trimestralmente, procedimentos de serviço semestralmente, conteúdo regulatório imediatamente após a alteração. O conteúdo que passou da sua data de validade deve ser removido automaticamente do índice e não permanecer até que alguém perceba o erro. Fallback é o comportamento mais importante a ser testado antes da exposição a clientes. O agente deve dizer explicitamente que não possui informações aprovadas e encaminhar, em vez de formular uma resposta provável. Uma boa pergunta para testar: perguntar sobre um produto inexistente e ver se o agente inventa termos de serviço para ele. ## Cenário: Uma Seguradora com 900 Artigos de Knowledge Uma seguradora queria um agente para responder a representantes de call center sobre termos de apólice. O piloto inicial falhou: 40% das respostas estavam incorretas ou incompletas. A análise mostrou que todo o problema estava na camada de fontes — dos 900 artigos, 380 não eram atualizados há mais de três anos, e 60 deles contradiziam artigos mais recentes sobre o mesmo tópico. A equipe não tocou no modelo. Reduziu o índice para três produtos principais, apenas cerca de 140 artigos, nomeou proprietários para cada linha de produto e arquivou os que eram contraditórios. Adicionou tagueamento de produto, ano da versão e status de aprovação, e passou a dividir por seção em vez de por comprimento fixo. A segunda rodada no mesmo conjunto de 80 perguntas de teste alcançou uma precisão muito maior e, mais importante, nos casos em que não havia fonte, o agente encaminhou para uma pessoa em vez de adivinhar. A conclusão que levou à expansão não foi "a IA melhorou", mas sim "sabemos em que ela se baseia". ## Riscos e Ações Preventivas | Risco | Como é detectado tardiamente | Ação preventiva | | --- | --- | --- | | Fontes contraditórias | Respostas diferentes para a mesma pergunta entre representantes | Arquivamento de versões antigas e uma única fonte da verdade para cada tópico | | Chunking que destrói a estrutura | Respostas incompletas em processos multifásicos | Chunking por seção, mantendo o título do contexto | | Permissões de nível de integração | Exposição de conteúdo interno em canal do cliente | Recuperação no contexto do usuário e testes de Persona | | Sem data de validade | Citação de política já revogada | SLA para atualização e remoção automática do índice | | Fallback não definido | Formulação de resposta convincente sem fonte | Caminho de "nenhuma informação aprovada" testado em cada versão | ## Métricas para a Camada de Grounding | Métrica | Definição | Frequência | | --- | --- | --- | | Retrieval recall | Porcentagem de perguntas para as quais o trecho correto foi recuperado | Em cada versão | | Validade da citação | Porcentagem de respostas com fonte existente e válida | Semanal | | Freshness do conteúdo | Porcentagem de artigos no índice dentro da data de validade | Mensal | | Taxa de Fallback | Porcentagem de encaminhamentos para pessoas na ausência de fonte | Semanal | | Vazamento de permissões | Número de ocorrências de exposição em testes de Persona | Em cada versão | Uma alta taxa de Fallback não é um fracasso – é um mapa de lacunas de conteúdo. A lista de perguntas que levaram ao Fallback é a melhor prioridade para escrever novos artigos. Quando falta capacidade interna para estabelecer uma camada de Grounding controlada, o [serviço de Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist Antes de Conectar um Agente a Fontes - ☐ As vinte perguntas mais frequentes foram mapeadas para a fonte da resposta atual - ☐ Cada fonte no índice tem um proprietário nomeado e uma frequência de atualização - ☐ Fontes contraditórias foram identificadas e arquivadas - ☐ Existe tagueamento de produto, mercado, idioma, público e data de validade - ☐ O Chunking preserva tabelas e listas de etapas - ☐ A recuperação ocorre no contexto das permissões do usuário - ☐ Um teste de Persona foi realizado para cada nível de permissão relevante - ☐ Existe um conjunto de teste com 50 perguntas com resposta e fonte corretas - ☐ As Citações apontam para o trecho efetivamente recuperado - ☐ Um caminho de Fallback é formulado e testado no canal do cliente ### Perguntas e respostas **Qual é a diferença entre Grounding e RAG?** RAG é um mecanismo que recupera trechos de informações relevantes e os anexa ao prompt. Grounding é o compromisso de negócios de que a informação recuperada é uma fonte de verdade aprovada, atualizada e autorizada para o usuário específico. É possível implementar um RAG excelente em um repositório de documentos desatualizado e obter respostas erradas com total confiança. **Quantos artigos de Conhecimento são necessários antes de começar?** Menos do que parece. É preferível ter vinte artigos atualizados que cobrem os dez cenários mais comuns do que mil artigos, onde metade foi escrita há quatro anos. Um artigo contraditório é mais prejudicial do que a ausência de um artigo, pois o agente não consegue decidir entre duas versões. **É possível conectar o agente diretamente ao SharePoint ou Confluence?** Tecnicamente sim, através de indexação ou conexão de dados. A verdadeira questão são as permissões: se o modelo de permissões na fonte externa não puder ser mapeado para o usuário no Salesforce, a recuperação poderá expor conteúdo que o usuário não deveria ver. Nesses casos, apenas um subconjunto classificado como público-interno é sincronizado. **Por que o agente retorna uma resposta genérica, embora a informação esteja disponível no artigo?** Geralmente é um problema de Chunking ou Metadados, e não um problema do modelo. Se o artigo for cortado no meio de uma tabela, ou se não houver marcação de produto, país e versão, a recuperação trará um trecho irrelevante. Verificação rápida: olhe no rastreamento quais trechos foram realmente recuperados antes de culpar o modelo. **O que deve acontecer quando o agente não encontra uma fonte apropriada?** Um caminho de 'Fallback' predefinido: uma declaração explícita de que não há informações aprovadas, e a transferência para um agente humano ou um formulário. Um agente que formula uma resposta plausível sem uma fonte é o risco principal na implantação para clientes, e, portanto, esse comportamento deve ser testado em cada versão. --- ## Human-in-the-Loop no Agentforce: Onde a IA Precisa de Aprovação Humana URL: https://hpi.pro/pt/insights/agentforce-human-in-the-loop Aprovação humana em cada ação anula o valor; nenhuma aprovação gera riscos. Este guia apresenta um método para definir pontos de parada baseados em reversibilidade, impacto e sensibilidade, três padrões de aprovação distintos e condições mensuráveis para remover um ponto de aprovação sem perder o controle. ## A Resposta Breve A questão não é se precisamos de intervenção humana (human-in-the-loop), mas sim onde exatamente. A aprovação em cada etapa anula as economias e gera uma fadiga que leva à assinatura automática. A ausência de aprovação em operações irreversíveis, por outro lado, produz o tipo de falha que chega à alta gerência. Um método prático começa com a decomposição do processo em ações individuais, classificando cada ação por sua reversibilidade e impacto. Em seguida, é escolhido um padrão de aprovação apropriado—bloqueador, retrospectivo ou por amostragem. Depois, a tela de decisão é projetada para que a aprovação seja um julgamento genuíno, e não apenas um clique. A estrutura de governança na qual essas decisões são tomadas é detalhada em [Governança de IA para Agentforce](/pt/insights/agentforce-ai-governance). ## Matriz de Decisão: Reversibilidade Versus Impacto | | Impacto Baixo | Impacto Alto | | --- | --- | --- | | **Facilmente Reversível** | Sem aprovação, apenas monitoramento | Amostragem de um percentual para auditoria | | **Reversível com Custo** | Auditoria retrospectiva | Aprovação bloqueadora antes da execução | | **Irreversível** | Aprovação bloqueadora antes da execução | Aprovação bloqueadora + justificativa escrita + trilha de auditoria (Audit trail) | A reversibilidade é medida por três perguntas: quanto tempo leva para reverter, quanto custa e quem é exposto antes da reversão. Uma mensagem enviada a um cliente não é reversível, mesmo que um comunicado de correção possa ser enviado – a impressão já foi criada. A atualização de um campo interno é reversível em um segundo e, portanto, não justifica uma interrupção. ## Os Três Padrões de Aprovação A aprovação bloqueadora interrompe a operação até uma decisão humana. É o padrão mais caro em termos de tempo e, portanto, reservado para operações irreversíveis ou de alto impacto. A regra: se a operação for interrompida, a pessoa deve ter tudo o que precisa para a decisão em uma única tela. A auditoria retrospectiva permite que o agente atue e envie o resultado para revisão dentro de um período de tempo definido. É adequada para ações de baixo custo e reversíveis, e exige duas condições: um curto período de tempo e um botão de cancelamento que realmente funcione. A amostragem verifica uma porcentagem dos casos, não todos. Este é o padrão correto para operações de alto volume e baixo impacto. É também o mecanismo de qualidade que, posteriormente, permite justificar a remoção de uma aprovação bloqueadora em outro lugar. ## Design da Tela de Decisão Esta é a parte que determina se o Human-in-the-Loop é real ou formal. Uma tela que exibe apenas a ação proposta recebe aprovação automática. Uma tela que exige a abertura de três abas para verificação causa atrasos e desvios. Quatro componentes devem aparecer juntos: a ação proposta em uma única linha, a justificativa em linguagem de negócios, a fonte na qual o agente se baseia com um link para o trecho recuperado, e o nível de certeza ou os sinalizadores que foram ativados. Abaixo, três opções, não duas: aprovar, rejeitar com motivo e corrigir antes da execução. O motivo da rejeição é o ativo mais valioso do processo. Ele cria o conjunto de treinamento e teste para a próxima versão e, portanto, deve ser uma lista curta de razões comuns, e não um campo de texto livre que ninguém preenche. Como essas decisões são monitoradas ao longo do tempo é explicado em [Observabilidade para Agentes de IA](/pt/insights/agentforce-observability). ## Prevenção de "Carimbos de Borracha" A fadiga por aprovação é uma falha previsível, não uma surpresa. Três sinais de alerta: tempo médio de decisão que cai abaixo de alguns segundos, taxa de rejeição que se aproxima de zero e aprovações concentradas no final do turno. O tratamento não está na formação, mas no design. Reduzimos o número de aprovações removendo interrupções desnecessárias em ações reversíveis, adicionamos amostragem retrospectiva que gera responsabilidade e fornecemos feedback ao aprovador sobre a qualidade de suas decisões. Quando o aprovador sabe que uma porcentagem das decisões é verificada, a atenção retorna. Métrica chave: se a taxa de correções é zero por meses, ou o agente é excelente e é possível reduzir as interrupções, ou ninguém está lendo. A amostragem é o que distingue os dois casos. ## Quando e Como Remover um Ponto de Aprovação A remoção é uma decisão baseada em dados, não em sentimento. Três condições cumulativas: volume suficiente de decisões documentadas na categoria, taxa de correções baixa e estável por vários meses consecutivos, e um mecanismo de cancelamento ou suspensão testado em campo. A remoção é feita em etapas. Primeiro para um subconjunto restrito — por exemplo, apenas valores abaixo de um certo limite, apenas clientes em um segmento definido, apenas durante o horário comercial. Depois, é medido por um mês. Somente então é expandido. Ao mesmo tempo, a amostragem retrospectiva permanece mesmo após a remoção, caso contrário, não há como identificar degradação. Também é necessária uma condição de retorno: se a taxa de erros ultrapassar um limite predefinido, a aprovação bloqueadora retorna automaticamente. Sem uma condição de retorno escrita, a decisão de remover torna-se irreversível. ## Cenário: Um Call Center Que Removeu a Aprovação Errada Uma empresa de telecomunicações utilizou um agente que preparava respostas para consultas de cobrança. Na primeira versão, cada resposta passava por aprovação de um representante, incluindo respostas de status simples. O tempo de atendimento diminuiu apenas ligeiramente, e os representantes reclamavam de ler o mesmo texto repetidamente. A equipe analisou 4.000 aprovações e descobriu que 78% delas eram apenas para respostas informativas — completamente reversíveis e de baixo impacto. A taxa de correções nesta categoria era inferior a 1%. Por outro lado, na categoria de créditos, a taxa de correções era significativamente maior. A decisão: remover a aprovação bloqueadora para respostas informativas, com amostragem de uma porcentagem delas para revisão semanal; reforçar a aprovação para créditos e adicionar a obrigatoriedade de uma justificativa escrita acima de determinado valor. O tempo de atendimento diminuiu significativamente, e as rejeições na categoria de créditos aumentaram — um sinal de que os aprovadores voltaram a ler. ## Riscos e Ações Preventivas | Risco | Como se manifesta | Ação Preventiva | | --- | --- | --- | | Aprovar tudo | O valor é anulado e os usuários desviam | Matriz de reversibilidade versus impacto para cada ação | | Assinatura automática | Tempo de decisão de segundos e zero rejeições | Amostragem retrospectiva e feedback personalizado ao aprovador | | Tela sem justificativa | O aprovador não consegue julgar verdadeiramente | Exibição de justificativa, fonte e nível de certeza em uma única tela | | Remoção prematura | Falha na produção após algumas semanas de sucesso | Limites de remoção mensuráveis, expansão em etapas e condição de retorno | | Sem documentação de rejeições | Não há aprendizado para a próxima versão | Lista curta de motivos de rejeição e revisão semanal | ## Métricas | Métrica | O que revela | Frequência | | --- | --- | --- | | Taxa de interrupção | Percentual de ações que exigiram aprovação | Semanal | | Taxa de correção | Percentual de casos que o aprovador alterou ou rejeitou | Semanal | | Tempo mediano de decisão | Se o aprovador realmente lê | Semanal | | Descobertas da amostragem | Erros que passaram pela aprovação | Mensal | | Tempo de reversão real | Se o mecanismo de retorno funciona | Em cada versão | Quando o acompanhamento é necessário no planejamento dos pontos de aprovação e sua adaptação à regulamentação aplicável à organização, o [serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist - ☐ O processo foi decomposto em ações individuais. - ☐ Cada ação foi classificada por reversibilidade e impacto. - ☐ Um padrão de aprovação foi escolhido para cada ação: bloqueador, retrospectivo ou por amostragem. - ☐ O aprovador foi definido de acordo com a autoridade existente no processo. - ☐ A tela de decisão exibe a ação, justificativa, fonte e nível de certeza. - ☐ Existe a opção de correção, e não apenas aprovação ou rejeição. - ☐ Os motivos de rejeição são documentados em uma lista curta. - ☐ Limites mensuráveis para a remoção da aprovação e condições de retorno foram definidos. - ☐ O mecanismo de reversão foi testado na prática, e não apenas planejado. ### Perguntas e respostas **A aprovação humana não anula a vantagem do agente de IA?** Não quando posicionada corretamente. O agente ainda economiza a coleta de informações, análise e redação – que consomem a maior parte do tempo. A pessoa toma uma decisão preparada e aprova em segundos. O valor é anulado apenas quando a aprovação exige que a pessoa revise tudo o que o agente fez. **Quem deve aprovar: o agente ou o gerente?** Em geral, quem aprovaria a ação mesmo sem um agente de IA. Se um representante está autorizado a conceder crédito até um determinado valor, ele é o aprovador também neste caso. A escalada para um gerente é necessária apenas quando o valor ou a sensibilidade excedem a autoridade regular, caso contrário, um gargalo que não existia antes será criado. **Como evitar a aprovação automática sem revisão?** De três maneiras: apresente a justificativa e a fonte, e não apenas o resultado; faça uma amostragem de uma porcentagem das aprovações para auditoria posterior; e monitore o tempo de decisão. Uma série de aprovações em menos de dois segundos é um sinal claro de validação automática e exige uma mudança no design da tela. **Quando um ponto de aprovação pode ser removido?** Quando há um volume suficiente de decisões documentadas, a taxa de correções pelo aprovador é baixa e estável por vários meses, e existe um mecanismo de cancelamento rápido. A remoção é feita em etapas – primeiro para um subconjunto restrito de casos, e não para todo o processo de uma vez. **É possível aprovar posteriormente, em vez de antes da execução?** Somente quando a ação é revertável de forma barata e rápida. O envio de um rascunho de e-mail interno é adequado para revisão posterior; um crédito monetário ou uma mensagem enviada ao cliente não são reversíveis e exigem aprovação prévia, mesmo que isso retarde o processo. --- ## Implementação do Sales Cloud: Um Processo Eficaz do Lead ao Forecast URL: https://hpi.pro/pt/insights/sales-cloud-implementation A implementação do Sales Cloud geralmente falha, não por configurações incorretas, mas por estágios de venda mal definidos, onde ninguém sabe exatamente quando transitar entre eles. Este guia mostra como construir uma cadeia única – Lead, Oportunidade, Forecast – onde cada estágio possui critérios de saída mensuráveis, e por que isso é a condição para um forecast confiável. ## A Resposta Curta A diferença entre uma implementação bem-sucedida e uma mal-sucedida do Sales Cloud reside, quase sempre, em uma única questão: é possível definir, em uma frase e sem discussões, o que faz uma negociação avançar de um estágio para o outro? Quando essa resposta existe, o restante — telas, campos, automações e relatórios — deriva dela. Quando falta, o resultado é um sistema bem configurado que gera uma previsão na qual ninguém confia. Portanto, a ordem de trabalho é: definir os estágios de venda e os critérios de saída, e em seguida, o modelo de dados, as permissões, as integrações e, por último, os relatórios. O inverso – começar por um painel de controle desejado e trabalhar de trás para frente – cria campos que são preenchidos para que o relatório funcione, não para que a venda seja conduzida. ## Onde a Falha Ocorre na Prática Em uma organização B2B típica, antes de qualquer intervenção, o cenário é o seguinte: 40% das negociações no pipeline com data de fechamento já expirada, um estágio de "Negociação" que inclui tanto conversas iniciais quanto contratos em fase de assinatura, e um gerente de vendas que mantém sua previsão em uma planilha separada, pois não confia no sistema. Nenhum desses problemas é técnico; todos são resultado de definições não estabelecidas. ## Estágios de Venda: Critérios de Saída para Cada Estágio A regra simples: um estágio é definido pelo que o comprador fez, não pelo que o vendedor sente. "O cliente está interessado" não é um critério. "Um tomador de decisão foi identificado e um orçamento foi alocado" é um critério. | Estágio | Critério de Saída Mensurável | Evidência no Sistema | Probabilidade | |---|---|---|---| | Qualificação | Necessidade, orçamento e tomador de decisão identificados | Campos de Orçamento e Tomador de Decisão preenchidos | 10% | | Descoberta | Mapeamento de necessidades apresentado e aprovado pelo cliente | Documento ou Nota vinculada | 25% | | Proposta | Proposta com precificação e escopo enviada | Cotação ativa | 50% | | Negociação | Cliente retornou com comentários comerciais ou jurídicos | Atividade documentada nas últimas duas semanas | 75% | | Fechado Ganho | Assinatura ou Pedido de Compra (PO) | Arquivo anexado | 100% | A Probabilidade não é uma percepção do representante, mas sim uma derivada do estágio. No momento em que se permite que o representante a sobrescreva manualmente, a previsão volta a ser subjetiva. ## Lead vs. Opportunity: A Fronteira que Determina a Qualidade do Pipeline O erro mais comum é a conversão automática de toda consulta em uma Opportunity, geralmente para que "pareça cheio". O resultado é um Pipeline que triplica de tamanho e uma taxa de fechamento que despenca, tornando qualquer análise histórica inútil. Uma definição funcional: um Lead permanece como Lead até que três condições sejam atendidas — um contato identificado com autoridade, uma necessidade formulada nas palavras do cliente e um horizonte de tempo. Uma consulta que não atende a isso é gerenciada como um Lead em Nurture, não como uma negociação. Isso também permite medir verdadeiramente a taxa de conversão entre marketing e vendas, em vez de medir a generosidade da conversão. Aqueles que constroem o modelo de dados por trás disso encontrarão informações complementares em [Design de Modelo de Dados no Salesforce](/pt/insights/salesforce-data-model-design). ## Atividades: Exigir Pouco, Onde Importa O registro de atividades é o ponto em que as implementações perdem a confiança dos representantes. Exigir o registro de toda interação é percebido como controle, resultando em documentação mínima e sem valor, e gerando dados piores do que a ausência de registro. A abordagem que funciona é exigir o registro em apenas três pontos: mudança de estágio, alteração do valor acima de um limite definido e adiamento da data de fechamento. Em cada um desses casos, o registro serve também ao próprio representante, pois ele documenta uma decisão que será questionada em reuniões. A sincronização automática de e-mail e calendário cobre o restante sem exigir digitação. ## Previsão: O Que Precisa Estar em Ordem Antes de Ativar Uma previsão confiável exige quatro pré-requisitos, e todos se comportam como uma corrente — um elo ausente anula o restante: 1. **Hierarquia de Usuários Correta** – A Previsão no Salesforce se baseia na Role Hierarchy, não em uma estrutura organizacional em planilha. 2. **Datas de Fechamento Limpas** – Uma regra operacional que não permite que uma negociação permaneça com uma data vencida por mais de uma semana. 3. **Categorias de Previsão Definidas** – Pipeline, Best Case, Commit, Closed – com uma definição acordada sobre quem move uma negociação para Commit e quando. 4. **Ciclo de Revisão Fixo** – Reunião semanal de Pipeline que é conduzida a partir do sistema, e não de uma planilha paralela. O último ponto é crucial. Enquanto existir uma planilha paralela, os representantes sabem que o sistema não é a fonte da verdade e o atualizam tardiamente. ## O Que Medir Após o Go-Live | Métrica | O Que Ela Revela | Limite Problemático | |---|---|---| | Precisão da Previsão | Diferença entre a previsão de *Commit* e o resultado | Desvio acima de 20% no trimestre | | Tempo de Estágio | Negociações que ficam presas em um estágio | Mais que o dobro da mediana | | Atualização em 7 dias | O sistema reflete a realidade? | Menos de 70% das negociações ativas | | Completude dos dados | Campos obrigatórios em estágios avançados | Menos de 90% | Métricas de adoção mais aprofundadas são detalhadas em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## O Que Não Fazer na Primeira Onda Territory Management complexo, múltiplos modelos de Previsão, CPQ completo e Scoring automático são todos recursos que vale a pena adicionar – depois que o processo básico estiver estável e dois ciclos de vendas tiverem passado. Adicioná-los na primeira onda fixa suposições ainda não testadas e encarece exponencialmente qualquer mudança futura. ## Resumo A implementação do Sales Cloud é, principalmente, um trabalho de definições de negócio: quando uma negociação avança de estágio, quando uma consulta se torna uma negociação e o que exige documentação. Essas três decisões determinam se a previsão será uma ferramenta de gestão ou um exercício de relatório. A ferramenta em si suportará qualquer definição que você escolher – incluindo uma definição inadequada. ### Perguntas e respostas **Quantos estágios de Oportunidade devem ser configurados?** Geralmente, entre quatro e seis. Um número maior pode parecer mais preciso, mas cria estágios que são difíceis de diferenciar, levando os representantes a atualizá-los tardiamente ou todos de uma vez antes das reuniões de Pipeline. **Qual a diferença prática entre um Lead e uma Oportunidade?** Um Lead é um interesse ainda não qualificado. Uma Oportunidade é um negócio com um comprador identificado, uma necessidade definida e um horizonte de tempo. Se a conversão é automática para cada consulta, o Pipeline incha e o forecast perde sua relevância. **É obrigatório documentar atividades?** Uma obrigatoriedade generalizada pode gerar documentação formal sem valor. É preferível que a documentação seja mandatória em pontos-chave que impactam uma decisão – transição de Stage, mudança de valor, adiamento da data de fechamento. **Quando integrar CPQ ou recursos de precificação?** Somente após os estágios de venda e a estrutura de produtos estarem estáveis. Integrar a precificação a um processo ainda em mudança duplica o custo de modificações e solidifica suposições temporárias. **Quanto tempo leva para o forecast ser confiável?** Geralmente, dois a três ciclos de vendas completos após a entrada em operação. Antes disso, não há negócios suficientes gerenciados pelas novas definições para comparar o forecast com os resultados reais. --- ## Implementação do Service Cloud: Casos, SLA, Roteamento e Knowledge URL: https://hpi.pro/pt/insights/service-cloud-implementation Muitos contact centers implementam o Service Cloud e percebem que o tempo de resposta não melhorou. A razão quase sempre não é a ferramenta, mas quatro decisões cruciais que não foram tomadas: o que é considerado um Caso, quem o recebe, quando o tempo começa a contar e o que acontece quando a resposta já existe. Este guia desdobra essas quatro questões em resultados verificáveis. ## A Resposta Concisa O Service Cloud, por si só, não reduz os tempos de resposta; ele apenas aplica as configurações que lhe foram fornecidas. Se não houver uma definição clara do que constitui um "Case", quem o recebe, e de quando o tempo é contabilizado, o sistema medirá precisamente um processo indefinido. Isso resultará em métricas que parecem melhores ou piores do que a realidade, independentemente do serviço efetivo. Quatro decisões cruciais determinam o resultado: a definição de Case, o modelo de alocação, o relógio do SLA e o repositório de conhecimento. O restante da implementação – telas, canais, automações – deriva dessas decisões. ## Decisão 1: O Que Constitui um Case Muitos call centers abrem um 'Case' para cada interação, alegando que "isso gera dados". O resultado é o oposto: milhares de registros fechados em um minuto inflacionam o volume, melhoram artificialmente o tempo médio de resolução e obscurecem as solicitações que realmente ficam pendentes. Uma definição eficaz distingue entre três tipos de interações: | Tipo de Interação | Um Caso é Aberto? | Razão | | --- | --- | --- | | Pergunta respondida durante a chamada | Não, registrada como interação | Sem rastreamento e sem compromisso | | Solicitação que exige ação ou espera | Sim | Requer rastreamento e SLA | | Problema que pode reocorrer | Sim, com classificação de causa | Requer análise de tendência | ## Decisão 2: Quem Recebe a Solicitação A falha comum é o roteamento baseado apenas no departamento, criando uma única fila grande da qual os agentes "pescam" os Cases mais fáceis. As solicitações complexas envelhecem no final da fila até que alguém as escale por telefone, tornando todo o mecanismo de SLA um teatro. Um modelo de alocação adequado define três dimensões: a habilidade necessária, a capacidade real do agente (não o número de Cases, mas o peso) e as regras de escalonamento baseadas no tempo. O Omni-Channel Routing oferece suporte a essas três dimensões, mas apenas se as habilidades reais forem definidas. Atribuir "Habilidade: Suporte" a todos os agentes é o mesmo que não atribuir nenhuma habilidade. Uma descrição completa do roteamento multicanal está disponível em [Omnichannel e SLA no Service Cloud](/pt/insights/service-cloud-omnichannel-sla). ## Decisão 3: Quando o Relógio Começa a Correr Esta é a decisão que a maioria das organizações salta, e é ela que determina se as métricas são confiáveis. Perguntas que devem ter uma resposta documentada: 1. **Quando o relógio começa** – No momento em que a solicitação é recebida ou no início do próximo horário comercial? O Business Hours deve ser configurado para cada fuso horário relevante. 2. **Quando ele para** – Um Case em espera pelo cliente deve pausar o contador; caso contrário, o call center é penalizado pela lentidão do cliente. 3. **O que exatamente é medido** – Tempo de primeira resposta, tempo de resolução, ou ambos com metas separadas para cada nível de criticidade. 4. **O que acontece antes da violação** – Um Milestone que gera um alerta a 80% do tempo é mais valioso do que um relatório mensal de violações. Entitlements e Milestones são os mecanismos que implementam essas quatro questões. Ativá-los sem uma decisão documentada de antemão gerará alertas que serão ignorados em duas semanas. ## Decisão 4: Onde o Conhecimento Reside Uma Knowledge Base não é um projeto separado, mas uma condição para reduzir a carga de trabalho. A falha comum: artigos são escritos na fase de lançamento, ninguém os mantém, e em seis meses os agentes voltam a perguntar no chat interno. O que funciona: um ciclo de vida definido para cada artigo – Owner, data de revisão e métrica de uso. Um Case fechado sem um artigo vinculado, e que aparece cinco vezes no mesmo trimestre, é um gatilho automático para a criação de um artigo. Uma visão aprofundada sobre o tema está disponível em [Gerenciamento de Conhecimento no Salesforce](/pt/insights/salesforce-knowledge-management). ## Métricas Operacionais | Métrica | Definição | Limite de Análise | | --- | --- | --- | | Tempo de primeira resposta | Até o primeiro contato humano | Mais de 10% de solicitações fora do limite | | Resolução no primeiro contato | Fechado sem transferência | Abaixo de 60% | | Taxa de reabertura | Caso reaberto dentro de 7 dias | Acima de 8% | | Envelhecimento do backlog | Casos abertos acima do SLA | Tendência de aumento semanal | | Taxa de anexos de conhecimento | Casos com artigo vinculado | Abaixo de 30% | A taxa de reabertura é a métrica mais importante e geralmente a mais negligenciada: ela revela fechamentos prematuros feitos para cumprir metas de tempo. ## Fluxo de Trabalho Recomendado Primeira onda: Definição de Case, um ou dois canais, roteamento básico, SLA para um nível de criticidade e dez artigos de conhecimento para as solicitações mais frequentes. Segunda onda: Canais adicionais, habilidades, Entitlements completos, Self-Service. Ativar tudo de uma vez faz com que um call center lide com mudança de processo, mudança de ferramenta e mudança de métricas na mesma semana, e geralmente acaba retornando a trabalhar com "atalhos". ## Conclusão Uma implementação bem-sucedida do Service Cloud é medida por uma única pergunta: o gerente do call center pode mostrar, diretamente do sistema e sem ajuda de uma planilha, onde estão as solicitações que excedem os limites e por quê. Se as quatro decisões estiverem resolvidas, a resposta existe. Se não, há um sistema novo, mas o mesmo call center. ### Perguntas e respostas **Toda interação deve ser registrada como um Caso?** Não. Uma pergunta respondida em uma chamada que não exige acompanhamento não é um Caso. Abrir casos indiscriminadamente inflaciona os dados e distorce as métricas de volume e resolução. A regra prática: um Caso é aberto quando é necessário acompanhamento, um compromisso de tempo ou documentação para análise. **Roteamento baseado em Fila ou Omni-Channel?** Fila é adequado para contact centers menores com agentes multifuncionais. Omni-Channel é necessário quando há canais paralelos, habilidades diferentes ou a necessidade de equilibrar a carga de trabalho de acordo com a capacidade real. **É obrigatório ativar Entitlements para gerenciar SLA?** É possível medir o SLA apenas em relatórios, mas Entitlements e Milestones permitem alertas proativos e escalonamento antes de uma violação, e não apenas o registro após o ocorrido. **Quando adicionar um Portal ou Autoatendimento?** Depois que a Base de Conhecimento contiver respostas verdadeiras para as solicitações mais comuns. Um portal que direciona para uma base de conhecimento vazia aumenta o número de solicitações em outros canais. **Quantos tipos de Casos devem ser definidos?** Poucos – geralmente três a cinco – com um campo de categorização secundário. Uma taxonomia muito detalhada faz com que os agentes escolham a primeira opção da lista, perdendo o valor da análise. --- ## Sales Cloud vs. Service Cloud: Qual a Diferença e o que sua Organização Precisa? URL: https://hpi.pro/pt/insights/sales-cloud-vs-service-cloud A escolha entre Sales Cloud e Service Cloud, frequentemente vista como uma comparação de produtos, é na verdade sobre a natureza do trabalho: gerenciar negócios com progressão ou solicitações com tempo de resposta. Este guia diferencia os dois por objetos, métricas e licenciamento, mostrando quando ambos são necessários e como integrá-los sem duplicar dados. ## A Resposta Curta O Sales Cloud gerencia **negócios em andamento** – uma unidade de trabalho que dura semanas ou meses, medida pela probabilidade de fechamento, e bem-sucedida ao ser concluída. O Service Cloud gerencia **solicitações que são resolvidas** – uma unidade de trabalho que dura horas ou dias, medida pelo tempo de resposta e resolução, e bem-sucedida ao ser fechada rapidamente e sem recorrência. Essa diferença, e não a lista de recursos, é que determina a escolha. Se você gerencia um Pipeline, use o Sales Cloud. Se você gerencia uma fila com SLA, use o Service Cloud. Se você gerencia um cliente que compra e também reclama, use ambos, na mesma Account. ## A Diferença em Termos Operacionais | Dimensão | Sales Cloud | Service Cloud | |---|---|---| | Objeto Central | Opportunity | Case | | Ciclo de Vida | Semanas a Meses | Horas a Dias | | Métrica Principal | Win rate, Forecast accuracy | First response, FCR, CSAT | | Mecanismo de Alocação | Propriedade individual de longo prazo | Roteamento dinâmico por disponibilidade | | Fonte de Carga | Número de negócios ativos | Picos imprevisíveis nos canais | | Componente de Conhecimento | Playbooks e precificação | Base de Conhecimento integrada | A linha mais importante é o mecanismo de alocação. Em vendas, a propriedade individual é um valor — o cliente deseja um ponto de contato fixo. No serviço, a propriedade individual é um problema — ela cria filas pessoais que estagnam quando um representante está de férias. ## Quando a Escolha é Clara **Sales Cloud apenas** é adequado para uma organização que vende através de um processo contínuo e onde o suporte pós-venda é mínimo ou tratado por um parceiro — por exemplo, um fornecedor de equipamentos que vende através de revendedores e não opera uma central de atendimento. **Service Cloud apenas** é adequado para uma organização cuja única interação com o cliente é o tratamento de solicitações — uma empresa de serviços operacionais, um órgão público ou um provedor de infraestrutura com contratos existentes. **Ambos** são necessários quando há renovação, Upsell ou retenção: a partir do momento em que um representante de serviço precisa saber que o cliente está em processo de renovação, e um representante de vendas precisa saber que o cliente abriu três casos graves neste mês — a separação se torna um obstáculo. ## Como Conectar Sem Duplicar Dados Este é o ponto onde as implementações combinadas falham. A regra: **Account e Contact são uma única camada compartilhada**. Não existem "clientes de vendas" e "clientes de serviço" separados. Distinguimos três tipos de decisões: 1. **Propriedade do registro do cliente** — quem atualiza informações de contato, endereço e estrutura organizacional. Geralmente o serviço, pois ele interage com o cliente com mais frequência. 2. **Visibilidade Mútua** — um representante de serviço visualiza negócios abertos em modo somente leitura; um representante de vendas visualiza casos abertos e métricas de satisfação. Ambas as direções são definidas no modelo de Sharing, e não por duplicação de campos. 3. **Gatilhos entre Áreas** — um caso crítico para um cliente em processo de renovação dispara um alerta para o gerente de contas. Este mecanismo é mais valioso do que qualquer dashboard integrado. Informações detalhadas sobre permissões e visibilidade podem ser encontradas em [Modelo de Sharing e Visibilidade no Salesforce](/pt/insights/salesforce-sharing-visibility-design). ## Licenciamento: O que Você Precisa Saber Antes de Comparar Preços A licença do Service Cloud é abrangente – ela inclui as funcionalidades básicas do Sales Cloud, portanto, um usuário que precise de ambos não necessita de duas licenças. O inverso não é verdadeiro: uma licença de Sales não inclui gerenciamento de Case, Entitlements ou Knowledge. A implicação prática: um cálculo de custo preciso começa com o mapeamento dos usuários de acordo com o que eles realmente fazem, e não com o departamento a que pertencem. Um representante que, duas vezes por ano, lida com uma oportunidade não é um usuário de vendas. ## Ordem de Implementação Quando Ambos São Necessários Uma implementação paralela parece eficiente, mas na prática duplica o risco: dois processos que mudam simultaneamente, dois grupos de usuários em treinamento, e a impossibilidade de atribuir melhorias ou falhas à sua origem. A ordem recomendada é começar pelo lado com a dor mais mensurável — geralmente o atendimento, pois o tempo de resposta e o abandono já são medidos hoje — e adicionar o outro lado após dois meses de operação estável. A camada comum (Account, Contact, permissões) é construída na primeira fase, mesmo que apenas um lado entre em operação, caso contrário, a segunda fase exigirá uma reestruturação. ## Resumo A questão não é qual produto é melhor, mas qual unidade de trabalho a organização gerencia: um negócio que avança ou uma solicitação que é resolvida. A maioria das organizações maduras gerencia ambas, e então a verdadeira decisão não é o que comprar, mas como manter uma única camada de cliente sob ambos. ### Perguntas e respostas **É possível gerenciar solicitações de serviço no Sales Cloud sem o Service Cloud?** Tecnicamente, sim, utilizando um objeto personalizado ou Tarefas. No entanto, a partir do momento em que SLAs, roteamento por disponibilidade, base de conhecimento ou diversos canais são necessários, o custo de desenvolvimento próprio supera a diferença de licenciamento. **Precisamos de duas organizações (Orgs) Salesforce separadas?** Quase sempre não. Ambos os Clouds residem na mesma Org e compartilham Contas e Contatos. A separação em Orgs distintas é considerada apenas por questões de regulamentação ou em empresas totalmente independentes. **O que acontece com um usuário que precisa de ambos?** Um usuário com licença Service Cloud também tem acesso às funcionalidades básicas do Sales Cloud. O inverso não é verdadeiro – uma licença Sales não inclui o gerenciamento completo de Casos. **Qual a diferença na definição de sucesso entre os dois?** Vendas são medidas por progresso e taxa de fechamento ao longo de semanas; serviços são medidos por tempo de resposta, resolução no primeiro contato e satisfação em horas. Essa diferença de ritmo impacta a frequência de medição, a carga de automações e o planejamento de desempenho. **Por onde começar se ambos são necessários?** Comece pelo lado onde a dor é mais mensurável. A implementação paralela de ambos duplica a área de mudança organizacional e dificulta a identificação do que causou melhoria ou falha. --- ## Gestão da Mudança na Implementação Salesforce: Plano de Ação Pré e Pós-Go Live URL: https://hpi.pro/pt/insights/salesforce-change-management-plan A Gestão da Mudança é muito mais do que apenas a semana de treinamento pré-lançamento. Apresentamos um plano de ação em quatro fases — mapeamento de impacto, engajamento de stakeholders, comunicação e ciclo de gestão contínua — com entregáveis, responsáveis e métricas para cada etapa. ## A Resposta Concisa A gestão de mudanças não é uma atividade de comunicação anexa ao final do projeto. É um fluxo de trabalho paralelo que inicia na fase de Discovery e se estende por meses após o Go Live. A diferença entre projetos bem-sucedidos e aqueles que falham reside quase sempre aqui, e não no código. Quatro fases, cada uma com um entregável definido: mapeamento de impacto, engajamento de stakeholders, comunicação e treinamento, e um ciclo de gestão contínuo. ## Fase 1 — Mapeamento do Impacto por Função Antes de planejar uma única tela, documente para cada função impactada: o que ela faz hoje, o que mudará, o que ficará mais fácil, o que ficará mais difícil e o que será medido de forma diferente. As terceira e quarta linhas são as mais importantes — projetos falham quando alguém descobre, apenas no Go Live, que perdeu controle ou recebeu trabalho adicional. | Função | O que muda | Principal Risco | Resposta Planejada | |---|---|---|---| | Representante de Vendas | Entrada no sistema em vez de Excel pessoal | Carga de entrada, perda de controle | Formulário simplificado, valor diário recorrente | | Gerente de Vendas | Previsão baseada no sistema | Exposição a números desfavoráveis | Preparação antecipada, Dashboard privado para período de transição | | Back Office | Novo processo de aprovação | Atrasos durante o período de transição | Treinamento prévio, procedimento de exceção | | Liderança | Fonte única de verdade para relatórios | Discrepâncias com relatórios antigos | Comparação paralela por um trimestre | O entregável é um documento de duas a quatro páginas, que serve como insumo para o planejamento da solução. ## Fase 2 — Stakeholders e Patrocínio (Sponsorship) Um Sponsor autêntico é aquele que pode alterar um processo, uma meta ou uma recompensa. Um Sponsor que só aparece na mensagem de abertura não é um Sponsor. Três compromissos mínimos que devem ser obtidos por escrito: - Participação na revisão mensal do projeto e na tomada de decisões abertas. - Declaração explícita sobre a fonte da verdade e o fim da geração paralela de relatórios em uma data definida. - Apoio à mudança de processo, mesmo que seja inconveniente para um departamento específico. Além do Sponsor, uma rede de representantes em campo é construída para funcionar como um canal bidirecional — detalhes na construção de uma [rede de Champions no Salesforce](/pt/insights/salesforce-champions-network). ## Fase 3 — Comunicação Diferenciada A comunicação eficaz responde a uma única pergunta do usuário: o que isso significa para mim. Mensagens que falam sobre "transformação digital" são lidas como ruído. Três princípios: 1. **Segmentação por função** — Uma mensagem única para toda a organização não funciona. Para o representante, o que muda na sua tela; para o gerente, o que muda na sua revisão. 2. **Reconhecimento do custo** — Mencionar explicitamente o que será mais difícil. A negação erode a confiança mais rapidamente do que qualquer desvantagem real. 3. **Ritmo constante** — Uma atualização curta a cada duas semanas, desde o Discovery até o Hypercare, mesmo quando não há notícias dramáticas. O treinamento em si é construído em torno de cenários de trabalho e não em torno de telas; a estrutura recomendada é detalhada em [treinamento Salesforce baseado em função](/pt/insights/salesforce-role-based-training). ## Fase 4 — O Ciclo de Gestão Pós-Go Live Esta é a fase mais frequentemente omitida e a que mais determina o sucesso. A mudança só se estabiliza quando se incorpora à rotina de gestão: - Revisão semanal da equipe a partir de um Dashboard no sistema, e não de um arquivo. - Relatório mensal à liderança gerado exclusivamente pelo sistema. - Um canal de requisições aberto com lançamentos periódicos e comunicação sobre o que foi corrigido. - Medição mensal da adoção conforme as [métricas de adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). A data-alvo significativa não é o Go Live, mas sim o dia em que o relatório paralelo é descontinuado. Enquanto houver um relatório sombra legítimo, o sistema permanece secundário. ## Riscos Comuns e Sinais de Alerta Precoce | Sinal de Alerta | Significado | Resposta | |---|---|---| | Sponsor pula duas revisões consecutivas | Falta de propriedade de negócio | Elevar a questão à liderança antes do UAT | | Pedidos de "apenas mais um campo" se acumulam | O processo não foi acordado | Congelar e reavaliar o processo | | O treinamento é adiado devido a pressão de cronograma | O projeto irá ao ar sem preparação | Adiar o Go Live apenas para a equipe relevante | | Gerentes pedem "também o relatório antigo" | Desconfiança nos dados | Corrigir dados antes de expandir o escopo | ## Métricas para o Plano de Mudança Medimos quatro: porcentagem de usuários que completaram o treinamento por cenários, taxa de execução da operação principal nas duas primeiras semanas, número de arquivos sombra ativos e tempo médio para fechar uma solicitação de mudança. Os três primeiros indicam adesão; o quarto indica confiança no canal. ## Resumo Um bom plano de gestão de mudanças começa com o mapeamento de impacto na fase de planejamento, apoia-se em um Sponsor com autoridade real, comunica-se por função e continua como um ciclo de gestão por meses após o Go Live. Esta é a parte mais econômica do projeto e a que mais afeta seu ROI. ### Perguntas e respostas **Quando iniciar a Gestão da Mudança em um projeto Salesforce?** Durante a fase de Discovery, simultaneamente à coleta de requisitos. O mapeamento do impacto nas funções é uma entrada para o planejamento da solução, não uma saída. Iniciar na fase de testes pode gerar um atraso de aproximadamente três meses. **Quanto orçamento alocar para a Gestão da Mudança?** Um intervalo aceitável é de 10% a 15% do orçamento do projeto em uma implementação média, e mais quando a estrutura organizacional ou o método de remuneração são alterados. Em projetos onde este valor é cortado, o custo retorna posteriormente como um projeto de recuperação. **Quem é responsável pela Gestão da Mudança — RH, PMO ou a equipe de CRM?** A responsabilidade pelos resultados pertence ao Patrocinador de Negócios. RH ou PMO fornecem metodologia e ferramentas, a equipe de CRM fornece conteúdo, mas as decisões sobre mudanças de processo e remuneração devem ser tomadas no nível de negócios. **Como lidar com a resistência de gerentes de nível médio?** Gerentes de nível médio resistem principalmente quando o sistema gera uma transparência que os ameaça ou lhes adiciona trabalho. A solução é oferecer-lhes valor gerencial imediato — um Dashboard que substitui relatórios manuais. **O que acontece após o Hypercare?** Três coisas persistem: um ciclo de revisão gerencial contínuo a partir do sistema, um canal aberto para solicitações com lançamentos periódicos e a medição mensal da adoção. Sem isso, a mudança regride em dois trimestres. --- ## Treinamento Salesforce por Função: Como Criar um Programa que Gera Autonomia URL: https://hpi.pro/pt/insights/salesforce-role-based-training Um treinamento que apenas explica telas é esquecido em uma semana. Conheça a estrutura de um programa de treinamento baseado em cenários: jornada separada para cada função, prática com dados reais no sandbox, teste de autonomia e manutenção contínua para novos colaboradores. ## A Resposta Concisa Treinamentos que simplesmente apontam a localização de cada botão são esquecidos rapidamente. Já um treinamento que simula os cenários reais do usuário — "um cliente liga pedindo uma proposta", "uma negociação travou", "preciso encerrar um Case com reembolso" — esse, sim, é retido, pois está diretamente ligado à memória da própria atividade. A estrutura ideal: uma trilha separada para cada função, com duração de duas a quatro horas, focada em exercícios práticos em um ambiente de sandbox com dados familiares, e culminando em um teste prático de autonomia. ## Por Que Treinamentos Genéricos Falham Um treinamento único para toda a organização ensina apenas o denominador comum — ou seja, principalmente a navegação. Cada função sai com 20% de conteúdo relevante e 80% de ruído, chegando ao primeiro dia de trabalho sem saber como executar suas tarefas de ponta a ponta. O resultado é a dependência do suporte para cada ação, ou o retorno aos métodos de trabalho antigos. Além disso, o treinamento genérico mascara problemas de interface. Se são necessários 40 minutos para explicar como inserir uma oportunidade, o problema não está no treinamento, mas na tela — um tema abordado em [Simplificação da UX no Salesforce](/pt/insights/salesforce-ux-simplification). ## Trilhas de Treinamento por Função | Função | Cenários Centrais | Duração | Teste de Autonomia | | --- | --- | --- | --- | | Representante de Vendas | Lead para Oportunidade, Avanço de Etapa, Proposta, Registro de Atividade | 3 horas | Fechar um ciclo completo sem ajuda | | Gerente de Vendas | Revisão de Pipeline, Previsão, Aprovação de Exceções, Análise de Equipe | 3 horas | Conduzir uma revisão semanal usando o sistema | | Agente de Serviço | Abertura de Case, Classificação, Escalada, Fechamento com Código de Motivo | 3 horas | Resolver três Cases diferentes dentro do tempo-alvo | | Back Office | Aprovações, Correções de Dados, Exceções | 2 horas | Gerenciar a fila diária de aprovações | | Liderança | Leitura de Dashboards, Perguntas sobre Dados | 1 hora | Tomar uma decisão baseada apenas nos dados do sistema | ## Estrutura de Encontro Eficaz Uma divisão 20/60/20: 20% de contexto — por que a mudança e o que ela me oferece; 60% de prática manual em cenários reais; 20% para perguntas e tratamento de exceções. Uma palestra sem teclado aberto não é treinamento. A prática deve ser realizada em um ambiente de sandbox com dados que se assemelham à realidade dos participantes: nomes de clientes conhecidos, valores razoáveis, produtos reais. Dados fictícios genéricos criam desconexão e dificultam a transição para o trabalho real. ## Teste de Autonomia Um programa de treinamento deve ter um critério de conclusão mensurável. O critério não é presença nem questionário de conhecimento — é execução: o participante deve realizar seu cenário central de ponta a ponta, sozinho, em tempo razoável, sem perguntar. Quem não passar recebe um treinamento adicional breve, não um retrabalho completo do treinamento. A falha recorrente de muitos na mesma etapa indica um problema no processo ou na interface, que deve ser solucionado antes do lançamento. ## Materiais de Apoio: Breves e Orientados por Tarefas Após o treinamento, o que realmente será necessário é um documento de uma página para cada função e uma biblioteca de vídeos de um a três minutos por tarefa. As duas regras: pesquisa por pergunta ("Como movo uma negociação para a próxima etapa?") e não por módulo, e um proprietário definido para atualizar o material a cada mudança no sistema. Um manual do usuário de 60 páginas é escrito uma vez, fica obsoleto em dois meses e nunca é lido. Não invista nele. ## Suporte Nas Primeiras Semanas Nas duas semanas após o lançamento, é essencial a presença de representantes de campo que possam ajudar no local. Essa rede — os Champions — é o braço operacional do treinamento, e sua construção está detalhada em [Rede de Champions no Salesforce](/pt/insights/salesforce-champions-network). Todo o treinamento é um componente de um plano mais amplo: [Gerenciamento de Mudanças no Salesforce](/pt/insights/salesforce-change-management-plan). ## Novos Integrantes Pós-Lançamento Em um ano, uma parte significativa dos usuários não terá participado do treinamento original. Sem um processo de integração contínuo, a adoção se desgasta silenciosamente. Esse processo deve incluir: acesso à trilha da função em até duas semanas após a entrada, acompanhamento por um Champion na equipe, e o próprio teste de autonomia. Esta é a ação mais econômica para manter a adoção a longo prazo. ## Medição Avalie três métricas: taxa de aprovação no teste de autonomia, volume de solicitações de suporte no primeiro mês por assunto, e taxa de execução da ação central nas duas primeiras semanas, conforme [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). A concentração de solicitações sobre um único tópico quase sempre indica uma correção necessária no sistema, e não no treinamento. ## Conclusão Crie uma trilha para cada função baseada em cenários de trabalho, pratique em um ambiente de sandbox com dados familiares, finalize com um teste prático de autonomia e mantenha um processo de integração para novos membros. Um bom treinamento não ensina um sistema — ele ensina como realizar o trabalho dentro dele. ### Perguntas e respostas **Quantas horas de treinamento são necessárias para um usuário final?** Entre duas e quatro horas para os cenários essenciais, divididas em duas sessões curtas, e não em uma única longa. Gerentes necessitam de uma hora adicional sobre relatórios e visão geral. Mais do que isso gera esquecimento, não conhecimento. **É preferível vídeo gravado ou treinamento ao vivo?** Uma combinação. Treinamento ao vivo para a prática dos cenários centrais, pois permite perguntas, e vídeos curtos de um a três minutos como biblioteca de apoio por tarefa. Vídeos longos de 40 minutos quase ninguém assiste. **Quando realizar o treinamento em relação ao Go Live?** Uma semana a dez dias antes. Um treinamento com um mês de antecedência é esquecido; um treinamento no dia anterior colide com a pressão do lançamento. Novos colaboradores após o lançamento seguem a mesma trilha em até duas semanas após assumirem a função. **Como treinar quando o sistema ainda está em mudança?** Congele os processos centrais duas semanas antes do treinamento e documente as mudanças tardias como uma breve lista de deltas. Treinar em um sistema instável gera desconfiança imediata. **O que fazer com usuários que não compareceram ao treinamento?** Bloqueie o acesso até a conclusão de uma trilha curta, com aval da gestão. Um usuário que entra no sistema sem treinamento gera dados incorretos pelos quais todos pagam. --- ## Métricas de Adoção do Salesforce: Por Que Logins Não São Suficientes URL: https://hpi.pro/pt/insights/salesforce-adoption-metrics Login é uma medida de presença, não de valor. Um guia prático para construir um conjunto de métricas de adoção que avalia as ações principais, a qualidade dos dados e o resultado de negócios — incluindo linha de base, segmentação por função e um plano de ação para cada descoberta. ## A Resposta Concisa O "login" prova que alguém acessou o sistema, mas não garante que o trabalho foi realizado, que os dados inseridos são confiáveis, ou que o gestor pode tomar decisões com base neles. Uma organização que relata 92% de "logins" mas gerencia sua previsão de vendas no Excel não adotou o Salesforce – ela apenas o abriu. Uma métrica de adoção útil responde a uma única pergunta: **o processo de negócio está sendo executado de ponta a ponta dentro do sistema, com qualidade que permita confiar nele?** A partir disso, derivam-se quatro camadas de medição: ações essenciais, qualidade dos dados, velocidade do processo e resultado de negócio. ## Três Níveis de Adoção | Nível | O que é Medido | Exemplo | O que Significa | |---|---|---|---| | Presença | Login, Tempo de permanência | 92% acessaram esta semana | Quase nada | | Uso Ativo | Ações essenciais por função | 78% das oportunidades atualizadas em 7 dias | O processo está em andamento | | Valor | Resultado de Negócio + Qualidade | O desvio da previsão caiu de 31% para 12% | A adoção gerou retorno | A maioria das organizações fica presa no primeiro nível, pois é o único disponível sem esforço adicional. Os dois níveis seguintes exigem uma decisão prévia: qual é a "ação essencial" para cada função. ## Como Definir uma Ação Essencial Uma ação essencial é aquela sem a qual o processo está quebrado. Não é a ação mais comum, mas sim a mais crítica. Para um representante de vendas, geralmente é a atualização do estágio e da data de fechamento; para um gerente de vendas, é a revisão semanal do Pipeline dentro do Salesforce; para um agente de serviço, é fechar um Case com um código de motivo correto. A regra prática: se a ação não foi executada, alguém no fluxo de trabalho está operando com informações incorretas. Se ninguém é prejudicado pela sua não execução, então não é uma ação essencial e, às vezes, nem deveria ser um campo obrigatório. Para cada função, defina uma ou duas ações essenciais, documente-as explicitamente na descrição da função e meça a porcentagem de usuários que as executaram no período de tempo relevante para o processo. ## Camada de Qualidade dos Dados Uma ação mal executada pode ser pior do que uma ação não executada, pois gera uma falsa confiança. Por isso, toda métrica quantitativa precisa de um par qualitativo: - Porcentagem de oportunidades com data de fechamento passada – métrica de "apodrecimento" do Pipeline. - Porcentagem de Cases fechados com um código de motivo genérico como "Outros" – métrica de categorização falha. - Porcentagem de clientes sem um contato ativo – métrica de dados básicos ausentes. - Porcentagem de registros duplicados criados manualmente – métrica de falha no processo de entrada. Essas quatro métricas revelam em uma semana se o sistema está em uso real ou em uso ritualístico. Mais detalhes sobre como corrigir a causa raiz podem ser encontrados em [Melhorando a Adoção do Salesforce](/pt/insights/recover-salesforce-user-adoption). ## Segmentação: A Média Engana Uma média organizacional de 70% de adoção pode esconder uma equipe com 95% e outra com 20%. Toda medição deve ser segmentada por pelo menos três critérios: 1. **Função** – Representante, Gerente, Back Office. Cada um tem uma expectativa diferente. 2. **Equipe ou Gestor Direto** – A maior diferença na adoção é quase sempre o gestor direto, não o treinamento. 3. **Tempo de Empresa no Sistema** – Usuários que entraram após o Go Live não passaram pelo mesmo treinamento, e seus dados indicam o processo de integração. Quando a diferença entre a equipe de melhor desempenho e a de pior desempenho é superior a duas vezes, o problema é gerencial e não sistêmico, e o investimento correto é na camada gerencial, não em desenvolvimento adicional. ## Baseline: O Erro Irreparável Retroativamente Uma métrica sem um ponto de referência é um número sem significado. O Baseline é medido antes da mudança – mesmo que seja medido manualmente, mesmo que seja estimado. Pergunte: quanto tempo leva hoje para fechar um Case? Quantas oportunidades são atualizadas a tempo? Qual é o desvio da previsão nos últimos três trimestres? Se o Baseline não foi medido antes do lançamento, pode-se recuperá-lo parcialmente de dados históricos, mas não é possível reconstruir métricas comportamentais. Por isso, a medição da adoção é uma decisão da fase de planejamento, não da fase de Go Live. ## Do Diagnóstico à Ação A tabela a seguir mapeia constatações comuns para as ações corretas. A lógica: quase nenhuma constatação de adoção é resolvida com treinamento adicional. | Diagnóstico | Causa Raiz Provável | Ação Recomendada | |---|---|---| | Logins altos, ações-chave baixas | O sistema não está no fluxo de trabalho diário | Incorporação ao processo: alertas, Path, listas de trabalho | | Ações realizadas, mas com semanas de atraso | Não há um ciclo de gestão que dependa do dado | Revisão semanal do Pipeline a partir do Dashboard | | Baixa qualidade em um campo específico | O campo não é relevante ou não é claro | Minimizar, mudar para Picklist ou remover | | Uma única equipe com baixo desempenho | Gestor direto que não é usuário | Trabalho com o gestor, não com a equipe | | Todos os campos preenchidos, mas a gestão não confia | Desajuste entre a métrica e a questão de negócio | Redefinição da métrica de resultado | ## Como Apresentar em um Relatório Mensal Um bom relatório de adoção cabe em uma página: quatro métricas com tendência de três meses, segmentação por equipe, três constatações e três ações com Responsável e data. Sem ações, é um relatório de status; com ações, é uma ferramenta de gestão. A conexão entre a medição e o plano de trabalho organizacional é detalhada em [Gerenciamento de Mudanças do Salesforce](/pt/insights/salesforce-change-management-plan), e o planejamento do treinamento derivado das constatações aparece em [Treinamento Salesforce Baseado em Função](/pt/insights/salesforce-role-based-training). ## Resumo As métricas de adoção não são um boletim de notas para os usuários – elas são um sistema de detecção de falhas no processo. Se a medição não leva a uma mudança no processo, na interface ou na camada de gestão, ela apenas gera trabalho. Comece com quatro métricas, segmente por equipe, estabeleça um Baseline e vincule cada constatação a uma ação com um responsável. ### Perguntas e respostas **Quantas métricas de adoção devem ser medidas?** Entre quatro e seis. Uma métrica de ação principal para cada função-chave, uma métrica de qualidade de dados, uma métrica de velocidade de processo e uma métrica de resultado de negócios. Mais do que isso cria um dashboard que ninguém consulta. **O que fazer quando os dados mostram alta adoção, mas a liderança não está satisfeita?** Quase sempre isso indica que você está medindo atividade em vez de resultado. Verifique se as ações medidas realmente impulsionam o número de negócios — por exemplo, se a atualização de um estágio de negócio melhora a precisão da previsão, ou apenas preenche um campo. **É possível medir a adoção sem uma ferramenta de Analytics dedicada?** Sim. Relatórios e Dashboards padrão com tipos de relatório sobre histórico de campos são suficientes para a maioria das organizações. Uma ferramenta externa é necessária principalmente quando é preciso analisar telas e sequências de cliques no nível do usuário. **Quando medir pela primeira vez após o Go Live?** Duas semanas após o término do período de Hypercare, não antes. Nas primeiras semanas, os números são distorcidos por suporte próximo, correções de dados e entusiasmo inicial. **Como evitar que a métrica se torne um jogo?** Cada métrica quantitativa deve ser acompanhada por uma métrica de qualidade. Se você mede o número de atividades, meça junto a porcentagem de atividades com conteúdo significativo ou link para uma oportunidade. Uma única métrica sempre sofrerá pressão artificial. --- ## 8 Sinais de que Seu Salesforce Existente Precisa de uma Atualização URL: https://hpi.pro/pt/insights/salesforce-system-upgrade-signs Um sistema de CRM raramente falha de uma vez. Ele se desgasta, e quem o utiliza diariamente deixa de perceber. Os oito sinais aqui são mensuráveis sem pesquisa ou consultoria, e cada um aponta para uma raiz diferente: processo, dados, arquitetura ou governança. ## A Resposta Concisa Um sistema requer uma atualização quando o esforço necessário para contorná-lo supera o esforço para operá-lo. Os oito sinais abaixo são manifestações diferentes do mesmo fenômeno, mas cada um aponta para uma raiz distinta – por isso, uma identificação precisa é mais importante do que a mera contagem. ## Os Oito Sinais | # | O Sinal | O que ele revela | | --- | --- | --- | | 1 | Planilhas paralelas para gestão de forecast ou filas | O sistema não é a fonte primária da verdade | | 2 | Relatórios que exibem números conflitantes | Definições de métricas não unificadas ou duplicação de dados | | 3 | Toda solicitação de mudança leva semanas | Débito em automações, falta de ambiente de teste adequado | | 4 | Telas com dezenas de campos que ninguém preenche | Acúmulo de requisitos sem limpeza | | 5 | Carregamento de registros perceptivelmente lento | Trigger duplicado, Flows em cascata, consultas ineficientes | | 6 | Operações manuais repetidas diariamente | Processo não implementado, apenas documentado | | 7 | Permissões concedidas "para fazer funcionar" | Modelo de visibilidade ilógico | | 8 | Conhecimento restrito a uma única pessoa | Ausência de documentação e governança | ## Como Interpretar o Cenário Os sinais são classificados em quatro famílias, o que determina o tipo de intervenção necessária: **Processo (1, 6)** - O sistema foi construído em torno de um processo que não reflete a realidade. A solução envolve um redesenho do fluxo, não apenas desenvolvimento técnico. **Dados (2)** - O problema reside nas definições e na qualidade dos dados, não na ferramenta de relatório. Mais detalhes em [Métricas de Qualidade de Dados Salesforce](/pt/insights/salesforce-data-quality-metrics). **Arquitetura (3, 5)** - Acúmulo de débito técnico em automações e código. Mais informações em [Otimização de Performance Salesforce](/pt/insights/salesforce-performance-optimization). **Governança (4, 7, 8)** - Indefinição sobre o que é implementado, quem tem acesso e quem documenta. Esta família, se negligenciada, anula os efeitos de outras correções. ## O Sinal Mais Evidente Entre os oito, uma planilha paralela utilizada por um executivo sênior para tomadas de decisão é o sinal mais inequívoco. Não é uma queixa; é uma declaração tácita da organização de que o sistema é inadequado. Enquanto essa situação persistir, qualquer melhoria nos relatórios será um esforço em exibições nas quais ninguém confia. ## O que Fazer Antes de Corrigir A tentação é começar pelo sinal mais ruidoso. No entanto, a ordem mais eficiente é diferente: duas semanas de medição dos três sinais mais críticos para estabelecer uma linha de base. Sem isso, mesmo uma correção bem-sucedida não poderá provar seu valor, e o financiamento para a próxima fase não será aprovado. Após a medição, é preciso decidir entre uma correção pontual e um trabalho estrutural, detalhado em [Reconstruir ou Refatorar no Salesforce](/pt/insights/salesforce-rebuild-vs-refactor). ## Resumo Os sinais não são uma lista de reclamações, mas uma ferramenta de diagnóstico: cada um aponta para uma família de causas-raiz diferente, e tratar um sintoma da família errada desperdiça todo um esforço. Três sinais ativos justificam uma análise sistemática; uma planilha paralela na alta gerência justifica-a por si só. ### Perguntas e respostas **Quantos sinais devem estar presentes para justificar uma avaliação?** Três dos oito, ou um de alta intensidade – como relatórios de gestão conflitantes. Um único sinal fraco é geralmente um problema pontual e não sistêmico. **Um grande número de planilhas paralelas sempre indica um problema no sistema?** Quase sempre, mas não necessariamente um problema técnico. Uma planilha nasce quando o sistema não suporta um processo real ou quando é muito lento – duas razões diferentes com soluções distintas. **Qual a diferença entre uma atualização e a manutenção contínua?** A manutenção lida com falhas e solicitações pontuais. A atualização muda a estrutura – modelo, automações ou permissões – para eliminar a causa que gera as solicitações. **É possível identificar os sinais sem acesso ao sistema?** Sim. A maioria é observada de fora: duração de uma reunião manual, número de arquivos enviados por e-mail, tempo para obter uma resposta a uma pergunta de relatório simples. **O que fazer após a identificação?** Meça antes de corrigir. Duas semanas de coleta de dados sobre os três sinais mais fortes fornecem uma linha de base, sem a qual é impossível comprovar melhorias futuras. --- ## Estratégia de Sandboxes e DevOps para Salesforce na Empresa URL: https://hpi.pro/pt/insights/salesforce-sandbox-devops-strategy O caminho para a mudança, do desenvolvimento à produção, é o que determina a segurança da implantação. Este guia detalha os tipos de Sandboxes necessários em cada etapa, como construir um pipeline orientado por código via Git e CI, e como gerenciar configurações manuais em produção. ## A Resposta Curta Uma boa estratégia de ambientes responde a três perguntas: onde cada tipo de trabalho é realizado, como as mudanças avançam e como reverter quando algo falha. A estrutura que funciona para a maioria das organizações é um ambiente Developer para cada desenvolvedor, um ambiente de integração compartilhado, um ambiente UAT com dados representativos e um ambiente de Produção — com o Git como única fonte de verdade e implantação automatizada pelo menos até o UAT. ## Mapa de Ambientes | Ambiente | Tipo | O que acontece | Dados | | --- | --- | --- | --- | | Desenvolvimento Pessoal | Developer | Construção, experimentos, testes de unidade | Apenas Metadados | | Integração | Developer Pro | Mesclagem do trabalho de toda a equipe, CI | Pequena amostra sintetizada | | UAT | Partial ou Full | Aceitação de negócios, treinamento, cenários de ponta | Dados reais mascarados | | Staging / Full | Full | Ensaio geral para Release, testes de volume | Cópia completa mascarada | | Produção | — | Operação contínua | Reais | Um Sandbox para Hotfix é recomendado para organizações cujos releases demoram mais de duas semanas: sem ele, qualquer correção urgente exige a implantação de um trabalho que ainda não está pronto. ## De Change Sets ao Source-Driven A transição ocorre em três etapas. Primeiro, exporta-se os metadados existentes para um repositório (Repo) e estabelece-se uma estrutura e estratégia de ramificação simples — uma branch principal, uma branch de Release e branches de Feature curtas. Em seguida, conecta-se o CI que executa a cada Pull Request Validation Deploy no ambiente de integração, testes Apex e testes estáticos. Na terceira etapa, conecta-se a implantação automática ao UAT, e a implantação para Produção é mantida como uma ação manual aprovada, com uma janela de release definida. O que impede a transição não é a ferramenta, mas a abrangência: tentar incluir toda a Org no Repo de uma vez gera milhares de arquivos que ninguém consegue revisar. É melhor começar com um grupo de metadados de uma única área de negócio e expandir gradualmente. ## O Que Não Entra no Repo Parte do estado não são metadados que podem ser implantados: registros de configuração em Custom Settings e Custom Metadata que dependem do ambiente, valores de Named Credentials, Assignment Rules que mudam frequentemente e conteúdo de Knowledge. Para cada uma dessas categorias, deve haver um documento curto que defina quem atualiza, onde e como sincronizar entre ambientes. A falta dessa definição é a causa mais comum de falhas que aparecem apenas em Produção. A relação entre a velocidade de release e a metodologia de trabalho é detalhada em [Agile vs. Waterfall Híbrido](/pt/insights/salesforce-agile-waterfall-hybrid) e no [Guia de Implementação do Salesforce](/pt/insights/salesforce-implementation-guide). ## Atualização e Manutenção de Ambientes Um Sandbox não atualizado há nove meses já não representa a Produção, e qualquer teste nele dá uma falsa sensação de segurança. A regra simples: o ambiente UAT é atualizado antes de cada Release significativo, os ambientes de desenvolvimento são atualizados ao final de cada sprint. É importante planejar com antecedência o que é perdido na atualização — dados de teste, usuários, configurações — e ter um script Post-Refresh que os restaure em uma hora, e não em três dias. ## Riscos Comuns e Ações Preventivas O primeiro risco é o Drift: lacunas que se acumulam silenciosamente entre a Produção e o Repo. Uma comparação automatizada semanal de metadados com alerta é a única defesa eficaz. O segundo risco são os testes Apex escritos apenas para atingir o limite de cobertura. Uma cobertura de 75% sem Assertions reais não é uma rede de segurança e oferece uma falsa segurança exatamente no momento em que a segurança real é necessária. O terceiro risco é o gargalo humano: uma única pessoa autorizada a implantar. É preciso ter pelo menos duas, com permissões documentadas. ## Como Medir o Sucesso Quatro métricas: frequência de releases, tempo desde a mesclagem até a Produção, taxa de implantações falhas e número de Hotfixes no mês após cada Release. Uma melhoria real se manifesta assim: frequência crescente, tempo decrescente e taxa de falhas e Hotfixes caindo simultaneamente. Um aumento na frequência junto com um aumento nos Hotfixes significa que o caminho é mais rápido, mas os testes são insuficientes. ### Perguntas e respostas **Quantos Sandboxes são realmente necessários?** O mínimo prático para uma organização de médio porte inclui: um Developer Sandbox para cada desenvolvedor, um Developer Pro para integração e um Full ou Partial para UAT e testes de volume. Uma pequena organização pode se contentar com dois, enquanto uma com várias equipes paralelas precisará também de um Sandbox dedicado para Hotfix. **É obrigatório migrar para Git e implantação automática?** Não no primeiro dia, mas sim antes que mais de duas pessoas estejam modificando os metadados. Até lá, Change Sets são suficientes. Além disso, sem uma única fonte de verdade no código, não há como saber quem mudou o quê, e não é possível reverter com segurança. **O que fazer quando alguém alterou algo manualmente em Produção?** Identifique a alteração através de comparações semanais de metadados, traga a mudança para o branch principal como um commit documentado e, se não for desejada, reverta-a. O que não pode acontecer é a alteração permanecer em Produção e não existir no repositório, pois a próxima implantação a sobrescreverá. **Um Full Sandbox contém dados reais? E a regulamentação?** Sim, e, portanto, é necessário aplicar Data Masking antes de conceder acesso amplo. Em ambientes com informações pessoais, a mascaramento ou um Partial Sandbox com uma amostra representativa são a escolha padrão correta, e não um Full Sandbox com uma cópia real. **Quanto tempo leva para configurar um pipeline básico de DevOps?** De quatro a oito semanas: duas semanas para a estrutura do repositório e estratégia de branches, duas semanas para CI e testes automatizados, e o restante para a adoção pela equipe. A parte mais demorada é sempre a mudança de hábitos, não as ferramentas. --- ## Hypercare Pós-Go-Live no Salesforce: Como Estabilizar Sem Criar Dependência URL: https://hpi.pro/pt/insights/salesforce-hypercare-plan O Hypercare não é uma extensão do projeto, mas sim uma ponte planejada para a Operação em Regime Normal (BAU). Estrutura do período de estabilização: composição da equipe, SLAs temporários, triagem diária, critérios de saída mensuráveis e transferência organizada de propriedade para a equipe interna. ## A Resposta Breve O dia após o "Go-Live" não marca o fim do projeto — é a fase em que o verdadeiro impacto do que foi construído se revela. Hypercare é um período planejado em que a equipe que desenvolveu o sistema permanece disponível, resolvendo lacunas rapidamente e, ao mesmo tempo, transferindo a propriedade para a equipe que fará a manutenção. Dois erros opostos devem ser evitados: dispensar esse período e deixar os usuários desamparados, ou estendê-lo indefinidamente, criando uma dependência permanente do fornecedor. Ambos são evitados com a definição prévia de critérios de saída claros. ## O Que Difere Nesse Período | Aspecto | Hypercare | Operações Normais (BAU) | | --- | --- | --- | | Canal de Contato | Direto com a equipe do projeto + presença no local | Fila de suporte regular | | Tempo de Resposta para Incidente Crítico | Até 1 hora | Conforme SLA atual | | Frequência de Liberação de Correções | Diária a bi-diária | Ciclo planejado | | Autoridade de Decisão | Proprietário do processo disponível diariamente | Comitê de Mudanças | | Foco | Estabilização e correção | Melhoria e desenvolvimento | ## A Triagem Diária é o Núcleo Uma reunião de 20 minutos todas as manhãs, em horário fixo, com três perguntas: o que foi aberto ontem, o que está bloqueando o trabalho agora e o que será liberado hoje. Cada solicitação é classificada em quatro categorias: 1. **Incidente Crítico** — Impossível realizar um processo de negócio. Tratamento imediato. 2. **Lacuna de Dados** — Migração ou integração resultou em informações incorretas. Alta prioridade, pois erode a confiança. 3. **Lacuna de Treinamento** — O sistema funciona conforme o planejado, o usuário não sabia. Resposta imediata e registro para atualização de materiais de apoio. 4. **Solicitação de Melhoria** — Para o Backlog, sem implementação durante este período. Essa classificação é a ferramenta central para controlar o escopo: sem ela, toda solicitação parece urgente e o período de estabilização se transforma em uma fase adicional de desenvolvimento. ## Composição da Equipe e Presença no Local Na primeira semana, é essencial uma presença física ou virtual próxima às unidades centrais. Os membros da equipe de projeto trabalham lado a lado com os usuários, observando as falhas em tempo real e corrigindo-as no mesmo dia. O valor da observação direta é muito maior do que relatórios escritos — a maioria dos obstáculos graves nem sequer é relatada. Os representantes de campo que acompanham a equipe são a rede de Champions, por isso recebem treinamento prévio e um canal direto. Detalhes em [Rede de Champions no Salesforce](/pt/insights/salesforce-champions-network). ## Critérios de Saída A saída do Hypercare é uma decisão mensurável. Um conjunto comum de critérios inclui: - Zero incidentes críticos abertos por cinco dias úteis consecutivos. - Redução de 60% ou mais no volume diário de solicitações em comparação com o pico da primeira semana. - Taxa de execução da ação principal por função acima da meta definida. - Os três principais indicadores de qualidade de dados dentro da faixa acordada. - A equipe de suporte interna resolveu de forma autônoma 80% das solicitações na última semana. O último critério distingue entre uma verdadeira transferência de propriedade e um abandono em uma data arbitrária. A medição baseia-se na mesma estrutura descrita em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## Transferência de Propriedade Organizada A transferência começa na primeira semana, e não no último dia. Um mecanismo simples: a partir da segunda semana, a equipe de suporte interna cuida das solicitações primeiramente, e a equipe de projeto acompanha de perto. Cada solicitação resolvida é documentada em uma base de conhecimento interna em três linhas — sintoma, causa, solução. Os produtos da transferência incluem: um documento de arquitetura atualizado, uma lista de integrações com pontos de falha conhecidos, procedimentos de execução periódica, uma lista de dívidas técnicas geradas sob pressão e acessos e permissões operacionais. ## Dependência do Método de Lançamento Em um lançamento "Big Bang", o período de Hypercare é intenso e relativamente curto, com uma equipe grande. Em um lançamento faseado, o período se repete a cada onda, mas em menor escala, com aprendizados de uma onda para a próxima. Essa implicação é uma das considerações na escolha da estratégia — consulte [Big Bang ou Rollout Faseado](/pt/insights/salesforce-big-bang-vs-phased-rollout). ## O Que é Medido Semanalmente Volume diário de solicitações por categoria, tempo médio para resolução de incidentes críticos, porcentagem de solicitações tratadas pela equipe interna e o número de dívidas técnicas abertas. Os três primeiros medem a estabilização; o último impede que o período deixe armadilhas. ## Resumo Planeje o Hypercare como uma fase com orçamento, equipe, triagem diária e critérios de saída numéricos. Classifique cada solicitação, não implemente melhorias nesse período e transfira a propriedade gradualmente a partir da segunda semana. Um sistema estável não é aquele sem falhas, mas sim aquele que a organização sabe corrigir por si mesma. ### Perguntas e respostas **Qual a duração ideal de um período de Hypercare?** De duas a quatro semanas para implementações de médio porte, e de seis a oito semanas para lançamentos multi-site ou com migração de dados complexa. A duração é determinada por critérios de saída, e não apenas por uma data fixa. **Qual a diferença entre Hypercare e suporte contínuo?** No Hypercare, a equipe que construiu o sistema está diretamente disponível, com tempos de resposta ultrarrápidos e correções quase instantâneas. No BAU, as solicitações passam por uma fila de suporte regular com um ciclo de liberação programado. **Quem deve compor a equipe de Hypercare?** Um desenvolvedor ou administrador familiarizado com a implementação, um especialista em processo de negócio autorizado a tomar decisões sobre conteúdo, um representante de migração de dados nas duas primeiras semanas, e um coordenador para gerenciar a triagem diária. **Como evitar que o período de Hypercare se estenda indefinidamente?** Defina critérios de saída numéricos previamente, comunique-os e monitore-os semanalmente. Além disso, transfira gradualmente as solicitações para a fila de suporte regular já a partir da segunda semana. **O que fazer com solicitações de melhorias durante o Hypercare?** Registre-as no Backlog, mas não as implemente. O Hypercare é destinado apenas a falhas e impedimentos. O desenvolvimento de melhorias neste período compromete a estabilidade que ele visa alcançar. --- ## User Stories e Backlog em Projetos Salesforce: Um Guia para Product Owners URL: https://hpi.pro/pt/insights/salesforce-user-stories-backlog O backlog de projetos Salesforce frequentemente falha pelo mesmo motivo: histórias que descrevem telas em vez de resultados e critérios de aceitação escritos após o desenvolvimento. Este guia apresenta uma estrutura de história testável, um método de decomposição por Vertical Slice e uma abordagem de priorização que se mantém mesmo sob pressão. ## A Resposta Curta Uma boa "story" no Salesforce descreve **quem, o que ele tenta alcançar e o que estará certo após a ação** – e não qual campo aparecerá em qual tela. O teste simples: se os critérios de aceitação podem ser escritos sem saber se a implementação será via Flow, Validation Rule ou Apex, a "story" está bem formulada. A falha comum é uma "story" que já contém a solução. No momento em que se escreve "Adicionar campo Picklist à tela da oportunidade", a discussão sobre o processo é encerrada antes mesmo de começar. ## Estrutura Eficiente | Componente | Função | Teste de Qualidade | | --- | --- | --- | | Contexto | Quem é o usuário e quando ele atua | Um papel real, não "usuário" | | Intenção | O que ele tenta alcançar | Expressa na linguagem do negócio | | Critérios de Aceitação | O que será verificado | Pode ser executado como um cenário com dados de teste | | Casos de Canto | O que falha intencionalmente | Pelo menos um negativo | | Fora do Escopo | O que explicitamente não está incluído | Evita discussões na aceitação | A última linha economiza a maioria dos conflitos. Uma declaração explícita de que o que não está incluído realmente não está incluído vale mais do que três parágrafos de descrição. ## Decomposição: "Vertical Slice" em vez de Camadas A tentação em um projeto de CRM é decompor por componentes técnicos – primeiro o modelo de dados, depois as automações, por fim os relatórios. O resultado é que não há nada para mostrar até o fim, e ninguém sabe se o processo funciona. A decomposição correta é vertical: um cenário completo, ponta a ponta, para um perfil de usuário. Uma única oportunidade que é aberta, avança, é fechada e aparece em um relatório – vale mais do que dez objetos definidos sem um processo. Posteriormente, adicionam-se perfis e cenários em torno da mesma estrutura. ## Priorização Quando Tudo é Urgente Três critérios são suficientes, nesta ordem: 1. **Bloqueia a entrada em produção?** – Sem isso, o processo está incompleto. Não há espaço para negociação. 2. **Quantos usuários por dia?** – A frequência supera a intensidade da reclamação. Um item que afeta 80 agentes diariamente tem prioridade sobre um pedido de um único gerente. 3. **Qual o custo da postergação?** – O custo da implementação aumenta se fizermos isso após o lançamento? Uma mudança no modelo de dados sim, uma mudança em um relatório não. O que não passa por esses três vai para o "Parking Lot". Essa separação impede que o Backlog se transforme em um arquivo de desejos. A profundidade da gestão de mudanças de escopo está em [Desvio de Escopo (Scope Creep) e Controle de Mudanças no Salesforce](/pt/insights/salesforce-scope-creep-change-control). ## Débito de Requisitos: A Falha Silenciosa O débito de requisitos surge quando uma "story" é fechada sem que se decida o que acontece em um caso de canto – fica-se com "resolveremos isso depois". Após o lançamento, esses casos de canto são a maioria das chamadas de suporte. A restrição simples: um item não é fechado sem uma decisão documentada para cada pergunta aberta registrada, mesmo que a decisão seja "intencionalmente não tratamos". A documentação da renúncia vale mais do que a ausência de documentação. ## Conexão com os Testes Critérios de aceitação bem escritos são, na verdade, os roteiros de UAT. Quando são escritos após o desenvolvimento, o UAT se torna uma demonstração do que foi construído, em vez de uma verificação do que foi solicitado. A sequência é detalhada no [Guia de UAT para Salesforce](/pt/insights/salesforce-uat-guide). ## Resumo Um Backlog de qualidade não é longo, mas claro: cada item indica para quem se destina, o que será medido como sucesso e o que explicitamente não está incluído. Essas três perguntas, feitas antes da construção e não depois, determinam quase toda a qualidade da aceitação no final do projeto. ### Perguntas e respostas **Qual é o nível de detalhe ideal para uma história antes do início do desenvolvimento?** Detalhada o suficiente para que o desenvolvedor saiba o que construir e o testador saiba o que falharia. Se os critérios de aceitação não puderem ser executados como um cenário de teste, a história ainda não está pronta, mesmo que seja longa. **Quem deve elaborar os critérios de aceitação?** O Product Owner define o que será considerado sucesso, e o testador ou arquiteto adicionam os casos de borda. A elaboração apenas pelo desenvolvedor resulta em um critério que descreve o que foi construído, não o que foi solicitado. **O que fazer com um requisito que é, na verdade, uma pergunta em aberto?** Não é uma história, mas sim um Spike – uma tarefa de investigação com tempo limitado, cujo resultado é uma decisão documentada. Misturar investigação e construção no mesmo item oculta o risco na estimativa. **É necessário usar Story Points em projetos Salesforce?** Estimativas relativas são úteis principalmente para identificar desacordos sobre o escopo. O valor não está na precisão do número, mas na discussão gerada quando as estimativas são muito diferentes. **Como evitar um backlog que cresce para milhares de itens?** Limite a profundidade: o que não for examinado para o próximo trimestre deve ser movido para uma 'Parking Lot' separada. Um backlog que ninguém lê por completo deixa de ser uma ferramenta de priorização e se torna um arquivo. --- ## Scope Creep em Projetos Salesforce: Como Gerenciar Mudanças Sem Paralisar seu Projeto URL: https://hpi.pro/pt/insights/salesforce-scope-creep-change-control Scope Creep não surge de muitas solicitações, mas da falta de um mecanismo para precificá-las em tempo real. Este guia apresenta uma baseline congelada, um formulário de Solicitação de Mudança conciso, um comitê de mudanças com reuniões semanais e um orçamento de alteração pré-alocado — permitindo dizer 'sim' sem perder prazos. ## A Resposta Breve O **Scope Creep** (desvio de escopo) surge quando não há uma distinção nítida entre o que foi prometido e o que foi construído. Três mecanismos podem resolver isso: um **Baseline** documentado e visível para todos; um formulário de solicitação de alteração de meia página que inclua uma estimativa de esforço; e uma regra de substituição, segundo a qual qualquer adição deve deslocar algo de tamanho semelhante ou consumir um orçamento de mudança pré-alocado. Sem esses três elementos, toda "pequena solicitação" desaparece no sprint e só é descoberta na data de entrega. ## Por Que Isso Acontece Justamente no Salesforce O Salesforce é flexível o suficiente para que quase qualquer solicitação pareça ter um custo baixo. Adicionar um campo leva dois minutos, o que dificulta explicar a uma parte interessada por que isso não deveria ser feito. No entanto, o campo envolve validação, permissões, uma coluna em um relatório, mapeamento na migração, uma linha no treinamento e um teste na UAT. O custo real é de cinco a dez vezes maior do que o tempo de construção, e essa é exatamente a diferença que ninguém percebe no momento da solicitação. ## Estrutura de Controle de Quatro Componentes | Componente | O que inclui | Responsável | Resultado | |---|---|---|---| | Baseline Congelada | Lista de capacidades, cenários e item explícito "Fora do Escopo" | Product Owner | Documento assinado ao final do Discovery | | Solicitação de Mudança (Change Request) | Descrição, justificativa de negócio, estimativa de esforço, impacto na data | Solicitante + Tech Lead | Formulário de meia página | | Comitê de Mudanças | Reunião semanal de 30 minutos sobre todas as solicitações abertas | Sponsor, PO, Tech Lead | Decisão: Aprovado / Rejeitado / Para a Próxima Onda | | Orçamento de Mudança | 10%–20% do escopo inicial, alocado no início do projeto | Sponsor | Acompanhamento do saldo semanal | ## O Poder do "Fora do Escopo" Explícito A seção mais importante do documento de Baseline não é o que está incluído, mas sim o que está explicitamente **fora do escopo**. Frases como "a integração com o sistema de folha de pagamento não está incluída na primeira fase" ou "a migração de atividades anteriores a 2022 não está incluída" economizam semanas de discussão. A regra é: qualquer coisa que uma parte interessada possa presumir erroneamente que está incluída deve aparecer na lista de exclusões de forma clara. ## Como Dizer "Sim" Sem Pagar Por Isso Uma rejeição generalizada geralmente resulta em um projeto entregue no prazo, mas que não serve a ninguém. A abordagem eficaz é aceitar cada solicitação para um backlog, precificá-la com transparência e deixar que a parte interessada escolha: iniciar agora às custas de outro item, esperar pela próxima onda ou consumir do orçamento de mudanças. Quando a escolha é transparente, a discussão se torna econômica em vez de emocional — e, na prática, cerca de um terço das solicitações são descartadas assim que o custo é percebido. Mais informações sobre a definição do Baseline podem ser encontradas em [Definição de MVP](/pt/insights/salesforce-mvp-scope) e [Discovery para CRM](/pt/insights/crm-discovery-guide). ## Riscos Comuns e Ações Preventivas O risco principal é um controle excessivamente rígido. Um processo que exige três formulários e duas semanas de espera faz com que as equipes o contornem – e as mudanças continuam, apenas sem documentação. Meia página e uma discussão semanal são o teto prático. O segundo risco é a “deriva técnica”: decisões arquitetônicas tomadas dentro de um sprint que expandem o escopo sem que ninguém as chame de mudança. Por isso, uma mudança arquitetônica significativa também deve passar pelo mesmo comitê. O terceiro risco é um Sponsor ausente: quando não há quem diga “não” com autoridade, toda solicitação recebe um “vamos verificar” – e isso é exatamente o mesmo que um “sim”. ## Como Medir o Sucesso Monitore quatro números em um relatório semanal: número de solicitações abertas, porcentagem aprovada, variação acumulada no projeto em relação ao Baseline e saldo do orçamento de mudanças. Um projeto saudável apresenta uma variação acumulada de até 15% e um saldo positivo do orçamento na fase de UAT. Uma variação acumulada acima de 30% é um sinal de que o Discovery foi superficial, e não que a equipe é indisciplinada. ### Perguntas e respostas **Qual a diferença entre Scope Creep e aprendizado legítimo?** O aprendizado altera a solução dentro do mesmo resultado de negócio; Scope Creep adiciona um novo resultado sem alterar o prazo ou orçamento. O teste prático: se a solicitação surge de algo descoberto no Discovery ou UAT, trata-se de aprendizado. Se surge de um departamento que se juntou tardiamente, é uma expansão. **Quanto do orçamento deve ser alocado para mudanças antecipadamente?** Entre 10% e 20% do orçamento do projeto, dependendo do nível de incerteza. Um projeto com Discovery aprofundado e processos conhecidos pode se contentar com 10%; um projeto que envolve várias unidades de negócio ou migração de um sistema indocumentado está mais próximo de 20%. **Quem está autorizado a aprovar uma mudança?** O Product Owner aprova substituições dentro da Baseline sem alterar data ou custo. O Patrocinador aprova qualquer coisa que afete a data, o orçamento ou o resultado. Uma clara cadeia de autoridade é a defesa mais eficaz contra o Scope Creep. **O que fazer quando o fornecedor alega 'isso não está na proposta'?** Verifique o SOW (Declaração de Trabalho) e a documentação do Discovery. Se for realmente uma expansão, precifique-a como uma mudança; se for uma lacuna criada por uma definição ambígua na proposta, a responsabilidade é compartilhada. A documentação das premissas no contrato evita este argumento desde o início. **O Agile anula a necessidade de controle de mudanças?** Não. O Agile permite trocar itens no Backlog com facilidade, mas o orçamento e os prazos ainda são finitos. O controle de mudanças no Agile é a regra de substituição: cada item que entra empurra para fora um item de tamanho similar. --- ## Ágil, Waterfall ou Híbrido em seu projeto Salesforce? A escolha do modelo de entrega. URL: https://hpi.pro/pt/insights/salesforce-agile-waterfall-hybrid O debate sobre metodologia em projetos Salesforce é quase sempre sobre outra coisa: quantas decisões podem ser adiadas e quanto tempo os usuários realmente têm disponível. Este guia decompõe a escolha em três variáveis cruciais e descreve o modelo híbrido que a maioria das organizações adota na prática. ## A Resposta Breve A escolha não se dá entre duas ideologias, mas sim entre dois tipos de decisões. Existem decisões cujo custo de alteração aumenta exponencialmente com o tempo – modelo de dados, permissões, integrações – e, portanto, precisam ser definidas precocemente. E há decisões cujo custo de alteração é baixo – telas, campos, relatórios, formulações – e estas são melhor descobertas ao longo do processo. Dessa forma, o modelo que funciona na maioria dos projetos Salesforce é híbrido, não por compromisso, mas pela sua estrutura: **uma estrutura fixa e conteúdo iterativo**. ## As Três Variáveis Determinantes | Variável | Impulsiona planejamento prévio | Impulsiona iterações | | --- | --- | --- | | Clareza do Processo | Processo regulamentado e documentado | Processo que muda ou não é acordado | | Disponibilidade do Usuário | Baixa, tempo limitado | Alta, possível revisar semanalmente | | Exposição Regulatória | Auditoria, conformidade, aprovações | Mínima | A segunda variável é mais decisiva do que se costuma assumir. Agile sem disponibilidade de usuários não é Agile – é uma série de sprints em que ninguém revisou nada, e todo o feedback chega de uma vez na UAT. ## O Modelo Híbrido em Ação A abordagem eficaz divide o projeto em duas partes com ritmos distintos: **Fase de Estrutura (4-6 semanas, planejamento)** – Modelo de dados, modelo de permissões e visibilidade, mapeamento de integrações, estratégia de migração e definição dos processos para a primeira onda. Os resultados são documentados e aprovados. **Ondas de Entrega (sprints de duas semanas)** – Cada onda entrega um cenário completo para um perfil de usuário, incluindo testes e feedback. As alterações dentro da onda não exigem nova aprovação, desde que não afetem a estrutura. A regra que sustenta isso: **Uma mudança na estrutura é uma decisão gerenciada; uma mudança no conteúdo é trabalho contínuo.** Sem essa distinção, cada pequena solicitação chega a um comitê diretor e cada mudança estrutural passa despercebida. ## Onde Cada Modelo Falha **Waterfall puro** falha na UAT: a lacuna entre o que foi escrito no documento há seis meses e o que o usuário espera é descoberta tarde demais para uma correção de baixo custo. **Agile puro** falha no modelo de dados: após seis sprints de decisões locais, descobre-se que a estrutura não suporta relatórios entre processos, e a correção exige uma migração. O **Híbrido** falha quando a estrutura não foi realmente fechada – quando é uma "estrutura" no nome, mas é reaberta em cada onda. Nesse caso, obtêm-se as desvantagens de ambos os modelos. ## O Que Medir ao Longo do Caminho Três métricas são suficientes para saber se o modelo está funcionando: a proporção de itens concluídos versus itens reabertos, o tempo do feedback do usuário até a correção, e o número de mudanças que afetaram a estrutura. Um aumento na terceira métrica é o sinal mais precoce de que o planejamento inicial foi superficial. A relação com o gerenciamento de escopo é detalhada em [Aumento do Escopo (Scope Creep) e Controle de Mudanças no Salesforce](/pt/insights/salesforce-scope-creep-change-control), e os cronogramas em [Cronograma de Projeto Salesforce](/pt/insights/salesforce-project-timeline). ## Resumo A pergunta correta não é qual metodologia é mais moderna, mas quais decisões neste projeto serão custosas de alterar posteriormente. Quem consegue responder a isso obtém o modelo de entrega quase automaticamente – e quase sempre é híbrido, com uma fronteira clara entre estrutura e conteúdo. ### Perguntas e respostas **É possível executar Agile verdadeiro quando o orçamento é aprovado antecipadamente como um preço fixo?** Sim, desde que o contrato fixe resultados e não uma lista de itens. Preço fixo versus um Backlog aberto cria uma tensão inerente onde cada mudança se torna uma discussão comercial em vez de profissional. **O que permanece Waterfall mesmo em um projeto ágil?** O modelo de dados, a arquitetura de permissões e o planejamento das integrações. Os três são caros demais para serem alterados tardiamente, portanto são decididos no início, mesmo quando todo o resto é iterativo. **Qual é a duração ideal de um sprint para um projeto Salesforce?** Duas semanas na maioria dos casos. Uma semana não é suficiente para configurar, testar e obter feedback; três semanas atrasam o feedback a ponto de a correção já ser cara. **O que fazer quando os usuários não estão disponíveis para revisões?** Reduza a revisão para 30 minutos e adicione uma decisão documentada: o que não for revisado dentro do prazo será considerado aprovado. A falta de disponibilidade não gerenciada torna-se, posteriormente, uma alegação de 'não foi isso que pedimos'. **A regulamentação exclui o Agile?** Não. Ela exige documentação e aprovações em pontos definidos, e isso se alinha com iterações, desde que o gateway de aprovação seja estabelecido previamente e não adicionado no meio do processo. --- ## Abordagem Big Bang ou Rollout Faseado na Implementação Salesforce? URL: https://hpi.pro/pt/insights/salesforce-big-bang-vs-phased-rollout A decisão é determinada pela interdependência de dados e processos, e não por preferências metodológicas. Este guia aborda a escolha entre lançamento único ou faseado, incluindo o custo de coexistência, riscos de migração e uma matriz de decisão por tipo de organização. ## A Resposta Breve O debate entre Big Bang e Go-Live faseado é frequentemente apresentado como uma questão de risco, mas é, sobretudo, uma questão de dependência. Se duas unidades compartilham o mesmo registro e o mesmo processo, dividi-las em ondas separadas gera um período intermediário caro e propenso a erros. Se as unidades são independentes, não há razão para implementá-las todas juntas. A regra prática: **primeiro, mapeie a dependência; depois, selecione a estratégia.** ## As Duas Abordagens em Resumo Um Go-Live Big Bang implementa todas as unidades em uma única data. A vantagem é a conclusão rápida, uma única fonte da verdade desde o primeiro dia e custo zero no período intermediário. A desvantagem é a concentração de riscos: qualquer erro afeta todos no mesmo momento, e a recuperação é complexa. Um Go-Live faseado implementa uma unidade ou processo em cada onda. A vantagem é o aprendizado de onda para onda, risco limitado e uma equipe que melhora progressivamente. A desvantagem é uma duração de projeto mais longa, desgaste organizacional e um período prolongado em que dois sistemas coexistem em paralelo. ## Mapeamento de Dependências — O Teste Decisivo | Pergunta | Resposta que Leva ao Big Bang | Resposta que Leva a Fases | | :------ | :--------------------------- | :------------------------ | | O mesmo registro é tratado por duas unidades? | Sim, continuamente | Não, com custo claro | | O processo transita entre departamentos? | Sim, de ponta a ponta | Processos separados | | O relatório gerencial unifica todos? | Sim, diariamente | Relatório por unidade | | É possível sincronizar bidirecionalmente a um custo razoável? | Não | Sim | | As unidades compartilham o mesmo catálogo de produtos e preços? | Sim | Não | Três ou mais respostas na coluna da esquerda — dividir em fases custará mais do que economizará. ## Custo da Coexistência Este é o item que decide muitas escolhas, mas que frequentemente é esquecido no planejamento. Um período intermediário inclui: sincronização bidirecional entre Salesforce e o sistema legado, geração de relatórios unificados de duas fontes, suporte para dois ambientes, treinamento dobrado para usuários que operam ambos, e tratamento de conflitos de atualização. Uma estimativa realista varia entre 10% e 25% do orçamento do projeto, e aumenta à medida que o período se estende. Se o plano inclui um ano de coexistência, deve-se considerar seriamente se encurtar o período justifica o risco adicional de uma implementação mais ampla. ## Riscos de Migração em Cada Abordagem No Big Bang, a migração é um evento único, de grande porte, em uma janela de tempo curta. Exige simulações completas (Mock Cutover) e um plano de reversão comprovado. Em um Rollout faseado, a migração se repete em cada onda, mas em menor escala — e cada vez é preciso decidir o que acontece com os registros que afetam unidades ainda não implementadas. Em ambos os casos, a qualidade dos dados é o fator decisivo para o dia do Go-Live. Detalhes de planejamento estão disponíveis no [Guia de Implementação do Salesforce](/pt/insights/salesforce-implementation-guide). ## Matriz de Decisão por Tipo de Organização | Contexto | Recomendação | Principal Justificativa | | :------- | :----------- | :---------------------- | | Até 150 usuários, processo unificado | Big Bang | Custo da Coexistência supera o risco | | Múltiplos sites ou países | Fases por site | Diferenças regulatórias e de processo | | Diversos departamentos com processo comum | Core comum e então fases | Evita sincronização bidirecional | | Data limite para término de contrato existente | Big Bang com escopo reduzido | Não há tempo para período intermediário | | Organização sem experiência prévia com Salesforce | Primeira fase pequena | Construção de capacidade interna | | Migração complexa de múltiplas fontes | Fases | Dispersão do risco de dados | ## A Abordagem Híbrida que Funciona na Prática A maioria das grandes implementações bem-sucedidas combina: uma camada de Core uniforme — modelo de dados, clientes, permissões, relatórios básicos — que entra em Go-Live para toda a organização de uma vez; sobre ela, fases por unidade para os processos específicos. Dessa forma, evita-se a sincronização bidirecional dos dados comuns, mantendo-se, ao mesmo tempo, o aprendizado gradual. A escolha do escopo mínimo para a primeira fase é uma decisão em si, e é detalhada na [Definição de MVP no Salesforce](/pt/insights/salesforce-mvp-scope). Em grandes organizações, as implicações são mais amplas e discutidas na [Implementação do Salesforce em Grandes Empresas](/pt/insights/enterprise-salesforce-implementation). ## Implicações para o Período de Estabilização A estratégia também define a estrutura de Hypercare: no Big Bang, é necessária uma equipe grande para um período intensivo e curto; em fases, é necessária uma equipe menor que se repete em cada onda e acumula conhecimento. Em ambos os casos, são necessários critérios de saída definidos, conforme detalhado no [Hypercare Pós Go-Live](/pt/insights/salesforce-hypercare-plan). ## Conclusão Mapeie as dependências entre unidades antes de discutir a metodologia, precifique o período de Coexistência em números, e escolha com base no contexto: uma organização pequena com processo unificado optará pelo Big Bang; uma organização multi-site optará por fases; e a maioria das organizações de médio porte se beneficiará de um Core comum seguido de fases. ### Perguntas e respostas **Qual é o fator decisivo na escolha entre as duas abordagens?** O grau de interdependência entre as unidades. Quando um processo transita entre departamentos e o mesmo registro é tratado em ambos, a divisão em fases exige sincronização bidirecional, o que pode ser dispendioso e, por vezes, favorece a abordagem Big Bang. **Qual o custo de um período de coexistência?** Geralmente entre 10% e 25% do orçamento do projeto: sincronização bidirecional, duplicidade de relatórios, suporte a dois sistemas e confusão do usuário. Este é o item mais subestimado na decisão por fases. **A primeira fase deve ser com a maior equipe?** Não. A primeira fase deve abranger uma unidade suficientemente representativa para aprendizado, mas pequena o suficiente para se recuperar de possíveis erros. Uma unidade de 20 a 50 usuários com um processo completo é uma boa escolha. **Quando o Big Bang é a escolha correta?** Quando se trata de uma organização com até aproximadamente 150 usuários, um processo uniforme, migração controlada e uma data-limite rígida devido ao término de contrato de um sistema anterior. Nessas condições, o custo da coexistência supera o risco do lançamento único. **É possível combinar as abordagens?** Sim, e essa é a escolha mais comum na prática: um lançamento "Core" uniforme para toda a organização de uma só vez, seguido por fases, por unidade, para os módulos e processos específicos. --- ## ROI em Projetos Salesforce: Como Definir e Medir o Valor Real URL: https://hpi.pro/pt/insights/salesforce-roi-kpis A maioria dos cálculos de ROI para projetos de CRM é elaborada apenas uma vez, para a aprovação orçamentária, e raramente revisited. Este guia propõe uma metodologia diferente: quatro tipos de valor medidos de forma distinta, uma linha de base definida antes do lançamento, e regras de atribuição que evitam vincular qualquer melhoria de negócio exclusivamente ao sistema. ## A Resposta Breve O Retorno sobre Investimento (ROI) de um projeto Salesforce não é um número único, mas sim a confluência de quatro fluxos de valor distintos: eficiência operacional, receita, risco e custo de sistemas. Amalgamar esses fluxos em um único valor resulta em uma afirmação impossível de provar ou refutar. **Regra prática:** Monitore no máximo seis métricas, cada uma com um *baseline* estabelecido antes da entrada em operação e sob a responsabilidade de um gestor que não seja o desenvolvedor do sistema. ## Os Quatro Fluxos de Valor | Fluxo | Exemplo de Métrica | Quando Medido | Nível de Certeza | | --- | --- | --- | --- | | Eficiência Operacional | Minutos por atendimento; Tempo de preparação de proposta | Primeiro trimestre | Alta | | Receita | Taxa de *win rate*; Valor médio da negociação; Tempo de ciclo de vendas | 2-3 ciclos de vendas | Média | | Risco e Conformidade | Resultados de auditoria; Exposição de permissões | Anualmente | Baixa quantitativamente, alta em impacto | | Custo de Sistemas | Licenças canceladas; Interfaces removidas | Imediatamente após a desativação | Muito alta | O último fluxo, embora frequentemente o mais simples de comprovar, é muitas vezes negligenciado. A desativação de dois sistemas auxiliares e uma interface representa um custo unívoco na fatura, sem a necessidade de premissas. ## Baseline: O Ponto Que Determina a Viabilidade da Medição Sem uma medição prévia, qualquer discussão pós-lançamento pode se tornar uma disputa de memória. Um *baseline* adequado requer três elementos: uma definição escrita de como a métrica é calculada, uma fonte de dados que permaneça disponível mesmo após a transição, e um horizonte de tempo suficientemente longo para cobrir a sazonalidade. O erro comum é medir o *baseline* apenas a partir do sistema legado. Se 40% do trabalho é realizado em planilhas, o *baseline* medido parecerá melhor do que a realidade, e a melhoria observada será menor que a real. Uma estimativa manual documentada é preferível a um dado preciso de uma fonte incompleta. ## A Regra de Atribuição Após um lançamento bem-sucedido, há a tentação de atribuir todo e qualquer avanço ao novo sistema. Três filtros ajudam a mitigar essa tendência: 1. **Filtro de Causalidade** – Existe um mecanismo explicável que conecta uma mudança no sistema a uma variação na métrica? Se não, trata-se de correlação. 2. **Filtro do Grupo de Controle** – Um grupo que ainda não fez a transição apresenta a mesma tendência? Se sim, a causa é externa. 3. **Filtro de Volume** – A métrica aumentou ou a atividade aumentou? A normalização por volume elimina a maioria das ilusões. Quem está disposto a declarar "esta melhoria não é nossa" ganha credibilidade mesmo quando reivindica uma melhoria que realmente lhe pertence. ## O Lado dos Custos: O Que é Omitido no Cálculo O custo do projeto não se resume ao valor do contrato. O cálculo completo inclui licenciamento por três anos, um percentual anual de manutenção e alterações (na prática, 15%-25% do custo de implementação), tempo interno de colaboradores em reuniões, UAT e treinamento, além do custo da operação paralela durante o período de transição. Um cálculo que ignora o item de manutenção apresenta um rápido retorno no primeiro ano e um prejuízo no segundo. Detalhes sobre estruturas de custos são apresentados em [Custo de Implementação do Salesforce](/pt/insights/salesforce-implementation-cost). ## O Que Medir no Primeiro Trimestre No primeiro trimestre, o valor de negócio mensurável ainda não é evidente. Portanto, medimos indicadores de desempenho (*leading indicators*) em vez de resultados: a proporção de processos executados no sistema em vez de externamente, a qualidade dos dados nos campos que alimentam os relatórios, e o número de solicitações de alteração que indicam uma lacuna processual. Esses três fatores predizem se o valor será gerado. Métricas de adoção detalhadas são apresentadas em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## Conclusão Um ROI confiável é construído a partir da separação entre valor comprovado (sistemas desativados) e valor estimado (receita), de um *baseline* coletado a tempo, e da disposição em renunciar a atribuições que não resistem a uma análise rigorosa. Um modelo modesto e consistente é mais valioso do que uma grande promessa que ninguém mais verificará. ### Perguntas e respostas **Quando a linha de base (baseline) deve ser medida?** Antes que o novo sistema impacte qualquer processo – geralmente na fase de descoberta. Uma linha de base coletada após o lançamento já está 'contaminada' pela mudança de comportamento e não serve para comparação. **Como diferenciar o impacto do sistema do impacto do mercado?** De três maneiras: comparando com um grupo de controle ainda não impactado, normalizando pelo volume de atividade, e focando em métricas de processo (tempo de ciclo, taxa de retrabalho) que são menos suscetíveis às flutuações da demanda. **A economia de tempo de um colaborador é considerada ROI?** Somente se o tempo liberado for direcionado a uma atividade mensurável ou se evitar a contratação de pessoal adicional. Dez minutos por dia economizados por um colaborador que mantém a mesma função e produtividade não representam uma economia de fluxo de caixa. **Qual é o prazo razoável para o retorno?** Em um projeto de médio porte, as métricas de processo mudam em um trimestre, as métricas de receita em dois a três ciclos de vendas, e o retorno financeiro completo é geralmente medido em 18 a 30 meses, incluindo o custo operacional contínuo. **O que está incluído no custo que a maioria das empresas esquece?** Licenciamento contínuo, manutenção e alterações pós-lançamento, tempo interno dos colaboradores no projeto e treinamento, e o custo de integrações que continuam a exigir atenção. Ignorá-los cria um ROI que só parece bom no papel. --- ## RFP para Implementação Salesforce: Estrutura, Perguntas Essenciais e Entregáveis Indispensáveis URL: https://hpi.pro/pt/insights/salesforce-rfp-guide Um RFP que detalha uma lista de requisitos geralmente recebe em troca uma lista de promessas. Um documento de solicitação bem elaborado, por outro lado, descreve processos, volumes e decisões em aberto — e força cada fornecedor a demonstrar sua linha de raciocínio. Apresentamos aqui uma estrutura de documento em nove partes, as perguntas que distinguem os fornecedores e o que exigir como entregáveis na proposta. ## O que um bom documento de RFP deve gerar O objetivo de uma RFP (Request for Proposal) não é obter apenas um preço, mas sim receber **propostas comparáveis** que permitam identificar qual fornecedor compreendeu verdadeiramente o problema. Um documento que lista cem requisitos e solicita marcações de "suporta / não suporta" atinge o efeito oposto: todos os fornecedores marcam "suporta", e a decisão se resume ao preço. Uma diferença prática: em vez de escrever "o sistema deve permitir o gerenciamento de oportunidades", descreva que a empresa gerencia cerca de quatrocentas transações por mês, que cada transação passa por uma aprovação de precificação, e que essa aprovação é atualmente feita por e-mail. Os fornecedores apresentarão respostas muito distintas – e é exatamente isso que se busca. ## As nove seções de um documento de RFP para Salesforce **1. Contexto e Objetivo de Negócio.** O que a organização faz, qual é o problema e o que será considerado sucesso em um ano. Uma seção de um parágrafo a uma página. **2. Situação Atual.** Sistemas em uso, número de usuários, o que funciona hoje e o que não funciona. Se já existe um ambiente Salesforce, especifique a edição, tempo de uso e nível de personalização. **3. Processos Essenciais no Escopo.** Três a sete processos, cada um em um parágrafo: quem executa, quais são os pontos de decisão, o que acontece quando algo foge do padrão. **4. Volumes e Dados.** Número de registros para cada entidade principal, taxa de criação mensal, anos de histórico a serem mantidos e o estado conhecido da qualidade dos dados. Esta é a seção que mais impacta a precisão da precificação e que, com frequência, é ignorada. **5. Integrações.** Para cada sistema: nome, tipo de interface (se conhecido), direção, frequência requerida e quem é o proprietário na organização. **6. Restrições.** Regulamentação, segurança da informação, localização do armazenamento, idiomas, acessibilidade, prazos inegociáveis. **7. O que é Requerido do Proponente.** Abordagem proposta, plano de ondas, composição da equipe com nomes e funções, premissas, riscos e precificação em uma estrutura padronizada. **8. Método de Avaliação.** Critérios e pesos, divulgados antecipadamente. Isso gera propostas mais focadas e reduz discussões após a seleção. **9. Cronograma da Solicitação.** Prazo para perguntas, prazo para respostas, prazo para submissão, prazo para demonstrações, prazo para decisão. ## Dados Essenciais a Revelar para Ter uma Precificação Realista | Dado | Por que é crítico | O que acontece sem ele | | --- | --- | --- | | Número de usuários por tipo | Define licenciamento, treinamento e permissões | Propostas com um intervalo de preços muito amplo | | Volume de registros e histórico | Define o esforço de migração | A migração é precificada com uma estimativa grosseira | | Número de sistemas de origem | Define a complexidade e a integração | Surpresas após a assinatura do contrato | | Nível de documentação existente | Define o nível de descoberta necessário | Fornecedores presumem documentação existente | | Disponibilidade dos proprietários de processo | Define o ritmo das decisões | Um cronograma irreal é acordado por ambas as partes | | Orçamento ou faixa de valores | Foca a solução | Propostas incomparáveis | ## Perguntas que Distinguem Fornecedores As perguntas a seguir recebem respostas muito diferentes de diversos fornecedores, e por isso são úteis. Uma pergunta à qual todos respondem de forma idêntica não vale a pena ser incluída no documento. - Quais são as três principais premissas nas quais esta proposta se baseia, e qual o impacto se uma delas estiver incorreta? - Em quais casos você recomendaria configuração, mesmo que desenvolvimento funcionasse melhor, e vice-versa? - Descreva um projeto no qual vocês excederam o cronograma. O que causou isso e o que mudaram desde então? - Quem serão os membros reais da equipe, e qual a porcentagem do tempo que cada um dedicará a este projeto? - O que vocês precisam de nós para ter sucesso, e o que farão se não receberem isso? - Como vocês nos transferirão a capacidade de manter o sistema sem a sua dependência? A última pergunta é um bom teste para a natureza do engajamento. Um fornecedor que a evita planeja criar dependência. ## O Que Exigir Como Entregáveis na Proposta - **Um diagrama de arquitetura inicial** em nível de blocos, incluindo fontes de verdade. - **Um plano de ondas** com o conteúdo de cada onda, e não apenas datas. - **Uma detalhamento de precificação em estrutura unificada** que você definir, por fase e por função. - **Uma lista explícita de premissas.** - **Um mapa de riscos** com estratégias de mitigação. - **Um exemplo de entregável real** de um projeto anterior, com nomes omitidos — por exemplo, um documento de decisões ou um plano de testes. O último item é talvez o mais distintivo, pois mostra um padrão de trabalho e não apenas uma promessa. ## Estrutura de Precificação Unificada — A Ferramenta que Impede a Comparação de "Maçãs com Laranjas" Defina você mesmo a tabela que todo proponente deve preencher: | Fase | Horas Sênior | Horas Júnior | Custo | O que é considerado concluído | | --- | --- | --- | --- | --- | | Levantamento | | | | | | Configuração e Desenvolvimento para a Onda 1 | | | | | | Integrações | | | | | | Migração de Dados | | | | | | Testes e UAT | | | | | | Treinamento e Adoção | | | | | | Estabilização Pós-Go-Live | | | | | | Gerenciamento de Projetos | | | | | Um fornecedor que se recusa a detalhar o preço de acordo com esta estrutura não é necessariamente mais caro, mas não pode ser comparado, e essa é uma razão suficiente para exigir essa informação. ## Exemplo Ilustrativo: Fundo de Previdência Médio Porte O cenário é hipotético e serve para ilustração. Uma instituição financeira emitiu uma RFP que incluía oitenta requisitos funcionais em uma tabela. Os quatro proponentes marcaram "suporta" em quase todas as linhas, e as propostas diferiam apenas no preço e no número de horas. Em uma segunda rodada, o documento foi alterado: em vez da tabela de requisitos, foram incluídos três processos detalhadamente descritos, dados de volume reais e uma solicitação para resolver um cenário específico em uma demonstração. As propostas recebidas diferiram substancialmente — uma propôs um modelo de dados completamente diferente, outra identificou uma dependência de aprovação regulatória que ninguém havia considerado. O comitê não optou pela proposta mais barata e não a questionou. Escolheu aquela que conseguiu explicar por que o sétimo requisito no documento original não era necessário de forma alguma. ## Erros Comuns na Redação de RFPs - Copiar um documento de outro projeto sem ajustar volumes e processos. - Exigir uma lista de clientes em vez de exemplos de entregáveis. - Critérios de avaliação formulados após o recebimento das propostas. - Um cronograma que não deixa tempo para perguntas e respostas. - Uma preferência oculta por um fornecedor existente, o que faz com que outros invistam em vão e prejudica a qualidade das propostas futuras. ## O Que Acontece Após a Submissão Um bom documento é apenas metade do trabalho. A próxima etapa é a normalização e comparação das propostas em uma base comum, conforme detalhado no [Guia de Comparação de Propostas Salesforce](/pt/insights/compare-salesforce-proposals), e então a pontuação estruturada de acordo com pesos predefinidos, conforme detalhado no [Guia de Scorecard para Seleção de Fornecedores](/pt/insights/salesforce-vendor-scorecard). A base de informações para a redação do documento geralmente provém de um breve processo de consultoria, como descrito no [Guia de Consultoria Salesforce](/pt/insights/salesforce-consulting-guide), e os critérios para a avaliação da empresa estão agrupados no [Guia para Escolher uma Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Próximo Passo Antes de enviar o documento, faça um teste: peça a alguém na organização que não esteja envolvido no projeto para lê-lo e explicar em uma frase qual é o problema que você está tentando resolver. Se essa pessoa não conseguir, os fornecedores também não conseguirão — e eles simplesmente apresentarão o que estão acostumados a vender. ### Perguntas e respostas **Quantos fornecedores devem ser convidados para um RFP de implementação Salesforce?** Três a cinco. Menos de três não oferece uma base de comparação adequada, e mais de cinco gera uma carga excessiva de avaliação, levando a comissão a focar no preço em vez do conteúdo. Se houver mais candidatos qualificados, é preferível realizar uma rodada de triagem breve com base em um questionário conciso antes de enviar o documento completo. **É necessário divulgar o orçamento no RFP?** É preferível divulgar uma faixa ou um limite. A divulgação evita propostas irrelevantes e permite que os fornecedores proponham uma divisão em fases dentro do limite. A não divulgação geralmente leva os fornecedores a precificar o que eles imaginam que será aprovado, em vez do que é necessário para resolver o problema. **O que fazer se os fornecedores fizerem perguntas que revelam lacunas no documento?** Publique todas as perguntas e respostas para todos os proponentes simultaneamente e atualize o documento, se necessário. Uma boa pergunta de um fornecedor é um indicador positivo; portanto, é útil documentar quem perguntou o quê – é uma das melhores métricas para avaliar a profundidade de seu entendimento. **É aconselhável solicitar uma demonstração ao vivo como parte do RFP?** Sim, mas não uma demonstração de produto padrão. Peça ao proponente para resolver um cenário breve e real de sua empresa e explicar suas escolhas de implementação. Uma demonstração de produto padrão mostra o que o Salesforce pode fazer, uma informação que não diferencia os fornecedores; a resolução de um cenário demonstra como o fornecedor pensa. **Quanto tempo deve ser concedido aos fornecedores para apresentar uma proposta?** Três a quatro semanas para um projeto médio, incluindo uma rodada de perguntas e respostas no meio do prazo. Um prazo muito curto gera propostas baseadas em modelos, que são exatamente o que você está tentando evitar. Se o cronograma for apertado, é melhor reduzir o escopo das informações exigidas na proposta do que o tempo de preparação. --- ## Como comparar propostas para um projeto Salesforce sem cair no preço mais baixo URL: https://hpi.pro/pt/insights/compare-salesforce-proposals Uma oferta 30% mais barata quase sempre é uma oferta diferente, não uma oferta melhor. Uma comparação correta começa com a normalização: mesmo escopo, mesmo período de garantia, mesmos componentes ocultos. Apresentamos um método de normalização em seis etapas, um mapa de custos ausentes na proposta e um modelo de comparação de custo total de três anos. ## Por Que Propostas de Salesforce Quase Nunca São Comparáveis Ao comparar três propostas e notar uma diferença de dezenas de pontos percentuais, a primeira reação é pensar que uma delas está inflacionada. Na maioria dos casos, a razão é mais simples: cada proposta precifica um projeto diferente. Um fornecedor incluiu a migração de três anos de histórico, enquanto outro considerou apenas um ano. Um incluiu seis semanas de estabilização pós-implantação, o outro entregou e finalizou. Um contou quatro integrações, o outro apenas duas, pois assumiu um relatório diário em vez de uma interface em tempo real. Nenhum deles agiu de má-fé — simplesmente não foram instruídos de outra forma. A comparação, portanto, começa pela normalização, não por uma tabela de preços. ## Método de Normalização em Seis Etapas **1. Estabeleça uma lista padronizada de componentes.** Onze itens são suficientes: Análise de Requisitos, Configuração, Desenvolvimento, Integrações, Migração, Testes, Treinamento, Gestão de Projeto, Estabilização, Documentação, Transferência de Conhecimento. **2. Para cada proposta, indique o que está incluído, o que é parcial e o que está faltando.** Não preencha valores nesta fase. **3. Precifique o que está faltando.** Para cada componente não incluído em uma proposta, use o custo de outra proposta como estimativa e adicione-o. **4. Alinhe as premissas.** Número de usuários, edição, anos de histórico, número de unidades de negócio, idiomas. **5. Alinhe o período de garantia.** Períodos diferentes equivalem a dinheiro. Uma diferença de dois meses de estabilização é um componente de custo real. **6. Calcule o custo médio por hora e a composição da equipe** em cada etapa, não apenas no total. Somente após essas seis etapas é possível comparar os números. Em muitos casos, a proposta que parecia mais barata passa para a segunda posição. ## Os Componentes Que Desaparecem das Propostas — e Aparecem na Fatura | Componente | Por Que Foi Omitido | Ordem de Grandeza Relativa | | --- | --- | --- | | Limpeza de Dados Pré-Migração | Considerado responsabilidade do cliente | Por vezes, muito significativa | | Segunda Rodada de UAT | Assume-se uma rodada única | Baixo, mas pode bloquear o cronograma | | Treinamento por Função | Precificado como um único workshop | Médio | | Suporte Aprimorado nas Primeiras Semanas | Não definido | Médio a Alto | | Documentação de Propriedade da Organização | Considerado óbvio | Baixo, fundamental posteriormente | | Tratamento e Monitoramento de Erros de Integração | Inclui apenas o "caminho feliz" | Médio | | Ambientes e DevOps | Assume-se que existe | Baixo a Médio | | Horas de Gestão Interna da Organização | Não incluído na proposta | Alto, e sempre presente | A última linha é aquela que surpreende a diretoria. Um projeto Salesforce consome tempo significativo dos _process owners_ e do PMO, e este é um custo real, mesmo que não apareça em nenhuma fatura. ## Da Comparação de Preços à Comparação de Custos Trienais Uma proposta é avaliada corretamente em um período de três anos, não apenas sobre o projeto. Uma estrutura de cálculo simples: | Componente | Ano 1 | Ano 2 | Ano 3 | | --- | --- | --- | --- | | Custo de Implementação | Total | — | — | | Licenciamento | Por número de usuários | Inclui crescimento esperado | Inclui crescimento esperado | | Manutenção e Suporte | Parcial | Total | Total | | Melhorias Planejadas | — | Escopo estimado | Escopo estimado | | Custo de Gestão Interna | Alto | Médio | Médio | A diferença entre as propostas no primeiro ano pode parecer grande. Em um período de três anos, o que geralmente determina é quão fácil será modificar o sistema sem o fornecedor — ou seja, a qualidade da documentação e da transferência de conhecimento, que quase nunca são ponderadas na decisão. ## Bandeiras Vermelhas em uma Proposta - Migração de dados precificada com um valor redondo, sem questionamento sobre volume ou qualidade. - Ausência de período de garantia, ou definida como "tratamento de _bugs_" sem especificação do que constitui um _bug_. - Proposta que inclui apenas horas de desenvolvimento e não tem uma linha para gestão de projeto. - Composição da equipe sem nomes, ou nomes que não são contratualmente obrigatórios. - Preço excepcionalmente baixo para a fase de Análise de Requisitos, que às vezes é uma "porta de entrada" para um projeto que será precificado posteriormente. - Ausência de premissas explícitas. Uma proposta sem premissas não foi devidamente examinada. ## Exemplo Ilustrativo: Uma Empresa de Energia Renovável O cenário é hipotético e serve apenas para ilustração. Uma empresa recebeu três propostas. A diferença entre a mais barata e a mais cara era de cerca de oitenta por cento. O comitê tendia à mais barata. Após a normalização, ficou claro: a proposta mais barata não incluía migração de dados, apenas a importação de registros de atividade; assumia duas integrações em vez de quatro, pois acreditava que o relatório financeiro seria feito por exportação manual; e o período de garantia era de duas semanas, comparado a oito semanas na proposta mais cara. Após a complementação dos custos faltantes com base nos outros proponentes, a diferença diminuiu para cerca de dez por cento. A decisão final não foi baseada no preço, mas na questão de quem oferecia uma transferência de conhecimento estruturada, pois a empresa não possuía equipe interna. ## O Que Fazer com a Diferença Restante Após a normalização, geralmente resta uma diferença real. Transforme-a em perguntas, não em suposições: - Por que sua estimativa para integração é menor que a dos outros — o que vocês sabem que eles não sabem? - O que acontece se a suposição sobre a qualidade dos dados não estiver correta? - Quantas rodadas de teste vocês planejaram? - Quem da equipe apresentada acompanhará o projeto do início ao fim? As respostas a essas perguntas distinguem um fornecedor que precificou baixo por ser eficiente de um fornecedor que precificou baixo por não ter compreendido completamente o escopo. ## A Conexão com a Decisão Final Uma comparação estruturada aborda apenas o lado comercial. O lado técnico é pontuado separadamente, de acordo com pesos predefinidos, e o preço é apenas um deles — os detalhes estão no [Guia para Escolher uma Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). A compreensão do que constitui o custo de antemão está detalhada no [Guia de Custo de Implementação Salesforce](/pt/insights/salesforce-implementation-cost), e a escolha do modelo de engajamento no [Guia de Precificação de Projetos](/pt/insights/salesforce-project-pricing-models). O que foi acordado na comparação deve constar no contrato com uma redação precisa, caso contrário, não existe — as cláusulas relevantes estão agrupadas no [Guia de Contrato e SOW Salesforce](/pt/insights/salesforce-sow-contract-clauses). ## Próximo Passo Construa a tabela de normalização antes de abrir os envelopes de preço. Quem a constrói depois de ver os valores, constrói-a — involuntariamente — de forma a justificar a proposta que já lhe agradou. ### Perguntas e respostas **Uma diferença de 40% entre as propostas para Salesforce — o que isso geralmente significa?** Quase sempre significa que as propostas se referem a escopos diferentes, e não que um fornecedor é uma vez e meia mais eficiente. As diferenças comuns incluem a migração de dados que foi ou não incluída, o número de integrações contadas, o período de estabilização pós-implantação e o treinamento. Antes de negociar o preço, é importante garantir que esses três pontos sejam definidos da mesma forma em todas as propostas. **Como comparar propostas com uma composição de equipe diferente?** Calcule um custo médio por hora e observe a proporção sênior-júnior em cada etapa. Uma proposta com uma taxa horária baixa e uma equipe composta apenas por juniores pode exigir mais horas para o mesmo trabalho. O que importa é quem realmente irá liderar as decisões de arquitetura e qual percentual do seu tempo é alocado para o projeto. **É aconselhável pedir aos fornecedores para corrigirem a proposta após a comparação?** Sim, uma rodada de esclarecimentos é uma prática comum e útil. Envie a cada proponente as diferenças que você identificou apenas em seu escopo, sem expor os preços dos outros, e solicite uma proposta atualizada com a mesma estrutura. Essa rodada geralmente reduz significativamente a diferença entre as propostas e revela quem realmente entendeu o projeto. **O que fazer quando a proposta mais barata vem de um fornecedor mais fraco?** Traduza a diferença para dinheiro em vez de discuti-la como uma sensação. Uma estimativa realista de uma rodada adicional de correções, de atrasos no cronograma e de horas adicionais de gerenciamento interno gera um número que pode ser comparado. Geralmente, a diferença comercial diminui significativamente após essa tradução. **O custo da licença Salesforce está incluído na proposta do integrador?** Geralmente não, e é adquirido separadamente. É importante garantir que todos os proponentes tenham assumido a mesma edição e o mesmo número de usuários, pois uma suposição diferente também altera o escopo do trabalho: um recurso disponível em uma edição superior pode exigir desenvolvimento em uma edição inferior. --- ## Contrato e SOW para Projetos Salesforce: Cláusulas Essenciais para Proteger a Entrega URL: https://hpi.pro/pt/insights/salesforce-sow-contract-clauses A maioria dos conflitos em projetos Salesforce não se trata de preço, mas sim do que é considerado "concluído". Um bom SOW define aceitação, dependências mútuas, propriedade de entregáveis e uma saída ordenada. Apresentamos doze cláusulas com redação recomendada e a explicação prática de como cada uma mitiga riscos. ## O Que Realmente Fragiliza Projetos de Salesforce Contratualmente Quase nenhuma disputa em um projeto Salesforce começa com a pergunta "quanto custa". Ela começa com a pergunta "está finalizado?". O fornecedor acredita que o produto foi entregue; a organização acredita que não está utilizável. Ambas as partes estão certas dentro de suas próprias percepções, pois ninguém definiu previamente o que seria considerado concluído. Daí se deriva um princípio que orienta todas as seções deste artigo: **um bom contrato não protege sua parte em uma disputa — ele previne a disputa.** ## Doze Cláusulas Essenciais ### 1. Definição de Aceitação para Cada Entrega A cláusula mais importante. Para cada entrega, é necessário um critério observável: não "tela de gerenciamento de clientes", mas sim "usuário no perfil X pode realizar o cenário Y e obter o resultado Z, conforme definido nos critérios de aceitação aprovados". Redação recomendada: um período de teste definido a partir da data de entrega, ao final do qual o cliente aprova ou detalha por escrito as lacunas. O silêncio após o período é considerado aceitação — uma cláusula que protege o fornecedor e gera disciplina no cliente. ### 2. Mecanismo de Solicitação de Mudança Define quem pode solicitar, quem avalia, em quanto tempo e por qual tarifa. A tarifa deve ser estabelecida na assinatura do contrato e não no momento da necessidade. ### 3. Dependência Bidirecional A maioria dos contratos define o que acontece quando o fornecedor atrasa, mas não o que acontece quando o cliente atrasa. Resultado: quando a organização atrasa uma aprovação, o fornecedor absorve o impacto — e depois o repassa através de solicitações de mudança. Redação equilibrada: o cronograma está condicionado à receptividade definida do cliente (tempo de aprovação, disponibilidade do proprietário do processo, entrega de dados), e um atraso excedente realoca o marco mediante notificação por escrito. ### 4. Propriedade do Código, Configuração e Documentação Separação entre entregas personalizadas e componentes genéricos do fornecedor, com licença de uso vitalícia para os componentes genéricos, não condicionada à continuidade do relacionamento. ### 5. Documentação Como Entrega Obrigatória A documentação que não é definida como uma entrega com critérios de aceitação — não será escrita, ou será escrita na última semana. Defina o mínimo: decisões arquitetônicas, modelo de dados, mapeamento de integrações, procedimentos operacionais. ### 6. Garantia e Correção de Defeitos Um período definido, e uma distinção clara entre defeito e mudança. Uma definição que funciona: uma lacuna entre o comportamento real e os critérios de aceitação aprovados é um defeito. ### 7. Profissionais Chave Nomes, percentual de alocação, aviso prévio para substituição e nível profissional equivalente com aprovação do cliente. ### 8. Acessos, Ambientes e Segurança da Informação Quem tem acesso a quais ambientes, por quanto tempo, o que acontece com os acessos ao término e como os dados reais são tratados em ambientes que não são de produção. ### 9. Conformidade com Requisitos Regulatórios e de Privacidade Local de armazenamento, tratamento de dados pessoais, direito de auditoria e comunicação de incidentes de segurança. Em organizações regulamentadas, esta é uma cláusula que exige redação específica e não um modelo padrão. ### 10. Portas de Decisão e Pontos de Saída Direito de interromper ao final de um marco definido, com um acordo de pagamento pré-determinado. Uma cláusula como esta reduz o risco de ambas as partes, e por isso um bom fornecedor não se oporia a ela. ### 11. Transferência de Conhecimento Não "treinamento", mas sim: número de horas, para quem, sobre o quê e qual a entrega. É desejável que a transferência ocorra ao longo do projeto e não se concentre apenas no final. ### 12. Finalização e Transição Lista do que será entregue, formato, período de transição e tarifa para horas de suporte na transição. Esta é a cláusula que ninguém quer discutir no momento da assinatura, e é exatamente por isso que vale a pena insistir nela. ## Mapa de Risco: O Que Cada Cláusula Previne | Cláusula | Falha Prevenida | Custo da Ausência | | --- | --- | --- | | Definição de Aceitação | Discussão sobre "finalizado" | Atraso no pagamento e na entrada em operação | | Pedidos de Mudança | Precificação em crise | Custo adicional descontrolado | | Dependência Bidirecional | Acusações mútuas sobre atraso | Ajuste de cronograma sem transparência | | Propriedade e Documentação | Dependência do fornecedor | Alto custo na troca de fornecedor | | Profissionais Chave | Troca silenciosa de equipe | Perda de relacionamento e conhecimento | | Garantia | Discussão de defeito vs. alteração | Pagamento duplo por correção | | Saída | Negociação em posição de fraqueza | Custo de transição inesperado | ## Redações a Serem Evitadas - "O fornecedor realizará o trabalho com a profissionalidade usual" — não pode ser aplicada sem um critério. - "As partes concordarão posteriormente sobre..." — cada cláusula como esta é uma disputa futura em potencial. - "Sujeito à cooperação total do cliente" — sem definir o que isso significa, é uma proteção unilateral. - "A entrega será realizada ao final do projeto" — sem definir o que é o final. - Cronograma de pagamentos baseado em datas de calendário em vez de aceitação. ## Exemplo Ilustrativo: Rede de Varejo O cenário é hipotético e destinado à ilustração. Uma rede varejista assinou um SOW que incluía "migração de dados de clientes de um sistema existente". A suposição da organização era que a migração incluía a limpeza de duplicatas; a suposição do fornecedor era que ele migraria o que lhe foi entregue. Na prática, centenas de milhares de registros com duplicatas foram migrados. Ambas as partes leram a mesma frase e a entenderam de forma oposta. Não havia no contrato uma linha que definisse o que era considerado um registro válido. A correção feita nos acordos subsequentes dessa rede foi esta: um anexo que define um limiar de qualidade mensurável para o carregamento — taxa de registros que passam por validação, regras de identificação de duplicatas e quem aprova. Este anexo substituiu dezenas de horas de discussão. ## O Que Verificar Antes de Assinar - Cada entrega da proposta aparece no SOW com um critério de aceitação. - Toda suposição apresentada na proposta aparece como uma suposição explícita no contrato. - O cronograma de pagamentos está vinculado à aceitação. - Há uma cláusula de saída e uma cláusula de transferência de conhecimento. - A definição de defeito é clara o suficiente para decidir um caso ambíguo. O que foi acordado na comparação das propostas, mas não foi incluído no contrato — simplesmente não existe. O processo de comparação em si está detalhado no [Guia de Comparação de Propostas Salesforce](/pt/insights/compare-salesforce-proposals), e a base para a formulação dos requisitos é estabelecida já no documento de solicitação, conforme detalhado no [Guia de RFP](/pt/insights/salesforce-rfp-guide). ## A Conexão com a Seleção do Fornecedor Algumas das cláusulas aqui também servem como ferramentas de avaliação: um fornecedor que se opõe a uma cláusula de propriedade da documentação ou a uma cláusula de saída está dizendo algo sobre seu modelo de trabalho. A combinação de avaliação profissional e prontidão contratual é pontuada em conjunto no [Guia de Scorecard para Seleção de Fornecedores](/pt/insights/salesforce-vendor-scorecard), e os critérios amplos para a avaliação da empresa estão resumidos no [Guia de Escolha de uma Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). A adequação do tipo de contratação ao tipo de serviço adquirido está detalhada no [Guia de Serviços Salesforce](/pt/insights/salesforce-services-guide). ## Próximo Passo Pegue o SOW que você tem em mãos e marque todos os locais onde está escrito "será entregue" ou "será executado" sem que esteja ao lado como se saberá que isso aconteceu. Cada marcação dessas é uma disputa potencial, e cada uma delas leva cinco minutos para ser corrigida agora. ### Perguntas e respostas **Qual a diferença entre um Acordo Master e um SOW em um projeto Salesforce?** O Acordo Master regula as relações jurídicas: confidencialidade, responsabilidade, seguro, propriedade intelectual, condições de pagamento e resolução de disputas. O SOW regulamenta o trabalho em si: entregáveis, marcos, aceitação, premissas e escopo. O mesmo Acordo Master pode servir para múltiplos SOWs, o que é uma estrutura conveniente ao trabalhar em fases (ondas). **A quem pertence o código e a configuração desenvolvidos em um projeto Salesforce?** Isso é definido exclusivamente no contrato. A regra padrão em alguns fornecedores é que o produto final desenvolvido pertence ao cliente, mas os componentes genéricos e a infraestrutura do fornecedor permanecem de sua propriedade, sob uma licença de uso. É crucial garantir que essa licença seja ilimitada no tempo e não dependa da continuidade do relacionamento, caso contrário, a troca de um fornecedor pode gerar um problema. **Qual é um período de garantia razoável após a entrada em produção?** Entre trinta e noventa dias, dependendo da complexidade. Mais importante do que a duração é a definição: o que é considerado um defeito a ser corrigido sem custo versus uma solicitação de mudança. A formulação prática é que qualquer discrepância entre o comportamento real e os critérios de aceitação aprovados é um defeito, e todo o resto é uma mudança. **Como redigir uma cláusula que proteja contra a substituição da equipe do fornecedor?** Nomeie os membros da equipe-chave e a porcentagem de sua alocação, exigindo aviso prévio e substituição por profissionais de nível equivalente, com aprovação do cliente. Além disso, é aconselhável definir um período mínimo de transição. Tal cláusula não impede a saída, mas a transforma de uma surpresa em um processo gerenciado. **O que deve ser incluído em uma cláusula de rescisão contratual?** Uma lista de entregáveis a serem fornecidos, o formato da entrega, um período de transição, a transferência de acessos e ambientes, e o custo das horas de suporte para a transição. Sem tal cláusula, a rescisão do contrato se torna uma negociação em posição de fraqueza, pois o conhecimento e os acessos estão com a outra parte. --- ## Scorecard para Seleção de Fornecedores Salesforce: Critérios e Pesos URL: https://hpi.pro/pt/insights/salesforce-vendor-scorecard Um comitê de seleção sem um modelo de pontuação acordado quase sempre chega a uma decisão justificada a posteriori. Um Scorecard predefinido estabelece o que é medido, qual evidência é necessária para cada pontuação e o que desqualifica imediatamente. Apresentamos um modelo de sete dimensões com pesos de exemplo e um processo de pontuação que evita vieses. ## Por que comitês tomam decisões acertadas, mas as justificam de forma inadequada Em uma reunião de decisão típica, após três apresentações, os participantes frequentemente expressam frases como "Fiquei impressionado com eles" ou "Eles pareceram os mais profissionais". Às vezes, a escolha é acertada. O problema é que não há como saber — e não há como justificar a decisão um ano depois, quando o projeto enfrenta desafios. Um *scorecard* não se destina a substituir o discernimento. Ele visa garantir que todos os proponentes foram avaliados pelos mesmos critérios, que a evidência para cada pontuação foi documentada, e que o que o comitê considerou importante *antes* das apresentações também prevaleceu *depois*. ## As sete dimensões de avaliação **1. Compreensão do Problema.** A proposta aborda seus processos e volumes, ou é genérica? O proponente identificou alguma inconsistência ou lacuna no documento de solicitação? **2. Qualidade da Proposta Arquitetônica.** Há um diagrama? As fontes da verdade foram definidas? As alternativas foram consideradas e o motivo da rejeição foi explicado? **3. Equipe Real.** Quem lidera? Quanto tempo dedica? Quem executa? Qual a proporção de profissionais sêniores nas fases de decisão? **4. Experiência Relevante.** Não o número de projetos, mas a similaridade: indústria, complexidade de integração, porte e regulamentação. **5. Modelo de Trabalho e Governança.** Frequência das demonstrações, gerenciamento de decisões, gerenciamento de riscos e método de lidar com mudanças. **6. Transferência de Conhecimento e Autonomia.** Há um plano explícito que lhes permitirá manter a solução sem o fornecedor? **7. Comercial.** Preço normalizado, modelo de engajamento, flexibilidade contratual e disposição para cláusulas de proteção. ## Exemplos de Pesos – e Como Ajustá-los | Dimensão | Projeto novo em organização sem equipe | Projeto de Recuperação | Expansão em organização com equipe forte | | --- | --- | --- | --- | | Compreensão do Problema | 20% | 25% | 15% | | Arquitetura | 20% | 20% | 25% | | Equipe Real | 15% | 20% | 15% | | Experiência Relevante | 10% | 10% | 10% | | Modelo de Trabalho e Governança | 10% | 10% | 10% | | Transferência de Conhecimento | 10% | 5% | 5% | | Comercial | 15% | 10% | 20% | A tabela ilustra um princípio: os pesos não são fixos, mas derivados do risco dominante. Em uma organização sem equipe interna, a transferência de conhecimento vale mais. Na recuperação de um projeto, a compreensão da situação e a identidade da equipe valem mais. Estabeleçam os pesos **antes** de receber as propostas e publiquem-nos no documento de solicitação (RFP), conforme detalhado no [Guia de RFP para Salesforce](/pt/insights/salesforce-rfp-guide). ## Escala de Pontuação com Evidência Necessária O problema com a escala de 1 a 5 é que todos pontuam 4. A solução é associar cada nível a uma evidência: | Pontuação | Significado | Evidência Requerida | | --- | --- | --- | | 1 | Não atende | O tópico não aparece na proposta | | 2 | Genérico | Texto padrão sem referência à organização | | 3 | Satisfatório | Referência correta, mas sem profundidade ou alternativas | | 4 | Bom | Referência específica com justificativa e exemplo | | 5 | Excelente | Alternativas consideradas, risco identificado e recomendação contra algo solicitado | A evidência para a pontuação 5 é o que torna o modelo útil: um fornecedor que diz "esta parte não deve ser construída agora" demonstra uma compreensão que não pode ser falsificada. ## Critérios de Desqualificação – Antes de Pontuar Existem aspectos que não faz sentido ponderar, pois são desqualificantes: - Recusa em ceder a propriedade dos entregáveis e da documentação à organização. - Recusa em nomear os membros da equipe e suas porcentagens de alocação. - Não cumprimento de requisitos regulatórios ou de segurança da informação obrigatórios. - Proposta que não atende à estrutura de precificação definida, após oportunidade de correção. - Indisposição para uma cláusula de saída básica. Definam-nos de antemão. Uma desqualificação decidida *a posteriori* sempre parecerá direcionada contra um proponente específico. ## Processo de Pontuação que Reduz Vieses 1. Cada membro do comitê pontua **individualmente** antes da discussão conjunta. 2. A pontuação é acompanhada por uma breve anotação que cita a fonte na proposta. 3. A discussão foca apenas em grandes discrepâncias entre os avaliadores — é onde a informação está. 4. O preço é revelado nesta etapa e não antes, se o processo permitir. 5. A pontuação final é documentada juntamente com a justificativa. O quarto passo é o mais impactante. Um comitê que viu os preços antes de pontuar a qualidade quase sempre pontuará a qualidade de acordo com o preço, muitas vezes sem perceber. ## Exemplo Ilustrativo: Uma Empresa de Segurança Comercial O cenário é hipotético e destinado à ilustração. Um comitê de seleção pontuou quatro proponentes. A proposta que recebeu a pontuação mais alta na dimensão "Experiência Relevante" recebeu a pontuação mais baixa na dimensão "Compreensão do Problema", pois o documento apresentado era quase idêntico a um documento que havia sido enviado por eles para outro projeto, incluindo o nome de um setor irrelevante. Na discussão, surgiu o argumento de que a experiência compensava. O comitê então revisitou os pesos estabelecidos dois meses antes, nos quais a compreensão do problema tinha o dobro do peso da experiência. A decisão permaneceu inalterada. O que o modelo evitou aqui não foi necessariamente uma escolha errada, mas sim a mudança das regras do jogo depois que o resultado já era conhecido. ## O Que Fazer com o Resultado A pontuação não é a decisão. É um documento que facilita uma conversa produtiva: onde a lacuna entre os proponentes é grande, o que falta na proposta do líder e qual risco permanece em aberto. Muitas vezes, o resultado mais útil é uma lista de condições para o contrato, e não a escolha entre fornecedores. A parte comercial é normalizada separadamente antes da pontuação, conforme detalhado no [Guia de Comparação de Propostas Salesforce](/pt/insights/compare-salesforce-proposals), e a relação entre a estrutura de custos e a pontuação comercial é explicada no [Guia de Custos de Implementação Salesforce](/pt/insights/salesforce-implementation-cost). ## Integração com a Entrevista Técnica A pontuação baseada em documentos é limitada. Um complemento essencial é uma reunião onde o fornecedor é questionado com perguntas abertas e sua forma de pensar é observada em tempo real. Uma lista completa de perguntas está disponível no [Guia de Perguntas Antes de Escolher um Integrador Salesforce](/pt/insights/questions-before-choosing-salesforce-integrator), e os critérios gerais para avaliar a empresa no [Guia de Como Escolher uma Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Próximo Passo Definam seus pesos no papel antes de ler a primeira proposta e permitam que cada membro do comitê pontue individualmente. Essas duas etapas, que levam aproximadamente uma hora juntas, alteram a qualidade da decisão mais do que qualquer rodada adicional de apresentações. ### Perguntas e respostas **Que peso atribuir ao preço na seleção de fornecedores Salesforce?** Em projetos onde o resultado depende principalmente da qualidade das decisões, um peso de vinte a trinta por cento é comum e suficiente. Um peso maior transforma a escolha em uma decisão de preço, e um peso muito baixo desconecta a decisão da realidade orçamentária. Mais importante que o peso é que o preço pontuado seja normalizado para o mesmo escopo. **Quem deve fazer parte do comitê de seleção?** Um representante de compras, o responsável pelo processo principal, um especialista em tecnologia que manterá o sistema e um representante financeiro. O tamanho típico é de quatro a seis pessoas. Um comitê maior tende a gerar uma pontuação média que não diferencia entre os proponentes, por isso é preferível incluir outros como consultores em vez de avaliadores diretos. **As entrevistas com clientes anteriores realmente valem a pena?** Sim, se as perguntas forem feitas corretamente. Perguntas sobre satisfação geram respostas polidas. Perguntas que geram informações relevantes são: o que deu errado e como o fornecedor reagiu, quem foi o gerente de projeto e o que ele fez, e o que você faria diferente. É preferível pedir feedback sobre um projeto complexo em vez de um projeto modelo. **O que fazer quando dois fornecedores recebem pontuação quase idêntica?** Não adicione um novo critério a posteriori, pois é exatamente onde preferências pessoais são inseridas. A ferramenta correta é uma rodada focada: o mesmo cenário breve para ambos, a mesma pergunta sobre gestão de riscos e uma avaliação da equipe em ação. A diferença que emerge é geralmente mais clara do que qualquer tabela. **É preferível um fornecedor grande ou uma boutique em um projeto Salesforce?** A resposta depende do tipo de risco que o preocupa. Um fornecedor grande oferece profundidade de recursos e continuidade, geralmente a um custo mais alto e com menor flexibilidade. Um fornecedor boutique oferece contato direto com executivos e flexibilidade, com o risco de dependência de indivíduos. Ambos os riscos podem ser pontuados explicitamente, em vez de decidir com base na percepção do tamanho. --- ## Limites de API no Salesforce: Projetando Integrações para Volume e Recuperação URL: https://hpi.pro/pt/insights/salesforce-api-limits-resilience O Salesforce contabiliza chamadas de API em janelas de 24 horas e, ao ultrapassar o limite, simplesmente bloqueia – não desacelera. Uma organização que executa sincronização noturna, Webhook de entrada e relatórios simultaneamente precisa de um orçamento de chamadas planejado, não apenas de uma nova tentativa após o esgotamento da cota. Este guia detalha os limites em vigor: como medir o consumo, quando mudar para a API de Lotes (Bulk API) e como construir um Backoff que não inunde o sistema em uma segunda onda de falhas. ## O Que Quebra Primeiro Quando Ignoramos Limites de API Uma empresa que executa três integrações simultaneamente – uma sincronização ERP noturna, um Webhook de um sistema de pagamento e um painel externo que busca dados a cada cinco minutos – não falha gradualmente. Ela funciona perfeitamente até ultrapassar um limite, e então cada chamada de API adicional é rejeitada com o código `REQUEST_LIMIT_EXCEEDED` até o reinício diário. Não há um aviso prévio integrado que evite isso antecipadamente – existe apenas um Dashboard que pode ser consultado, se alguém tiver construído um processo para verificá-lo. Essa falha difere da maioria das falhas em projetos Salesforce porque não depende de código ruim ou design falho. Ela depende do acúmulo: uma nova integração é sempre construída considerando o status atual, sem verificar quanto do orçamento diário já foi consumido pelos processos existentes. O resultado é que a quinta integração "quebra" as quatro anteriores, embora nenhuma delas tenha sido alterada. ## O Mapa de Limites Realmente Relevante Nem todo Limite existente no Salesforce é igualmente importante para o planejamento de integrações. Aqueles que realmente definem a arquitetura são: | Tipo de Limite | O que ele mede | Quem ele afeta primeiro | | --- | --- | --- | | Requisições de API Diárias | Total de requisições REST/SOAP em 24 horas | Qualquer integração síncrona de alta frequência | | Batches de Bulk API | Número de Batches abertos/diários | Processos noturnos de Batch que inserem dados históricos | | Requisições Concorrentes de Longa Duração | Chamadas em execução por mais de 20 segundos simultaneamente | Relatórios pesados ou lógicas complexas de Apex assíncronas | | Entrega de Platform Event | Volume de eventos por dia por assinatura | Arquiteturas Event-Driven entre Salesforce e sistemas externos | | Linhas SOQL por Transação | Linhas buscadas em uma única transação (50.000) | Lógica Apex que executa consultas dentro de um loop | Esta tabela não é uma documentação genérica – é uma ordem de prioridades. Uma organização que planeja uma nova integração deve verificar primeiro as duas primeiras linhas, pois são as que realmente são bloqueadas em produção. Os demais limites afetam principalmente o desempenho, não a disponibilidade. ## Orçamento de Chamadas: Como Construí-lo Corretamente A principal ferramenta para evitar bloqueios não é o monitoramento pós-fato, mas um orçamento predefinido para cada consumidor de API. O princípio é: cada sistema externo, cada Usuário de Integração e cada processo agendado recebe uma alocação definida da cota total, e não "o quanto for necessário". A construção do orçamento envolve três etapas: 1. **Mapeamento de Consumidores** – Uma lista de todos os processos que chamam a API: integrações externas, Apex Agendado, Data Loader manual, ferramentas de BI. Cada um tem um Usuário de Integração separado para que o consumo possa ser isolado no Event Monitoring. 2. **Cálculo da Carga com Base no Volume de Negócios, não em Presunção** – Quantos registros são processados por dia, quantas chamadas são necessárias por registro (incluindo a busca de Related Lists) e o que acontece nos picos (final de trimestre, Black Friday, fechamento de mês). 3. **Alocação de Reserva** – Não se divide 100% da cota entre os processos existentes. Deixa-se 15%-20% como reserva para processos de emergência, relatórios ad-hoc e manutenção – caso contrário, qualquer pequena adição empurra a organização para uma violação. Quem deseja aprofundar no design da camada que gerencia esse orçamento em nível de plataforma deve ler o [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide), onde é apresentada a divisão entre a camada de integração e a camada de negócios. ## REST vs. Bulk: Quando a Transição Compensa O erro mais comum é usar a API REST normal para tráfego de dados de alto volume, porque é o que é construído primeiro e funciona em Provas de Conceito (PoCs). O problema surge quando o volume aumenta: REST conta cada requisição (até 200 registros em Composite) como uma chamada separada em relação à cota, enquanto Bulk API 2.0 executa lotes de até 10.000 registros e é contabilizado com um custo significativamente menor por registro. Uma regra prática: se um único processo atualiza mais de 2.000 registros em uma única execução, a transição para Bulk API quase sempre compensa – mesmo que isso signifique alterar o código do consumidor para trabalhar assincronamente com *polling* no status do Job, em vez de uma resposta imediata. O custo é uma latência maior (minutos em vez de segundos), e, portanto, Bulk não é adequado para processos que exigem decisão em tempo real, como verificação de inventário antes da aprovação de um pedido. ## Backoff e Retry: Prevenindo a Auto-Sobrecarga Quando uma chamada de API falha devido a um bloqueio de limite, a resposta instintiva da maioria das equipes é tentar novamente imediatamente. Este é exatamente o comportamento que transforma um bloqueio temporário em uma falha contínua: se dez processos tentarem novamente no mesmo instante, eles empurram o sistema mais profundamente para o bloqueio, em vez de permitir que ele se recupere. Um mecanismo de Backoff adequado requer três componentes juntos: - **Exponential Backoff** – O tempo de espera entre as tentativas aumenta exponencialmente (por exemplo, 2, 4, 8, 16 segundos), e não permanece constante. - **Jitter** – Uma pequena adição aleatória ao tempo de espera, para que processos paralelos não tentem novamente no mesmo segundo e criem uma nova onda de carga. - **Circuit Breaker** – Após um certo número de falhas consecutivas (por exemplo, cinco), o processo para de tentar completamente por um período fixo e reporta ao monitoramento, em vez de continuar "batendo na porta". Sem um Circuit Breaker, um processo que é executado a cada cinco minutos e falha consistentemente continuará a tentar cem vezes por dia e consumir cota apenas para falhas – isso é exatamente o oposto do que o mecanismo deveria prevenir. Detalhes adicionais sobre o tratamento de erros em nível de integração são apresentados em [Gerenciamento de Erros de Integração no Salesforce](/pt/insights/salesforce-integration-error-handling). ## Estudo de Caso: Varejo com Três Pontos de Integração Suponhamos uma rede de varejo de médio porte, com aproximadamente 40 filiais, que opera o Salesforce Service Cloud integrado a um sistema de PDV e um sistema ERP para controle de estoque. Três integrações estão ativas: sincronização de estoque a cada 15 minutos do ERP (cerca de 8.000 itens SKU), um Webhook do PDV para cada transação que falha (cerca de 300 por dia) e um painel externo para o Power BI que busca dados de serviço a cada hora. No mês em que a rede adicionou um novo programa de fidelidade, uma quarta integração foi inserida: a verificação de pontos de crédito em tempo real do Salesforce a partir de cada caixa, adicionando cerca de 6.000 chamadas por dia. Em duas semanas, a sincronização de estoque começou a falhar por volta das 14:00-15:00, o horário de pico dos caixas. A equipe verificou inicialmente o ERP e pensou que o problema estava lá, mas o log do Salesforce mostrou `REQUEST_LIMIT_EXCEEDED` exatamente nesse período. A solução não foi comprar cota adicional, mas sim mudar as prioridades: a verificação de pontos de crédito passou a usar o Platform Cache para resultados que não mudam frequentemente, o que reduziu as chamadas em cerca de 70%, e a sincronização de estoque mudou de REST para Bulk API com execução a cada 30 minutos em vez de 15. O resultado: a mesma cobertura de negócios, consumo de cota 45% menor e uma reserva real para o próximo crescimento. ## Riscos e Ações Preventivas Específicas | Risco | Como ele se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Nova integração não verificada em relação ao orçamento existente | Bloqueio aparece apenas após a implantação em produção | Exigência de Revisão de Capacidade (Capacity Review) para toda nova integração antes do Go Live | | Retry sem Backoff | Bloqueio temporário se torna uma falha de horas | Exponential Backoff com Jitter e Circuit Breaker em todo consumidor de API | | Uso de REST para grandes volumes | Um único processo consome dezenas de porcento da cota diária | Transição para Bulk API acima de um limite de volume predefinido | | Ausência de separação de Integration Users | Impossibilidade de saber qual integração consome a cota | Usuário de Integração dedicado para cada sistema externo, monitorado separadamente | | Falta de reserva no orçamento | Qualquer pequena adição leva à violação | Alocação de 15%-20% da cota como reserva permanente, não atribuída a processos diários | ## Checklist Antes de Adicionar uma Nova Integração - ☐ É conhecido o percentual da cota diária consumido atualmente, por Integration User. - ☐ O volume de pico (não o volume médio) da nova integração foi verificado. - ☐ Foi decidido usar REST vs. Bulk API com base no limite de volume, não na conveniência de desenvolvimento. - ☐ Existe um mecanismo de Backoff com Jitter e Circuit Breaker no código do consumidor. - ☐ Foi configurado um alerta quando o consumo da cota diária excede 70%. - ☐ O uso possível de Platform Cache para reduzir chamadas repetidas foi verificado. - ☐ Há uma reserva de 15%-20% da cota que não foi previamente alocada. - ☐ Um Proprietário operacional foi definido para receber o alerta, e não apenas um log técnico. ## Como Monitorar no Dia a Dia A medição confiável requer a combinação de três fontes: Event Monitoring (ou Shield Event Monitoring) para o consumo real de API por usuário, Apex Limits no próprio código (`Limits.getLimitApiRequests()`) para verificação local em tempo de execução, e o Dashboard integrado em Company Information que exibe o consumo versus a cota em nível de organização. Nenhuma das três é suficiente sozinha: a primeira mostra tendências, a segunda previne falhas dentro de um único processo, e a terceira serve como um panorama diário para a equipe de operações. Uma métrica a ser acompanhada ao longo do tempo não é apenas "quanto foi consumido", mas "qual a taxa de crescimento mensal do consumo" – pois é isso que permite prever quando a organização atingirá o limite, em vez de reagir depois que o bloqueio já ocorreu. Quando há vários sistemas interdependentes, vale a pena examinar também o padrão geral de integração em relação à [integração Salesforce com sistemas ERP](/pt/insights/salesforce-erp-integration), e a questão da implementação – Flow vs. Apex – que também afeta a eficiência das chamadas, em [Salesforce Flow ou Apex](/pt/insights/salesforce-flow-vs-apex). ## Resumo Os Limites de API do Salesforce não são um problema que se resolve no momento em que é descoberto – eles são uma variável que deve fazer parte de cada decisão de integração desde o primeiro dia. Um orçamento de chamadas documentado por Integration User, uma escolha consciente entre REST e Bulk com base no volume, e um mecanismo de Backoff que previne a auto-sobrecarga – esses três juntos são o que diferencia uma organização que descobre o problema quando já está bloqueada, de uma organização que o vê se aproximando com um mês de antecedência e age a tempo. ### Perguntas e respostas **Quantas chamadas de API uma organização recebe no Salesforce e como isso é atualizado?** A cota diária é derivada do tipo de edição e do número de licenças, sendo reiniciada a cada 24 horas em um horário fixo, não à meia-noite do servidor. O complemento 'Chamadas de API Adicionais' adiciona pacotes fixos se for necessário mais, mas resolve apenas o curto prazo – se o consumo aumentar com cada nova integração, o problema é arquitetônico e não quantitativo. **Qual a diferença prática entre a API REST padrão e a API de Lotes (Bulk API) no contexto dos Limites?** A API REST contabiliza cada chamada separadamente em relação à cota diária, de modo que a atualização sequencial de 50.000 registros pode consumir dezenas de porcento do orçamento. A API de Lotes 2.0 funciona em lotes e é contabilizada de forma significativamente mais barata por registro, mas é assíncrona – o código de consumo precisa ser adaptado para polling sobre o status da tarefa e não para esperar uma resposta imediata. **O que fazer ao receber um erro REQUEST_LIMIT_EXCEEDED no meio de um processo de negócios crítico?** Interrompa a thread solicitante, não tente novamente imediatamente com a mesma intensidade. Implemente o Exponential Backoff com Jitter, envie a solicitação para uma fila de espera e alerte a equipe de operações se o bloqueio persistir além de um limite predefinido. Um processo que continua tentando em uma taxa constante apenas prolonga o bloqueio e põe em risco outros processos que compartilham a mesma cota. **As Platform Events ou o Change Data Capture são contados na cota da API?** Eventos distribuídos via Platform Events e sua recepção via CometD não são contados como chamadas de API normais, sendo, portanto, uma maneira eficiente de transmitir atualizações em tempo real sem consumir do orçamento diário. No entanto, qualquer chamada REST que o consumidor faz em resposta a um evento – por exemplo, a recuperação dos detalhes completos do registro – é contada. Portanto, vale a pena considerar incluir os campos necessários no corpo do próprio evento. **Como saber antecipadamente que uma nova integração excederá os limites da organização?** Execute uma previsão simples: volume diário de registros multiplicado por chamadas por registro (incluindo Registros Relacionados e Lookups que são recuperados separadamente), e compare com o que resta após as integrações existentes. Se o resultado exceder 70%-80% da cota total, é preciso planejar Bulk, Caching ou redução de campos antes de ir para produção – não depois do primeiro bloqueio. --- ## Arquitetura Orientada a Eventos no Salesforce: Platform Events e Change Data Capture URL: https://hpi.pro/pt/insights/salesforce-event-driven-architecture Platform Events e CDC resolvem um único problema: a dissociação entre sistemas que não precisam esperar um pelo outro. O problema começa quando a seleção entre eles é baseada na conveniência técnica, e não em quem é o proprietário dos dados, qual o nível de confiabilidade necessário e o que acontece quando uma mensagem chega duas vezes ou não chega de forma alguma. ## A escolha que, na verdade, não é sobre tecnologia Quando uma organização começa a discutir Arquitetura Orientada a Eventos no Salesforce, a conversa tende a se inclinar rapidamente para "Platform Events ou CDC?", como se fosse puramente uma questão de ferramenta. No entanto, o cerne da questão é completamente diferente: que lado da integração é a fonte da verdade, o que pode ser perdido, e quem arca com o custo quando uma mensagem chega atrasada, em duplicidade ou não chega de todo. A resposta concisa: Change Data Capture (CDC) é adequado quando um sistema externo precisa saber que o Salesforce atualizou um registro, e isso não exige o encapsulamento de lógica de negócios. Platform Events personalizados são ideais quando se deseja publicar um evento de negócios significativo – "cliente fez upgrade de plano", não "o campo Status_c foi alterado". A escolha inadequada não se manifesta no dia do lançamento; ela se revela quando alguém precisa reconstruir o que aconteceu após uma falha parcial, e descobre que não há um caminho confiável para obter essa informação. Aqueles que buscam uma visão mais abrangente das integrações Salesforce além dos eventos encontrarão informações úteis no [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide). ## Três perguntas que definem a arquitetura antes de escrever uma linha de código Antes de selecionar um mecanismo, três perguntas precisam ser respondidas. Pular qualquer uma delas é a causa mais comum de projetos de integração que empacam na fase de testes. **Quem é o proprietário dos dados?** Se o Salesforce é a fonte da verdade para o registro do cliente, eventos de saída do Salesforce (Platform Event ou CDC) são a direção natural. Se o sistema ERP é o proprietário, a direção oposta é verdadeira, e o Salesforce precisa consumir eventos, e não publicá-los, para a mesma entidade. **O que pode ser perdido?** Um alerta para um dashboard gerencial pode perder uma única mensagem sem prejuízos. A atualização de um limite de crédito antes da aprovação de uma transação não pode. Essa distinção determina se basta um modelo "fire-and-forget" ou se é necessário um mecanismo de confirmação e monitoramento de divergências (Reconciliation). **O que acontece se a mensagem chegar duas vezes?** Platform Events garantem "At-Least-Once", e não "Exactly-Once". Se a resposta for "não sabemos", a solução ainda não está pronta para produção, independentemente da qualidade do código. ## Platform Events vs. CDC — Tabela de Decisão | Critério | Platform Event Personalizado | Change Data Capture | | --- | --- | --- | | O que é publicado | Evento de negócio definido (Payload personalizado) | Alteração bruta de registro (Antes/Depois) | | Quem constrói a lógica | Desenvolvedor Salesforce, no Trigger ou Flow | A plataforma, automaticamente para qualquer DML configurado | | Acoplamento ao esquema | Baixo — Payload controlado pelo publicador | Alto — Toda alteração na estrutura do objeto afeta o consumidor | | Adequado quando... | Se deseja publicar uma intenção de negócio ("Pedido Aprovado") | Se deseja sincronização de dados brutos entre sistemas | | Custo de manutenção | Mais alto inicialmente (construção de Payload e lógica) | Baixo inicialmente, alto quando a estrutura do objeto muda | | Retention | Conforme definição da licença (horas a dias) | Conforme definição da licença, geralmente o mesmo que Platform Events | | Volume recomendado | Eventos de domínio de frequência média | Alterações em nível de registro, incluindo alta frequência | A regra prática: se o consumidor do evento precisa entender "por que" isso aconteceu e não apenas "o que" aconteceu, um Platform Event personalizado é necessário. Se o consumidor apenas precisa de uma cópia atualizada dos dados, o CDC economiza uma camada completa de desenvolvimento. ## Ordering, Replay e Idempotency: Os três conceitos que transformam teoria em produção estável Estes não são temas para a fase tardia do projeto – eles definem a estrutura do consumidor desde o primeiro dia. **Ordering.** Platform Events são enviados na ordem de publicação dentro do mesmo tópico, mas a carga e falhas parciais podem perturbar a ordem de recebimento no lado do consumidor. Solução prática: anexar um carimbo de versão ou número de sequência (Sequence Number) do registro original a cada evento, e permitir que o consumidor rejeite eventos cuja versão seja inferior à última versão já processada. **Replay.** Cada evento recebe um Replay ID. Um consumidor que falha deve salvar o último Replay ID que processou com sucesso – não na memória, mas em um local durável (Custom Object, tabela externa) – e continuar a partir daí com a recuperação. A dependência de "o sistema começará do zero" só funciona dentro da janela de Retention, e além dela, os eventos são perdidos. **Idempotency.** Todo consumidor deve identificar um evento que já foi processado, geralmente por meio de um identificador de transação único enviado no Payload. Sem isso, um Retry automático por parte do remetente – ou um Replay manual após uma falha – resulta em uma atualização duplicada, criação de registro duplicado ou, no pior cenário, uma cobrança duplicada. Essa lacuna quase nunca é descoberta na demonstração. Ela aparece sob carga, em uma falha de rede real ou em uma mudança no ambiente de produção, e então o custo para corrigi-la já inclui também a correção de dados. Organizações que enfrentam um problema semelhante na camada de automação encontram uma análise complementar em [Dívida Técnica no Salesforce com Flow e Apex](/pt/insights/salesforce-flow-apex-technical-debt). ## Cenário de exemplo: Uma rede de varejo com 40 filiais e um sistema de estoque separado Considere uma rede de varejo hipotética, "Varejo do Norte", que opera Salesforce Sales Cloud para equipes de vendas em 40 filiais e um sistema ERP separado que gerencia o estoque em tempo real. Até então, cada pedido fechado no Salesforce era transferido para o ERP por meio de um Job agendado que rodava a cada 15 minutos, uma solução que ocasionalmente fazia com que os representantes vissem estoque desatualizado e aprovassem pedidos para produtos esgotados. A equipe de arquitetura decidiu publicar um Platform Event personalizado chamado `Order_Confirmed__e` a cada confirmação de pedido, com um Payload que incluía um identificador de transação único, lista de itens e quantidades. O ERP escuta o evento e atualiza o estoque em segundos, verificando o identificador da transação em uma tabela de transações já processadas para evitar deduções duplicadas caso o evento chegasse duas vezes. Além disso, foi definido um processo de Reconciliação noturno que compara o total de pedidos aprovados no Salesforce com o total de atualizações recebidas no ERP, alertando sobre uma divergência acima de um limite definido. A razão: mesmo com Idempotency adequado, desejava-se a detecção precoce de uma falha de rede prolongada, e não apenas a dependência de que o evento "certamente chegou". O resultado: o tempo de atualização caiu de 15 minutos para menos de um minuto, e o número de eventos de estoque incorretos diminuiu de forma mensurável em um mês após a implementação. O cenário ilustra um princípio central: o valor não é gerado pela "passagem de eventos" por si mesma, mas pela combinação de um evento de negócios claro, verificação de duplicidade no lado do consumidor e um processo de monitoramento que identifica divergências antes que se tornem uma reclamação do cliente. ## Riscos comuns e ações preventivas | Risco | Como se manifesta na prática | Ação preventiva | | --- | --- | --- | | Publicação de evento a cada alteração de campo | O limite diário de eventos é excedido em poucos dias | Publicar eventos de Dominio com significado de negócio, não um evento técnico a cada DML | | Ausência de verificação de duplicidade no consumidor | Retry ou Replay criam registros ou atualizações duplicadas | Anexar um identificador de transação único e verificá-lo antes de cada operação | | Dependência da ordem de chegada | Uma atualização antiga sobrescreve uma atualização mais recente | Anexar um carimbo de versão e rejeitar eventos antigos em relação à última versão processada | | Ausência de salvamento do Replay ID | Após uma falha do consumidor, eventos entre a falha e a janela de Retention são perdidos | Salvar o Replay ID em um local durável e executar Replay automático ao reiniciar | | CDC em objeto cuja estrutura muda frequentemente | Qualquer alteração de campo quebra o consumidor externo sem aviso | Definir um contrato de dados explícito e comunicar mudanças de esquema antecipadamente | | Ausência de monitoramento de negócio, apenas técnico | A integração está "verde", mas o estoque ou pedidos reais não correspondem | Adicionar Reconciliação diária que compare o resultado de negócio entre os sistemas | ## Checklist antes de iniciar o desenvolvimento da camada de eventos - ☐ Cada evento possui um proprietário claro: quem publica e quem é o proprietário de negócio dos dados - ☐ Um Payload fixo e documentado foi definido, não uma estrutura que muda a cada Sprint - ☐ A escolha entre Platform Event personalizado e CDC foi feita com base na intenção de negócio versus alteração bruta - ☐ Cada consumidor possui um identificador de transação único e verificação de duplicidade (Idempotency) - ☐ O tratamento da ordem é definido por carimbo de versão, não por ordem de chegada - ☐ O Replay ID é salvo em um local durável e o processo de recuperação é definido e testado - ☐ Existe monitoramento de negócio (Reconciliação) além do monitoramento técnico da fila de mensagens - ☐ O cenário de carga e o cenário de falha parcial foram testados, não apenas o Happy Path - ☐ O limite diário de eventos (Publicação + Entrega) foi verificado contra o volume esperado em produção - ☐ Um Owner operacional foi definido para responder quando uma divergência for detectada na Reconciliação ## Como medir a eficácia da arquitetura | Área | O que medir | Frequência de verificação | | --- | --- | --- | | Confiabilidade da entrega | Percentual de eventos concluídos sem Retry, e percentual bem-sucedido após Retry | Contínuo | | Divergências de Reconciliação | Diferença entre registros confirmados na origem e recebidos no destino | Diário | | Latência ponta a ponta | Tempo entre o evento de negócio e a atualização real no consumidor | Contínuo | | Utilização do limite de eventos | Percentual da cota diária realmente utilizada | Semanal | | Duplicidades evitadas | Número de eventos identificados como duplicados e bloqueados antes da execução | Semanal | Recomenda-se selecionar não mais do que três a quatro métricas para a primeira versão, e medi-las contra uma linha de base (Baseline) coletada antes da transição para a arquitetura de eventos – não contra uma percepção geral de que "agora está mais rápido". Para o planejamento de uma estrutura organizacional mais ampla com múltiplas integrações, é útil examinar também os [Padrões de Integração do Salesforce](/pt/insights/salesforce-integration-patterns) e as implicações para a [Arquitetura de Single Org versus Multi Org do Salesforce](/pt/insights/salesforce-single-org-vs-multi-org), pois a decisão sobre eventos pode, às vezes, transcender os limites organizacionais. ## Resumo A escolha entre Platform Events e CDC não é uma questão técnica a ser analisada brevemente no início de um projeto – ela define quem é a fonte da verdade, o que pode ser perdido e como o sistema se comporta quando algo falha no meio do processo. Uma organização que planeja antecipadamente Ordering, Replay e Idempotency, e adiciona uma camada de Reconciliação de negócio, e não apenas monitoramento técnico, obtém uma integração que suporta carga e falhas parciais. Uma organização que pula essas etapas obtém um sistema que parece funcional nos testes, mas falha silenciosamente em produção, geralmente sem que ninguém perceba até que o dano já tenha ocorrido. Organizações que buscam suporte na construção de uma camada de eventos confiável no Salesforce podem entrar em contato através do [serviço de arquitetura de CRM](/pt/crm-architecture). ### Perguntas e respostas **Quando o Change Data Capture é preferível a um Platform Event customizado?** Quando o Salesforce é a fonte da verdade e o sistema de destino precisa saber que um registro foi alterado, sem a necessidade de construir uma lógica manual para a publicação. O CDC elimina essa camada, mas expõe a estrutura interna do objeto a ouvintes externos – qualquer alteração de campo afeta o consumidor. Um Platform Event customizado é preferível quando se deseja publicar uma intenção de negócio ('Pedido Aprovado') e não uma alteração técnica de um registro. **Os Platform Events garantem que a mensagem será entregue apenas uma vez?** Não. A plataforma garante "At-Least-Once" (pelo menos uma vez), o que significa que pode chegar duas vezes em cenários de falha de rede ou uso de Replay. É fundamental que o consumidor seja projetado para ser Idempotente – verificando um identificador de transação único antes de executar uma ação – caso contrário, uma atualização duplicada, criação de registros duplicados ou cobranças em dobro são resultados esperados, e não falhas incomuns. **O que acontece se o consumidor de eventos ficar indisponível por algumas horas?** Os Platform Events são armazenados no Event Bus de acordo com uma janela de Retenção definida pela licença (geralmente de 24 horas a 3 dias), e é possível executar um Replay a partir do último Replay ID recebido com sucesso. É essencial salvar o Replay ID no lado do consumidor e não confiar na suposição de 'recebemos tudo' – se a janela de retenção expirar sem um Replay, os eventos serão perdidos permanentemente. **Como manter a ordem das atualizações quando vários eventos se referem ao mesmo registro?** Os Platform Events não garantem a ordem entre diferentes canais e, ocasionalmente, nem dentro do mesmo canal sob alta carga. A solução comum é adicionar um timestamp de versão ou um número serial a cada evento e permitir que o consumidor rejeite uma atualização que chegou com uma versão mais antiga do que a já processada, em vez de depender da ordem de chegada. **Quantos Platform Events podem ser publicados sem impactar o desempenho?** O limite é medido pela quantidade de eventos por dia e por entrega diária, de acordo com a edição e a licença, e também contabiliza eventos que falharam no envio. Um projeto que publica um evento para cada alteração de campo em uma tabela movimentada atinge o limite rapidamente; por isso, publicamos eventos de Domínio com significado de negócio, e não eventos técnicos para cada DML (Data Manipulation Language). --- ## SSO, MFA e Identity no Salesforce: Princípios de Design Corporativo URL: https://hpi.pro/pt/insights/salesforce-sso-identity-architecture SAML ou OIDC, iniciado pelo IdP ou pelo SP, JIT ou SCIM para gestão do ciclo de vida – cada escolha na arquitetura de Identity para o Salesforce determina quem acessa o sistema, com quais permissões e o que acontece no dia em que o usuário sai. Este artigo apresenta uma estrutura de decisão concreta, incluindo um cenário de Offboarding malsucedido e como corrigi-lo. ## A Resposta Breve A arquitetura de identidade no Salesforce não é um projeto técnico pontual, mas sim uma camada de controle que se executa diariamente: quem acessa, com qual identidade, com quais permissões, e o que acontece no momento em que o acesso não deveria mais ser permitido. A escolha entre SAML e OIDC, JIT e SCIM, e entre políticas de MFA no nível do IdP versus aplicação interna no Salesforce – tudo isso pode parecer detalhes de configuração, mas na prática, determina quanto tempo leva para bloquear o acesso de um funcionário desligado e qual fração desses incidentes só será descoberta em auditoria. A abordagem correta não começa com o protocolo, mas com duas perguntas: quem é a fonte da verdade para a identidade do usuário, e qual é o tempo máximo permitido entre um evento de Offboarding e o bloqueio efetivo do acesso. A partir daí, todas as outras decisões são derivadas – o tipo de Federação, o método de Provisionamento, a política de Sessão e o processo de Break Glass. Organizações que também consideram a questão das permissões em si, e não apenas a autenticação, encontrarão mais informações no [Modelo de Permissões do Salesforce](/pt/insights/salesforce-permission-model). ## Mapa de Decisões: Quatro Camadas de Identidade no Salesforce | Camada | Pergunta a Decidir | Principais Opções | O que Falha se a Decisão For Errada | | --- | --- | --- | --- | | Federação e Autenticação | Quem é o IdP e como o Salesforce confia nele | SAML 2.0, OIDC, Autenticação Delegada | Login duplicado, incompatibilidade de Atributos, quebra de confiança | | Provisionamento e Ciclo de Vida | Como o usuário é criado, atualizado e cancelado | Provisionamento JIT, SCIM, criação manual | Contas órfãs, acesso remanescente após desligamento | | Sessão e MFA | Onde o nível de autenticação e a duração da Sessão são aplicados | MFA no IdP, MFA interno no Salesforce, Políticas de Sessão | Bypass de MFA por caminho alternativo, Sessão que nunca expira | | Break Glass e Auditoria | O que acontece se o SSO falhar e quem verifica anomalias | Usuário de emergência controlado, Histórico de Login, Event Monitoring | Dependência total do IdP, incapacidade de investigação retrospectiva | ## SAML vs. OIDC: Não é Uma Questão de "O que é Mais Novo" A escolha entre os dois protocolos não deve ser ditada por tendências, mas sim pela infraestrutura existente. SAML opera com XML e Assertions assinadas, sendo comum em organizações com Active Directory Federation Services ou um IdP estabelecido que já serve dezenas de outros sistemas. OIDC é construído sobre o OAuth 2.0, é mais leve para manter e particularmente conveniente quando o mesmo IdP precisa atender tanto a consumidores de API modernos quanto ao login de usuários. O erro comum é escolher com base no que parece "avançado" sem verificar quais Atributos o IdP existente já envia, e como eles são mapeados para o Salesforce (Username, Federation ID, Profile, Permission Set Group). Um mapeamento de Atributo incorreto na fase de configuração geralmente leva à correção manual de dezenas de usuários em produção, e não apenas à alteração de uma configuração. Um ponto frequentemente esquecido: mesmo ao escolher OIDC ou SAML, é bom planejar o Login Iniciado pelo IdP vs. o Iniciado pelo SP separadamente – alguns dos incidentes de segurança mais comuns resultam de o Login Iniciado pelo SP permanecer aberto, mesmo que todo o processo de login tenha sido planejado exclusivamente através do portal do IdP. ## Provisionamento JIT vs. SCIM: Quando "No Momento do Login" Não é Suficiente O Provisionamento JIT (Just-In-Time) cria ou atualiza o usuário no Salesforce no momento do primeiro login, com base nos dados que chegam do IdP na SAML Assertion ou no OIDC Token. É conveniente, barato de implementar e suficiente para a maioria das organizações onde os usuários fazem login regularmente. O problema: o JIT não resolve o Deprovisionamento. Se um funcionário é removido do IdP, mas não faz mais login, sua conta permanece ativa no Salesforce indefinidamente, pois não há um evento que acione uma atualização. É exatamente aqui que o SCIM (System for Cross-domain Identity Management) entra – ele permite a sincronização proativa do IdP com o Salesforce, incluindo a desativação imediata quando um usuário é removido na origem. A regra prática: se a organização tem um requisito de Offboarding em horas, e não em dias – subcontratados, funcionários temporários, acesso a dados sensíveis –, o SCIM não é um "seria bom ter", mas uma exigência de Compliance. Se o ciclo de funcionários é lento e a Governança já inclui uma revisão trimestral de acessos, o JIT por si só pode ser suficiente, desde que seja acompanhado por um processo manual documentado para bloqueio imediato. O planejamento do provisionamento deve sempre ser avaliado também em relação à complexidade da automação relacionada – por exemplo, quando Flows que executam lógicas de atribuição de permissões no момент da criação do usuário estão envolvidos, onde a comparação entre [Flow e Apex](/pt/insights/salesforce-flow-vs-apex) é relevante para identificar onde o código customizado vale a pena. ## MFA e Política de Sessão: Duas Camadas, Não Apenas Uma Um erro comum é satisfazer-se com o MFA aplicado no Identity Provider e assumir que ele cobre todos os caminhos de acesso ao Salesforce. Na prática, enquanto houver um usuário que pode se conectar diretamente via login.salesforce.com – por exemplo, uma integração, um Usuário de API, ou um Administrador que mantém acesso de backup – é necessária uma política de MFA separada definida dentro do próprio Salesforce (Verificação de Identidade, Níveis de Segurança de Sessão). Além disso, a política de Sessão determina coisas fáceis de perder: Tempo Limite de Sessão, "Forçar logout no tempo limite da sessão", Intervalos de IP de Login e Sessão de Alta Confiança obrigatória para operações sensíveis (por exemplo, alteração de permissões ou exportação massiva de dados). Uma organização que define um MFA forte, mas mantém o Tempo Limite de Sessão no padrão de duas horas, abre uma janela em que um computador roubado mantém acesso ativo muito além do tempo razoável. ## Break Glass e Auditoria: Quando o SSO Falha, Quem Acessa A dependência total de um IdP externo cria um ponto único de falha: se o IdP falhar ou se houver um bug na configuração da Federação, ninguém consegue fazer login, incluindo quem precisa corrigir o problema. A solução comum é um usuário Break Glass – uma conta de superadministrador com autenticação independente (não dependente do SSO), senha gerenciada em um cofre (Vault) e não na memória de uma pessoa, e MFA separado. É importante notar: Break Glass não é um "backdoor conveniente" – é um mecanismo de emergência controlado. Seu uso deve acionar um alerta automático e ser revisado dentro de um dia útil por uma entidade diferente da que o utilizou. Muitas organizações configuram o usuário corretamente, mas esquecem o controle contínuo – a senha não é rotacionada e suas permissões são muito amplas por padrão. ## Cenário Corporativo: Falha de Offboarding em uma Seguradora de Médio Porte Imagine uma companhia de seguros com cerca de seiscentos funcionários, utilizando Okta como Identity Provider e uma configuração SAML para o Salesforce estabelecida há aproximadamente três anos. O Provisionamento é totalmente baseado em JIT: quando um novo funcionário faz login pela primeira vez, uma conta de usuário é criada para ele com Perfil e Grupo de Conjuntos de Permissões de acordo com o grupo Okta ao qual pertence. Em um dos casos, um representante de serviço foi demitido na sexta-feira à tarde. A equipe de TI o desativou no Okta imediatamente. Na prática, como não havia um mecanismo SCIM ou Webhook para sincronizar a desativação com o Salesforce, a conta dele permaneceu no estado Ativo lá – e como a sessão dele já estava ativa desde a manhã e "Force logout on session timeout" não estava configurado, ele continuou a acessar o sistema mesmo depois da demissão, até que alguém notou em uma revisão semanal de acessos na segunda-feira. A solução implementada não foi uma transição completa para SCIM (que exigiria um projeto separado e orçamento de integração), mas sim a combinação imediata de três ações: ativação de "Force logout on session timeout" para todos os perfis sensíveis, redução do Tempo Limite de Sessão de 120 minutos para 30 minutos para cargos de atendimento ao cliente, e a adição de uma etapa automática no processo de Offboarding organizacional que executa a desativação direta no Salesforce como uma ação independente, e não apenas como um resultado indireto da desativação no Okta. O SCIM permaneceu como meta para o próximo trimestre, já com orçamento e aprovação, mas a lacuna mais perigosa foi fechada em uma semana. ## Riscos Comuns e Ações Preventivas | Risco | Como se Manifesta na Prática | Ação Preventiva | | --- | --- | --- | | Dependência total de JIT sem Desprovisionamento | Usuários desligados permanecem Ativos indefinidamente | Adição de etapa de Offboarding independente no Salesforce, não dependente de sincronização | | MFA apenas no IdP | Usuários de integração e Administradores ignoram MFA via login direto | Política de MFA interna no Salesforce para todos os tipos de usuários | | Tempo Limite de Sessão muito longo | Computador roubado ou sessão esquecida aberta mantém acesso por horas | Redução do Tempo Limite e Force Logout para perfis sensíveis | | Break Glass sem controle | Uso da conta de emergência não é detectado a tempo | Alerta automático e revisão dentro de um dia útil para qualquer uso | | Mapeamento de Atributos incorreto do IdP | Usuário obtém Perfil ou Role incorretos no primeiro login | Verificação completa do mapeamento em ambiente Sandbox antes da mudança para Produção |

Checklist para Implementação ou Auditoria de Arquitetura de Identidade

- ☐ Um único Identity Provider foi definido como fonte da verdade, e o que acontece quando ele falha é conhecido. - ☐ O protocolo (SAML ou OIDC) foi escolhido com base na infraestrutura existente, e não em tendências. - ☐ O mapeamento de Atributos entre o IdP e o Perfil/Grupo de Conjuntos de Permissões foi testado no Sandbox. - ☐ Uma política clara foi definida: JIT apenas, ou JIT combinado com SCIM conforme a exigência de Offboarding. - ☐ O MFA é aplicado também dentro do Salesforce, não apenas no IdP. - ☐ O Tempo Limite de Sessão e o Force Logout são configurados de acordo com a sensibilidade do perfil. - ☐ Existe um usuário Break Glass controlado, com MFA separado e senha armazenada em cofre. - ☐ O processo de Offboarding inclui uma etapa independente para desativação no Salesforce. - ☐ O Histórico de Login e o Event Monitoring são verificados em um cronograma regular. - ☐ Existe um plano de revisão periódica (Access Review) que não depende apenas da memória da equipe de TI. ## Como Avaliar o Desempenho da Arquitetura O principal indicador não é "se o SSO está ativo", mas sim o tempo de resposta entre um evento na fonte autoritativa e a mudança correspondente no Salesforce: quanto tempo se passa entre a remoção de um usuário no IdP e a desativação efetiva. Um indicador complementar é a taxa de logins realizados por um caminho inesperado (Login Direto em vez de via IdP), que deve tender a zero, exceto para usos documentados do Break Glass. Um terceiro indicador é a frequência da revisão das permissões em relação ao status real – nem toda mudança organizacional chega via IdP, e, por isso, uma revisão trimestral continua sendo essencial, mesmo com provisionamento automático completo. Para a implementação ou auditoria de uma arquitetura de identidade em um ambiente Salesforce existente, é possível avançar através de [serviço de arquitetura de CRM](/pt/crm-architecture). Organizações que também examinam a conexão com o ERP e sistemas de folha de pagamento como parte do quadro geral de identidade encontrarão informações complementares em [Conexão do Salesforce com ERP](/pt/insights/salesforce-erp-integration) e um panorama arquitetural mais amplo no [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide). ## Conclusão A arquitetura de identidade no Salesforce é construída uma única vez, mas testada diariamente por incidentes isolados – um funcionário que se desliga, uma sessão esquecida aberta, uma integração que ignora o MFA. As escolhas críticas (SAML vs. OIDC, JIT vs. SCIM, MFA duplo, Break Glass controlado) não devem ser ditadas por configurações padrão do IdP, mas sim pelo tempo de resposta necessário para bloquear o acesso e pelo nível de sensibilidade dos dados expostos. Uma organização que planeja essa camada antecipadamente, em vez de descobrir as lacunas em uma auditoria ou após um incidente de segurança, economiza tanto custos de correção quanto riscos reputacionais e regulatórios. ### Perguntas e respostas **Qual a diferença prática entre SAML e OIDC para o Salesforce?** Ambos são suportados como Provedores de Single Sign-On, mas o OIDC é baseado em REST/JSON e se integra mais facilmente com IdPs modernos e outros consumidores de API, enquanto o SAML é mais comum em organizações com infraestrutura de IAM existente ou requisitos regulatórios já construídos em torno dele. A escolha deve ser baseada no IdP existente na organização e não apenas em considerações tecnológicas – a transição entre os dois após a construção de mapeamentos de Atributos e Permission Sets ao redor deles é um trabalho não trivial. **Quando usar JIT Provisioning e quando usar SCIM?** JIT é apropriado quando é suficiente criar e atualizar um usuário no momento do primeiro login, e quando não há uma necessidade real de desprovisionamento imediato fora do ciclo SSO. O SCIM é necessário quando há uma obrigação operacional de revogar o acesso minutos após o usuário ser removido no IdP, ou seja, em organizações com requisito de Offboarding imediato, subcontratados temporários ou regulamentações que exigem prova de sincronização entre fontes. **O MFA imposto no IdP é suficiente, ou também é necessário MFA no Salesforce?** Se todos os acessos passam pelo IdP e não há um caminho de acesso direto ao Salesforce, o MFA no IdP pode ser suficiente para o login regular. Mas sempre é necessária uma política de MFA interna no Salesforce para cobrir usuários de Break Glass, integrações com usuários de serviço e qualquer rota que contorne o IdP – caso contrário, é criada uma lacuna de segurança justamente no ponto mais sensível. **Como construir um usuário Break Glass que não se torne uma brecha permanente?** Um usuário Break Glass precisa de uma senha gerenciada em um cofre, MFA separado, permissões restritas apenas à função de emergência e não um System Administrator abrangente, além de notificação automática a cada uso. A regra obrigatória é que cada acesso com ele seja auditado dentro de um dia útil, e que exista um processo trimestral para garantir que a senha foi rotacionada mesmo que não tenha sido utilizada. **O que acontece quando um funcionário sai e o IdP não está sincronizado com o Salesforce em tempo real?** Sem SCIM ou Webhook que acione a desativação imediata, o usuário permanece ativo no Salesforce mesmo depois de ser removido no IdP, pois uma sessão existente não é verificada com o IdP a cada solicitação. A solução prática é uma combinação de Session Timeout curto, Login IP Ranges e um processo de Offboarding que executa a desativação direta no Salesforce como um passo independente, e não apenas como uma dependência da sincronização lenta com o IdP. --- ## Sharing e Visibilidade no Salesforce: Planejando o Acesso a Dados Complexos URL: https://hpi.pro/pt/insights/salesforce-sharing-visibility-design Um OWD aberto com a premissa de 'não bloquear ninguém' e uma Hierarquia de Funções que cresce de forma ad-hoc são o caminho mais rápido para um relatório em que o gerente regional vê todos os clientes de seu concorrente interno. Este artigo propõe um fluxo de trabalho inverso: primeiro, mapeia-se quem precisa ver o quê e por quê, e só então se escolhe entre OWD, Hierarquia de Funções, Regras de Compartilhamento, Equipes e Apex Sharing. ## Por que um modelo de compartilhamento reativo é mais difícil do que um bem planejado O problema típico não é percebido no primeiro mês. Ele se manifesta quando um gerente de vendas regional nota que está vendo uma oportunidade de um território concorrente, ou quando um agente de serviço abre um caso de um cliente VIP que deveria ser acessível apenas a uma equipe dedicada. Ambos os cenários são resultado direto de uma ordem de trabalho invertida: objetos e campos são definidos, e somente no final se questiona quem deveria ver o quê. O modelo de visibilidade no Salesforce é construído em camadas que funcionam juntas, não isoladamente: Organization-Wide Defaults (OWD) estabelece a linha de base mais restritiva, Role Hierarchy adiciona acesso vertical com base na estrutura gerencial, Sharing Rules abrem acesso horizontal baseado em critérios de negócio, Teams e Manual Sharing tratam de casos específicos, e Apex Managed Sharing entra em cena quando a lógica é muito complexa para ser expressa estaticamente. Essa ordem é crucial: qualquer camada escolhida prematuramente gera uma dívida que é difícil de desfazer, pois permissões já concedidas são percebidas como um direito adquirido. ## O Mapa das Camadas e Quando Cada Uma é Apropriada | Camada | O Que Resolve | Quando Escolher | Risco de Escolha Incorreta | | --- | --- | --- | --- | | OWD | Linha de base: quem não pode ver nada por padrão | Sempre definido, geralmente "Private" para objetos sensíveis | OWD muito aberto torna outras camadas redundantes | | Role Hierarchy | Acesso vertical do gestor às informações dos subordinados | Quando a estrutura de gestão reflete a necessidade de supervisão de dados | Hierarquia "política" que não corresponde à propriedade real dos dados | | Sharing Rules | Abertura de acesso horizontal por critério fixo (função, grupo, valor de campo) | Equipe inter-hierárquica que precisa de acesso ao mesmo tipo de registro | Múltiplas regras sobrepostas, dificultando saber quem concedeu o acesso | | Public Groups | Agrupamento de usuários para compartilhamento, independente da hierarquia | Quando um grupo de trabalho não corresponde a uma única função organizacional | Grupos não atualizados quando um colaborador muda de função | | Account/Case Teams | Acesso variável em um único registro, conforme a composição da equipe | Quando cada cliente ou caso possui uma equipe única e variável | Manutenção manual que é esquecida quando a equipe muda | | Territory Management | Atribuição de acesso baseada em regras dinâmicas e multidimensionais | Atribuição variável por várias características simultâneas, acesso paralelo para vários representantes | Complexidade de manutenção que não se justifica abaixo de um certo limite organizacional | | Apex Managed Sharing | Compartilhamento derivado de lógica dinâmica que não pode ser expressa estaticamente | Critério que depende de cálculo, evento externo ou combinação de campos | Código sem monitoramento que continua a executar após a mudança da necessidade de negócio | ## OWD: A Decisão que Define Tudo o Mais O OWD não é apenas uma configuração de segurança técnica — é uma declaração organizacional sobre quem é o proprietário principal da informação. A regra prática: defina o OWD para o estado mais restritivo que seja realmente necessário, e a partir daí, expanda o acesso usando Sharing Rules, e não o contrário. A razão: expandir o acesso pontual é fácil e documentado, enquanto restringir o acesso já existente exige comunicação organizacional, pois os usuários percebem a perda de acesso como um prejuízo, mesmo que seja a correção de um erro histórico. Um ponto que nem sempre recebe atenção suficiente: o OWD é definido separadamente para cada objeto, e objetos dependentes (Master-Detail) herdam a visibilidade do objeto principal. Ao construir um novo modelo de dados, é essencial verificar a cadeia de dependência completa antes de definir o OWD — caso contrário, um objeto "secundário" inadvertidamente definido como Público pode expor informações do objeto principal. ## Hierarquia de Funções Versus Estrutura Gerencial Real O erro mais comum é replicar o organograma na Role Hierarchy tal como ele é, sem verificar se ele também reflete o fluxo de propriedade dos dados. Um gerente regional precisa ver as oportunidades de sua equipe — esta é uma função gerencial. Mas um CFO não precisa ver automaticamente todos os casos de serviço apenas por estar em uma posição superior na hierarquia geral; se houver tal necessidade, ela deve ser resolvida por uma Sharing Rule direcionada, e não por uma hierarquia excessivamente ampla. Uma hierarquia de compartilhamento separada da hierarquia de relatórios organizacional é uma solução legítima e, por vezes, preferível, especialmente em organizações com uma estrutura matricial onde os relatórios gerenciais não se alinham com a propriedade dos dados do cliente. ## Matriz de Decisão: O Que Ativa Cada Mecanismo de Compartilhamento - **A necessidade varia por função fixa e previsível** → Role Hierarchy. - **A necessidade é compartilhada por um grupo de trabalho que transcende funções** → Public Group + Sharing Rule. - **A necessidade varia conforme a composição da equipe em um único registro** → Account Team ou Case Team. - **A necessidade depende de uma combinação de condições dinâmicas (geografia, produto, porte do cliente)** → Territory Management. - **A necessidade deriva de um cálculo, evento externo ou condição que não pode ser expressa estaticamente** → Apex Managed Sharing. - **A necessidade é uma exceção pontual e temporária para um único registro** → Manual Sharing, com supervisão e documentação. Esta matriz deve ser elaborada antes de iniciar o trabalho nas ferramentas, e não em paralelo — caso contrário, um mecanismo será escolhido com base no que é familiar à equipe de desenvolvimento, e não no que é mais adequado à necessidade. ## Cenário Ilustrativo: Fabricante de Equipamentos Industriais com Três Canais de Venda Considere um fabricante hipotético de equipamentos industriais com aproximadamente 180 usuários Salesforce, operando por meio de três canais: venda direta por região geográfica, venda por meio de distribuidores e venda para contas estratégicas globais gerenciadas em paralelo por vários representantes em diferentes países. A tentativa inicial de usar apenas a Role Hierarchy falhou: uma conta estratégica global não pertence a uma única hierarquia regional, e um representante na Alemanha não via as atualizações de seu colega no Brasil na mesma conta. A solução escolhida combinou três camadas: OWD em Account e Opportunity foi definido como “Private”; a Role Hierarchy foi usada para o acesso gerencial padrão dentro de cada região; e para contas estratégicas, um Account Team dinâmico foi configurado para ser atualizado automaticamente via Flow quando o campo "Strategic Account Owner Region" fosse alterado. Os distribuidores receberam acesso separado por meio de uma Sharing Rule baseada em um Public Group dedicado, para não serem expostos às contas de venda direta. Resultado: O tempo de Recálculo de Compartilhamento permaneceu estável, pois a maior parte do acesso deriva de uma estrutura constante (Role, Public Group) e apenas uma minoria das contas — as estratégicas — depende de atualizações dinâmicas. A principal lição: não existe um único mecanismo "certo" para toda a organização; é preciso adaptar o mecanismo ao tipo de dependência de cada subconjunto de registros. Mais detalhes sobre a escolha de padrões de integração e um modelo de dados de suporte estão disponíveis no [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide). ## Riscos Específicos do Planejamento de Visibilidade e Ações Preventivas | Risco | Como se Manifesta na Prática | Ação Preventiva | | --- | --- | --- | | OWD aberto "temporariamente" na fase piloto | A abertura permanece mesmo após o sistema entrar em produção plena | Definir uma data de fechamento prévia e documentá-la como um item de Go-Live, não como recomendação | | Múltiplas Sharing Rules sobrepostas | Impossibilidade de saber com certeza por que um usuário vê um registro específico | Nomenclatura padrão para cada regra, incluindo a razão de negócio, e revisão periódica de regras não usadas | | Apex Sharing sem testes de execução sob carga | Cálculo de compartilhamento que atrasa com o aumento do volume de dados | Executar teste de carga no Recálculo de Compartilhamento antes de dobrar o volume de registros em produção | | Hierarquia de compartilhamento copiada de hierarquia organizacional política | Gerentes veem dados para os quais não têm necessidade de negócio | Separar a hierarquia de funções para fins de compartilhamento da hierarquia de relatório oficial, quando não forem idênticas | | Manual Sharing acumulado sem proprietário | Permissões excepcionais permanecem após a razão para o compartilhamento não ser mais relevante | Processo de expiração ou revisão trimestral de compartilhamentos manuais | | Mudança de função do usuário sem atualização de grupos públicos | Acesso antigo permanece aberto e novo acesso está ausente | Integrar a atualização de grupos e funções como uma única etapa no processo de mudança de status do colaborador | ## Checklist Antes de Finalizar o Modelo de Compartilhamento - ☐ OWD configurado de acordo com a condição mais restritiva exigida, não pela conveniência da fase de desenvolvimento. - ☐ A cadeia de dependência entre objetos Master-Detail foi verificada em relação ao OWD do objeto principal. - ☐ A Role Hierarchy foi verificada em relação à propriedade real dos dados, e não apenas em relação ao organograma. - ☐ Toda Sharing Rule possui uma razão de negócio documentada e um proprietário responsável por sua validade. - ☐ Verificado se o Territory Management é realmente necessário ou se representa uma complexidade desnecessária. - ☐ O código Apex Sharing foi testado sob um volume de dados realista, e não apenas em um ambiente Sandbox pequeno. - ☐ Existe um processo para atualização de grupos públicos e permissões em caso de mudança de função ou desligamento. - ☐ Uma frequência de revisão periódica foi definida para Manual Sharing e Sharing Rules inativas. - ☐ O impacto do modelo de compartilhamento no desempenho de relatórios e execuções de Batch grandes foi avaliado. - ☐ Existe um plano de resposta para o caso de uma exposição excessiva ser descoberta em produção. ## Como Saber se o Modelo Suporta a Carga A primeira métrica é o tempo de Recálculo de Compartilhamento após uma mudança estrutural — um aumento consistente ao longo do tempo indica que o modelo está se aproximando de uma complexidade não planejada. A segunda métrica é o número de solicitações de suporte do tipo "não tenho acesso" versus "tenho acesso desnecessário" — uma proporção que pende drasticamente para um lado sugere que o OWD ou as Sharing Rules não estão calibrados corretamente. A terceira métrica, especialmente importante em organizações com múltiplos sistemas, é a consistência entre as permissões do Salesforce e as permissões em sistemas sincronizados — em particular quando se trata de arquiteturas de integração baseadas em eventos, conforme descrito no [Guia de Arquitetura Orientada a Eventos no Salesforce](/pt/insights/salesforce-event-driven-architecture). Em organizações que utilizam múltiplos "Orgs", a questão do modelo de compartilhamento é muitas vezes interligada à pergunta sobre se é realmente necessário mais de um ambiente de produção — a discussão completa está em [Salesforce Single Org versus Multi Org](/pt/insights/salesforce-single-org-vs-multi-org), e na escolha do padrão de integração correspondente no [Guia de Padrões de Integração Salesforce](/pt/insights/salesforce-integration-patterns). ## Resumo Um bom modelo de compartilhamento e visibilidade não é medido no dia do lançamento — ele é medido quando a organização cresce, quando um usuário muda de função e quando alguém pergunta "por que não estou vendo isso?". A maneira de chegar lá não é escolhendo uma única ferramenta e a aplicando a tudo, mas sim mapeando cada grupo de registros de acordo com seu tipo de dependência — fixa, horizontal, dinâmica ou excepcional — e escolhendo o mecanismo apropriado para cada um. OWD restrito por padrão, Role Hierarchy que reflete a verdadeira propriedade, Sharing Rules com uma razão documentada, e Apex Sharing apenas quando a lógica o justifica — essa é a combinação que se sustenta mesmo quando a organização dobra de volume e complexidade. ### Perguntas e respostas **É possível começar com OWD aberto e fechar posteriormente?** Tecnicamente sim, mas na prática isso quase sempre se reverte: uma vez que usuários e relatórios se adaptam a ver tudo, qualquer restrição posterior é percebida como prejudicial e gera resistência. A direção correta é o oposto — começar fechado e abrir seletivamente através de Sharing Rules quando uma necessidade real surge. **Quando usar Sharing Rule e quando usar Apex Managed Sharing?** Sharing Rule é adequado quando o critério para compartilhamento é derivado de um campo fixo ou da participação em uma função/grupo público. Apex Sharing é necessário quando o critério depende de uma lógica que muda em tempo de execução — por exemplo, compartilhamento baseado em uma combinação de campos, no resultado de um cálculo ou em um evento de um sistema externo. **A Gestão de Territórios (Territory Management) vale a complexidade mesmo em uma organização de médio porte?** Geralmente não, a menos que pelo menos uma das seguintes condições exista: a atribuição de clientes muda de acordo com várias características simultaneamente (geografia, indústria, tamanho), é necessário acesso paralelo de vários representantes ao mesmo registro, ou a hierarquia organizacional e a hierarquia de compartilhamento já não são as mesmas. Abaixo desse limite, a Hierarquia de Funções e as Regras de Compartilhamento são suficientes e mais simples de manter. **Como identificar que o modelo de compartilhamento não é mais adequado para a organização?** Os sinais práticos são: o tempo de recálculo de compartilhamento (Sharing Recalculation) que se estende de execução para execução, chamados de suporte repetidos do tipo 'eu não vejo um registro que deveria ver', uso crescente de Compartilhamento Manual pontual como solução alternativa, e reclamações de que relatórios gerenciais mostram números diferentes dependendo de quem os executa. **O que acontece com o modelo de compartilhamento quando um usuário é movido entre funções ou departamentos?** Qualquer mudança de função aciona um recálculo do compartilhamento da Hierarquia de Funções. Se houver também Sharing Rules baseadas em grupo público, é necessário garantir que o usuário também seja atualizado lá — os dois mecanismos não se sincronizam automaticamente. Uma organização que faz mudanças estruturais frequentes precisa de um processo definido, incluindo a verificação de que o acesso antigo foi bloqueado e não apenas que um novo acesso foi aberto. --- ## Tratamento de Erros e Monitoramento de Integrações Salesforce de Ponta a Ponta URL: https://hpi.pro/pt/insights/salesforce-integration-error-handling A maioria das falhas de integração que chegam aos clientes não são causadas por uma API fora do ar, mas sim por uma mensagem que falhou silenciosamente e ninguém soube procurar. Este artigo desmembra a cadeia de tratamento de erros em quatro camadas – Idempotência, Retry, Dead Letter e Reconciliação – e demonstra onde cada uma delas falha na prática. ## Por que uma integração "funciona" em demonstrações e falha silenciosamente em produção Em um teste de aceitação padrão, enviamos uma única mensagem, confirmamos seu recebimento e a aprovamos. Em produção, a mesma integração processa milhares de mensagens por dia, e algumas delas falharão – devido a *timeouts*, bloqueios de linha, autorizações expiradas ou mudanças de esquema no outro sistema. A questão crucial que determina a qualidade da solução não é "a integração está funcionando?", mas sim "o que acontece quando ela não funciona, e quem percebe?". A maioria das falhas custosas que observei não decorreu de um *bug* no código da integração em si, mas da ausência de três capacidades: a identificação de que uma mensagem falhou, um mecanismo que tenta novamente sem criar duplicatas, e um processo que garante que a informação em ambos os sistemas esteja de fato consistente no final do dia. Sem isso, qualquer integração "funciona" até o momento em que se descobre que ela não funciona há duas semanas. ## As quatro camadas que compõem o tratamento adequado de erros | Camada | O que ela resolve | Falha típica sem ela | | --- | --- | --- | | Idempotência | A reexecução da mesma mensagem não cria um registro duplicado | Pedido duplicado ou movimento de estoque duplicado após a Retentativa | | Retentativa com *Backoff* | Falha temporária (*Timeout*, *Rate Limit*) é corrigida automaticamente | Carga inesperada momentânea se torna um problema persistente | | *Dead Letter Queue* | Falha não temporária é sinalizada e não desaparece silenciosamente | Mensagem é "engolida" e as partes envolvidas pensam que foi processada | | Reconciliação de Negócios | Lacunas de dados que não foram explicitamente identificadas são reveladas | Relatório mensal revela uma inconsistência cuja origem é difícil de rastrear | Cada camada depende da anterior. Uma retentativa sem idempotência cria duplicatas; uma *Dead Letter* sem reconciliação esconde o fato de que, mesmo mensagens "tecnicamente" bem-sucedidas, não necessariamente refletem a situação de negócios correta. ## Idempotência: A chave para prevenir duplicação Toda integração que pode receber a mesma mensagem mais de uma vez – e quase todas as integrações se enquadram nessa categoria – precisa de um identificador externo único (*External ID*) que identifique o evento, e não apenas o registro. No Salesforce, a implementação comum é um *Upsert* por meio de um campo *External ID* com restrição de unicidade, combinado com uma tabela de log (*Custom Object* ou *Platform Event Log*) que registra quais identificadores de evento já foram completamente processados. O erro comum: contentar-se com um *Upsert* no próprio registro de negócio (por exemplo, *Order External ID*) sem documentar os estágios intermediários. Se o processo também envolve a atualização de estoque em um sistema externo, um *Upsert* na ordem não impede uma repetição de chamada para a atualização de estoque – cada suboperação com um efeito colateral externo (*Side Effect*) deve ser idempotente por si só, não apenas o registro final. ## Retentativa: Política de *Backoff* e Classificação de Erros Nem todo erro merece uma retentativa. É preciso separar previamente três categorias: - **Erros Temporários** (*Timeout*, 503, *Rate Limit*) – Candidatos a retentativa com *Exponential Backoff*, ou seja, o intervalo entre as tentativas aumenta (por exemplo, 30 segundos, 2 minutos, 10 minutos) para não agravar a carga. - **Erros Estruturais** (campo obrigatório ausente, violação de *Validation Rule*, valor inválido) – Não devem ser retentados, pois falharão novamente da mesma forma. Eles precisam ser direcionados diretamente para a *Dead Letter*. - **Erros de Autorização ou Configuração** (*Token* expirado, mudança de *API Version*) – Exigem notificação imediata à equipe técnica, pois bloqueiam toda a fila e não apenas uma única mensagem. No Salesforce, a implementação de retentativa geralmente é feita na camada do *Middleware* ou em *Apex Queueable*/*Batch* com um contador de tentativas armazenado no próprio registro. Um número razoável de tentativas para a maioria dos casos é de 3-5 com *Backoff*, não uma retentativa infinita – uma retentativa sem limite transforma uma falha temporária em uma carga contínua para ambos os sistemas. ## *Dead Letter Queue*: Onde as mensagens com falha "vivem" Uma *Dead Letter* não é apenas um local de armazenamento; é um contrato. Cada mensagem que chega até ela deve conter: identificador de evento original, *Payload* completo, motivo de falha classificado, número de tentativas realizadas e tempo de entrada na fila. Sem essas informações, o "tratamento" de uma *Dead Letter* se torna um exercício de adivinhação. Duas abordagens comuns para implementação no Salesforce: 1. **Custom Object dedicado** (`Integration_Failed_Message__c`) com campos estruturados e *List View* por tipo de erro – adequado quando a equipe de negócios precisa de visibilidade dentro do próprio Salesforce. 2. **Fila externa na camada de *Middleware*** (por exemplo, *Dead Letter Exchange* no MuleSoft/Boomi) – adequado quando a equipe técnica monitora externamente ao Salesforce e deseja evitar sobrecarga na *Org*. A escolha depende de quem deve agir sobre a falha: se for o proprietário do processo de negócio, ele precisa ver isso dentro do Salesforce; se for a equipe técnica de integração, é preferível na camada externa. ## Reconciliação de Negócios: O teste que revela o que a retentativa não detectou Mesmo com idempotência e retentativa perfeitas, existem falhas que "são bem-sucedidas" do ponto de vista técnico, mas criam uma lacuna de negócios – por exemplo, uma mensagem que foi recebida e processada, mas com um valor incorreto proveniente de uma fonte de dados desatualizada. A reconciliação é um processo periódico (diário, horário, dependendo da frequência dos eventos) que compara uma contagem ou um somatório acumulado entre os dois sistemas – por exemplo, o número de pedidos criados no ERP versus o número de pedidos criados no Salesforce para o mesmo dia – e destaca as diferenças antes que se tornem um problema de serviço ao cliente. Um bom processo de reconciliação não exige uma verificação campo por campo de cada registro; uma soma de verificação (*Checksum*) ou uma contagem acumulada que sinaliza quando é preciso detalhar é suficiente. Na maioria das organizações, uma frequência diária é suficiente; em processos financeiros ou críticos (pedidos, faturamento), é necessária uma verificação em poucas horas. ## *Decision Framework*: Quando cada camada é obrigatória e quando pode ser dispensada | Critério | Idempotência Obrigatória | Retentativa Automática Obrigatória | *Dead Letter* Separada Obrigatória | Reconciliação Diária Obrigatória | | --- | --- | --- | --- | --- | | O evento cria movimento financeiro ou de estoque | Sim | Sim | Sim | Sim | | O evento é unidirecional, apenas leitura (*Read*) | Não crítico | Sim | Não | Não | | Volume acima de 500 mensagens por dia | Sim | Sim | Sim | Recomendado | | Parceiro externo sem SLA de alta disponibilidade | Sim | Sim, com *Backoff* longo | Sim | Recomendado | | Integração entre dois objetos não financeiros de baixo volume | Recomendado | Recomendado | Não essencial | Não | A regra que orienta a tabela: quanto maior o impacto financeiro ou irreversível de uma falha (envio, faturamento, atualização de estoque), todas as quatro camadas passam de "desejável" para "obrigatória" – independentemente do volume. ## Cenário de Exemplo: Varejista com sincronização de pedidos bidirecional Uma empresa varejista com 40 filiais utiliza o Salesforce para gerenciar pedidos B2B e um ERP externo para estoque e faturas. A integração foi construída originalmente com uma chamada REST simples: quando um pedido é criado no Salesforce, uma chamada síncrona o cria no ERP. Sem retentativa, sem *Dead Letter*. Durante um período de alta demanda (*Black Friday*), o ERP começou a retornar *Timeout* em cerca de 3% das chamadas. Sem um mecanismo de retentativa, esses 3% simplesmente "desapareceram" – o pedido permaneceu no Salesforce com status "enviado" sem que o ERP soubesse dele. Em dois dias, acumularam-se cerca de 140 pedidos que não chegaram ao processo de empacotamento, e foram descobertos apenas quando os clientes ligaram para perguntar sobre o paradeiro da mercadoria. A solução desenvolvida subsequentemente: uma camada *Queueable* no Apex que tenta novamente até 5 vezes com *Backoff* de 1/5/15/30/60 minutos; um campo `ERP_Sync_Status__c ` com valores Pending/Synced/Failed; um *Custom Object* `Integration_Failed_Message__c ` que centraliza as falhas finais com um botão "Processar Novamente" para a equipe de operações; e um relatório de reconciliação diária que compara a contagem de pedidos entre os sistemas e envia um alerta no Slack quando a diferença excede zero. O tempo de detecção de uma falha semelhante diminuiu de dois dias para menos de uma hora. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Retentativa infinita de erros estruturais | A mesma mensagem falha repetidamente, gerando carga | Classificar erros previamente e enviar erros estruturais diretamente para a *Dead Letter* | | Ausência de um identificador único de evento | Retentativas ou chamadas duplicadas criam registros duplicados | *External ID* no evento, não apenas no registro final | | *Dead Letter* sem Proprietário | Mensagens se acumulam e ninguém as resolve | Definir Proprietário e SLA de tratamento por tipo de evento, não por sistema | | Monitoramento apenas técnico (status de API) | A integração está "verde", mas os dados de negócio não estão alinhados | Adicionar Reconciliação que compare o resultado de negócio, não apenas o código de resposta | | *Backoff* fixo e muito curto | Tentativas repetidas agravam a carga durante uma falha generalizada | *Exponential Backoff* com um limite de tentativas definido | ## *Checklist* antes da aprovação do design de tratamento de erros - ☐ Cada evento possui um identificador único (*External ID*) que impede duplicidade em reexecuções - ☐ Erros são classificados previamente em temporários/estruturais/autorização, com tratamento distinto para cada tipo - ☐ Uma política de *Backoff* é definida com um número máximo de tentativas - ☐ Existe uma *Dead Letter* acessível com *Payload* completo e motivo de falha - ☐ Há um Proprietário e um SLA de tratamento definidos para cada tipo de falha - ☐ Existe um processo de Reconciliação periódico que compara o resultado de negócio entre os sistemas - ☐ Alertas chegam a um canal onde alguém realmente os lê (não apenas para logs) - ☐ O cenário de teste inclui a interrupção do serviço do outro sistema, não apenas o *Happy Path* ## Como isso se conecta ao restante da arquitetura O design do tratamento de erros não é um recurso isolado – ele se apoia na camada de dados e permissões definida no [Guia de Arquitetura de CRM](/pt/insights/crm-architecture-guide), e na decisão se a lógica é implementada em Flow ou Apex, conforme [Salesforce Flow ou Apex](/pt/insights/salesforce-flow-vs-apex). O modelo de permissões pelo qual os componentes de integração escrevem dados deve ser verificado em relação ao [Modelo de Permissões do Salesforce](/pt/insights/salesforce-permission-model), para que um usuário técnico da integração não obtenha acesso excessivamente amplo. E à medida que o volume de mensagens aumenta, a questão da retentativa se encontra diretamente com as limitações de API detalhadas em [Limites de API do Salesforce](/pt/insights/salesforce-api-limits-resilience). ## Conclusão O tratamento de erros de integração não é um recurso a ser adicionado no final – é a diferença entre um sistema que se revela quebrado depois que um cliente reclamou, e um sistema que se alerta antes que o dano se acumule. As quatro camadas – Idempotência, Retentativa classificada, *Dead Letter* com Proprietário, e Reconciliação de Negócios – não exigem um projeto separado, mas demandam uma decisão explícita na fase de planejamento, antes que a primeira integração entre em produção. Uma organização que se alerta sobre 3% de mensagens com falha em uma hora é fundamentalmente diferente de uma organização que descobre isso por um cliente insatisfeito. ### Perguntas e respostas **Qual a diferença entre Retry automático e Dead Letter Queue?** O Retry tenta executar novamente uma chamada que falhou por um motivo temporário – Timeout, bloqueio de linha, limitação de taxa – de acordo com uma política de Backoff definida. Quando o número de tentativas se esgota ou o erro é classificado como não-recuperável (por exemplo, campo obrigatório ausente), a mensagem é movida para uma Dead Letter Queue: um local onde aguarda tratamento manual ou automático separado, sem bloquear o restante da fila. **Como manter a Idempotência quando um sistema externo envia a mesma mensagem duas vezes?** É necessário ter um identificador externo (External ID) único que identifique o evento, e não apenas o registro, e uma verificação de existência antes da criação – Upsert com base nesse mesmo identificador. Se o evento também incluir uma transação financeira ou alteração de estoque, é necessária uma tabela de log separada que registre quais IDs de evento já foram processados, para que uma execução duplicada não gere um movimento duplicado. **Por quanto tempo uma mensagem pode permanecer em uma Dead Letter Queue antes de se tornar um problema de negócios?** Não há uma resposta universal – isso depende do processo. Um pedido não sincronizado em uma hora pode causar entrega duplicada; uma atualização de contato pode esperar um dia. A regra prática é definir um SLA de tratamento com base no tipo de evento e não no tipo de sistema, e garantir que esse SLA se traduza em um alerta real, e não apenas em uma linha no log. **Quem é responsável por uma mensagem travada – a equipe do Salesforce ou a equipe do outro sistema?** A responsabilidade operacional deve ser de quem detém a camada de integração, e não de um dos dois sistemas separadamente. Se não houver tal camada e a mensagem passar de ponto a ponto, é preciso definir previamente uma tabela de escalonamento: que tipo de erro vai para a equipe do Salesforce, que tipo para o proprietário da API externa, e quem decide em quanto tempo quando não está claro. **O Middleware resolve automaticamente a questão do tratamento de erros?** Não. Ferramentas de Middleware (como MuleSoft, Boomi ou outras plataformas iPaaS) fornecem infraestrutura para Retry, Queue e monitoramento, mas a política de Backoff, a classificação de erros e a reconciliação de negócios ainda precisam ser definidas pela organização. Uma ferramenta sem política gera um log detalhado de falhas que ninguém resolve. --- ## Dívida Técnica em Flows e Apex: Como Identificar e Reduzir sem Parar o Desenvolvimento URL: https://hpi.pro/pt/insights/salesforce-flow-apex-technical-debt A dívida técnica nas automações Salesforce não surge de uma escolha errada entre Flow e Apex, mas de centenas de pequenas decisões tomadas sem uma política clara e sem uma visão acumulada. Este artigo mostra como identificá-la na prática — através de métricas, não de intuição — e como construir um plano de redução que não interrompa o ritmo de desenvolvimento. ## Por que a Dívida Técnica em Automações Difere da Dívida Técnica Regular No Salesforce, é mais fácil acumular dívida técnica do que em um ambiente de desenvolvimento tradicional, pois a ferramenta permite que qualquer pessoa adicione automação sem passar por um processo formal de código. Cada Admin que adiciona um Flow Before Save para resolver um problema pontual, cada Trigger que alguém adicionou há dois anos e ninguém se lembra o porquê, e cada campo de fórmula que contém uma dependência de um campo que não existe mais — tudo isso se acumula em uma camada que ninguém vê em sua totalidade. A diferença fundamental entre a dívida técnica regular e a dívida técnica em automações Salesforce é que esta última quase sempre carece de documentação centralizada. O código reside em um Repository com histórico de Commits; um Flow reside em Setup sem explicação de por que foi criado. Isso torna a fase de identificação particularmente difícil — não porque o problema seja tecnicamente complexo, mas porque não há a quem perguntar. Este artigo trata da identificação, medição e redução dessa dívida. Ele não discute a questão de quando escolher Flow e quando Apex inicialmente — para isso, há um artigo dedicado: [Flow vs. Apex: Como Escolher](/pt/insights/salesforce-flow-vs-apex). ## Três Tipos de Dívida que se Comportam Diferentemente Nem toda dívida técnica é igual, e o tratamento abrangente de todas como o mesmo problema leva ao desperdício de esforço. É aconselhável separar em três categorias: | Tipo de Dívida | Exemplo Típico | O que acontece se ignorada | Prioridade de Tratamento | |---|---|---|---| | Dívida Estrutural | Vários Triggers no mesmo objeto sem um Framework unificador | Ordem de execução imprevisível, falha silenciosa | Alta | | Dívida Lógica | Flow com dezenas de ramificações de decisão que representam uma regra de negócio já alterada | Decisões errôneas executadas silenciosamente | Alta | | Dívida de Manutenção | Campos, Flows e variáveis permanentes sem documentação ou uso | Tempo de desenvolvimento prolongado, medo de tocar | Média | A dívida estrutural e a dívida lógica geram risco operacional real — elas podem causar dados incorretos que chegam ao cliente ou a um relatório financeiro. A dívida de manutenção retarda a equipe, mas não necessariamente quebra um processo. Esta divisão determina a ordem de tratamento: primeiro, remove-se o risco operacional, depois melhora-se a velocidade de desenvolvimento. ## Como Identificar a Dívida Antes que Exploda em Produção A identificação não deve começar com uma revisão manual e abrangente de código — isso é muito caro e insustentável. Ela começa com alguns indicadores quantitativos que podem ser extraídos em uma hora: * **Número de Flows ativos em cada objeto principal** (Lead, Opportunity, Case, etc.). Acima de cinco ou seis Flows ativos no mesmo objeto, a ordem de execução torna-se difícil de prever. * **Número de Triggers que não estão unificados sob um único Framework** para cada objeto. Mais de um Trigger por objeto já é um sinal de alerta, a menos que exista uma camada de roteamento explícita. * **Densidade de consultas SOQL dentro de loops** que aparece nos logs como Governor Limit próximo ao limite, mesmo que não tenha sido efetivamente cruzado. * **Tempo de execução incomum de Flow ou Apex Batch** que aumenta ao longo do tempo sem que o volume de negócios cresça na mesma proporção. * **Campos e variáveis sem uso identificado** no relatório Field Usage, que permanecem "apenas no caso de alguém precisar". Esses indicadores não provam um problema inequívoco, mas fornecem uma lista focada de suspeitos. A combinação deles com uma compreensão profunda das integrações das quais a automação depende é detalhada em [Padrões de Integração Salesforce](/pt/insights/salesforce-integration-patterns). ## Decision Framework: O que Tratar Primeiro Nem todo achado na lista de suspeitos merece o mesmo investimento. Um Framework simples para priorização baseado em dois eixos — impacto de negócio e probabilidade de falha: | Situação | Impacto de Negócio em caso de falha | Probabilidade de Falha a Curto Prazo | Ação | |---|---|---|---| | Automação em processo de pedido/faturamento com múltiplos Triggers não documentados | Alta | Alta | Refactor imediato, fora da fila normal | | Flow complexo em atualização de status interno sem impacto externo | Baixa | Alta | Documentação e simplificação em ritmo normal | | Trigger antigo que funciona de forma estável, mas não está claro por que existe | Potencialmente alta | Baixa | Documentação primeiro, sem intervenção imediata | | Campos não utilizados e variáveis permanentes órfãs | Baixa | Baixa | Limpeza cíclica no nível do Release | A regra orientadora: não se trata o que mais incomoda os desenvolvedores, mas sim o que é mais perigoso para o negócio. Um Trigger antigo e estável que ninguém entende é, muitas vezes, o caso mais tentador para se mexer primeiro — e é exatamente o caso em que uma intervenção descuidada causa o maior dano. ## Cenário Organizacional: Uma Seguradora com 14 Flows na Opportunity Suponha uma seguradora de médio porte que gerencia vendas B2B através do Salesforce há seis anos. Ao longo do tempo, acumularam-se 14 Flows ativos no objeto Opportunity: sete tratam de atualizações de estágio, três enviam notificações internas, dois sincronizam dados com uma ferramenta de BI externa, e outros dois são resquícios de um processo antigo que foi substituído há dois anos, mas nunca desativado. O gatilho para identificar o problema foi uma falha concreta: uma transação passou para o estágio "Fechado-Ganho", mas a notificação para a equipe de subscrição não foi enviada, porque um outro Flow atualizou o mesmo campo em paralelo e criou uma sequência de execução não prevista. A equipe passou dois dias tentando entender o porquê — não porque o bug fosse complexo, mas porque ninguém sabia a ordem de execução completa dos 14 componentes. O tratamento não foi "reescrever tudo em Apex". A equipe primeiro mapeou todos os 14 Flows e os classificou de acordo com a tabela acima: os dois Flows antigos foram desativados após verificar que não havia dependência ativa, as três notificações foram unificadas em um único Flow com lógica de roteamento clara, e as sete atualizações de estágio foram unificadas sob um único Record-Triggered Flow com ordem de execução explícita. Resultado: de 14 componentes para 6, com documentação da ordem de execução que qualquer novo desenvolvedor pode ler em quinze minutos. ## Riscos no Processo de Redução em si A redução da dívida técnica é uma operação com riscos próprios, não apenas uma correção de um risco existente: | Risco | Como se manifesta na prática | Ação de Prevenção | |---|---|---| | Mudança na ordem de execução que quebra uma dependência oculta | Processo que funcionava para de funcionar após a unificação de Flows | Mapeamento completo de dependências e teste de Regressão antes de qualquer unificação | | Exclusão de um componente "morto" que na verdade ainda é executado em um cenário raro | Falha que aparece apenas no final do trimestre ou em um cenário sazonal de ponta | Verificação de logs de execução durante um ano completo, não apenas o último mês | | Conversão para Apex sem um proprietário de processo que entenda a regra de negócio | O novo código é "tecnicamente correto", mas implementa uma regra antiga que já foi alterada | Verificação da regra de negócio com o proprietário do processo antes de escrever o código, não apenas com o código existente | | Refactor feito em uma única Sandbox e não sincronizado | O problema retorna no ambiente de produção após o próximo Deploy | Gerenciar a mudança através de um processo de Release regular e não como uma correção "fora da fila" | O risco comum a todos é o mesmo fenômeno: a equipe acredita que está "apenas limpando" e, portanto, pula os testes que faria para um novo recurso. No nível de Governance, um Refactor deve passar pelo mesmo processo de aceitação que um desenvolvimento regular — não menos. ## Métricas para Monitoramento Contínuo da Redução Para saber se o esforço está realmente reduzindo a dívida e não apenas a deslocando, é aconselhável monitorar: * **Número de componentes de automação ativos por objeto**, como uma métrica de tendência trimestral e não pontual. * **Tempo médio para diagnóstico de falha de automação**, desde o momento do relatório até a identificação do componente responsável. * **Porcentagem de componentes documentados** do total de automações ativas no cluster principal. * **Número de falhas recorrentes no mesmo componente** em um período de três meses. Organizações que têm dificuldade em priorizar entre Refactor e desenvolvimento contínuo utilizam o [serviço de arquitetura de CRM](/pt/crm-architecture) para construir um plano de trabalho vinculante e mensurável. ## Checklist Operacional Antes de Iniciar um Refactor * ☐ Existe um mapa completo de todas as automações ativas no objeto relevante. * ☐ A ordem de execução real é conhecida, não apenas pela ordem de criação. * ☐ Cada componente destinado à remoção foi verificado em relação aos logs de execução de um ano completo. * ☐ O proprietário do processo de negócio aprovou a regra que está sendo reimplementada. * ☐ Existe um ambiente de teste que simula volumes de dados reais. * ☐ Uma métrica "antes e depois" foi definida para o número de componentes e o tempo de diagnóstico. * ☐ O processo de Refactor segue um Release normal, não um Deploy excepcional. * ☐ Capacidade fixa foi alocada em cada Sprint para tratamento contínuo, não apenas um evento único. ## Conclusão A dívida técnica em automações Salesforce é construída silenciosamente, um componente por vez, e, portanto, também deve ser desmantelada silenciosamente — não em um grande projeto de limpeza que paralisa o desenvolvimento por um mês. As ferramentas necessárias são relativamente simples: contagem de componentes por objeto, mapeamento da ordem de execução e classificação por impacto de negócio versus probabilidade de falha. O que determina o sucesso é a continuidade — a alocação de capacidade fixa para a redução da dívida ao lado do desenvolvimento contínuo, e não a perseguição pontual do componente que causou a última falha. Uma organização que adota tal hábito de medição atinge um estado em que qualquer novo desenvolvedor pode entender em uma hora o que acontece ao salvar um registro — e isso, no final das contas, é a definição mais prática de ausência de dívida técnica. ### Perguntas e respostas **Quantos Flows no mesmo objeto são considerados muitos?** Não existe um número mágico, mas há um sinal claro: quando um desenvolvedor não consegue prever o que acontecerá ao salvar um registro sem abrir toda a lista e seguir a ordem de execução, já existe um problema operacional — mesmo que sejam apenas três Flows. O problema não é a quantidade, mas a falta de coordenação e documentação da ordem de execução entre eles. **É possível reduzir a dívida técnica sem parar o desenvolvimento de novas funcionalidades?** Sim, e geralmente essa é a abordagem correta. Aloca-se uma porcentagem fixa de cada Sprint — por exemplo, um décimo da capacidade — para a redução da dívida com base em uma lista de prioridades, em vez de solicitar um 'Sprint de Congelamento' dedicado, que quase sempre é adiado quando a vez das prioridades de negócio chega. **Quando converter um Flow para código Apex por causa da dívida técnica?** Quando o Flow contém lógica complexa com mais do que alguns ramos de decisão, quando ele chama a mesma consulta várias vezes devido a uma estrutura modular deficiente, ou quando precisa ser testado com testes automatizados que as ferramentas gráficas não suportam adequadamente. A conversão em si é uma ferramenta técnica; a decisão deriva da medição da complexidade real e não de uma preferência estilística. **Como medir a dívida técnica sem pagar por uma ferramenta externa?** É possível começar com o Salesforce Optimizer e os relatórios internos de Configuração para contar Flows ativos por objeto, juntamente com uma consulta da Tooling API sobre os limites do Apex e Debug Logs para tempos de execução incomuns. Isso não é um substituto completo para uma ferramenta dedicada de Análise Estática, mas é suficiente para construir uma primeira lista de prioridades. **O que fazer quando a equipe de desenvolvimento se opõe a investir tempo em Refactoring?** Apresente o custo em termos que a gestão compreenda: horas de suporte repetidas para o mesmo problema, tempo de lançamento de versão estendido e risco concreto para um processo de negócio central. Um Refactoring apresentado como 'limpeza de código' é quase sempre rejeitado; um Refactoring apresentado como redução de risco operacional é priorizado. --- ## Modelagem de Dados no Salesforce: Standard Objects, Custom Objects e Decisões Chave URL: https://hpi.pro/pt/insights/salesforce-data-model-design A modelagem de dados é a decisão mais custosa e difícil de alterar após o Go Live. Este guia aborda quando manter-se em Standard Objects, quando um Custom Object se justifica, como escolher entre Lookup e Master-Detail, e como um modelo que parece limpo no "workshop" pode gerar restrições de relatórios, permissões e desempenho anos depois. ## A Resposta Concisa Um bom modelo de dados no Salesforce não é o mais teoricamente elegante, mas sim aquele que harmoniza três elementos simultaneamente: o processo de negócio, o modelo de permissões e os relatórios necessários. A maioria dos modelos falhos concentra-se apenas no primeiro. A diferença entre uma decisão de modelo e outras decisões de projeto reside no custo da mudança. Adaptar um Flow leva um dia; alterar o tipo de relacionamento entre objetos após dois anos de dados, automações e integrações é um projeto por si só. Portanto, o investimento na fase de planejamento é crucial aqui, mais do que em qualquer outro lugar. ## A Primeira Regra: Comece Pelos Objetos Padrão Account, Contact, Lead, Opportunity, Case e Product vêm com funcionalidades que não são gratuitas para objetos personalizados: processos de vendas, Forecasting, Entitlements, Omni-Channel, aplicativo móvel e integração nativa com outros produtos na plataforma. Uma organização que cria um `Customer__c` em vez de um Account pode, inicialmente, ter um modelo que parece mais organizado, mas depois descobre que cada funcionalidade padrão exige construção independente. A regra é: desvie do padrão apenas se houver uma razão clara que possa ser articulada em uma única frase. ## Quando um Objeto Personalizado é Necessário | Cenário | Objeto Personalizado? | Justificativa | |---|---|---| | Contrato/Assinatura com ciclo de vida próprio | Sim | Status, renovação, propriedade e relatórios separados | | Ativo instalado no cliente | Sim (ou Asset padrão) | Entidade independente com histórico de serviço | | "Prospect" adicional | Não | Use Lead ou Account com Record Type | | Departamento na organização | Não | Dado de usuário, não uma entidade | | Linhas de preço complexas | Depende | Avalie Quote Line ou CPQ antes de construir | ## Normalização Versus Desnormalização: A Escolha que Afeta os Relatórios Em bancos de dados clássicos, a normalização é uma virtude. No Salesforce, ela é trocada pela facilidade de geração de relatórios: cada nível adicional de relacionamento dificulta a construção de relatórios sem ferramentas externas, pois os relatórios padrão são limitados pela profundidade dos relacionamentos. O compromisso comum é a normalização onde os dados mudam e são duplicados, e uma desnormalização controlada de campos de consulta comuns no objeto a partir do qual os relatórios são gerados – desde que a duplicação seja gerenciada automaticamente e não manualmente. Um campo duplicado que é atualizado por entrada manual se torna obsoleto em questão de meses. ## Permissões São Parte do Modelo, Não Uma Etapa Posterior A pergunta "quem vê o quê" deve ser feita ao desenhar os objetos. Um modelo em que dados sensíveis residem no mesmo objeto que dados operacionais força soluções alternativas – objetos sombra, campos criptografados ou uma visibilidade excessivamente ampla. O teste prático: para cada novo objeto, anote uma linha – quem é o proprietário, quem lê, quem modifica e o que acontece na hierarquia. Se a resposta exigir mais de quatro linhas, a estrutura provavelmente está misturando duas entidades. Para mais informações sobre fontes de informação e autoridade de atualização, veja [Source of Truth na organização](/pt/insights/salesforce-source-of-truth), e sobre gestão de entidades principais em [Master Data Management](/pt/insights/salesforce-master-data-management). ## Cenário: Uma Empresa de Software Que Construiu um Modelo em Torno de Departamentos Uma empresa SaaS de médio porte construiu um modelo com quatro objetos personalizados – um para cada equipe de vendas – porque cada equipe tinha um processo diferente. Um ano e meio depois, as equipes foram unificadas, exigindo a unificação de relatórios, automações paralelas em quatro locais e uma migração interna de 60 mil registros entre objetos. A reconstrução baseou-se em um único Opportunity com Record Types para os diferentes processos. A mesma distinção de negócio foi mantida – diferentes pipelines de vendas, diferentes campos, diferentes Page Layouts – mas no nível da configuração e não no nível da estrutura. A próxima mudança organizacional exigirá uma mudança de Record Type, não uma migração. A regra que surgiu disso: a estrutura representa entidades; a configuração representa a organização. O que é esperado mudar a cada dois anos não deve residir na estrutura. ## Desempenho e Volume - O Que Realmente Importa Problemas de desempenho em modelos de dados surgem principalmente de três fontes: Data Skew (um único pai com dezenas de milhares de filhos, por exemplo, o Account "Clientes Particulares"), fórmulas aninhadas que calculam em tempo real em múltiplos relacionamentos, e compartilhamento baseado em Apex Sharing criado em grande escala. Todos os três podem ser identificados na fase de planejamento se for perguntado quantos registros são esperados sob cada pai. ## Riscos Comuns e Ações Preventivas | Risco | Como se Manifesta na Prática | Ação Preventiva | |---|---|---| | Objeto Personalizado Desnecessário | Funcionalidades padrão são recriadas manualmente | Verifique os objetos padrão antes de criar um novo objeto | | Master-Detail Precoce Demais | Exclusões em cascata e estrutura imutável | Comece com Lookup se não houver necessidade de Roll-Up | | Modelo que Reflete a Organização | Cada mudança organizacional se torna uma migração | Use Record Types em vez de objetos | | Data Skew | Bloqueios e lentidão em atualizações em massa | Distribuição equitativa de pais, verificação de volume no planejamento | | Permissões como Pensamento Posterior | Soluções alternativas e visibilidade excessivamente ampla | Matriz de acesso para cada objeto no planejamento | ## Como Medir o Sucesso | Área | O que Medir | Frequência de Verificação | |---|---|---| | Uso de Campos | Taxa de preenchimento por campo | Trimestral | | Relatórios | Porcentagem de relatórios que exigem consolidação manual | Trimestral | | Estabilidade da Estrutura | Número de mudanças estruturais por semestre | Semestral | | Desempenho | Tempos de atualização em massa e bloqueios | Mensal | O planejamento do modelo de dados como parte de uma arquitetura abrangente é realizado no âmbito do [serviço de integrações e dados](/pt/integrations-data). ## Checklist Antes de Congelar o Modelo - ☐ Para cada objeto personalizado, há uma justificativa em uma frase - ☐ Foi verificado um objeto padrão alternativo para cada entidade - ☐ O tipo de relacionamento foi selecionado explicitamente com uma justificativa para Master-Detail - ☐ O volume esperado para cada pai foi estimado (teste de Skew) - ☐ Matriz de acesso: proprietário, leitor, modificador, hierarquia - ☐ Foi verificado que cada relatório central pode ser construído no modelo - ☐ Campos duplicados são atualizados apenas automaticamente - ☐ Mudanças organizacionais esperadas são tratadas na configuração - ☐ Existe um ERD atualizado e documentado - ☐ Foi determinado quem aprova futuras mudanças de estrutura ## Recursos Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Quando um Custom Object se justifica e quando é um erro?** Ele se justifica quando a entidade possui seu próprio ciclo de vida – status, propriedade, permissões e relatórios separados. É um erro quando criado apenas para evitar campos adicionais em um objeto existente, ou para refletir uma estrutura organizacional. Estruturas organizacionais mudam; os objetos não se movem facilmente com elas. **Lookup ou Master-Detail?** Master-Detail oferece Roll-Up Summary e herança de permissões, mas é rígido: a exclusão do pai exclui os filhos, e o registro não pode existir sem um pai. Lookup é mais flexível e pode ser modificado posteriormente. A regra prática: Master-Detail apenas quando o filho é realmente sem significado sem o pai e é necessário um resumo automático. **Quantos campos são demais em um objeto?** O número é menos importante do que o uso. Um objeto com 200 campos, todos utilizados para relatórios, é aceitável; um objeto com 60 campos, a maioria vazia em 80% dos registros, indica entidades que foram agrupadas artificialmente. A melhor verificação é a taxa de preenchimento por campo, não apenas a contagem. **É necessário espelhar a estrutura do ERP no Salesforce?** Não. O ERP é projetado em torno de transações, o Salesforce em torno de relacionamentos e processos. Um espelhamento completo gera dezenas de objetos que ninguém usa. Transfira para o Salesforce apenas o que é necessário para o processo de vendas e serviço, e para o restante utilize acesso remoto ou Data 360. **Como saber se o modelo não será sustentável?** Três sinais antecipados: relatórios que exigem união manual entre objetos, campos de fórmula aninhados profundamente para compensar a estrutura, e solicitações de permissão que não podem ser implementadas sem abrir uma visibilidade ampla. Cada um deles indica que a estrutura não se alinha ao processo. --- ## Master Data Management (MDM) com Salesforce: Governança de Dados e Golden Record URL: https://hpi.pro/pt/insights/salesforce-master-data-management Projetos de MDM falham quando encarados apenas como empreitadas tecnológicas e prosperam quando compreendidos como regimes de governança de dados. Este guia explora quais entidades realmente demandam gestão Master, como construir um Golden Record entre CRM e ERP sem causar disrupções, quando uma ferramenta de MDM dedicada é necessária e quando o Salesforce é suficiente, além de como medir a eficácia da sua estratégia. ## A Resposta Curta Master Data Management (MDM) não é um repositório; é um acordo. Este acordo define quem estabelece a entidade, quem está autorizado a modificá-la, como identificar duas entradas como a mesma entidade e o que acontece quando os sistemas divergem. A tecnologia apenas garante a aplicação do que foi acordado. O erro comum é começar pela escolha da ferramenta. Uma organização que não definiu claramente o que constitui um "cliente" acabará com uma ferramenta que unificará essa mesma ambiguidade, porém de forma mais rápida e com um custo mais elevado. ## O Que Entra e o Que Não Entra no Master Data | Tipo de Dado | Exemplo | É Master Data? | | --- | --- | --- | | Master Data | Cliente, Produto, Fornecedor, Local | Sim | | Reference Data | Países, Moedas, Códigos de Indústria | Gerenciamento separado e mais simples | | Transacional | Pedido, Fatura, Case | Não | | Analítico | Segmentação, Pontuação, Previsão | Não - É derivado | Esta distinção é crucial, pois cada tipo requer uma governança diferente. O Reference Data é controlado em uma pequena tabela com um único proprietário; os dados Transacionais permanecem no sistema que os gerou; e os dados Analíticos não devem se tornar uma fonte de verdade, pois são o produto de um cálculo que pode mudar. ## Três Estilos de Implementação **Registry** - Gerencia apenas uma tabela de identificadores que interliga registros em diferentes sistemas. É de baixo custo, rápido, não altera nenhum sistema existente e fornece uma visão unificada para consulta. Quase sempre adequado como primeira etapa. **Consolidation** - Cria um Golden Record para fins de relatório e análise, sem sincronizar de volta aos sistemas de origem. Adequado quando a principal dor é a duplicação de relatórios. **Centralized** - O Master Data se torna a fonte autoritativa, e os sistemas consomem dele. Oferece o maior valor, mas também exige a maior governança e processos de aprovação. Organizações que pulam diretamente para esta etapa descobrem que não possuem as equipes (Stewards) para operá-lo. A abordagem prática é gradual: comece com um Registry para uma única entidade e, em seguida, expanda — com base em valor comprovado, e não em um plano mestre. ## Survivorship: As Regras Que Determinam o Que Permanece O cerne do Golden Record são as regras de Survivorship em nível de campo: para cada campo, há uma fonte preferencial e uma regra de fallback quando a fonte preferencial está vazia. Além disso, os identificadores dos sistemas de origem são sempre mantidos para que cada valor possa ser rastreado. Um princípio que evita discussões: o Golden Record não apaga os registros de origem e não se propõe a substituí-los. É uma camada que os referencia. Isso significa que uma regra pode ser corrigida e recalculada – uma capacidade ausente para quem consolidou tudo na fase de carregamento. Uma discussão mais aprofundada sobre a propriedade dos dados é abordada em [Source of Truth na Organização](/pt/insights/salesforce-source-of-truth) e na eliminação de duplicidades que precede isso em [Eliminação de Duplicidades no Salesforce](/pt/insights/salesforce-data-deduplication). ## Stewardship: O Papel Que Determina o Sucesso Todo regime de MDM gera uma fila de decisões: correspondências sobre as quais o sistema não tem certeza, solicitações para criar novas entidades e inconsistências entre as fontes. Se não houver uma pessoa com tempo alocado para resolver essa fila, ela crescerá até ser ignorada. Alcance realista: em uma organização de médio porte, isso significa algumas horas por semana para uma única entidade, geralmente alguém do lado comercial e não da TI. Este é o investimento que define se o MDM prospera ou se torna uma infraestrutura esquecida. ## Cenário: Um Fabricante Com Três Sistemas e Um Cliente Um fabricante industrial gerenciava seus clientes em três locais: ERP, Salesforce e um sistema de serviço. A mesma empresa aparecia como três entidades distintas, e um relatório de "receita por cliente" era gerado manualmente em Excel a cada trimestre. Em vez de um projeto completo de MDM, a organização começou com um Registry: foi criada uma tabela de identificadores no Data 360 que vinculava os três registros usando CPF/CNPJ e uma chave secundária, e só depois foi construído um Golden Record para consulta. O Salesforce não teve sua estrutura alterada; ele recebeu um campo de identificador global e uma visualização de "toda a atividade do grupo". O resultado após um trimestre: o relatório manual foi eliminado, e os vendedores viram pela primeira vez o risco de crédito em nível de grupo – o que impulsionou uma decisão de precificação que recuperou o custo da fase inicial. A expansão para um modelo Centralized foi considerada somente após a comprovação de que havia um Steward ativamente resolvendo a fila. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Começar pela ferramenta | Um repositório unificado que reflete a ambiguidade existente | Definições de entidade e propriedade antes da escolha da ferramenta | | Muitas entidades | Projeto longo sem valor visível | Uma entidade até a produção, depois expansão | | Ausência de Steward | Fila de reconciliações que cresce e é abandonada | Função com tempo alocado e SLA | | Fusão destrutiva | Impossibilidade de explicar ou reverter valores | Preservar identificadores de origem e permitir recálculo | | Centralized prematuro | Todos os sistemas dependem de uma infraestrutura imatura | Começar com Registry | ## Como Medir o Sucesso | Área | O Que Medir | Frequência de Verificação | | --- | --- | --- | | Cobertura | Percentual de registros vinculados a um identificador global | Mensal | | Precisão | Taxa de vínculos cancelados ou corrigidos | Mensal | | Fila de Stewardship | Itens abertos e tempo médio de resolução | Semanal | | Valor de Negócio | Relatórios manuais eliminados, decisões em nível de grupo | Trimestral | A construção de um regime de MDM escalonado é realizada como parte dos [serviços de integração e dados](/pt/integrations-data). ## Checklist Antes de Iniciar o MDM - ☐ Foram escolhidas até três entidades para a primeira fase - ☐ Para cada entidade, existe uma definição de negócio documentada - ☐ O estilo de implementação foi selecionado: Registry, Consolidation ou Centralized - ☐ Chaves de identificação robustas foram identificadas para cada fonte - ☐ Regras de Survivorship foram escritas em nível de campo - ☐ Identificadores de origem são mantidos e permitem recálculo - ☐ Um Steward foi nomeado com tempo alocado e SLA - ☐ Foi definido um processo de aprovação para a criação de novas entidades - ☐ Foi estabelecida uma métrica de valor para a primeira fase - ☐ Há uma decisão sobre quando considerar uma ferramenta especializada ## Recursos Profissionais - Salesforce Data 360 — [https://www.salesforce.com/data/](https://www.salesforce.com/data/) - Salesforce Data 360 Architecture — [https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html](https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html) - HPI Pro – Integrações e Dados — [https://hpi.pro/integrations-data](https://hpi.pro/integrations-data) ### Perguntas e respostas **Quais entidades realmente precisam de gestão Master?** Apenas aquelas que aparecem em mais de um sistema e que impactam finanças, regulamentação ou a experiência do cliente. Na maioria das organizações, trata-se de três a cinco entidades: Cliente/Fornecedor, Produto, Estrutura Organizacional-Comercial e, ocasionalmente, Localização ou Ativo. Tentar gerenciar 20 entidades simultaneamente é a maneira mais rápida de estagnar o projeto. **Uma ferramenta de MDM dedicada é necessária?** Nem sempre. Para até três sistemas de origem e complexidade de соответствие (matching) média, o Salesforce com External IDs, Matching Rules e integração gerenciada pode ser suficiente. Uma ferramenta dedicada justifica-se quando há múltiplas fontes, requisitos formais de Stewardship (gestão de dados), necessidade de histórico de alterações para conformidade regulatória, ou Survivorship (definição do dado mestre) complexo em nível de campo. **Qual a diferença entre MDM Registry, Consolidation e Centralized?** O MDM Registry armazena apenas o mapeamento de identificadores, mantendo os dados em suas fontes originais. O MDM Consolidation cria uma cópia unificada para fins exclusivos de relatórios. O MDM Centralized estabelece o repositório como a fonte autoritativa, da qual todos os sistemas leem. Quanto mais se avança na escala, maior o valor, mas também maior o custo de implementação e governança. **O Salesforce pode ser o sistema Master para dados de clientes?** Sim, especialmente quando o cliente é criado e gerenciado no processo de vendas. Na maioria das organizações, a solução de compromisso é uma divisão: identidade legal e termos comerciais no ERP, e entidade comercial e detalhes de contato no Salesforce, com um identificador comum que interliga os dois. **Quanto tempo leva para gerar valor inicial?** Para uma única entidade com duas fontes, leva de seis a doze semanas para ter um Golden Record ativo em produção. Projetos de MDM planejados para dois anos, visando uma 'infraestrutura completa', geralmente não sobrevivem a mudanças na liderança. É preferível ter uma entidade em produção do que uma arquitetura completa apenas em uma apresentação. --- ## Data 360 vs. Dados de CRM no Salesforce: Onde Armazenar Cada Informação? URL: https://hpi.pro/pt/insights/data-360-vs-crm-data Nem todo dado relacionado ao cliente precisa estar no CRM. Este guia diferencia dados operacionais que impulsionam processos diários de dados comportamentais de alto volume, destinados a unificação de perfil, segmentação e ativação, e demonstra como essa decisão afeta performance, custo, permissões e o potencial da IA. ## A Resposta Concisa A decisão entre CRM e Data 360 não se resume a "onde há espaço", mas sim a "quem consome os dados e em que ritmo". O CRM é construído em torno de um registro que alguém inicia, edita e processa. O Data 360 é centrado em um fluxo de eventos que é unificado em um perfil e utilizado para segmentação, análise e ativação. Quando os dois são misturados, obtêm-se um de dois resultados: um CRM pesado com milhões de registros que ninguém usa, ou uma camada de dados rica que ninguém ativa porque não chega ao fluxo de trabalho. ## Divisão Prática | Tipo de Informação | Onde | Justificativa | | --- | --- | --- | | Cliente, Contato, Oportunidade, Caso | CRM | Gerenciado manualmente, impulsiona processos e permissões | | Estágio de Venda, Tarefas, Aprovações | CRM | Automação e operação diária | | Cliques, Visualizações, Uso do Produto | Data 360 | Alto volume, não gerenciado manualmente | | Histórico de Transações do ERP | Data 360 (ou acesso virtual) | Volume e fonte de verdade externa | | Perfil Unificado e Identidade Cross-system | Data 360 | Sua função é unificar identificadores | | Pontuação, Segmentação, Recomendação | Calculado no Data 360, exibido no CRM | Cálculo em volume, uso no fluxo de trabalho | A última linha é o princípio central: calcule onde há volume, exiba onde há decisão. ## O Teste das Quatro Perguntas Antes de inserir um dado no CRM, pergunte: alguém o edita manualmente? A automação ou validação dependem dele? É necessário em um relatório operacional diário? Afeta permissões ou propriedade? Se a resposta para todas as quatro for não, o dado quase sempre pertence à camada de unificação. O inverso também é válido: um dado que é mantido apenas no Data 360, mas é necessário para tomada de decisão em tempo real, deve ter um mecanismo de retorno – um campo resumido, uma visualização ou uma ação – caso contrário, não impactará o resultado do negócio. ## Volume, Desempenho e Custo O CRM é precificado e projetado em torno de registros de negócios. Inserir eventos comportamentais nele altera o perfil de carga: atualizações em massa ficam lentas, a construção de relatórios se torna pesada, e o backup e os ambientes de teste crescem. O Data 360 é projetado para essa velocidade e precificado por consumo – o que exige uma atenção diferente: consultas amplas e fluxos redundantes geram um custo contínuo. Em ambos os casos, a higiene é a mesma: transferir apenas o que tem um consumidor e definir a retenção para cada fluxo. A discussão sobre cópia versus acesso remoto é detalhada em [Zero Copy e Federação](/pt/insights/data-360-zero-copy-federation). ## Permissões: A Lacuna Fácil de Perder O modelo de permissões do CRM é rico e preciso no nível de registro e campo. Uma camada de unificação funciona de forma diferente – ela é construída para análise, e sua exposição é gerenciada por regras de acesso e máscaras. Uma organização que transfere dados sensíveis para a camada de unificação sem planejar isso pode criar uma visibilidade mais ampla do que existe no CRM. A regra: cada fluxo que contém informações sensíveis recebe uma decisão explícita de exposição antes da ingestão, e não depois. ## Cenário: Um Varejista que Moveu Tudo para o CRM Uma rede varejista transferiu três anos de histórico de compras – cerca de 40 milhões de linhas – para um objeto personalizado no CRM, com o desejo de que "o vendedor tivesse uma visão completa". O resultado: longos tempos de carregamento na tela do cliente, atualizações noturnas que excederam a janela disponível e relatórios que falharam por tempo limite. Na reconstrução, apenas quatro valores derivados permaneceram no CRM: data da última compra, valor dos últimos 12 meses, categoria principal e identificação de risco de churn. O histórico completo foi para a camada de unificação, com um link para uma visualização detalhada sob demanda. A tela do cliente carregou rapidamente, os vendedores receberam o que realmente pediram, e a segmentação de marketing até melhorou – porque rodava em dados que estavam todos no mesmo lugar e não apenas nos que conseguiram entrar no CRM. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Tudo no CRM | Desempenho, custo e tempos de carregamento | Valores derivados em vez de histórico bruto | | Tudo na camada de unificação | Insights que não chegam ao fluxo de trabalho | Mecanismo de retorno: campo, visualização ou ação | | Sem Retenção | Volume que cresce sem ser gerenciado | Política de retenção para cada fluxo | | Permissões não planejadas | Exposição de informações sensíveis na análise | Decisão de exposição antes da ingestão | | Identidade não Unificada | Perfil dividido para o mesmo cliente | Regras de Resolução de Identidade em vigor | ## Como Medir o Sucesso | Área | O que medimos | Frequência de Verificação | | --- | --- | --- | | Desempenho | Tempo de carregamento da tela do cliente e atualizações em massa | Mensal | | Unificação | Percentual de perfis unificados com sucesso | Mensal | | Ativação | Segmentações e ações geradas a partir dos dados em si | Trimestral | | Custo | Consumo versus orçamento por fluxo | Mensal | O planejamento da divisão entre CRM e a camada de unificação é realizado como parte do [Serviço de Integrações e Dados](/pt/integrations-data). ## Checklist para Decisão - ☐ Mapeamento de fluxos de dados por volume e taxa de atualização - ☐ Teste das quatro perguntas para cada fluxo - ☐ Definição dos valores derivados a serem exibidos no CRM - ☐ Mecanismo de retorno da unificação para o fluxo de trabalho - ☐ Regras de Resolução de Identidade documentadas - ☐ Decisão de exposição para cada fluxo com informações sensíveis - ☐ Política de Retenção para cada fluxo - ☐ Estimativa de custo de consumo para a primeira onda - ☐ Seleção de um "Use Case" para prova de valor - ☐ Atribuição de proprietário para cada fluxo de dados ## Fontes Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Qual pergunta determina onde um dado deve ser armazenado?** Se um usuário ou automação interage com este dado dentro de um fluxo de trabalho. Se sim, seu lugar é no CRM. Se for para segmentação, análise, unificação de perfil ou alimentação de modelo, seu lugar é no Data 360. Dados que não são utilizados nem analisados por ninguém não deveriam estar em nenhum dos dois. **O Data 360 substitui um Data Warehouse?** Não necessariamente. Ele se especializa na unificação do perfil do cliente e na sua ativação de volta nos processos de vendas, serviço e marketing. Um Data Warehouse corporativo continua a suportar relatórios financeiros e operacionais mais amplos. Na prática, eles coexistem, e às vezes são conectados por acesso virtual sem necessidade de duplicação. **É preciso ter Data 360 para utilizar IA?** Não para todos os usos. Para resumir uma conversa ou formular uma resposta, o contexto no CRM é suficiente. Para recomendações, pontuações ou um Agente que precise de um histórico amplo de vários sistemas, uma camada de unificação é necessária – e esse é precisamente o papel do Data 360. **O que acontece ao replicar dados comportamentais para o CRM?** Começa-se a pagar duas vezes: em armazenamento e em performance. Milhões de linhas de eventos em objetos personalizados lentificam atualizações em massa, incham índices e dificultam a elaboração de relatórios. A solução usual é um resumo: manter no CRM um valor derivado – pontuação, última data, contador – e não os próprios eventos. **Por onde começar quando já existe um CRM sobrecarregado?** Pela identificação de três grupos de dados de alto volume e baixo uso operacional, e sua transferência para a camada de unificação, mantendo um campo sumarizado no CRM. Isso melhora a performance e cria uma base para segmentação sem a necessidade de um projeto infraestrutural completo. --- ## Zero Copy e Federação de Dados no Data 360: Quando Não Copiar Informações URL: https://hpi.pro/pt/insights/data-360-zero-copy-federation Cada cópia de dados representa um compromisso: um pipeline, um custo, uma latência e um risco. O Zero Copy permite consultar dados onde eles residem, mas não é uma solução universal. Este guia explora quando a abordagem virtual é preferível, quando a ingestão é mais adequada e como decidir com base em atualização (freshness), desempenho, governança e custo de tráfego. ## A Resposta Breve A regra antiga era "para analisar um dado, primeiro copie-o". O Zero Copy, em muitos casos, anula essa premissa: é possível consultar uma tabela que reside em um *data warehouse* externo sem transferi-la. Esta é uma capacidade real, mas ela troca um tipo de custo por outro – em vez de custo de armazenamento e *pipeline*, obtém-se custo de processamento e dependência da disponibilidade da fonte. A decisão correta é tratá-la como qualquer decisão de arquitetura: baseada em requisitos de uso, não em modismos. ## Quatro Parâmetros Decisivos | Parâmetro | Pendendo para Zero Copy | Pendendo para Ingestion | | --- | --- | --- | | Freshness | Dados mais atualizados são sempre necessários | Ciclos agendados são suficientes | | Desempenho | Análise e segmentação, tolerância a segundos | Operação em tempo real, tempo de resposta constante | | Volume e Frequência | Grande volume, poucas consultas | Volume médio, muitas consultas | | Governança | A fonte mantém uma política robusta | Controle total sobre a cópia é necessário | Esta tabela também explica por que a maioria das organizações adota uma abordagem híbrida: fluxos operacionais são ingeridos, enquanto fluxos analíticos pesados permanecem no local. ## O Que Permanece sob a Responsabilidade da Equipe, Mesmo com Zero Copy O acesso virtual remove o *pipeline*, não o trabalho. Ainda são necessários: mapeamento de esquema para o modelo comum, decisão sobre chaves de identificação para unificação de perfil, tratamento de mudanças de esquema na origem e monitoramento de disponibilidade. Uma mudança no nome de uma coluna no *data warehouse* externo quebrará a visualização virtual, assim como quebraria um ETL. Portanto, o acordo com a equipe de dados que mantém a fonte é parte da implementação: aviso prévio sobre mudanças de esquema, janela de manutenção conhecida e orçamento de consultas acordado. ## Padrões Híbridos Eficazes **Resumo para dentro, detalhe para fora** – Valores resumidos por cliente são inseridos na camada de unificação, e as linhas de detalhe são mantidas no *data warehouse* para acesso sob demanda. Este é o padrão mais comum e geralmente o mais econômico. **Janela quente e arquivo frio** – Os últimos 12 a 24 meses são copiados internamente para desempenho, e o histórico mais antigo permanece acessível virtualmente. **Virtual primeiro, cópia conforme necessidade** – Começa-se com acesso virtual, mede-se a frequência de uso real e copia-se apenas o que se provou ser frequentemente necessário. Esta é a maneira eficiente de evitar a cópia de dados que ninguém consultará. A relação entre esta decisão e a divisão de responsabilidades entre sistemas é detalhada em [Data 360 vs. Dados de CRM](/pt/insights/data-360-vs-crm-data) e [Fonte da Verdade na Organização](/pt/insights/salesforce-source-of-truth). ## Cenário: Empresa Financeira com 400 Milhões de Linhas Uma empresa de serviços financeiros desejava segmentação de clientes baseada em histórico transacional de sete anos – aproximadamente 400 milhões de linhas em um *data warehouse* na nuvem. O plano original era a ingestão completa na camada de unificação. O *piloto* mudou a decisão. Foi medido que as segmentações reais dependiam de apenas três cálculos – média mensal, tendência de 90 dias e classificação de atividade – e todos poderiam ser calculados no próprio *data warehouse*. Em vez de transferir 400 milhões de linhas, foram transferidas três colunas resumidas por cliente, atualizadas diariamente, enquanto os detalhes permaneceram virtualmente acessíveis para investigação pontual. O que foi decidido aqui não foi "virtual vs. cópia", mas sim o nível de granularidade: a pergunta correta era qual resolução de dados era realmente necessária. Ao respondê-la, a questão da cópia se tornou insignificante. ## Riscos Comuns e Ações Preventivas | Risco | Como se manifesta na prática | Ação Preventiva | | --- | --- | --- | | Custo de processamento surpreendente | Consultas amplas com alta frequência | Medição em *piloto* e acordo prévio | | Dependência da disponibilidade da fonte | Falha no *data warehouse* desativa segmentação | Fallback ou janela quente copiada | | Mudanças de esquema | Visualizações quebram sem aviso | Acordo de modificação e monitoramento de esquema | | Permissões indefinidas | Exposição mais ampla do que na fonte | Identidade da consulta e política de exposição documentada | | Granularidade incorreta | Transferência de detalhes que ninguém usa | Decidir a resolução antes do método | ## Como Medir o Sucesso | Área | O Que Medir | Frequência de Verificação | | --- | --- | --- | | Desempenho | Tempo de resposta para consultas de segmentação chave | Mensal | | Custo | Custo de processamento e tráfego por Use Case | Mensal | | Estabilidade | Falhas de consulta e disponibilidade da fonte | Semanal | | Valor | Segmentações e ações geradas efetivamente | Trimestral | A escolha entre acesso virtual e ingestão é feita no âmbito dos [Serviços de Integrações e Dados](/pt/integrations-data). ## Checklist para a Decisão de Zero Copy - ☐ Casos de uso concretos definidos e não uma "capacidade geral" - ☐ Requisito de *freshness* estabelecido para cada Use Case - ☐ Resolução dos dados necessária verificada na prática - ☐ Frequência da consulta e volume de varredura estimados - ☐ Acordo de mudanças de esquema com o proprietário da fonte existente - ☐ Identidade da consulta e política de exposição definidas - ☐ Padrão híbrido considerado antes de uma decisão binária - ☐ Plano de *fallback* para falha da fonte existente - ☐ *Piloto* medido antes da expansão - ☐ Proprietário para monitoramento de custos e revisão periódica ## Fontes Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **O que o Zero Copy realmente economiza?** Ele economiza o pipeline e a duplicação: não há ETL para manter, não há cópia que envelhece e não há dúvida sobre qual cópia está correta. O que ele não economiza é o processamento – a consulta ainda é executada, mas no local onde os dados residem, utilizando o orçamento do proprietário dos dados. **Quando ainda é preferível copiar os dados?** Quando é necessário um tempo de resposta baixo e estável para uso operacional, quando a fonte não é estável ou é limitada em sua taxa de consultas, quando é preciso recuperar um histórico para um ponto específico no tempo, ou quando a fonte pode desaparecer. Nesses casos, a ingestão controlada é a escolha mais responsável. **O Zero Copy é adequado para operações em tempo real?** Menos. Uma consulta virtual é adequada para segmentação, análise e enriquecimento de contexto, mas um processo operacional que aguarda uma resposta em frações de segundo deveria depender de um valor pré-calculado e armazenado próximo ao consumidor. **Como ficam a governança e as permissões no acesso virtual?** Elas permanecem principalmente na fonte, o que é uma vantagem: não há uma cópia separada para proteger. No entanto, é fundamental definir explicitamente a identidade pela qual a consulta é executada, o que é exposto a quem na ponta consumidora e como a auditoria é registrada. Caso contrário, pode-se criar uma exposição mais ampla do que a existente no sistema de origem. **Como estimar os custos antecipadamente?** Com base em três fatores: a frequência da consulta, o volume de dados escaneados em cada execução e a quantidade de tráfego entre ambientes e regiões. Uma consulta abrangente que é executada a cada quinze minutos pode custar mais do que uma cópia diária dos mesmos dados. É aconselhável medir em um projeto piloto antes de escalar. --- ## Reconciliação e Cutover na Migração para Salesforce: Um Plano para o Dia da Virada URL: https://hpi.pro/pt/insights/salesforce-migration-cutover-reconciliation O dia da virada geralmente falha, não pela carga de dados, mas pelo que acontece ao redor: um Delta não capturado, uma integração ativada antes do tempo, ou a falta de alguém para tomar decisões cruciais às duas da manhã. Este guia apresenta um plano de Cutover hora a hora, regras de Freeze, um método de Reconciliação em quatro níveis e critérios claros de Go/No-Go. ## Resumo Executivo O *cutover* é um exercício operacional, não uma etapa puramente técnica. Três fatores determinam seu sucesso: um plano detalhado, hora a hora, com um responsável nomeado para cada etapa; um processo de *Reconciliation* que comprove a correção dos dados, e não apenas sua chegada; e critérios Go/No-Go definidos em um momento de calma. A diferença entre uma organização que realizou uma transição suave e outra que sofreu duas semanas de caos reside quase sempre no número de testes de simulação (*rehearsals*) realizados, e não na qualidade das ferramentas. O planejamento completo de uma migração é descrito no guia [Migração de Dados para Salesforce](/pt/insights/salesforce-data-migration-guide). ## Estrutura da Janela de Migração: Três Ondas | Onda | Quando | Dados Carregados | | --- | --- | --- | | Histórica | 3-10 dias antes | Dados históricos fechados: negociações concluídas, Cases finalizados, histórico | | Delta | Durante a janela | Todas as alterações desde a primeira onda | | Pós-Go-Live | 24-72 horas depois | Arquivos grandes, dados não críticos, complementos | Essa divisão é o que permite uma janela de migração curta. Organizações que tentam carregar tudo em uma única noite descobrem que o tempo de carregamento depende do volume, e esse volume não pode ser compactado além dos limites da plataforma. ## Cronograma Exemplo – Janela de 12 Horas | Hora | Ação | Responsável | | --- | --- | --- | | T-2 | Aprovação Go, verificação de disponibilidade da equipe e decisores | Líder do Projeto | | T0 | Congelar sistema de origem, desconectar integrações de saída | Operações de TI | | T0+1 | Extração do Delta e validação de contagens na origem | Líder de Dados | | T0+2 | Carregamento do Delta em ordem de dependências | Migração | | T0+6 | *Reconciliation* automático: contagens, somas, relacionamentos | QA | | T0+8 | Amostragem manual e aprovação dos proprietários do processo | Negócio | | T0+9 | Ponto sem retorno: Decisão Go / Rollback | Comitê Diretor | | T0+10 | Ativação de integrações, liberação de permissões de usuário | Operações de TI | | T0+11 | *Smoke Tests* em processos críticos | QA + Negócio | | T0+12 | Comunicação de abertura aos usuários, transição para *Hypercare* | Comunicação | Dois princípios do cronograma: cada linha tem um responsável, e cada verificação tem um limiar numérico. Uma linha sem responsável não será executada; uma verificação sem limiar resultará em discussão. ## Reconciliation: Quatro Níveis Indispensáveis **Contagem** – Comparação do número de registros na origem versus destino, para cada entidade e período. Detecta carregamentos parciais. **Soma** – Soma de campos monetários e numéricos. Detecta conversões incorretas, truncamentos e ZEROs silenciosos; contagens corretas não os revelariam. **Relacionamentos** – Número de registros filhos por pai, e registros órfãos. Detecta ordem de carregamento incorreta e mapeamento de chaves quebrado. **Amostragem Manual** – 20 a 50 registros pré-selecionados, incluindo casos de borda: cliente com caracteres especiais, negociação em moeda estrangeira, registro que passou por fusão. Este é o único nível que detecta erros semânticos – dados carregados com sucesso, mas no local errado. A dependência entre a precisão da conversão e a qualidade do mapeamento é explicada em [Mapeamento de Dados para Migração no Salesforce](/pt/insights/salesforce-data-mapping). ## Estudo de Caso: A Migração Interrompida na Oitava Hora Uma empresa de distribuição planejou uma janela de dez horas em um fim de semana. O carregamento foi concluído, as contagens correspondiam perfeitamente, e a equipe se preparava para a liberação. Na amostragem manual, descobriu-se que, em seis dos 30 clientes verificados, as oportunidades em aberto estavam atribuídas ao proprietário errado – resultado de uma tabela de mapeamento de usuários não atualizada após duas saídas e uma mudança de função. As contagens estavam corretas. As somas estavam corretas. Apenas a amostragem manual detectou o problema. A equipe não realizou um *Rollback*: identificaram que se tratava de 1.400 registros que poderiam ser corrigidos com uma consulta, realizaram uma correção focada dentro da janela e verificaram novamente. A decisão foi possível porque o critério No-Go havia sido definido previamente como "erro impossível de corrigir em até duas horas" e não como "qualquer erro". Um critério bem formulado é o que permite a uma equipe exausta tomar a decisão certa às três da manhã. ## Hypercare: Os 14 Dias Seguintes A janela de *Cutover* termina com a liberação para os usuários, mas o risco persiste. É necessária uma equipe de prontidão com um único canal de comunicação, um relatório diário de anomalias de integração e monitoramento de métricas de qualidade em comparação com a linha de base (*baseline*). As falhas são classificadas pela sua impacto nos negócios, e não por quem se manifesta mais efusivamente. A medição contínua da qualidade pós-migração é descrita em [Métricas de Qualidade de Dados Salesforce](/pt/insights/salesforce-data-quality-metrics). ## Riscos Comuns e Ações de Prevenção | Risco | Como se manifesta em prática | Ação de Prevenção | | --- | --- | --- | | Janela única para todo o volume | O carregamento excede o tempo e a migração é adiada | Divisão em três ondas | | Integração que "acordou" | Registros duplicados ou atualizações conflitantes | Desconexão controlada e ativação ordenada | | *Reconciliation* superficial | Contagens corretas e dados incorretos | Quatro níveis, incluindo amostragem manual | | Ausência de critérios No-Go | Continuação devido ao "momento" | Limites definidos por escrito antes da janela | | Mapeamento de usuários desatualizado | Propriedade de registros incorreta | Atualização da tabela de usuários um dia antes | ## Como Medir o Sucesso | Área | O que medir | Frequência da Verificação | | --- | --- | --- | | Precisão da Migração | Diferenças de contagem, soma e relacionamentos | Em cada onda e no *Cutover* | | Conformidade com o Cronograma | Desvio dos tempos planejados | Em cada *Rehearsal* | | Estabilidade Pós-Migração | Falhas de integração e incidentes P1/dia | Diariamente nos 14 dias | | Adoção | Logins e ações versus *Baseline* | Semanalmente no primeiro mês | O suporte no planejamento e execução de um *Cutover* é fornecido como parte dos [serviços de Integrações e Dados](/pt/integrations-data). ## Checklist para Decisão Go/No-Go - ☐ Duas execuções completas de *Rehearsal* com volume de produção - ☐ Cronograma com horários e responsável por cada linha - ☐ Plano de *Freeze* acordado com o negócio - ☐ Lista ordenada de integrações para desconexão e ativação - ☐ Roteiro de *Reconciliation* em quatro níveis, o mais automatizado possível - ☐ Amostragem manual pré-definida, incluindo casos de borda - ☐ Tabela de mapeamento de usuários e propriedade atualizada - ☐ Critérios No-Go escritos com limiares numéricos - ☐ Ponto de não-retorno e plano *Fix-Forward* - ☐ Equipe de *Hypercare*, canal de contato e relatório diário ## Recursos Profissionais - Salesforce Data 360 — https://www.salesforce.com/data/ - Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Quantos ensaios (Rehearsal) são realmente necessários?** Pelo menos dois completos, sendo o segundo com volume de produção e nas mesmas condições de tempo. O primeiro ensaio revela erros de conteúdo, o segundo descobre problemas de tempo e sequência – que são os que derrubam uma janela de Cutover. Organizações com muitas integrações executam três. **Quanto tempo o sistema de origem precisa ficar congelado (Freeze)?** O menor tempo possível, e intencionalmente. Uma janela de Freeze longa gera resistência nos negócios e trabalho fora do sistema. A abordagem comum é: carga histórica completa dias antes da migração, e apenas um Delta curto na própria janela – geralmente entre quatro e doze horas. **Como realizar a Reconciliação corretamente?** Em quatro níveis: contagem de registros por entidade, somatórias de campos financeiros e numéricos, integridade de relacionamentos pai-filho, e amostragem manual de 20-50 registros selecionados previamente, incluindo casos de exceção. Os três primeiros níveis são automáticos; o quarto é o que detecta erros semânticos. **Quando decidir por um No-Go?** De acordo com critérios definidos antes da janela de Cutover e não baseados em sensações em tempo real: exceder um limite de exceções, falha na reconciliação financeira, não cumprimento de um prazo intermediário definido, ou ausência de um tomador de decisões disponível. Quem não define critérios de No-Go antecipadamente quase sempre seguirá em frente. **Um Rollback é realmente possível?** Somente se planejado. Na maioria dos casos, um Rollback completo é possível apenas na primeira janela, antes que os usuários criem novos dados. Por isso, define-se um 'ponto de não retorno' em um horário específico, e a partir daí, passa-se para um plano de 'Fix-Forward' com uma equipe dedicada. --- ## Custo do Agentforce: Consumo, Licenças e o TCO Real de um Agente Organizacional URL: https://hpi.pro/pt/insights/agentforce-cost-tco O custo de licenciamento é a parte mais fácil de calcular e, geralmente, não é a maior parcela. Este guia detalha o Custo Total de Propriedade (TCO) verdadeiro em cinco componentes – licenciamento, consumo, construção, operação e manutenção de conteúdo – e apresenta uma fórmula de custo por tarefa que permite comparar o agente ao custo do tratamento humano, em vez de depender de promessas. ## A Resposta Curta A pergunta "quanto custa o Agentforce" recebe uma resposta enganosa quando traduzida para o preço da licença. O custo real é composto por cinco elementos: licenciamento, consumo em tempo de execução, desenvolvimento inicial, operação contínua e manutenção de conteúdo. Na maioria das implementações que observamos, os três últimos superam a soma dos dois primeiros no primeiro ano. A métrica decisiva não é o custo mensal, mas sim o custo por tarefa concluída sem escalonamento. É a única métrica que pode ser comparada ao custo de tratamento existente e também revela se o problema reside no preço ou no número de tentativas necessárias para a conclusão. ## Os Cinco Componentes do Custo Total de Propriedade (TCO) | Componente | O que Inclui | Comportamento ao Longo do Tempo | Sinal de Desvio | | --- | --- | --- | --- | | Licenciamento | Licenças de plataforma e usuário | Fixo, aumenta com a expansão | Licenças adquiridas antes da seleção do caso de uso | | Consumo | Operações em tempo de execução de acordo com o modelo de precificação | Varia com o volume e duração da conversa | Consumo que aumenta sem aumento de tarefas concluídas | | Desenvolvimento | Descoberta, Ações, Base de conhecimento (Grounding), Testes | Pontual para cada caso de uso, diminui com a experiência | Escopo que se expande sem decisão de negócio | | Operação | Monitoramento, revisão de falhas, correções, gestão de mudanças | Fixo enquanto o agente estiver ativo | Ausência de um proprietário e, portanto, ausência de custo registrado – o que resulta em falta de manutenção | | Manutenção de Conteúdo | Atualização da Base de Conhecimento (Knowledge), arquivamento, controle de validade | Fixo de acordo com o número de áreas de conhecimento | Queda gradual na precisão das respostas | ## Custo por Tarefa: A Fórmula a Ser Construída Calcula-se o custo mensal total de todos os cinco componentes e divide-se pelo número de tarefas concluídas com sucesso – ou seja, finalizadas com o resultado desejado sem escalonamento para um ser humano. Este é o único número que pode ser comparado ao custo de tratamento existente. A definição de "concluída" é a decisão difícil e vincula o proprietário do processo. Uma conversa na qual o cliente recebeu uma resposta e recorreu novamente no dia seguinte sobre o mesmo assunto não é uma tarefa concluída. Uma definição frouxa cria números positivos que não resistem a uma análise crítica. É crucial comparar com uma Linha de Base (Baseline) real. O custo do tratamento humano inclui salários, sistemas, treinamento e tempo de espera – não apenas os minutos de conversação. A comparação com um número parcial é a razão comum pela qual a justificativa econômica desmorona na revisão trimestral. ## O Que Realmente Aumenta os Custos na Prática O primeiro fator é um "Grounding" fraco. Quando o agente não consegue encontrar uma fonte precisa, ele tenta mais vezes, a conversa se alonga e o consumo aumenta – e, no final, a conversa é escalonada de qualquer maneira. Aprimorar o conteúdo geralmente gera uma economia maior do que a troca de um modelo. O segundo fator são as execuções repetidas após uma falha de integração. Cada tentativa é contabilizada, e quando um sistema externo é instável, o custo é multiplicado sem qualquer valor adicional. O terceiro fator é um "Escopo" amplo. Um agente que deve responder a tudo consome mais em cada conversa, porque verifica mais fontes e realiza mais considerações. Um agente mais focado custa menos e é mais preciso. A relação entre a qualidade das fontes de informação e o custo é detalhada em [Uso de Grounding e RAG no Agentforce](/pt/insights/agentforce-grounding-rag). ## Controles Orçamentários a Serem Estabelecidos Antecipadamente Um teto mensal definido para cada Use Case, com alerta antes de ser atingido. Sem um teto, a descoberta da violação chega com a fatura. Quebra de custo por Use Case e não apenas no nível da organização. Quando há três agentes e apenas um número total, não é possível saber qual deles não é rentável e desativá-lo. Medição semanal do consumo em relação às tarefas concluídas. Um aumento no consumo em paralelo com a estabilidade nas tarefas é um sinal de alerta precoce – indica uma deterioração na qualidade das respostas antes que os usuários reclamem. Como configurar o monitoramento que alimenta os controles é detalhado em [Observabilidade para Agentes de IA](/pt/insights/agentforce-observability). ## Cenário: Um Piloto Que Parecia Caro e Acabou Sendo Barato Uma empresa de software executou um piloto de oito semanas e recebeu uma fatura de consumo superior ao esperado. A primeira reação foi considerar a interrupção. A análise revelou um cenário diferente: 62% do consumo veio de uma única categoria de perguntas, na qual o agente não conseguiu encontrar uma fonte e, portanto, tentou repetidamente antes de escalar. O tratamento não foi técnico. Onze novos artigos de Knowledge foram escritos para essa categoria, e um "Fallback" foi definido para escalar após a segunda tentativa, em vez de tentar até o fim. O consumo mensal caiu significativamente, e o número de tarefas concluídas, por sua vez, aumentou. O custo por tarefa – a única métrica examinada pelo CFO – melhorou várias vezes, e o projeto foi aprovado para expansão. A conclusão: uma fatura alta é, na maioria das vezes, um sintoma de uma lacuna de conteúdo e não de precificação. ## Quando o Agente Simplesmente Não é Lucrativo Três situações que devem ser identificadas precocemente. Baixo volume: um processo com apenas algumas centenas de casos por mês não retornará o custo operacional, mesmo que seja irritante. Variação excessivamente alta: quando quase todo caso é uma exceção, a taxa de escalonamento permanecerá alta e, com ela, o custo duplicado. E dependência de um sistema externo instável: o custo é afetado por um fator que está fora do controle do projeto. Nessas situações, a resposta correta não é "não para IA", mas sim "não para este processo". Quase sempre há um subprocesso com volume maior que justifica o investimento. ## Riscos e Ações Preventivas | Risco | Como se Manifesta | Ação Preventiva | | --- | --- | --- | | Licenciamento antes do Use Case | Licenças não utilizadas e pressão para mostrar valor | Verificação de prontidão e seleção de processo antes da compra | | Ausência de orçamento para operação | Queda na qualidade após o primeiro trimestre | Orçamento anual para monitoramento e manutenção de conteúdo | | Medição apenas no nível da organização | Impossibilidade de identificar um agente não lucrativo | Quebra de custo por Use Case | | Definição frouxa de "concluído" | Números positivos que falham na análise crítica | Definição de sucesso pelo proprietário do processo antecipadamente | | Tentativas repetidas sem teto | Consumo duplicado sem valor | Limitar tentativas e escalar precocemente | ## Métricas Econômicas | Métrica | Definição | Frequência | | --- | --- | --- | | Custo por tarefa concluída | Custo total dividido por tarefas sem escalonamento | Mensal | | Consumo por tarefa | Unidades de consumo médias por tarefa | Semanal | | Taxa de conclusão | Porcentagem de casos finalizados com o resultado desejado | Semanal | | Custos fixos de operação | Horas de monitoramento, correções e manutenção de conteúdo | Mensal | | Relação com o custo da Linha de Base (Baseline) | Custo do agente versus custo do atendimento existente | Trimestral | Quando um modelo econômico que resistirá à revisão interna é necessário antes de uma decisão de investimento, os [Serviços de Agentforce e IA](/pt/agentforce-ai) são o caminho prático a seguir. ## Checklist para Construção de Modelo de Custo - ☐ Os cinco componentes do TCO foram precificados separadamente - ☐ Foi definido o que se considera "tarefa concluída" pelo proprietário do processo - ☐ Foi medida a Linha de Base (Baseline) do custo de atendimento existente - ☐ Foi estabelecido um teto de consumo mensal para cada Use Case - ☐ Existe uma quebra de custo no nível do Use Case, e não apenas da organização - ☐ Foram orçados monitoramento e manutenção de conteúdo para o primeiro ano - ☐ Foi definido o número máximo de tentativas antes do escalonamento - ☐ Foi estabelecido um limite econômico no qual o agente é suspenso ou desativado ### Perguntas e respostas **O que realmente encarece um agente mais do que o esperado?** Três coisas: conversas mais longas do que o previsto devido a um 'grounding' fraco, execuções repetidas após falhas e manutenção de conteúdo que ninguém orçou. O custo de consumo geralmente não decorre do preço unitário, mas do número de unidades consumidas por cada tarefa concluída com sucesso. **Como comparar o custo de um agente com o custo de um atendente humano?** Calcule o custo por tarefa concluída sem escalonamento, não o custo por conversa. Se o agente lida com oitenta por cento da conversa e escala, a economia está no tempo poupado, não no atendimento completo. Uma comparação justa inclui também o tempo do atendente humano necessário para concluir após o escalonamento. **O custo operacional diminui com o tempo?** O custo de construção diminui, mas o custo operacional não necessariamente. Monitoramento, revisão de conversas falhas e atualização de conteúdo são custos constantes enquanto o agente estiver ativo. Organizações que orçam apenas o projeto e não o primeiro ano após sua implementação descobrem a lacuna no segundo trimestre. **O que é razoável alocar para manutenção de conteúdo?** Na prática, este é um item que equivale a um regime de meio período fixo para uma área de conhecimento ativa. Alguém que atualiza artigos, arquiva informações conflitantes e verifica sua validade. Sem essa alocação, a qualidade das respostas diminui gradualmente, levando a uma decisão de reinvestir com um custo mais alto. **Quando a conclusão correta é não implementar um agente?** Quando o custo da tarefa é maior do que o valor gerado, mesmo após otimização, ou quando o volume é muito baixo para justificar a operação contínua. Um processo com apenas algumas centenas de casos por mês é quase sempre mais barato de ser resolvido com automação clássica ou melhoria de processo. --- ## Segurança Agentforce e o Modelo de Responsabilidade Compartilhada URL: https://hpi.pro/pt/insights/agentforce-security-shared-responsibility A plataforma garante a segurança da infraestrutura; a organização é responsável pelo que o Agente tem permissão para ver e fazer. Este guia delineate a linha prática de divisão — dados, permissões, instruções, ações e monitoramento — e demonstra os novos riscos introduzidos por um Agente sem paralelo em um sistema CRM convencional. ## A Resposta Breve O modelo de responsabilidade compartilhada não é apenas um documento formal – é a linha que determina quem é o culpado quando algo dá errado. A regra é simples: a plataforma é responsável pela segurança do serviço em si, e a organização é responsável por todas as decisões sobre o que o agente vê, o que ele pode fazer e a quem ele responde. O grande risco não é uma falha na segurança da plataforma. É um agente com permissões excessivas que expõe informações à parte errada ou executa uma ação que não deveria ter executado – duas falhas que têm sua origem inteiramente no lado da organização. ## Divisão Real da Responsabilidade | Área | Responsabilidade da Plataforma | Responsabilidade da Organização | | --- | --- | --- | | Infraestrutura | Criptografia, isolamento, disponibilidade, gestão de vulnerabilidades | Seleção do ambiente e configuração de rede aprovada | | Dados | Armazenamento e processamento de acordo com o contrato | O que é indexado e o que é classificado como sensível | | Identidade e Permissões | Mecanismos de permissão da plataforma | Definição de quem pode ver e fazer o quê | | Comportamento do Agente | Capacidades do modelo e ferramentas de controle | Instruções, limites, pontos de aprovação | | Ações | Infraestrutura de execução | Autorização para cada Action e validação interna | | Monitoramento e Auditoria | Logs da plataforma | Trilha de auditoria de negócios, amostragem e revisão | ## Os Novos Riscos que Não Existiam em um CRM Regular O primeiro é a exposição através da recuperação (retrieval). Em um sistema regular, o usuário vê o que a tela exibe; em um agente, um texto livre pode resultar na recuperação de um trecho de um documento que não era destinado a ele. Portanto, a recuperação deve ser executada no contexto das permissões do usuário, e não no contexto de uma conta de integração ampla. O segundo é o Prompt Injection. O conteúdo que o agente lê – um e-mail de cliente, um campo de descrição, um documento anexado – pode conter instruções que tentam alterar seu comportamento. Não é possível se proteger disso apenas com a formulação; a proteção é arquitetônica. O terceiro é o vazamento de conteúdo interno para um canal externo. Um artigo escrito para representantes com margens de desconto ou formulações de objeção não deve chegar ao cliente, e a separação deve ser feita por uma lista de permissões (allowlist) e não por uma lista de bloqueio (blocklist). O quarto é a ampliação silenciosa da autoridade: adicionar uma Action ou permissão para resolver um problema pontual, sem passar pelo processo de aprovação. ## Cinco Controles que Sustentam a Maior Parte do Peso Recuperação no contexto do usuário. Este é o único controle que, se falhar, todo o resto não ajuda. Autorização separada para cada Action, de acordo com o princípio da permissão mínima. Um agente que recebe um perfil amplo e único impede qualquer controle futuro. Validação dentro da ação e não nas instruções. Uma instrução é uma diretriz; uma validação é um controle. Uma ação que realiza um estorno deve verificar o valor, a elegibilidade e a autorização em seu próprio código, mesmo que as instruções digam ao agente para não ativá-la em certos casos. Aprovação humana para uma ação irreversível. Este é o controle que transforma uma possível falha em um evento que é interrompido a tempo. Trilha de auditoria (audit trail) que conecta usuário, ação, origem e aprovador. Sem isso, não há resposta para a pergunta de auditoria "com base em quê o agente fez isso". Os princípios gerais do modelo de permissões no Salesforce são detalhados no [Modelo de Permissões no Salesforce](/pt/insights/salesforce-permission-model). ## O Que Verificar Antes do Go Live Testes de Persona: As mesmas dez a vinte perguntas executadas com diferentes identidades – representante, gerente, usuário limitado, cliente externo – e as respostas são comparadas. Qualquer discrepância que não seja explicada por uma permissão é um achado. Red Teaming de Conteúdo: Tentativas deliberadas de extrair informações não autorizadas, executar uma ação proibida e contornar a escalada. Os cenários são escritos uma vez e mantidos para execução repetida em cada versão. Teste do Fluxo de Ações: Para cada Action, verifica-se se a validação funciona mesmo quando ativada diretamente, não apenas através do agente. Teste de Retenção de Dados: O que é armazenado, por quanto tempo e quem pode acessar os logs que contêm o conteúdo da conversa com dados do cliente. Como esses testes se integram a uma estrutura de testes mais ampla é explicado em [Testes do Agentforce](/pt/insights/agentforce-testing-scorers). ## Cenário: Um Achado Capturado em um Teste de Persona Uma empresa de saúde preparou um agente interno para responder a perguntas sobre procedimentos. Em um teste de Persona antes do lançamento, descobriu-se que um usuário com função administrativa recebeu uma resposta baseada em um procedimento classificado apenas para a equipe médica. A razão não foi um bug no agente. O índice foi construído por uma conta de integração com acesso amplo, e a recuperação não restringia de acordo com as permissões do usuário. A mesma exposição existia potencialmente em qualquer pergunta relacionada a essa área. A correção incluiu dois pontos: a recuperação passou para o contexto do usuário e a marcação explícita de documentos classificados para que não entrassem no índice geral. O teste foi adicionado como um cenário permanente que é executado antes de cada lançamento de versão. ## Riscos e Ações Preventivas | Risco | Como é Descoberto | Ação Preventiva | | --- | --- | --- | | Recuperação com permissões amplas | Exposição de documento classificado em uma resposta inocente | Recuperação no contexto do usuário e testes de Persona | | Prompt Injection | Ação ativada devido a conteúdo externo | Permissões restritas, validação na ação, aprovação humana | | Mistura de conteúdo interno e externo | Formulação interna chega ao cliente | Lista de permissões no canal externo | | Ampliação silenciosa da autoridade | Agente faz mais do que o aprovado | Marcação de mudanças significativas e reaprovação | | Ausência de Audit Trail | Não há resposta para a auditoria | Registro de usuário, ação, origem e aprovador | ## Métricas de Segurança | Métrica | O Que Ela Revela | Frequência | | --- | --- | --- | | Achados de Persona | Lacunas de permissão na recuperação | Em cada versão | | Resultados de Red Teaming | Resiliência contra tentativas de contorno | Em cada versão | | Ações sensíveis sem aprovação | Falhas no fluxo de controle | Mensal | | Mudanças que contornaram a aprovação | Disciplina do processo de mudança | Trimestral | | Cobertura do Audit Trail | Percentual de ações sensíveis totalmente documentadas | Trimestral | A estrutura de aprovações na qual os controles são aplicados é detalhada na [Governança de IA para o Agentforce](/pt/insights/agentforce-ai-governance). Quando for necessário suporte na definição do modelo de responsabilidade e nos testes antes da entrada em produção, o [Serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Lista de Verificação de Segurança Antes do Go Live - ☐ O documento de divisão de responsabilidades foi escrito e aprovado. - ☐ As condições de uso de dados em relação ao modelo estão documentadas por escrito. - ☐ A recuperação é executada no contexto de permissões do usuário. - ☐ Testes de Persona foram realizados para cada nível de permissão. - ☐ Para cada Action, há uma permissão separada e validação interna. - ☐ Ações irreversíveis exigem aprovação humana. - ☐ Em canais externos, uma lista de permissões para conteúdo está ativa. - ☐ Cenários de Red Teaming de conteúdo foram escritos e executados. - ☐ O Audit Trail conecta usuário, ação, origem e aprovador. - ☐ A política de retenção de logs e conteúdo de conversa foi aprovada. ### Perguntas e respostas **O que a plataforma realmente cobre e o que não cobre?** A plataforma cobre a infraestrutura, criptografia, isolamento do ambiente e compromissos de uso de dados em relação ao modelo. Ela não determina quem pode ver o quê na organização, quais ações o Agente está autorizado a realizar, o que entra na base de conhecimento e quem monitora. Estas são as decisões que geram a maior parte do risco. **O que é Prompt Injection no contexto corporativo?** Conteúdo que o Agente lê — um e-mail recebido, um campo de descrição, um documento carregado — que contém instruções que tentam alterar seu comportamento. A defesa não reside em formular instruções melhores, mas em controles: permissões restritas para ações, validação dentro da ação e aprovação humana antes de uma ação sensível. **Os dados da organização são usados para treinar modelos?** A resposta depende do contrato e da configuração, portanto, deve ser documentada por escrito antes do Go Live, não se baseie em suposições. Esta é uma das primeiras perguntas que a auditoria interna fará, e é aconselhável que a resposta seja apoiada por um documento e não pela memória de quem participou da conversa de vendas. **É necessária uma auditoria de penetração para o Agente?** Sim, mas de um tipo diferente. Além do teste técnico regular, é necessário um Red Teaming de conteúdo: tentativas de extrair informações não autorizadas, causar uma ação não permitida e contornar as regras de escalonamento. Esses testes são escritos como cenários e salvos para reexecução em cada versão. **O que é necessário para fins de auditoria e regulamentação?** Uma trilha de auditoria que mostra para cada ação sensível quem é o usuário, o que o Agente fez, com base em qual fonte e quem aprovou. Além disso, um registro atualizado de Agentes e um documento que define a divisão de responsabilidades. Estes três itens cobrem a maioria das perguntas de auditoria. --- ## Testes do Agentforce: Conjuntos de Testes, Avaliadores e Cenários Limite URL: https://hpi.pro/pt/insights/agentforce-testing-scorers Testar um Agente é diferente de testar um Flow: a mesma pergunta pode ter duas respostas válidas. Este guia demonstra como construir um conjunto de testes representativo da realidade, quais dimensões medir separadamente, quando a automação é suficiente e quando o julgamento humano é necessário, e qual limite permite o lançamento. ## A Resposta Curta O teste de agentes não é um teste de software clássico. Não há uma única resposta correta; a mesma pergunta pode ser formulada de vinte maneiras diferentes, e a falha geralmente não é um erro, mas sim uma resposta razoável que omite uma condição essencial. Portanto, é necessário um método diferente: um conjunto representativo de casos, critérios de aceitação em vez de respostas exatas, e medição em diversas dimensões separadamente. A separação entre as dimensões é o que torna o teste útil. “A resposta não é boa” não é um achado; “o tópico foi corretamente identificado, mas a fonte relevante não foi recuperada” é um achado que pode ser corrigido. ## As Quatro Dimensões de Avaliação | Dimensão | O que é Avaliado | Como é Medido | Quem Corrige | | --- | --- | --- | --- | | Identificação do Tópico | Se o agente compreendeu o assunto | Comparação com o tópico esperado | Quem escreve instruções e descrições de Actions | | Recuperação | Se a fonte correta foi recuperada | Se a seção esperada apareceu na recuperação | Proprietário do conteúdo e da tag | | Resposta | Se o conteúdo está correto e completo | Critérios de aceitação: obrigatório, proibido, citação | Conteúdo e instruções | | Processo | Se a Action correta foi executada e a escalada foi mantida | Verificação da sequência de Actions e decisão de parada | Actions e regras de escalada | ## Construindo um Conjunto de Testes Representativo A fonte de material são interações reais, e não cenários criados em reuniões. Transcrições, e-mails e descrições de Case contêm o que falta em cenários inventados: erros de digitação, formulações incompletas, duas perguntas em uma única frase e informações ausentes. Composição recomendada: cerca de metade de casos comuns, aproximadamente um quarto de casos extremos — exceções, condições de elegibilidade limítrofes, perguntas de múltiplas partes — e cerca de um quarto de casos que devem falhar intencionalmente: solicitações fora do escopo, tentativas de extrair informações não autorizadas e clientes que solicitam um agente humano. Para cada caso, quatro campos são definidos: a solicitação conforme formulada, o tópico esperado, o critério de aceitação para a resposta e o comportamento processual esperado — incluindo “deve escalar” como um resultado correto e não como uma falha. ## Critério de Aceitação em Vez de Resposta Exata Este é o princípio que permite qualquer teste. Em vez de escrever a resposta correta, escreva três listas curtas: fatos que devem aparecer, afirmações que não devem aparecer e a fonte que deve ser citada. O exemplo típico: uma pergunta sobre elegibilidade para reembolso. É obrigatório que o período de tempo e as condições de estado do produto apareçam; é proibido que um compromisso de crédito apareça; a fonte deve ser a política de reembolso em sua versão válida. Duas formulações completamente diferentes podem ser aceitas. Esta é também a forma que permite uma avaliação automatizada confiável — a verificação da presença de um fato definido é muito mais precisa do que pedir a um modelo para avaliar a “qualidade”. ## Automação vs. Julgamento Humano Scorers automatizados são adequados para identificação de tópicos, presença de citação válida, conformidade com formato, comprimento e identificação de declarações proibidas. Eles são executados em todo o conjunto em cada versão, com baixo custo. O julgamento humano é necessário para a precisão do conteúdo em áreas sensíveis e para a formulação com o cliente. Não é necessário testar todo o conjunto — uma amostra fixa de vinte a trinta casos em cada versão, selecionada para incluir os casos extremos. O perigo de depender totalmente de um avaliador automático é a tendência para respostas que soam autoritárias. Uma resposta convincente que omite uma condição de elegibilidade passará automaticamente e será detectada por um avaliador humano. Como os resultados dos testes se conectam ao monitoramento de produção é explicado em [Observabilidade para Agentforce](/pt/insights/agentforce-observability). ## Cenários de Borda para Incluir Sempre Uma pergunta com dois tópicos em uma frase. Uma solicitação com informações essenciais ausentes — o agente faz uma pergunta de esclarecimento ou adivinha. Um cliente que formula em tom negativo — a escalada é acionada. Uma solicitação de ação não permitida para o usuário. Uma pergunta sobre um produto que não existe — o agente admite ou inventa. Conteúdo que contém uma instrução disfarçada que tenta alterar o comportamento. Esses seis cobrem a maioria das falhas que vimos em produção, e são de baixo custo para serem executados repetidamente. Os cenários de bypass se conectam aos testes de segurança detalhados em [Segurança do Agentforce e Responsabilidade Compartilhada](/pt/insights/agentforce-security-shared-responsibility). ## Limites para Lançamento O limite não é um número uniforme, mas derivado do canal e do risco. Um agente interno de suporte ao representante pode operar com um nível de precisão mais baixo, pois o representante filtra. Um agente que interage com clientes requer um limite significativamente maior, e principalmente zero falhas nas categorias críticas. A regra mais importante do que o número: zero falhas nas categorias obrigatórias. Exposição de informações não autorizadas, ação irreversível sem aprovação, falha na escalada em uma solicitação explícita por um humano — cada um desses bloqueia o lançamento, independentemente da pontuação geral. ## Cenário: Conjunto Pequeno que Evitou um Mau Lançamento Uma empresa de turismo planejava lançar um agente de clientes após um piloto interno apresentar bom desempenho. O conjunto de testes construído incluiu 90 casos, dos quais 22 eram casos extremos de interações reais. A execução revelou um padrão: em perguntas sobre alteração de datas com condições especiais de cancelamento, o agente fornecia uma resposta geralmente correta, mas omitia as taxas de alteração em um terço dos casos. Nos testes internos, isso não foi detectado – os representantes sabiam como adicionar as informações por conta própria. O lançamento foi adiado por três semanas. A correção foi no conteúdo: as condições de cobrança foram movidas para uma seção separada e destacada em cada artigo relevante, e um critério de aceitação explícito foi adicionado. A reexecução foi bem-sucedida, e o lançamento ocorreu sem incidentes. ## Riscos e Ações Preventivas | Risco | Como é Detectado | Ação Preventiva | | --- | --- | --- | | Conjunto de testes inventado | Tudo passa no teste e falha em produção | Casos de interações reais | | Avaliação apenas por pontuação geral | Não se sabe o que corrigir | Medição separada para as quatro dimensões | | Dependência de avaliador automático | Respostas convincentes com omissões são aceitas | Amostra humana fixa para cada versão | | Sem casos que devem falhar | O agente responde ao que não deveria | Um quarto do conjunto: fora do escopo e bypass | | Sem regressão | Uma pequena correção quebra outro cenário | Execução do conjunto antes de cada atualização de versão | ## Métricas de Teste | Métrica | Definição | Limiar de Princípio | | --- | --- | --- | | Topic accuracy | Porcentagem de identificação correta do tópico | Alta; falha aqui quebra todo o resto | | Retrieval hit rate | Porcentagem de casos em que a fonte esperada foi recuperada | Alto em canais de cliente | | Answer acceptance | Porcentagem de respostas que atenderam aos critérios de aceitação | Derivado do canal e do risco | | Process compliance | Porcentagem de casos em que a ação ou escalada correta foi realizada | Zero desvios para categorias obrigatórias | | Regression delta | Mudança nas pontuações em relação à versão anterior | Sem declínio inexplicável | Quando necessário suporte para a construção de um conjunto de testes e a definição de limites de lançamento, o [Serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist para Testes - ☐ O conjunto de testes foi construído a partir de interações reais - ☐ A composição inclui casos comuns, extremos e que devem falhar - ☐ Para cada caso, um critério de aceitação: obrigatório, proibido, fonte - ☐ A medição é dividida em tópico, recuperação, resposta e processo - ☐ Scorers automáticos são executados em todo o conjunto - ☐ Uma amostra humana fixa é revisada em cada versão - ☐ Cenários de bypass e instruções disfarçadas foram incluídos - ☐ Categorias obrigatórias com tolerância zero foram definidas - ☐ O conjunto é executado como regressão antes de cada atualização de versão - ☐ Os resultados dos testes são documentados e comparados com a versão anterior ### Perguntas e respostas **Quantos casos são necessários no conjunto de testes?** De 50 a 150 casos são suficientes para uma primeira versão, desde que sejam representativos. Um conjunto de 500 casos com formulações perfeitas é menos útil do que um conjunto de 80 que inclua erros de digitação, perguntas ambíguas, solicitações fora do escopo e tentativas de contorno. **Onde obter casos de teste reais?** De interações já recebidas: transcrições de chamadas, e-mails, descrições de casos. Casos escritos pela equipe tendem a ser bem formulados e, portanto, enganosos. A maneira mais rápida é pegar as duzentas últimas interações e filtrar as repetidas. **É possível confiar em um modelo que avalia respostas automaticamente?** Para algumas dimensões, sim – identificação do tópico, existência de citação, conformidade com formato e política. Para precisão de conteúdo em áreas sensíveis, amostras humanas são necessárias, pois um avaliador automático tende a aprovar uma resposta que parece correta. A combinação usual: automação para tudo, julgamento humano para uma amostra. **O que é considerado uma falha quando há várias respostas corretas?** Definimos um critério de aceitação, e não uma resposta exata: quais fatos devem aparecer, quais são proibidos e qual fonte deve ser citada. Assim, duas formulações diferentes podem ser aprovadas, e uma resposta que omite uma condição de elegibilidade falha, mesmo que pareça boa. **Com que frequência o conjunto de testes deve ser executado?** Antes de cada lançamento de versão, e também regularmente em produção sobre uma amostra. Uma mudança aparentemente inócua – atualização de instrução, adição de artigo, alteração de Ação – pode afetar o comportamento em outros cenários, e a regressão é a única maneira de identificar isso antes dos usuários. --- ## Observabilidade para Agentforce: Como Mensurar, Analisar e Aprimorar um Agente de IA URL: https://hpi.pro/pt/insights/agentforce-observability Um agente de IA sem monitoramento é uma caixa preta que ninguém consegue defender em uma reunião de diretoria. Este guia detalha a camada de monitoramento em três níveis — conversas individuais, tendências e resultados de negócios — explica o que DEVE aparecer no Trace e como transformar conversas que falharam em uma fila de trabalho semanal, em vez de um relatório que ninguém lê. ## A Resposta Breve O monitoramento de Agentes é diferente do monitoramento de sistemas comuns: o Agente raramente "cai", ele apenas se torna menos eficaz. Portanto, as métricas clássicas de disponibilidade e erros são insuficientes. É necessária uma camada que meça a qualidade da decisão, e não apenas a correção técnica. Uma estrutura prática inclui três níveis: o Trace, que explica uma interação individual; as Tendências semanais, que identificam deterioração; e a Métrica de Resultado de Negócio, que justifica a continuidade da operação. Cada nível responde a uma pergunta diferente e é direcionado a um público específico. ## Três Níveis de Monitoramento | Nível | Pergunta à qual responde | Público | Frequência | | --- | --- | --- | --- | | Trace | Por que esta interação terminou de tal forma? | Equipe técnica e analistas | Conforme necessário | | Tendência | O que está mudando para melhor ou para pior? | Proprietário do processo e gerente de plataforma | Semanal | | Resultado | O Agente justifica sua existência? | Liderança e Sponsor | Mensal e trimestral | ## Nível 1: O Que o Trace Deve Conter Um Trace útil permite reconstruir a decisão sem precisar perguntar a ninguém. Sete componentes essenciais: a consulta formulada, o tópico identificado, os trechos realmente recuperados, as ações disparadas com seus parâmetros, o resultado de cada ação, pontos de aprovação e suas decisões, e o motivo do encerramento. O componente mais frequentemente esquecido são os trechos recuperados. Sem eles, é impossível distinguir entre duas falhas completamente diferentes: o Agente não encontrou a informação, ou a encontrou e a utilizou incorretamente. A primeira é abordada com conteúdo, a segunda com instruções – e o tratamento incorreto desperdiçou semanas em todas as organizações que vimos. É fundamental também vincular o Trace a um registro de negócio: Case, Order ou Opportunity. Sem essa ligação, é impossível verificar se a interação levou a um resultado satisfatório ou a um contato de retorno. ## Nível 2: As Tendências a Serem Monitoradas Cinco métricas são geralmente suficientes para a maioria das implementações: taxa de conclusão sem escalonamento, taxa de contato de retorno em uma semana, porcentagem de respostas com fonte válida, taxa de falha de ação e consumo em relação às tarefas concluídas. A leitura é feita em pares. Um *containment* alto com uma alta taxa de contato de retorno não é um sucesso. O consumo que aumenta enquanto as tarefas permanecem estáveis significa que o Agente está trabalhando mais para o mesmo resultado – um sinal precoce de deterioração do conteúdo. Alertas automáticos são configurados com base em mudanças relativas, e não em valores absolutos: um salto na taxa de escalonamento, uma queda na porcentagem de fontes válidas, um aumento nas falhas de ação em relação a um sistema externo específico. A relação entre essas métricas e os custos é detalhada em [Custo do Agentforce e TCO](/pt/insights/agentforce-cost-tco). ## Nível 3: Resultado de Negócio Este é o nível decisivo na revisão trimestral. Dois números: qual foi a mudança na métrica do processo previamente escolhida – tempo de resolução, abandono, volume de consultas ao Agente – e qual o custo da tarefa concluída em relação ao *baseline*. É crucial definir as métricas de sucesso com antecedência e não alterá-las após a visualização dos resultados. Mudar a definição de "sucesso" no meio do caminho é o que mais prejudica a confiança da liderança nos dados, mesmo quando a mudança é justificada. ## Da Análise à Fila de Melhoria O relatório semanal não é o produto final. O produto é uma fila de trabalho. A prática eficaz: amostrar vinte interações que falharam ou foram escalonadas, classificá-las pela causa raiz – lacuna de conteúdo, rotulagem incorreta, instrução pouco clara, falha de ação ou solicitação fora do escopo – e abrir um item de trabalho apenas para a maior categoria. A regra para evitar desvios: resolver uma causa raiz por semana. Organizações que tentam corrigir cinco simultaneamente acabam sem saber o que melhorou ou piorou a métrica. As lacunas de conteúdo identificadas aqui são um *input* direto para a lista de escrita – o processo é detalhado em [Gestão do Conhecimento para Agentforce](/pt/insights/agentforce-knowledge-readiness). ## Cenário: Uma Queda Silenciosa Detectada a Tempo Uma empresa de serviços financeiros operou um Agente interno que permaneceu estável por quatro meses. Na décima quinta semana, a taxa de escalonamento aumentou gradualmente sem que ninguém reclamasse – os agentes humanos simplesmente estavam concluindo o atendimento por conta própria. O alerta configurado para um aumento relativo no escalonamento disparou uma investigação. A amostragem de Traces mostrou que, em metade dos novos casos, nenhum trecho relevante foi recuperado. A razão: uma mudança na política de produto levou ao arquivamento automático de onze artigos, e nenhuma alternativa foi criada. A correção levou dois dias e não exigiu intervenção no Agente. Sem a camada de monitoramento, a falha só teria sido descoberta quando um gerente perguntasse por que o tempo médio de atendimento havia aumentado – provavelmente, um trimestre depois. ## Riscos e Ações Preventivas | Risco | Como se manifesta | Ação preventiva | | --- | --- | --- | | Apenas monitoramento técnico | Tudo "verde" e as respostas piores | Métricas de qualidade e escalonamento, além das métricas de disponibilidade | | Trace sem trechos recuperados | Meses de suposições entre conteúdo e modelo | Registro obrigatório dos trechos recuperados | | Relatório sem fila de trabalho | Dados apresentados sem mudança | Amostragem semanal e item de trabalho para uma causa raiz | | Alteração de definições no meio do caminho | Perda de confiança nos dados | Definição prévia das métricas de sucesso | | Sem vínculo com registro de negócio | Impossibilidade de identificar contato de retorno | Vínculo do Trace ao Case ou à Ordem | ## Painel de Métricas Recomendado | Métrica | Definição | Limite para alerta | | --- | --- | --- | | Taxa de Conclusão | Encerramento sem escalonamento e sem contato de retorno | Queda relativa significativa semanal | | Taxa de Escalonamento | Porcentagem de transferências para agente humano | Aumento relativo contínuo | | Fonte Válida | Porcentagem de respostas com citação existente e válida | Queda abaixo do limite definido | | Falhas de Ação | Porcentagem de operações com falha por sistema de destino | Aumento de falhas em relação a um destino específico | | Consumo por Tarefa | Unidades de consumo por tarefa concluída | Aumento sem crescimento nas tarefas | Quando for necessário suporte na implementação de uma camada de monitoramento e de um processo de melhoria semanal, o [Serviço Agentforce e AI](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist para Implementação de Observabilidade - ☐ O Trace registra a consulta, o tópico, os trechos recuperados, as ações e o resultado. - ☐ Todo Trace está vinculado a um registro de negócio. - ☐ A política de retenção separa metadados do conteúdo da conversa. - ☐ Foram selecionadas apenas cinco a sete métricas de tendência. - ☐ Alertas foram configurados para mudanças relativas, não para valores absolutos. - ☐ Existe uma rotina semanal de amostragem de interações com falha. - ☐ Foi definida uma taxonomia de causas-raiz de falha. - ☐ O proprietário do processo de negócio participa da revisão semanal. - ☐ As definições de sucesso foram estabelecidas antes do início da medição. ### Perguntas e respostas **O que deve ser incluído no Trace de uma conversa?** A solicitação conforme formulada, o tópico identificado, os trechos efetivamente recuperados, as ações invocadas e seus parâmetros, o resultado de cada ação, os pontos de aprovação humana e sua decisão, e o motivo do encerramento ou escalonamento. Sem os trechos recuperados, é impossível distinguir entre um problema de conteúdo e um problema de modelo. **Por quanto tempo Traces devem ser armazenados?** Tempo suficiente para investigar uma tendência trimestral, mas em conformidade com as políticas de retenção de dados e regulamentação. O conteúdo da conversa com dados do cliente é geralmente armazenado por um período mais curto do que os metadados. Portanto, é comum separar: métricas e metadados a longo prazo, conteúdo completo a curto prazo. **É necessário usar uma ferramenta de monitoramento externa?** Não inicialmente. Um Dashboard interno com cinco a sete métricas e uma fila de conversas falhas é suficiente para o primeiro ano. Uma ferramenta externa é justificada quando há múltiplos agentes, múltiplos canais e a necessidade de cruzar dados com outros sistemas de monitoramento na organização. **Como saber se a queda na qualidade se deve ao modelo ou ao conteúdo?** Observe a fase de recuperação no Trace. Se o trecho correto não foi recuperado, é um problema de conteúdo ou categorização. Se o trecho correto foi recuperado e a resposta ainda está incorreta, o problema está nas instruções ou na formulação. Essa distinção economiza semanas de adivinhação. **Quem deve, de fato, analisar os dados?** O proprietário do processo de negócios semanalmente, juntamente com o gerente da plataforma. O monitoramento que se restringe apenas à equipe técnica identifica falhas, mas não detecta respostas tecnicamente corretas e comercialmente prejudiciais — e este é o tipo de falha mais comum. --- ## Build ou Buy no Agentforce: Ações Prontas, Flow, Apex e APIs URL: https://hpi.pro/pt/insights/agentforce-build-vs-buy-actions Toda ação executada por um agente tem quatro caminhos de implementação, e a diferença entre eles não é meramente técnica: ela impacta quem manterá o sistema, como os testes serão realizados e o tempo necessário para futuras mudanças. Este guia apresenta uma ordem de escolha clara, o custo de manutenção de cada opção e os casos em que o Apex é a escolha correta, apesar do custo. ## A Resposta Breve Ações são o ponto onde um agente para de falar e começa a fazer, e é por isso que a maior parte do risco e do custo de manutenção está concentrada nelas. Existem quatro formas de implementação: Ações Padrão, Flow, Apex e External Services acionando uma API externa. A escolha entre elas não é uma questão de capacidade – quase todas as ações são possíveis em qualquer uma delas – mas sim de quem as manterá, com que rapidez podem ser alteradas e como são testadas. A ordem de escolha recomendada é de cima para baixo: começar com uma Ação Padrão, passar para o Flow quando for necessária lógica de negócios, para o Apex quando a complexidade for real e para External Services quando a verdade estiver fora do Salesforce. Cada degrau para baixo na escala adiciona um custo de manutenção e, portanto, exige uma justificativa. ## Tabela de Decisão | Implementação | Quando é Apropriado | Quem Mantém | Custo da Opção | | --- | --- | --- | --- | | Ação Padrão | Recuperação, atualização de campo, abertura de Case, resumo de registro | Administrador da plataforma | Flexibilidade limitada para regras de negócios | | Flow | Regras de negócios variáveis, várias etapas, validação | Administrador ou proprietário do processo | Desempenho em alto volume, tratamento de erros limitado | | Apex | Lógica complexa, processamento massivo, controle de erros | Apenas desenvolvedor | Cada alteração requer ciclo de implantação e testes | | External Services / API | Fonte da verdade fora do Salesforce | Equipe de integração | Dependência da disponibilidade, latência e versões de terceiros | ## A Primeira Regra: Descrição Antes da Implementação Antes de escolher a tecnologia, escreva a descrição da ação. Isso pode parecer processual, mas é o elemento que determina se o agente executará a ação correta. O agente não lê o código – ele lê a descrição e decide com base nela. Uma boa descrição inclui três partes: o que a ação faz, em que situações usá-la e, explicitamente, em que situações não usá-la. A terceira linha é a que é esquecida, e é ela que impede o agente de ativar uma ação de crédito quando o cliente apenas perguntou sobre a política de devoluções. Os parâmetros devem ser mínimos e de um tipo definido. Um parâmetro de texto livre onde o agente deve preencher um valor de uma lista fechada é um convite a erros; uma lista de valores definida resolve isso sem lógica adicional. ## Quando Usar Flow e Quando Usar Apex Flow é o padrão para regras de negócios porque é visível e permite que o proprietário do processo entenda o que está acontecendo. Para agentes, uma vantagem adicional é a velocidade de correção: quando se descobre que a ação não está verificando as condições de elegibilidade, a correção pode ser feita no mesmo dia. Apex é justificado em quatro situações: lógica com muitas ramificações que tornam o Flow ilegível, processamento de grandes volumes em uma única leitura, necessidade de controle preciso no tratamento de erros e transações, e integração que requer processamento de resposta complexo. Fora dessas situações, o Apex principalmente eleva o custo da próxima mudança. A escolha também está ligada a uma dívida técnica existente. Uma organização que já carrega milhares de linhas de Apex sem testes deve pensar duas vezes antes de adicionar outra camada – as considerações completas são apresentadas em [Salesforce Flow vs. Apex](/pt/insights/salesforce-flow-vs-apex). ## Ações com Sistemas Externos Esta é a área onde as falhas chegam ao usuário final. Três decisões devem ser tomadas antes da construção: qual é o tempo máximo de espera, o que o agente diz quando a chamada falha e se é permitido tentar novamente. Idempotência é o conceito crucial. Uma ação de leitura pode ser repetida com segurança. Uma ação que cria um registro, envia uma mensagem ou cobra um cartão – uma nova tentativa pode gerar duplicidade. A solução é uma chave única para cada solicitação que o sistema receptor identifica, ou uma renúncia consciente à nova tentativa. A Latência é uma consideração de experiência, e não apenas técnica. Uma chamada que leva alguns segundos é aceitável em um canal de chat se o agente disser que está verificando; uma chamada que leva mais tempo do que isso requer um caminho assíncrono – o agente confirma o recebimento e atualiza quando a resposta chega. Os padrões de tratamento de falhas de integração são detalhados em [Tratamento de Erros de Integração no Salesforce](/pt/insights/salesforce-integration-error-handling). ## Permissões no Nível da Ação Cada Ação deve ser restrita por uma permissão separada. O erro comum é conceder ao agente um perfil amplo que cobre todas as ações, impedindo que uma ação específica seja aberta para um grupo sem abrir todas. Princípio de trabalho: permissão mínima para cada ação, validação dentro da ação e não apenas nas instruções para o agente, e verificação de que a ação respeita o contexto do usuário. Não se deve confiar que as Instruções impedirão a execução – as instruções são orientação, não controle. ## Quando Dividir uma Ação Uma ação que realiza três coisas é difícil de testar e difícil de aprovar. Um sinal para dividir: quando parte da ação requer aprovação humana e parte não, quando partes diferentes exigem permissões diferentes, ou quando uma falha no meio deixa o processo em um estado inconsistente. A divisão encarece um pouco a orquestração, mas compensa: cada parte é testada separadamente, o agente pode fazer pausas entre as partes e as permissões são precisas. A regra prática – uma ação, um critério de decisão. O planejamento dos pontos de parada entre as partes é detalhado em [Human-in-the-Loop no Agentforce](/pt/insights/agentforce-human-in-the-loop). ## Cenário: Uma Organização que Voltou do Apex para o Flow Uma empresa de serviços construiu seis Ações em Apex em um projeto piloto, assumindo que assim obteria controle total. Em dois meses, descobriu-se que quatro delas haviam alterado a lógica três vezes cada – não por bugs, mas porque as regras de negócios foram descobertas em uso. Cada alteração exigia um desenvolvedor, testes e um ciclo de implantação de vários dias. Na segunda rodada, as duas ações que permaneceram em Apex eram aquelas com múltiplas chamadas a um sistema externo e processamento de resposta. As outras quatro foram migradas para Flow, e o administrador da plataforma assumiu a responsabilidade por elas. O tempo médio de correção caiu de dias para horas. A lição não foi que o Apex é ruim, mas que, na fase em que as regras ainda estão sendo formuladas, o custo da mudança é mais importante do que o custo inicial de construção. ## Riscos e Ações Preventivas | Risco | Como se Manifesta | Ação Preventiva | | --- | --- | --- | | Descrição da ação vaga | O agente executa a ação errada | Descrição com "quando sim" e "quando não" e parâmetros definidos | | Nova tentativa cega | Registros ou cobranças duplicadas | Chave única para a solicitação ou renúncia ao Retry | | Ampla permissão para o agente | Ação sensível acessível a qualquer usuário | Permissão separada para cada Ação e validação dentro da ação | | Toda a lógica em Apex | Cada mudança de negócio se torna um projeto de desenvolvimento | Flow para regras variáveis, Apex para complexidade real | | Ação que faz três coisas | Falha no meio deixa estado inconsistente | Divisão por critério de decisão e por permissão | ## Métricas para Ações | Métrica | O que Revela | Frequência | | --- | --- | --- | | Taxa de sucesso da Ação | Percentual de execuções concluídas com sucesso | Semanal | | Taxa de ação errada | Percentual de casos em que uma ação incorreta foi selecionada | Em cada versão | | Latência mediana por ação | Se a experiência permanece razoável | Semanal | | Taxa de falhas de integração | Estabilidade dos sistemas de destino | Semanal | | Tempo médio de correção | Se a implementação escolhida permite mudanças rápidas | Mensal | Quando for necessário acompanhamento no planejamento da camada de Ações e na sua adaptação à arquitetura existente, o [serviço Agentforce e AI](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist para Cada Ação - ☐ Descrição escrita com "o quê", "quando sim" e "quando não" - ☐ Parâmetros mínimos e de tipo definido - ☐ Implementação de nível mais alto suficiente para a necessidade selecionada - ☐ Permissão separada definida para a ação - ☐ Validação reside dentro da ação e não apenas nas instruções - ☐ Determinado se a ação é idempotente e qual a política de Retry - ☐ Tempo máximo de espera e mensagem de falha para o usuário definidos - ☐ Múltiplas ações de decisão divididas - ☐ Cenário de teste para falha e não apenas para sucesso existente ### Perguntas e respostas **Por que não simplesmente construir tudo em Apex e finalizar?** Porque cada Ação em Apex torna a próxima modificação dependente de um desenvolvedor e de um ciclo de implantação. Em operações baseadas em regras de negócios mutáveis, o Flow permite que o proprietário do processo atualize-as de forma autônoma. O Apex se justifica quando há lógica complexa, processamento massivo ou chamadas que exigem controle preciso de erros. **As Ações Padrão são suficientes para um piloto?** Geralmente sim, e de propósito. Um piloto que começa com a recuperação de um registro, atualização de um campo e abertura de um caso é construído em dias, não semanas, permitindo testar a questão fundamental – se o agente escolhe corretamente quando usar uma ação – antes de investir no desenvolvimento. **Como o agente sabe quando ativar uma Ação específica?** Pela descrição que lhe foi atribuída. Uma descrição ambígua é a razão mais comum para o agente ativar a ação errada. Uma boa descrição explica o que a ação faz, quando usá-la e, explicitamente, quando não usá-la, utilizando termos que aparecem nas perguntas dos usuários. **O que acontece quando uma chamada para um sistema externo falha no meio do processo?** É preciso definir previamente: uma mensagem clara para o usuário, o registro da falha no Trace e uma política de nova tentativa apenas para operações idempotentes. Uma ação que cria um registro ou cobra um cartão de crédito não deve ser tentada novamente cegamente, para evitar duplicidades. **Quando é aconselhável dividir uma única ação em várias Ações?** Quando a ação executa mais de uma decisão ou quando parte dela exige aprovação humana e outra parte não. A divisão permite atribuir permissões diferentes a cada parte, testar cada parte separadamente e permitir que o agente pause o processo sem deixar uma operação parcialmente executada. --- ## Gestão do Conhecimento para Agentforce: Preparando Dados Não Estruturados para IA URL: https://hpi.pro/pt/insights/agentforce-knowledge-readiness Uma base de conhecimento construída para humanos não está pronta para um Agente: contém versões conflitantes, documentos sem proprietário e conteúdo interno misturado com conteúdo para o cliente. Este guia apresenta um processo de preparação de cinco etapas – auditoria, arquivamento, estruturação, rotulagem e propriedade – com limites de entrada para indexação e um modelo de manutenção sustentável a longo prazo. ## A Resposta Breve Um acervo de conhecimento organizacional é frequentemente construído para seres humanos que sabem preencher lacunas, identificar documentos desatualizados e consultar colegas. Um agente não é capaz de fazer nenhuma dessas três coisas. Por isso, o treinamento não se concentra em adicionar conteúdo, mas principalmente em remover, decidir e categorizar. O processo prático envolve cinco etapas: auditoria de cobertura e validade, arquivamento de conteúdo obsoleto e conflitante, reorganização da estrutura do artigo, categorização para recuperação e atribuição de responsabilidade com um SLA para atualização. A quinta etapa é a que determina se o investimento será sustentável por mais de seis meses. Como a camada de recuperação consome esse conteúdo é explicado em [Grounding e RAG no Agentforce](/pt/insights/agentforce-grounding-rag). ## Etapa 1: Auditoria Focada Não audite o acervo inteiro. Pegue a lista de cenários que o agente irá lidar e gere uma lista de perguntas reais – a partir de consultas recebidas na prática, não da imaginação. Para cada pergunta, verifique: existe um artigo, quando foi atualizado, quem é o proprietário e se a resposta está correta hoje. O resultado são quatro categorias: coberto e válido, coberto mas desatualizado, coberto em várias versões conflitantes, e não coberto de forma alguma. A terceira categoria é a mais perigosa, pois é a que faz com que o agente forneça respostas diferentes para a mesma pergunta. A lacuna encontrada na quarta categoria não é necessariamente um problema – ela se torna uma lista de redação e, por enquanto, uma lista de tópicos que são encaminhados a um humano. ## Etapa 2: Arquivar Antes de Escrever A instrução mais difícil de aceitar em organizações é a de excluir. No entanto, um artigo desatualizado que permanece no acervo causa mais danos do que um artigo ausente: a falta leva à escalada, enquanto a desatualização leva a uma resposta incorreta com confiança. Uma regra de trabalho simples: qualquer artigo que não tenha um proprietário e não tenha sido atualizado além do período definido para sua área – é removido do índice. Ele pode permanecer no arquivo para fins de documentação, mas não é acessível ao agente. Em caso de conflito entre duas versões, a decisão é do proprietário do conteúdo e não da equipe técnica. Este é um ponto que requer uma decisão de negócio, e ignorá-lo fará com que o problema retorne na fase de testes. ## Etapa 3: Estrutura do Artigo Uma boa estrutura para um agente também é uma boa estrutura para um leitor, portanto não é um trabalho redundante. O título é formulado como uma pergunta ou cenário na linguagem que os usuários utilizam, não em uma linguagem interna. O primeiro parágrafo fornece uma resposta curta e independente. Os detalhes vêm em seções com subtítulos. Duas regras que afetam diretamente a qualidade da recuperação: condições de elegibilidade e exceções são colocadas em uma seção separada e marcada, não inseridas em uma frase; e tabelas permanecem pequenas e independentes, pois uma tabela cortada no meio gera uma resposta parcial. O que se deve evitar: artigos longos que cobrem cinco tópicos. É preferível dividir em cinco artigos focados – a recuperação é mais precisa e a manutenção é mais fácil. Os princípios mais amplos de gerenciamento de conhecimento no Service Cloud são detalhados em [Gerenciamento de Conhecimento no Salesforce](/pt/insights/salesforce-knowledge-management). ## Etapa 4: Categorização e Separação de Públicos Categorização mínima necessária em quase todas as organizações: produto ou linha de serviço, mercado ou país, idioma, público-alvo, status de aprovação e data de validade. Em uma organização global, a falta de categorização por mercado e idioma é a principal causa de respostas incorretas – o agente recuperará uma política de outro país com total confiança. A separação de públicos é uma decisão de segurança e não apenas de classificação. O conteúdo escrito para agentes às vezes inclui margens de desconto, formulações de objeções e informações competitivas. No canal do cliente, a regra padrão deve ser uma lista de permissão: apenas o conteúdo explicitamente marcado como aprovado para o cliente é incluído. Um documento em que a maior parte é permitida e um parágrafo é sensível não é um caso extremo – é comum. A solução é dividir o documento e não marcá-lo todo como interno. ## Etapa 5: Propriedade e Manutenção Esta é a etapa que determina a sustentabilidade do resultado. Para cada área de conhecimento, um proprietário é designado pelo nome, a frequência de revisão é definida e o que acontece quando um artigo expira é estabelecido – remoção automática do índice, em vez de um alerta que ninguém lê. O mecanismo de feedback é o que torna a manutenção eficaz. Cada conversa que resultou em escalonamento devido à falta de uma fonte entra na lista de lacunas de conteúdo, e esta é a melhor lista de prioridades para novas redações. É melhor escrever cinco artigos que foram realmente necessários do que cinquenta que pareciam importantes. Orçamento: a manutenção de conteúdo é um item permanente, não um projeto. Organizações que a tratam como uma tarefa única veem uma diminuição na precisão em dois trimestres. ## Limiares de Entrada no Índice | Critério | Limite Mínimo | Porquê | |---|---|---| | Propriedade | Proprietário nomeado para cada artigo | Sem proprietário, ninguém para atualizar | | Validade | Dentro do período de revisão definido para a área | Impede a citação de políticas canceladas | | Unicidade | Fonte única para cada tópico | Evita respostas contraditórias | | Público | Marcado como interno ou aprovado para cliente | Impede a exposição de conteúdo sensível | | Estrutura | Título com pergunta e resposta curta na introdução | Melhora a precisão da recuperação | ## Cenário: 1.400 Documentos Reduzidos para 190 Uma provedora de serviços de TI queria conectar um agente a uma pasta do SharePoint com 1.400 documentos. A auditoria inicial mostrou que apenas cerca de 30% deles haviam sido atualizados nos últimos três anos, e que aproximadamente 200 eram rascunhos ou versões de trabalho. Em vez de um projeto de limpeza abrangente, a equipe mapeou os 25 cenários que o agente deveria cobrir. Do acervo, foram encontrados 190 documentos relevantes; destes, 40 eram contraditórios e exigiram uma decisão de três proprietários de área. Os documentos selecionados foram divididos em artigos focados e categorizados por produto e público. O projeto piloto foi lançado com 190 itens, em vez de 1.400, e a precisão das respostas foi significativamente maior do que na primeira tentativa. O restante do acervo permaneceu arquivado e foi gradualmente inserido conforme a lista de lacunas acumuladas pelas escaladas reais. ## Riscos e Ações Preventivas | Risco | Como se manifesta | Ação Preventiva | |---|---|---| | Inclusão de todo o acervo | Baixa precisão e dificuldade em identificar a causa | Inclusão com base em cenários, não em todo o acervo | | Artigos sem proprietário | Obsolescência silenciosa | Propriedade como condição de entrada no índice | | Versões contraditórias | Respostas diferentes para a mesma pergunta | Decisão de negócio e arquivamento | | Mistura de conteúdo interno e externo | Exposição de informações sensíveis ao cliente | Lista de permissões no canal externo | | Manutenção como projeto único | Queda de precisão em dois trimestres | Orçamento regular e SLA para atualização | ## Métricas de Preparação de Conteúdo | Métrica | Definição | Frequência | |---|---|---| | Cobertura de Cenários | Percentual de cenários com artigo aprovado | Mensal | | Validade | Percentual de artigos no índice dentro da data de validade | Mensal | | Duplicidade de Tópicos | Número de tópicos com mais de uma fonte | Trimestral | | Lacunas de Escalonamento | Número de novos tópicos necessários e ausentes | Semanal | | Tempo Médio de Atualização | Quanto tempo leva para corrigir um artigo incorreto | Mensal | Quando é necessário suporte na preparação do acervo e na configuração do modelo de manutenção, o [Serviço Agentforce e IA](/pt/agentforce-ai) é a abordagem prática para prosseguir. ## Checklist para Preparação do Conhecimento - ☐ Lista de perguntas reais construída a partir de solicitações práticas - ☐ Cada pergunta classificada: válida, desatualizada, contraditória ou ausente - ☐ Artigos sem proprietário arquivados ou com proprietário atribuído - ☐ Conflitos resolvidos pelo proprietário do conteúdo - ☐ Artigos estruturados: título com pergunta, resposta curta, seções - ☐ Condições de elegibilidade e exceções em seção separada - ☐ Tagging de produto, mercado, idioma, público e validade existente - ☐ Conteúdo interno separado do conteúdo aprovado para o cliente - ☐ Frequência de revisão e remoção automática na expiração definida - ☐ Mecanismo estabelecido para converter escalonamentos em lista de redação ### Perguntas e respostas **É necessário reescrever todos os artigos antes de começar?** Não. Comece pelos cenários que o agente abordará na primeira versão – geralmente de vinte a quarenta artigos. A reescrita abrangente de uma base com centenas de artigos leva meses e muitas vezes é interrompida no meio, enquanto o treinamento focado é suficiente para um projeto piloto. **O que fazer com artigos que não têm proprietário?** Ou designe um proprietário ou archive. Um artigo sem proprietário continuará a se tornar obsoleto e o agente continuará a citá-lo. Esta é uma decisão inconveniente, mas é muito mais econômica do que descobrir retrospectivamente que o agente forneceu uma política que foi descontinuada há dois anos. **Como identificar artigos conflitantes em uma base de conhecimento grande?** Agrupe por tópico e verifique manualmente apenas os grupos com mais de um artigo. Você também pode perguntar ao próprio agente as vinte perguntas mais frequentes e verificar quais fontes foram recuperadas – uma inconsistência é revelada imediatamente quando aparecem dois artigos com respostas diferentes. **PDFs e documentos do Word são adequados como fonte?** Menos eficaz que um artigo estruturado, mas possível quando o documento é dividido em seções com títulos claros. Um documento digitalizado, uma apresentação ou um arquivo com tabelas complexas são fontes problemáticas, e é preferível extrair o conteúdo relevante para um artigo dedicado. **Qual é a estrutura correta de um artigo destinado também a um agente?** Uma pergunta ou cenário como título, uma resposta curta no primeiro parágrafo e, em seguida, detalhes em seções com subtítulos. Condições de elegibilidade e exceções em uma seção separada e não dentro de uma frase. Esta estrutura também serve a um leitor humano, portanto, não há comprometimento aqui. --- ## Governança de IA para Agentforce: Modelo de Responsabilidade, Riscos e Controles URL: https://hpi.pro/pt/insights/agentforce-ai-governance A governança de IA falha de duas maneiras: um comitê que bloqueia toda iniciativa, ou a ausência de controle que é exposta em auditorias. Nosso guia apresenta um modelo escalonado por risco – quem aprova o quê, quais controles são obrigatórios em cada nível, quais documentos são realmente necessários e como manter a agilidade sem comprometer a responsabilidade. ## A Resposta Breve Uma boa governança de IA não é uma camada adicional de aprovações, mas sim um mecanismo que decide rapidamente questões recorrentes: quem decide o que um agente pode fazer, quais controles são obrigatórios de acordo com o nível de risco e o que é exigido para mudar o comportamento após o lançamento. Na ausência de tal mecanismo, cada novo agente se torna uma discussão do zero. O princípio central é a classificação. Um agente interno que lê informações e não escreve nada não precisa passar pelo mesmo caminho que um agente que interage com clientes e processa estornos. Um caminho único gera bloqueio ou contorno, e geralmente ambos. ## Classificação de Risco: A Base para Todas as Outras Decisões | Nível | Características | Aprovadores | Controles Obrigatórios | | --- | --- | --- | --- | | Baixo | Interno, somente leitura, sem dados sensíveis de clientes | Dono do processo + Gerente da Plataforma | Grounding aprovado, log de conversas, revisão mensal | | Médio | Interno com escrita reversível, ou exposição de informações ao cliente | + Arquiteto + Representante de Dados | Conjunto de testes, testes de Persona, monitoramento semanal | | Alto | Operação com cliente, dinheiro, permissões ou dados irreversíveis | + Risco, Jurídico e CISO | Aprovação humana, trilha de auditoria completa, plano de Rollback | | Proibido | Decisões com impacto jurídico ou regulatório direto sem intervenção humana | - | Use Case rejeitado ou dividido em subtarefas de nível inferior | A classificação é determinada por apenas três perguntas: a ação é reversível, quem é exposto ao resultado e que tipo de informação está envolvida no processo. Três perguntas que podem ser respondidas em dez minutos, e é exatamente isso que torna o modelo utilizável. ## As Três Funções Essenciais O proprietário de negócios é responsável pelo resultado, define o que o agente pode fazer e resolve conflitos. Ele é quem terá que explicar à gerência por que o agente respondeu daquela maneira, e, portanto, não é possível deixar a função vazia ou dividi-la entre dois gerentes. O proprietário técnico é responsável pela implementação, monitoramento, processo de mudança e custo. Ele mantém o registro dos agentes e o Runbook para lidar com falhas. Um auditor independente – geralmente um representante de Risco ou segurança da informação – não está envolvido na construção e, portanto, pode auditar. Sua função é amostrar conversas, verificar se os controles declarados estão realmente funcionando e apresentar as descobertas ao fórum de decisão. Sem um ator que não seja parte interessada no sucesso do projeto, o controle se torna um auto-relato. O modelo de responsabilidade em relação à Salesforce e aos fornecedores de modelos é detalhado em [Segurança do Agentforce e Responsabilidade Compartilhada](/pt/insights/agentforce-security-shared-responsibility). ## Registro de Agentes Este é o único documento que não pode ser dispensado. Não precisa ser um sistema – uma tabela bem mantida é suficiente –, mas deve estar atualizado. Para cada agente ativo: objetivo em uma frase, proprietário de negócios e técnico, nível de risco, canais ativos, lista de Actions e suas permissões, fontes de Grounding, pontos de aprovação humana, data da última revisão e os três principais KPI. O registro resolve um problema que surge no segundo ano: a proliferação de agentes. Quando cada equipe constrói seu próprio agente, percebe-se que três agentes respondem à mesma pergunta de três maneiras diferentes, e ninguém sabe quem aprovou o terceiro. ## Processo de Mudança Pós-Lançamento A distinção entre uma mudança rotineira e uma mudança substancial é o que impede uma governança paralisante. Uma mudança rotineira – redação, correção de redação em uma resposta, adição de um artigo de Knowledge existente ao índice – segue o processo de mudança regular da plataforma. Uma mudança substancial requer nova aprovação no nível apropriado. Quatro mudanças são sempre significativas: adição de uma nova Action, ampliação de permissão, abertura de um novo canal e remoção ou suavização de um ponto de aprovação humana. Estas são precisamente as mudanças que são feitas discretamente sob pressão para melhorar o desempenho, e, portanto, precisam ser marcadas com antecedência. Os mecanismos de monitoramento que alimentam o processo de mudança são detalhados em [Observabilidade para Agentes de IA](/pt/insights/agentforce-observability). ## O Que a Governança Verifica na Prática, Trimestralmente A revisão trimestral não é uma apresentação de status. Ela verifica cinco coisas: se os agentes registrados ainda são necessários, se os controles declarados estão funcionando na amostragem, se o custo-benefício é justificável, quais escalonamentos recorrentes indicam uma lacuna de conteúdo e se as mudanças substanciais seguiram o caminho correto. O resultado da revisão é uma lista de decisões: expandir, reduzir, suspender ou encerrar um agente. Uma governança que não consegue encerrar um agente não é governança – é documentação. ## Cenário: Um Varejista Que Recuperou o Controle Sem Parar o Desenvolvimento Uma rede de varejo descobriu sete iniciativas de IA simultâneas em quatro departamentos, sem registro e sem o conhecimento da área de Risco. A primeira resposta proposta foi uma paralisação geral até o estabelecimento de uma política – uma medida que também congelaria as duas iniciativas que já estavam gerando valor. Em vez disso, foi realizado um mapeamento de duas semanas: cada iniciativa foi classificada por nível de risco. Cinco foram consideradas de baixo risco e continuaram com aprovação simplificada do proprietário do processo e do gerente da plataforma. Duas – uma que envolvia reembolsos a clientes e outra que expunha dados de estoque a fornecedores – foram movidas para um nível de alto risco, receberam pontos de aprovação humana e foram auditadas pela área de Risco antes de prosseguir. Seis meses depois, o número de iniciativas aumentou, mas a gerência sabia pela primeira vez o que existia, quem era responsável e qual era o custo. A conclusão prática: a governança ganhou legitimidade precisamente porque não bloqueou o nível de baixo risco. ## Riscos de Governança e Ações Preventivas | Risco | Como se manifesta | Ação preventiva | | --- | --- | --- | | Comitê bloqueador | Equipes constroem fora do caminho aprovado | Caminho rápido para baixo risco com apenas dois aprovadores | | Registro desatualizado | Auditor descobre agente que ninguém conhecia | Atualização do registro como condição para o lançamento de versão | | Propriedade apenas em TI | Ninguém decide sobre o comportamento de negócios | Nomeação de proprietário de negócios para cada agente | | Controle auto-relatado | Os controles existem no documento, mas não na realidade | Amostragem de conversas por um ator não envolvido na construção | | Mudança substancial silenciosa | Remoção de aprovação humana para melhorar o tempo de resposta | Lista fechada de mudanças que exigem nova aprovação | ## Métricas de Governança | Métrica | O que revela | Frequência | | --- | --- | --- | | Cobertura do registro | Percentual de agentes ativos documentados | Mensal | | Tempo médio de aprovação | Se o processo se tornou um gargalo | Mensal | | Resultados da amostragem | Discrepância entre controle declarado e situação real | Trimestral | | Mudanças substanciais no caminho correto | Disciplina do processo | Trimestral | | Agentes suspensos ou encerrados | Se a governança é capaz de decidir não | Trimestral | Quando é necessário suporte para estabelecer um modelo de governança que se adapte ao tamanho da organização e à regulamentação aplicável, o [Serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ## Checklist para Estabelecimento de Governança - ☐ Modelo de classificação de risco de três perguntas aprovado - ☐ Aprovadores definidos para cada nível, incluindo um caminho rápido para o nível baixo - ☐ Proprietários de negócios e técnicos nomeados para cada agente existente - ☐ Auditor independente não envolvido na construção nomeado - ☐ Registro de agentes com todos os campos obrigatórios estabelecido - ☐ Lista fechada de mudanças substanciais definida - ☐ Rotina de revisão trimestral estabelecida com autoridade para encerrar um agente - ☐ Métricas de governança e frequência de relatório à gerência definidas ### Perguntas e respostas **É necessário ter um comitê de IA separado ou podemos usar fóruns existentes?** Na maioria das organizações, é preferível expandir um fórum existente – como um comitê de mudanças ou arquitetura – adicionando representantes de Risco e Jurídico para as discussões de IA. Um comitê separado tende a se reunir mensalmente, tornando-se um gargalo, o que leva as equipes a contorná-lo. **Quem é o proprietário do agente: a área de negócio ou a TI?** O proprietário do processo de negócio é o responsável pelo resultado e pela decisão sobre o que o agente pode fazer. A TI é responsável pela implementação, monitoramento e estabilidade. Quando a propriedade permanece apenas na TI, ninguém decide sobre questões de comportamento, e o agente estagna na primeira versão. **Toda alteração nas 'Instructions' requer aprovação?** Não. Uma alteração de redação em um agente de baixo risco pode seguir um processo de mudança regular. No entanto, uma mudança que expanda permissões, adicione uma Ação (Action), abra um novo canal ou remova um ponto de aprovação humano – isso é uma mudança substancial que requer nova aprovação no nível apropriado. **O que realmente deve constar no registro dos agentes?** Para cada agente ativo: o objetivo em uma frase, proprietário da área de negócio, classificação de risco, canais, lista de Ações (Actions) e suas permissões, fontes de 'grounding' (base de conhecimento), pontos de aprovação humana, data da última revisão e métricas de desempenho. Este é o primeiro documento que qualquer auditor solicitará. **Como evitar que a governança retarde o desenvolvimento?** Definimos um caminho rápido para riscos baixos: um agente de leitura em um canal interno aprovado pelo proprietário do processo e pelo gerente da plataforma, sem a necessidade de um comitê. À medida que o risco aumenta, adicionamos aprovadores e controles. Um caminho único e padronizado para todos os agentes é a razão mais comum para a governança ser contornada. --- ## Lead-to-Cash no Sales Cloud: Otimizando o Processo de Vendas até o Pedido URL: https://hpi.pro/pt/insights/salesforce-lead-to-cash O processo Lead-to-Cash frequentemente enfrenta rupturas em três pontos cruciais: da qualificação do lead à oportunidade, da oportunidade à proposta aprovada, e da proposta ao pedido no ERP. Este guia detalha as configurações essenciais em cada etapa, como determinar a fonte do preço e por que a aprovação de descontos é um gargalo comum. ## A Resposta Curta Lead-to-Cash é um processo que cruza quatro áreas – Marketing, Vendas, Finanças e Operações – e, portanto, tende a falhar nas interfaces entre elas, e não no centro. As três principais transições que definem tudo são: quando um lead se torna uma oportunidade, quando uma proposta é aprovada, e quando uma oportunidade fechada se transforma em um pedido no sistema operacional. Para cada uma dessas transições, devem existir três respostas documentadas: quem decide, o que é necessário para a transição e o que acontece quando a transição falha. A falta de qualquer uma dessas respostas cria uma dependência de planilhas auxiliares, o que leva à maioria das discrepâncias entre o que foi vendido e o que foi faturado. ## Transição 1: De Lead para Oportunidade Este é o limite que determina a qualidade de todo o Pipeline. A falha comum é a conversão automática de cada lead, o que inflaciona a previsão e torna o histórico de conversão inútil. O que é necessário: critério de conversão documentado (contato com autoridade, necessidade articulada, horizonte de tempo), um Owner definido para cada lado da transição e uma regra para lidar com leads que não atendem aos critérios – Nurture, e não exclusão. Mais detalhes sobre este tópico estão disponíveis em [Implementação do Sales Cloud](/pt/insights/sales-cloud-implementation). ## Transição 2: De Proposta para Proposta Aprovada Esta etapa concentra a maior parte do atraso no processo, quase sempre devido a uma hierarquia de aprovação indefinida, e não à ferramenta em si. | Componente | O Que Deve Ser Definido | O Que Acontece Sem Ele | | --- | --- | --- | | Catálogo e Lista de Preços | Fonte única de verdade para precificação | Propostas com preços inseridos manualmente | | Limite de Desconto | Hierarquia baseada em porcentagem e tipo de cliente | Todo desconto vai para o CEO ou nenhum é concedido | | Tempo de Resposta para Aprovação | Meta definida, por exemplo, um dia útil | Contato telefônico para aprovação e registro posterior | | Condições Não-Comerciais | Prazos de pagamento, garantia, SLA | Compromissos que nunca chegam ao financeiro | A última linha é frequentemente negligenciada: as organizações implementam um controle rigoroso de descontos, mas permitem que um representante prometa condições de pagamento com prazo de +90 dias sem qualquer aprovação. ## Transição 3: De Oportunidade Fechada para Pedido Este é o ponto mais técnico e onde as falhas são mais custosas. Três questões que definem a arquitetura são: 1. **Quem emite o pedido** – Geralmente o ERP. O Salesforce envia uma solicitação e recebe um identificador, sem gerenciar estoque ou faturamento. 2. **O que acontece em caso de falha** – É necessário um status visível na oportunidade, um alerta para o responsável pelo processo e um mecanismo de reenvio idempotente para evitar a criação de pedidos duplicados. 3. **O que retorna** – Pelo menos o identificador do pedido, o status de entrega e o status de faturamento. Sem esse retorno, os vendedores telefonam para o financeiro para obter respostas para os clientes. Os princípios de design da própria integração estão detalhados em [Integração Salesforce e ERP](/pt/insights/salesforce-erp-integration), e o tratamento de falhas em [Tratamento de Erros em Integrações](/pt/insights/salesforce-integration-error-handling). ## O Problema Silencioso: Coordenação de Produtos Entre Sistemas A maioria das discrepâncias entre a proposta e a fatura não se deve ao preço, mas ao produto. Um código de item que existe no ERP mas não no Salesforce, um produto que foi descontinuado em um sistema e permanece ativo no outro, ou uma unidade de medida diferente. A regra: o catálogo de produtos é de propriedade exclusiva de um sistema – geralmente o ERP – e é sincronizado com o Salesforce em uma frequência definida, incluindo a marcação de produtos descontinuados em vez de sua exclusão. A exclusão quebra vendas históricas e distorce análises. ## O Que Medir | Métrica | O Que Ela Revela | | --- | --- | | Tempo médio para aprovação de proposta | O gargalo mais comum | | Taxa de propostas recriadas | Sinal de precificação não clara ou catálogo incompleto | | Falhas na criação de pedidos | Estabilidade da integração | | Diferença entre valor da oportunidade e valor da fatura | Qualidade do processo de ponta a ponta | | Oportunidades fechadas sem pedido em 48 horas | Leads que se perderam entre os sistemas | A última métrica é a verificação mais simples da saúde do processo, e poucas organizações a monitoram regularmente. ## Ordem de Implementação Primeiro, implemente um único caminho de vendas de ponta a ponta – um tipo de cliente, uma categoria de produto – até a criação bem-sucedida de um pedido no ERP. Somente depois que esse caminho estiver estável, adicione configurações, moedas, entidades legais e renovações. Uma expansão prematura fixa decisões de preço antes que sejam testadas em campo. ## Resumo Lead-to-Cash não é um projeto tecnológico, mas um acordo entre quatro áreas sobre três transições. Quem documenta e define essas transições – incluindo os caminhos para falhas – obtém um processo que pode ser medido; quem começa pelas ferramentas obtém uma cadeia que funciona em demonstrações e depende de telefonemas na prática. ### Perguntas e respostas **É essencial ter um CPQ para gerenciar o Lead-to-Cash?** Não. Catálogos de produtos e listas de preços padrão são suficientes para precificações simples. O CPQ é necessário para configurações dependentes, níveis de quantidade, renovações ou precificação de assinaturas complexas. **Onde a precificação deve residir: no Salesforce ou no ERP?** O preço de tabela pode existir em ambos, mas apenas um deve ser a fonte da verdade, alimentando o outro. Preços definidos independentemente em dois sistemas resultam em inconsistências entre a proposta e a fatura. **O que fazer quando um pedido falha no ERP?** É crucial ter um caminho de falha definido: um status claro no pedido, alerta para o responsável pelo processo e a opção de reenvio sem duplicidade. Sem isso, negócios fechados podem se perder entre os sistemas. **Quem aprova limites de desconto?** É necessário um escalonamento de aprovação com base em limites e tipos de exceção, com tempo de resposta definido. Aprovações que excedem um dia útil levam a desvios telefônicos e perdem o valor do controle. **É obrigatório o objeto 'Order' no Salesforce?** Quando o ERP é o emissor do pedido, geralmente é suficiente refletir o status e o ID. Um objeto 'Order' completo é justificável quando há múltiplos pedidos por transação, entregas parciais ou renovações gerenciadas no CRM. --- ## Forecast e Dashboards no Sales Cloud: Como criar uma previsão confiável URL: https://hpi.pro/pt/insights/salesforce-forecast-dashboards Quando um gerente de vendas elabora uma previsão em uma planilha separada, o problema não está no dashboard. Uma previsão confiável se baseia em quatro pré-requisitos: uma hierarquia sólida, datas de fechamento precisas, categorias acordadas e um ciclo de revisão consistente. Este guia explica como construir esses elementos e o que monitorar para determinar se a previsão realmente melhorou. ## A Resposta Curta Uma previsão (forecast) não é o resultado de um dashboard, mas sim de uma disciplina de dados. Se as oportunidades (deals) são atualizadas uma vez por semana, na noite anterior à reunião de pipeline, nenhum design de relatório gerará uma imagem confiável. Portanto, o trabalho de previsão começa com quatro condições operacionais e somente depois na sua visualização. O sinal mais claro de que essas condições não estão sendo atendidas é simples de identificar: existe uma planilha de previsão paralela. Enquanto ela existir, a própria organização declara que o sistema não é a fonte da verdade. ## As Quatro Pré-condições | Condição | O Que É Necessário | O Que Acontece Sem Ela | | --- | --- | --- | | Hierarquia de Usuários Correta | Role Hierarchy que reflete a estrutura de vendas real | Consolidação incorreta da previsão no nível do gestor | | Datas de Fechamento Limpas | Regra que proíbe datas passadas há mais de uma semana | Previsão que inclui oportunidades "mortas" | | Categorias Acordadas | Definição escrita para Pipeline, Best Case, Commit | Cada gestor interpreta de forma diferente | | Ciclo de Revisão Fixo | Reunião semanal diretamente no sistema | Atualização retroativa antes das reuniões | A quarta condição é a que gera as três primeiras. No momento em que a reunião é conduzida a partir da tela e não de uma planilha, os representantes atualizam seus dados, pois, caso contrário, suas oportunidades não seriam visíveis. ## Categorias de Previsão (Forecast): Onde o Julgamento Humano se Encontra A confusão comum é entre probabilidade e categoria. A probabilidade é derivada do estágio e usada para o cálculo ponderado – é uma estatística. A categoria é uma declaração de compromisso de uma pessoa. Uma separação correta se parece com isso: o estágio determina a probabilidade automática que ninguém pode sobrescrever; o gerente de contas classifica a oportunidade como Best Case ou Commit de acordo com o conhecimento do cliente; e o gerente de equipe pode alterar a classificação na revisão, com documentação. Assim, obtêm-se dois números com significados diferentes – uma estimativa estatística e um compromisso gerencial – em vez de um único número vago. A definição dos próprios estágios de vendas, dos quais a probabilidade é derivada, é detalhada em [Implementação do Sales Cloud](/pt/insights/sales-cloud-implementation). ## Três Dashboards, Não Trinta A proliferação de dashboards é um sintoma de que ninguém confia nos existentes. A estrutura que funciona é: 1. **Previsão para a Diretoria** - Um único número para o trimestre com segmentação por categoria, comparação com a meta e tendência semanal. Sem detalhes de oportunidades. 2. **Pipeline para Gestão de Equipe** - Oportunidades por estágio e idade, com destaque para anomalias: oportunidades que não se moveram, datas vencidas, valores alterados. 3. **Lista de Trabalho para o Representante** - O que exige ação hoje. Não é um relatório, mas uma fila de trabalho. O teste simples: se dois dashboards exibem o mesmo número com valores diferentes, pelo menos um deles é redundante ou incorreto. ## Medição da Precisão da Previsão Esta é a métrica que a maioria das organizações não mede e, portanto, não sabe se melhorou: - **Desvio de Commit** - A diferença entre o valor do Commit no início do trimestre e o resultado real. Um desvio acima de 20% indica uma definição de Commit frouxa. - **Estabilidade da Previsão** - O quanto a previsão mudou de semana para semana. Alta volatilidade indica atualização tardia, não um mercado dinâmico. - **Slippage** - Oportunidades adiadas para o próximo trimestre. Uma alta taxa indica critérios de estágio fracos. - **Precisão por Representante** - Revela quem inflaciona sistematicamente e quem é conservador, permitindo correção individual em vez de um fator de correção geral. Métricas complementares para adoção estão disponíveis em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## O Erro Recorrente: Construir um Relatório em Vez de Corrigir um Processo Quando a previsão não é precisa, a resposta comum é pedir mais recortes – por produto, por região, por fonte. Isso gera uma sobrecarga de relatórios e esconde a causa. Se 30% das oportunidades têm uma data passada, nenhuma segmentação ajudará. A sequência correta: corrigir a qualidade dos dados, fixar o ciclo de revisão, medir a precisão por um trimestre e, só então, considerar recortes adicionais. ## Resumo Uma previsão confiável é o produto de uma rotina de gestão suportada pelo sistema, não de uma ferramenta de previsão. Três perguntas que determinam se você chegou lá: Existe uma planilha paralela, todos concordam com o que entra no Commit e alguém mede a precisão da previsão retroativamente? Três boas respostas valem mais do que qualquer aprimoramento de dashboard. ### Perguntas e respostas **Por que a previsão no sistema difere da previsão do gerente de vendas?** Quase sempre porque a definição de 'Commit' (compromisso) não está alinhada: o gerente inclui negócios na previsão com base no conhecimento do cliente, e o sistema calcula com base no estágio. A solução é uma definição escrita do que entra no 'Commit' e quem está autorizado a movimentar. **Devo usar probabilidade automática ou o julgamento do representante?** Ambos, mas separadamente. A probabilidade é derivada do estágio e usada para um cálculo ponderado; o julgamento humano é expresso na categoria da previsão. Misturar os dois – um representante que sobrescreve porcentagens manualmente – anula a eficácia de ambos. **Quantos dashboards são necessários?** Geralmente, três: uma previsão para a gestão, um pipeline para a gestão da equipe e uma lista de trabalho para o representante. O excesso de dashboards gera versões conflitantes do mesmo número. **O que fazer com negócios cujas datas de fechamento já passaram?** Uma regra operacional rígida: um negócio com data vencida há mais de uma semana exige atualização ou movimentação para 'Closed Lost'. Sem isso, qualquer cálculo de previsão é baseado em dados imprecisos. **Em quanto tempo posso esperar uma melhoria na precisão?** Geralmente após dois a três ciclos de vendas completos – este é o tempo mínimo para acumular negócios gerenciados de acordo com as novas definições, permitindo comparar a previsão com o resultado real. --- ## Omni-Channel e SLA no Service Cloud: Planejamento de Roteamento e Capacidade URL: https://hpi.pro/pt/insights/service-cloud-omnichannel-sla A falha do Omni-Channel geralmente não reside nas configurações de roteamento, mas sim no modelo de capacidade. Quando chat, e-mail e telefone são medidos com a mesma unidade de peso, os agentes ficam sobrecarregados ou ociosos intermitentemente. Este guia explica como determinar pesos de trabalho, conectar Entitlements ao roteamento e identificar antecipadamente se o modelo não suporta a carga. ## A Resposta Concisa O Omni-Channel não é um mecanismo de distribuição, mas sim um modelo de capacidade. Ele faz uma única pergunta a cada momento: qual a carga de trabalho que este agente consegue suportar agora? Se a resposta a essa pergunta estiver incorreta – por exemplo, se um chat e um e-mail tiverem o mesmo peso –, o roteamento funcionará exatamente como configurado e prejudicará o serviço. Portanto, a ordem de trabalho é: primeiro o modelo de capacidade e pesos, depois as habilidades, em seguida os Entitlements e Milestones, e só no final as automações de escalonamento. ## O Modelo de Capacidade: O Ponto Que Define Tudo O Omni-Channel atribui a cada agente uma "cota de trabalho" (Capacidade) e um peso a cada item de trabalho. Um contact center que define um peso uniforme para todos os canais obterá um dos dois resultados: agentes de chat sobrecarregados, ou agentes que tratam e-mails parecendo ocupados enquanto estão disponíveis. Um ponto de partida razoável para calibração: | Tipo de Trabalho | Característica | Peso Relativo Recomendado | | --- | --- | --- | | Chamada Telefônica | Síncrona completa | Ocupa toda a capacidade | | Chat ao Vivo | Síncrono com pequenas pausas | Alto, geralmente 2-3 simultâneos no máximo | | E-mail / Formulário | Assíncrono | Baixo | | Case Aguardando Cliente | Inativo | Zero - deve liberar capacidade | A última linha é a mais comum nos erros: um Case que espera pelo cliente e continua a ocupar capacidade faz com que os agentes pareçam ocupados, embora não tenham trabalho ativo. ## Habilidades: Menos É Mais O Roteamento Baseado em Habilidades (Skills-Based Routing) parece uma melhoria óbvia, mas na prática é a fonte mais comum de solicitações travadas. Quanto mais requisitos de habilidades são adicionados, maior a chance de que não haja um agente disponível que atenda a todos eles. Três regras para evitar isso: definir habilidades apenas quando a ausência delas realmente impede o atendimento; definir um nível de Fallback para cada requisito, que é ativado após um tempo de espera definido; e verificar mensalmente quantas solicitações foram alocadas via Fallback – uma porcentagem alta indica que o modelo não está alinhado com a equipe do contact center. ## Entitlements e Milestones: Do Compromisso ao Mecanismo Um SLA que aparece apenas em um relatório é um registro pós-evento. Entitlements e Milestones o transformam em um mecanismo ativo: 1. **Entitlement** define qual cliente tem direito a qual nível de serviço – geralmente um padrão e algumas exceções contratuais. 2. **Milestone** define os pontos de tempo medidos: primeira resposta, atualização periódica, resolução. 3. **Business Hours** determinam quando o relógio está em execução e devem ser configurados para cada fuso horário e para cada canal separadamente. 4. **Stopped Time** congela o cronômetro enquanto aguarda o cliente – sem isso, as métricas penalizam o contact center pelo comportamento do cliente. 5. As **Ações do Milestone** geram alertas e escalonamentos **antes** da violação, geralmente em torno de 75-80% do tempo. A regra principal: se o primeiro alerta chegar após a violação, o mecanismo está medindo, não gerenciando. As decisões fundamentais sobre a definição do Case e do relógio de SLA são detalhadas em [Implementação do Service Cloud](/pt/insights/service-cloud-implementation). ## Como Saber Se o Modelo Não Está Aguentando Cinco sinais precoces, antes que as métricas mensais revelem um problema: - Alta porcentagem de alocações via Fallback – as habilidades não correspondem à equipe. - Solicitações na fila de alocação por mais de alguns minutos – falta de capacidade ou regra de Overflow ausente. - Agentes relatando sobrecarga, enquanto o relatório de capacidade mostra disponibilidade – pesos incorretos. - Concentração incomum de violações de SLA em um horário fixo do dia – problema de equipe, não de roteamento. - Alta taxa de solicitações alocadas e imediatamente abandonadas – agentes recusando trabalho que não lhes convém. ## Medição Contínua | Métrica | O Que Ela Revela | | --- | --- | | Tempo na fila de alocação | Se o modelo encontra um agente a tempo | | Utilização média da capacidade | Se os pesos são realistas | | Violações por Milestone | Onde exatamente o SLA é quebrado | | Taxa de escalonamentos evitados | Se o alerta precoce está funcionando | | Diferenças nas violações entre canais | Se um determinado canal está sendo prejudicado no roteamento | ## Ordem de Implementação Ative um canal com um único Entitlement e sem habilidades, calibre os pesos com dados reais por duas semanas, e só então adicione um segundo canal e habilidades. A ativação completa em um único dia impede a capacidade de identificar qual componente causou a sobrecarga e geralmente termina com o desligamento do roteamento e o retorno às filas manuais. ## Resumo O Omni-Channel é um modelo de capacidade, não de distribuição, e o SLA é um mecanismo de alerta, não um relatório. Esses dois princípios determinam se o contact center funcionará de acordo com o sistema ou encontrará maneiras de contorná-lo – e a diferença é revelada já na primeira semana de operação. ### Perguntas e respostas **Como é determinado o peso da capacidade para cada canal?** Medimos quanto do tempo real cada tipo de trabalho exige atenção contínua. Um chat ao vivo ocupa um agente quase que totalmente, enquanto um e-mail não é síncrono. Pesos definidos apenas por estimativa geralmente se mostram incorretos em duas semanas. Por isso, é fundamental planejar um ciclo de calibração. **Quantas Habilidades devem ser configuradas?** Poucas e claras. O excesso de habilidades gera cenários em que nenhum agente atende a todos os requisitos, e as solicitações ficam paralisadas sem atribuição. É preferível uma habilidade básica com um Fallback definido. **Os Entitlements são necessários para todos os clientes?** Não. Define-se um padrão para todos os clientes e exceções apenas para aqueles com um contrato de serviço diferente na prática. A duplicação de Entitlements para cada conta gera uma manutenção insustentável. **O que acontece com uma solicitação para a qual nenhum agente está disponível?** Deve haver uma regra de Overflow com tempo máximo de espera e uma fila de backup. Sem essa regra, as solicitações ficam na fila de atribuição sem que ninguém as veja, e o SLA é violado silenciosamente. **É possível confiar apenas no Push Routing?** Geralmente sim, e esta é uma preferência acertada – o Pull permite que os agentes escolham solicitações mais fáceis. Uma combinação razoável é o Push para a maior parte do trabalho e uma fila Pull limitada para trabalhos que não dependem do tempo. --- ## Salesforce Knowledge na Service Cloud: Como Construir um Repositório de Conhecimento Confiável para Agentes e IA URL: https://hpi.pro/pt/insights/salesforce-knowledge-management Repositorios de conhecimento frequentemente falham em seu segundo ano, não no lançamento: artigos são escritos uma vez, ninguém os mantém, e os agentes voltam a perguntar no chat interno. Este guia descreve um ciclo de vida sustentável – custo, gatilho de criação, revisão periódica e medição de uso – e o que muda quando um agente de IA lê do mesmo repositório. ## A Resposta Curta Uma base de conhecimento não é um projeto de conteúdo, mas um processo operacional. A questão que determina sua sobrevivência não é quantos artigos foram escritos no lançamento, mas sim o que leva à criação de um novo artigo e o que leva à revisão de um artigo antigo. Sem esses dois mecanismos, qualquer base de conhecimento degenera em uma pasta de arquivos que ninguém abre. O teste simples da situação atual: quantos **Cases** foram fechados este mês com um artigo vinculado. Abaixo de 30% significa que a base de conhecimento não faz parte do fluxo de trabalho. ## Ciclo de Vida de um Artigo | Fase | Responsável | Gatilho | |---|---|---| | Criação | Agente que resolveu o **Case** | **Case** repetido sem artigo vinculado | | Aprovação | Editor de Conhecimento ou Especialista no Assunto | Fila de aprovação com prazo | | Publicação | Editor | Definição de visibilidade: interna ou pública | | Revisão | Proprietário definido | Data de revisão ou dados de uso | | Retirada | Proprietário | Produto descontinuado ou procedimento alterado | A fase que frequentemente é ignorada é a retirada. Artigos antigos não são prejudiciais quando são uma minoria, mas no momento em que representam um quarto da base, os agentes param de confiar nos resultados da pesquisa – e esse é o ponto sem retorno. ## O Gatilho que Faz a Base de Conhecimento Crescer Corretamente A abordagem eficaz não é planejar uma lista de tópicos antecipadamente, mas permitir que os dados de serviço a ditem. Uma regra automática simples: um tipo de **Case** que se repetiu mais de cinco vezes no trimestre e cujos fechamentos não estão vinculados a um artigo – entra na fila de escrita. Dessa forma, a base de conhecimento reflete o que realmente acontece e não o que foi estimado em uma reunião de planejamento. Uma adição importante: o agente que escreveu o artigo recebe crédito visível. A contribuição de conhecimento que não é contabilizada em lugar algum para depois de algumas semanas. ## Estrutura de Artigo que Atende Tanto à Pesquisa Quanto à IA Um artigo escrito como um documento contínuo é difícil de escanear rapidamente durante uma chamada e difícil de ser recuperado com precisão por um modelo. Uma estrutura eficaz inclui: título formulado como a pergunta de um cliente, uma resposta curta no primeiro parágrafo, etapas de ação numeradas, condições e exceções separadas, e categorização por produto, versão e validade. A separação das exceções em uma seção distinta é o ponto crucial: quando elas são integradas às etapas, tanto um agente estressado quanto um mecanismo de recuperação têm dificuldade em distinguir a regra da exceção. ## Visibilidade: Interna vs. Pública O mesmo tópico geralmente exige duas versões. A versão interna inclui limitações conhecidas, soluções alternativas e diretrizes de escalonamento; a pública inclui apenas o que o cliente pode realizar. A gestão dessa separação é feita no nível do artigo, não no nível da base de conhecimento, para evitar a criação de duas bases de conhecimento que se ramificam. Antes de abrir um portal de **Self-Service**, é importante verificar se as versões públicas são realmente autossuficientes. Um portal que direciona para artigos parciais não diminui o volume de *tickets*, mas os transfere para outro canal, geralmente telefônico. O contexto operacional detalhado pode ser encontrado em [Implementação do Service Cloud](/pt/insights/service-cloud-implementation). ## O Que Muda Quando um Agente de IA Lê da Base de Conhecimento Uma base de conhecimento com a qual os agentes conseguem trabalhar apesar das lacunas pode não estar necessariamente pronta para uso por um Agente de IA. Um agente experiente sabe ignorar um artigo antigo; um mecanismo de recuperação, não. Três requisitos adicionais: não há dois artigos ativos que forneçam respostas conflitantes para a mesma pergunta; cada artigo tem validade e fonte claras; e é explicitamente definido o que pode ser apresentado ao cliente. Um Agente de IA que cita um artigo interno ou que combina duas fontes conflitantes gera um dano à confiança difícil de reparar. Mais informações sobre este tópico podem ser encontradas em [Grounding e RAG no Agentforce](/pt/insights/agentforce-grounding-rag) e [Prontidão do Conhecimento para o Agentforce](/pt/insights/agentforce-knowledge-readiness). ## Medição | Métrica | O que revela | Limite para Revisão | |---|---|---| | Taxa de anexação de conhecimento | Se a base de conhecimento faz parte do fluxo de trabalho | Abaixo de 30% | | Pesquisas sem resultados | Lacunas reais de conteúdo | Lista semanal para fila de escrita | | Artigos sem visualizações em seis meses | Conteúdo redundante ou não encontrado na pesquisa | Acima de 25% da base de conhecimento | | Tempo de criação à publicação | Se a fila de aprovação está sobrecarregada | Acima de duas semanas | | Classificação "Não Ajudou" | Qualidade específica do conteúdo | Concentração em um tópico | A lista de pesquisas sem resultados é a fonte mais barata e precisa para o planejamento de conteúdo, e é quase sempre subutilizada. ## Conclusão Uma base de conhecimento bem-sucedida é construída de baixo para cima – a partir de **Cases** reais – e mantida por apenas dois mecanismos: um gatilho para criação e um gatilho para revisão. Todo o resto, incluindo a adaptação para uso com Agentes de IA, deriva do fato de que o conteúdo é atualizado e não se contradiz. ### Perguntas e respostas **Quantos artigos são necessários para começar?** Entre dez e vinte, cobrindo as consultas mais frequentes. Uma base de conhecimento grande, escrita antecipadamente, fica obsoleta antes de ser usada; uma base pequena, atualizada a partir de Cases reais, cresce de forma mais eficaz. **Quem deve escrever os artigos?** Os agentes que resolvem as consultas, com um editor que aprova e padroniza. A escrita por uma parte externa pode gerar conteúdo preciso, mas que não se alinha à linguagem que o agente utiliza. **Um mesmo artigo pode ser usado por agentes e clientes?** Geralmente não na íntegra. São necessários diferentes níveis de visibilidade – uma seção interna (restrições, soluções alternativas) e uma seção pública. As Categorias de Dados e Canais gerenciam isso no nível do artigo. **Como saber se um artigo está desatualizado?** Combine a data de revisão, dados de uso e sinalizações dos agentes. Um artigo que não foi visualizado por seis meses ou que foi sinalizado como inútil entra automaticamente em fila de revisão. **O que é necessário antes que um agente de IA leia da base de conhecimento?** Limpeza de artigos conflitantes, marcação de validade e fonte, e definição do que pode ser exposto ao cliente. Um agente que cita dois artigos conflitantes gera um dano maior do que a ausência de resposta. --- ## Integração Call Center com Service Cloud: CTI, Voz e Visão 360 do Cliente URL: https://hpi.pro/pt/insights/service-cloud-cti-integration A integração de telefonia com o Salesforce é medida em segundos: o tempo que o agente leva para identificar quem está ligando e o motivo. Este guia aborda as decisões cruciais que impactam o resultado – identificação do chamador, Screen Pop, propriedade do roteamento, tratamento de transferências e desconexões, e a escolha entre Service Cloud Voice e um adaptador CTI existente. ## A Resposta Curta A qualidade de uma conexão CTI é medida em três segundos: do momento em que o agente atende até ele visualizar quem está ligando, o histórico e o que está aberto. Se a identificação falhar, o agente inicia cada chamada perguntando "Com quem estou falando?" — e todo o investimento em telefonia integrada se torna imperceptível. A decisão central não é qual adaptador escolher, mas sim **onde a decisão de roteamento é tomada**: na central telefônica ou no Salesforce. É aí que reside a maior parte do risco e do custo. ## A Decisão Chave: Quem Gerencia o Roteamento | Aspecto | Roteamento na Central Telefônica (Adaptador CTI) | Roteamento no Omni-Channel (Voice) | | --- | --- | --- | | Origem da Decisão | IVR e regras da central telefônica | Disponibilidade e habilidades no Salesforce | | Equilíbrio entre Canais | Telefone gerenciado separadamente de chat e e-mail | Capacidade única para todos os canais | | Alteração de Regras | Dependente do fornecedor de telefonia | Nas configurações do Salesforce | | Complexidade da Implementação | Relativamente baixa | Alta, impacta a operação do contact center | | Quando é Adequado | Contact center predominantemente telefônico, central robusta | Contact center omnichannel com carga mista | O problema ocorre com o roteamento duplo – a central telefônica roteia e o sistema roteia novamente. O resultado são agentes recebendo chamadas enquanto estão ocupados com um chat, e métricas de disponibilidade que não refletem a realidade. Se for escolhido o Voice, as regras de roteamento são desvinculadas da central telefônica; se a central telefônica for mantida, o Omni-Channel não é ativado no canal de voz. ## Identificação de Chamadas: Um Problema de Dados Antes de Tecnologia A maioria das falhas de Screen Pop não são problemas de integração, mas sim de falta de normalização de números de telefone. O mesmo cliente aparece como 050-1234567, +972501234567 e 0501234567 em três sistemas diferentes, e a correspondência falha. O que é necessário antes da conexão: 1. **Formato Uniforme** - E.164 como padrão, com conversão na entrada e não no momento da pesquisa. 2. **Ordem de Pesquisa Definida** - Primeiro Contact, depois Account, depois Case aberto por número. A ordem determina o que aparecerá quando houver várias correspondências. 3. **Tratamento de Múltiplas Correspondências** - Uma tela de seleção rápida, não um palpite. Em centrais telefônicas corporativas e números de centrais de clientes empresariais, essa é a situação normal, não a exceção. 4. **Tratamento de Não Identificação** - Uma tela de criação rápida, para que a chamada não termine sem documentação. Os princípios de identificação e unificação de registros são detalhados em [Deduplicação e Unificação de Registros](/pt/insights/salesforce-data-deduplication). ## O Que Acontece Quando a Chamada Não Flui Perfeitamente Cenários de borda são o que determinam se o contact center confia no sistema: - **Transferência entre Agentes** - O Case acompanha a chamada ou um novo é aberto? Uma transferência que gera um segundo Case prejudica tanto a métrica de FCR quanto a experiência do cliente, que repete a história duas vezes. - **Desconexão no Meio** - É necessária uma regra de retorno de chamada com uma janela de tempo, caso contrário as solicitações desaparecem sem rastros. - **Chamada de Saída** - Ela é contabilizada e associada a um Case? Sem isso, os dados de carga do agente ficam incompletos em cerca de um terço. - **Fila de Espera e Abandono** - Os abandonos devem estar disponíveis no Salesforce, não apenas nos relatórios da central telefônica, caso contrário a imagem operacional é parcial. Cada um dos quatro cenários deve ser escrito como um cenário de teste ponta a ponta antes da implantação. Testar apenas uma chamada bem-sucedida não prova nada. ## Gravação, Transcrição e Privacidade A transcrição automática tornou-se acessível e barata, e a tentação de aplicá-la a tudo é grande. Três perguntas que precisam de resposta antes: Qual a base legal para a gravação e o processamento; por quanto tempo a transcrição é mantida e quem pode pesquisá-la; e se o conteúdo é usado para treinar modelos. A transcrição é informação sensível – ela inclui detalhes que o cliente forneceu verbalmente e não inseriria em um formulário. Restrição de acesso em nível de campo e uma política de retenção definida fazem parte da implementação, não uma tarefa pós-implementação. ## Medição Pós-Ativação | Métrica | Por que é Importante | | --- | --- | | Porcentagem de Identificação Automática | Medida direta da qualidade dos dados e da conexão | | Tempo para Screen Pop | Acima de dois segundos é percebido como lentidão | | Chamadas sem Case Associado | Revela lacunas de documentação | | Cases Duplicados na Transferência | Revela falha na continuidade | | Abandono na Fila | Indicação de falha de roteamento ou dimensionamento | ## Resumo Uma conexão CTI bem-sucedida não é medida pela instalação do adaptador, mas pelo fato de o agente iniciar a chamada sabendo quem está na linha e o que está aberto, e que todos os cenários não padrão – transferência, desconexão, múltiplas correspondências – foram predefinidos. A decisão sobre a localização do roteamento é a primeira a ser fechada, pois dela derivam o modelo operacional e o custo. ### Perguntas e respostas **Qual a diferença entre Service Cloud Voice e um adaptador CTI comum?** Um adaptador CTI exibe a telefonia dentro do Salesforce, mas o roteamento permanece na central telefônica. O Service Cloud Voice transfere o roteamento para o Omni-Channel e disponibiliza transcrições e dados de chamadas como registros. A diferença fundamental está em onde a decisão de roteamento é tomada. **Por que o Screen Pop não abre algumas vezes?** Geralmente, isso ocorre porque o número do chamador não está normalizado – prefixo internacional, zeros à esquerda ou formato inconsistente entre os sistemas. É um problema de dados, não um problema de integração. **O que fazer quando um número é identificado para vários clientes?** Defina antecipadamente uma tela de seleção rápida para o agente, em vez de uma suposição automática. Uma seleção automática incorreta é pior do que a falta de identificação, pois gera documentação para o cliente errado. **É obrigatório gravar e transcrever todas as chamadas?** Não, e na maioria das organizações, não é o ideal. A gravação indiscriminada exige políticas de retenção, base legal e controle de acesso. É preferível começar com categorias definidas. **Quem é responsável quando a chamada chega, mas o registro não é criado?** Isso deve ser definido por escrito antes do lançamento. Sem um único responsável pela jornada de ponta a ponta, qualquer falha se torna uma discussão entre o fornecedor de telefonia e a equipe de CRM. --- ## Rede de Champions Salesforce: Como Construir um Motor de Adoção Interna URL: https://hpi.pro/pt/insights/salesforce-champions-network Um Champion que é apenas um título simbólico não muda nada. Como selecionar representantes, quanto tempo dedicar a eles, qual exactamente o papel, como recompensar e como evitar que a rede se esvai após dois meses. ## A Resposta Concisa A Rede de Champions é a infraestrutura de distribuição da adoção dentro da organização. Os usuários procuram um colega próximo antes de abrir um chamado de suporte e confiam mais nele do que em uma comunicação da gerência. A Rede explora essa dinâmica em vez de lutar contra ela. No entanto, um Champion sem alocação de tempo, sem uma descrição de cargo definida e sem influência real nas prioridades é um título vazio. Esses três componentes determinam se a Rede durará um ano ou desaparecerá em um trimestre. ## Quem se Qualifica — e Quem Não se Qualifica | Critério | Por que importa | Bandeira Vermelha | | --- | --- | --- | | Confiança entre Pares | Determina se as pessoas o procuram | Alguém nomeado por estar disponível | | Expertise em Processos de Negócio | Permite uma resposta correta, não apenas técnica | Conhecimento sistêmico sem compreensão operacional | | Vontade Genuína | Função voluntária gera comprometimento | Nomeação forçada pela gerência | | Apoio do Gerente Direto | Determina se haverá tempo para a função | Acordo verbal apenas | O erro comum é selecionar o usuário mais técnico. Ele fornecerá respostas precisas que ninguém pediu e não identificará que o problema real é a ilogicidade do processo. ## Descrição de Cargo por Escrito Sem uma definição por escrito, a função é interpretada como "a pessoa a quem se mostram os problemas". A descrição inclui quatro responsabilidades: 1. **Suporte Local** — Primeira linha de resposta a perguntas da equipe e registro de recorrências. 2. **Coleta de Feedback** — Encaminhamento de barreiras e necessidades ao fórum central, incluindo questões que ninguém relata oficialmente. 3. **Testes Preliminares** — Participação em UAT e testes de mudanças antes da liberação para a equipe. 4. **Comunicação de Mudanças** — Explicação verbal do que mudou, na linguagem da equipe. Junto com as responsabilidades, também é definida a alocação: de quatro a seis horas semanais durante o período de lançamento. Se o gerente direto não aprovar a alocação por escrito, a função será eliminada na primeira situação de pressão. ## O Fórum Central é o Coração Uma reunião quinzenal de 45 minutos com estrutura fixa: o que surgiu do campo, o que foi corrigido desde a reunião anterior, o que será lançado em breve e uma pergunta aberta. Os dois primeiros itens são o motor — um Champion que vê sua solicitação implementada e comunicada em seu nome trará mais cinco solicitações. Um Champion que encaminhou três solicitações que desapareceram simplesmente deixará de encaminhar. O fórum também serve como um canal de alerta precoce: reclamações recorrentes que são ouvidas ali só chegam ao Dashboard dois meses depois. A conexão com a medição é detalhada em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## O que é Oferecido em Troca Incentivos eficazes, em ordem de comprovada eficiência: - **Influência** — Um assento permanente na definição das prioridades para o próximo lançamento. - **Acesso Antecipado** — Visualização de mudanças antes de todos e autoridade para dizer "ainda não". - **Exposição Gerencial** — Apresentação de descobertas à gerência uma vez por trimestre. - **Desenvolvimento** — Financiamento de certificação Salesforce ou participação em conferências. - **Reconhecimento** — Menção nominal na atualização de qualquer correção resultante de sua contribuição. A recompensa financeira é rara e não essencial. O que mata as redes é a falta de influência, não a falta de bônus. ## O Papel da Rede no Lançamento e na Operação Regular Nas duas semanas após o Go Live, os Champions são a primeira linha de suporte no local, motivo pelo qual recebem treinamento uma semana antes de todos os outros. A estrutura é descrita em [Treinamento Salesforce Baseado em Função](/pt/insights/salesforce-role-based-training). Em operação regular, o papel muda: integração de novos membros, identificação de atritos que se acumulam e testes de mudanças antes do lançamento. Aqui, a Rede se transforma de um mecanismo de lançamento para um mecanismo de manutenção que impede a regressão e alimenta as correções discutidas em [Simplificação da UX no Salesforce](/pt/insights/salesforce-ux-simplification). ## Sinais de Declínio e o que Fazer | Sinal | Causa Comum | Correção | | --- | --- | --- | | Queda na presença no fórum | As solicitações não são implementadas | Liberar imediatamente duas correções da lista deles | | Champion pede para sair | Pressão nas metas do cargo principal | Renovar a alocação junto ao gerente | | Nenhuma solicitação nova | A rede se tornou apenas um canal de comunicação | Abrir discussão sobre barreiras, não sobre atualizações | | Todas as solicitações vêm de uma única equipe | Representação parcial | Adicionar Champions em áreas ausentes | ## Medição Três métricas são suficientes: número de problemas levantados via Rede por trimestre, taxa de implementação deles e a lacuna de adoção entre equipes com um Champion ativo e equipes sem. Essa lacuna é a justificativa orçamentária de todo o programa. A própria Rede é um componente dentro do [Plano de Gerenciamento de Mudanças do Salesforce](/pt/insights/salesforce-change-management-plan). ## Conclusão Escolha com base na confiança e não no conhecimento técnico, estabeleça a alocação de tempo por escrito com o gerente direto, realize um fórum quinzenal onde as solicitações são realmente implementadas e recompense com influência. Uma rede que sente que está mudando o sistema durará anos; uma rede simbólica desaparecerá em um trimestre. ### Perguntas e respostas **Quantos Champions são necessários?** Uma proporção comum é de um Champion para cada 15 a 25 usuários, e pelo menos um em cada equipa autónoma ou localidade geográfica. Menos do que isso cria um gargalo, mais do que isso dificulta a manutenção da rede. **Quanto tempo semanal dedicar a um Champion?** Quatro a seis horas semanais durante o período de lançamento, e duas horas depois. A alocação deve ser acordada com o gestor direto e deduzida dos objetivos correntes, caso contrário, a função é a primeira a ser negligenciada. **Um Champion precisa ser um usuário tecnicamente avançado?** Não. O critério importante é a confiança dos colegas e a experiência no processo de negócio. O conhecimento do sistema pode ser ensinado; a influência social na equipa não pode ser atribuída. **Como recompensar os Champions sem orçamento?** Exposição à gestão, influência real no Roadmap, formação ou certificação patrocinada pela organização, e reconhecimento nominal nas atualizações. A influência nas prioridades é o incentivo mais forte na prática. **O que fazer quando a rede de Champions enfraquece após dois meses?** Verifique três coisas: se os seus pedidos são realmente implementados, se o gerente direto apoia a alocação de tempo e se existe um fórum regular. O enfraquecimento quase sempre decorre do facto de o canal ter deixado de ter influência. --- ## Aprimorando a UX no Salesforce: Menos Campos, Menos Cliques e Mais Adoção URL: https://hpi.pro/pt/insights/salesforce-ux-simplification Cada campo desnecessário representa um imposto diário sobre a produtividade de cada usuário. Apresentamos uma metodologia prática para simplificar telas no Salesforce: auditoria de uso de campos, teste dos três cliques, layout por perfil e medição do tempo de tarefa antes e depois da otimização. ## A Resposta Curta Cinco segundos adicionais por entrada, multiplicados por trinta entradas por dia, multiplicados por cem usuários — isso soma um dia de trabalho completo perdido diariamente devido a uma interface sobrecarregada. A simplificação da experiência do usuário (UX) geralmente representa a ação com o maior Retorno sobre o Investimento (ROI) em um sistema existente, e quase sempre baseia-se em remoção, e não em adição. Três ferramentas são suficientes: auditoria de uso de campos, o teste dos três cliques para cada tarefa central, e a personalização de Layouts por função e estágio do processo. ## Por Que Telas Incham Ninguém projetou uma tela com 80 campos. Ela se formou ao longo de sete anos de solicitações pontuais, cada uma razoável em si mesma. Três mecanismos recorrentes: - **A solicitação de "apenas mais um campo"** — Custo marginal que parece ser zero, mas com um custo acumulado enorme. - **Campo que permaneceu depois que o processo mudou** — Ninguém se responsabilizou por removê-lo. - **Campo de "gaveta de segurança"** — "Talvez precisemos disso para um relatório futuro." Portanto, a simplificação não é um projeto único, mas uma prática contínua: cada solicitação para um novo campo deve exigir a indicação de um campo a ser removido ou uma justificativa explícita. ## Etapa 1 — Auditoria de Uso de Campos Para cada objeto central, elabore uma tabela com quatro colunas: porcentagem de preenchimento nos últimos 12 meses, uso em relatórios, uso em automações e integrações, e o proprietário do processo declarado. | Achado | Interpretação | Decisão | |---|---|---| | Preenchimento abaixo de 10%, sem uso em relatório | Campo abandonado | Remoção do Layout | | Preenchimento alto, sem uso em relatório | Trabalho que ninguém consome | Investigar com o proprietário do processo | | Preenchimento baixo, campo obrigatório | Usuários preenchem valor arbitrário | Remover obrigatoriedade ou alterar para Picklist | | Preenchimento alto e uso em relatório | Campo ativo | Manter, talvez reposicionar | A terceira linha é a mais perigosa: um campo obrigatório preenchido com um valor fictício contamina os dados e também desgasta a confiança. ## Etapa 2 — Teste dos Três Cliques Para cada tarefa central — atualização de estágio, registro de chamada, encerramento de Case — conte o número de cliques e telas desde o início da intenção até a conclusão. Mais de três cliques para uma tarefa diária justifica uma correção. As ferramentas disponíveis incluem: Quick Actions em vez de abrir um registro completo, edição a partir de uma lista, Path com campos de orientação para cada estágio, e componentes que aparecem apenas no contexto relevante. A pergunta orientadora é sempre a mesma: o que o usuário veio fazer aqui e o que está no seu caminho? ## Etapa 3 — Layout Por Função, Não Por Objeto Uma tela uniforme para todas as funções representa uma unificação de todas as necessidades, o que significa que é péssima para todos. Um representante de vendas precisa de oito campos; um gerente de operações precisa de outros cinco; o Back Office precisa de campos de aprovação que não têm lugar para os dois primeiros. A separação por Record Type e Profile, combinada com Dynamic Forms para exibição condicional por estágio, reduz uma tela de 60 campos para uma tela de 12 campos relevantes. Importante: a exibição condicional não substitui uma decisão de negócio sobre o que é realmente necessário. ## Etapa 4 — A Página Inicial Como Lista de Trabalho A primeira tela que o usuário vê deve responder à pergunta "o que devo fazer agora?", não exibir gráficos gerais. Uma lista de tarefas classificadas por prioridade, itens travados e exceções que exigem atenção. Este é o retorno diário que justifica a entrada de dados, e é um fator central na recuperação da adoção — veja [Melhorar a Adoção do Salesforce](/pt/insights/recover-salesforce-user-adoption). ## Medição: Antes e Depois Antes da correção, meça o tempo médio de execução para três tarefas essenciais, com cinco usuários reais, utilizando um cronômetro. Após a correção, meça novamente usando o mesmo método. Uma redução de 30% ou mais no tempo da tarefa é um resultado aceitável em uma primeira onda de simplificação. Além disso, monitore a qualidade dos dados e a taxa de execução da operação principal, conforme os [Indicadores de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). A simplificação verdadeira melhora ambos; se o tempo diminuiu, mas a qualidade foi comprometida, um campo necessário foi removido. ## Objeções e Como Respondê-las "Mas precisamos do campo para um relatório" — Quem gerou o relatório no último ano? "O Gerente X pediu" — O processo que o justificou ainda existe? "Talvez precisemos no futuro" — Pode ser restaurado em uma hora, e os dados históricos são mantidos mesmo após a remoção do Layout. Essas objeções devem ser gerenciadas dentro do processo de mudanças organizacionais, e não como uma discussão técnica — veja [Gestão de Mudanças Salesforce](/pt/insights/salesforce-change-management-plan). ## Resumo Execute uma auditoria de uso de campos, remova os abandonados, reduza os campos obrigatórios para dois por estágio, construa Layouts por função e transforme a página inicial em uma lista de trabalho. Meça o tempo da tarefa antes e depois — esta é a prova que justifica a próxima onda. ### Perguntas e respostas **Como identificar quais campos podem ser removidos?** Execute um relatório de uso de campos: verifique a porcentagem de registros preenchidos nos últimos 12 meses e sua utilização em relatórios e automações. Um campo com baixo preenchimento que não aparece em relatórios ou automações é um forte candidato à remoção. **É preferível excluir campos ou apenas ocultá-los?** Inicie removendo-os do Layout, aguarde um trimestre e, só então, considere a exclusão. A remoção do Layout já oferece os benefícios ao usuário sem o risco de perda de dados históricos. **Quantos campos obrigatórios são aceitáveis em uma única tela?** Recomendamos um máximo de cinco campos obrigatórios ao longo de todo o processo, e não mais de dois por etapa. Qualquer campo obrigatório adicional deve ter um responsável que justifique sua necessidade e quem consumirá os dados. **Dynamic Forms resolve o problema de telas complexas?** É uma ferramenta excelente para exibição condicional, baseada em etapa ou perfil do usuário, mas não substitui a decisão de negócio. Uma tela sobrecarregada, mesmo que parcialmente oculta, ainda evidencia um processo desalinhado. **Qual a duração média de um projeto de simplificação?** A fase de auditoria e planejamento geralmente leva de duas a três semanas, e a primeira implementação, de três a quatro semanas. Este é um dos projetos com a melhor relação impacto-esforço no Salesforce. --- ## Como Reengajar Usuários no Salesforce Após um Lançamento Mal-sucedido URL: https://hpi.pro/pt/insights/recover-salesforce-user-adoption Um lançamento fracassado do Salesforce não é um problema de treinamento. Este guia prático de recuperação aborda como diagnosticar a causa do abandono, o que corrigir nos primeiros 30 dias, como reconstruir a confiança sem um 'relançamento' alardeado – e quando é melhor simplificar o sistema em vez de expandi-lo. ## A Resposta Concisa Quando os usuários abandonam o Salesforce, a razão quase nunca é "eles não entenderam o sistema". A verdadeira razão é que o sistema exigia mais deles do que lhes oferecia em retorno. A recuperação da adoção começa com o diagnóstico do custo que o usuário está pagando, e não com mais treinamento. A sequência prática: duas semanas de diagnóstico, 30 dias de correções perceptíveis e, em seguida, um ciclo de gestão regular baseado em dados. O treinamento só entra em cena depois que o sistema já vale o tempo investido nele. ## Cinco Razões Para o Abandono — E Como Distingui-las | Razão | Indicador Prático | Correção Adequada | | --- | --- | --- | | Carga de Entrada Excessiva | Formulários longos, campos obrigatórios sem proprietário | Exclusão de campos, definição de valores padrão, automação | | Desconfiança dos Dados | Todos mantêm planilhas "sombra" | Limpeza de dados + definição de uma única fonte da verdade | | Falta de Valor de Retorno | O usuário insere dados e não recebe nada em troca | Listas de tarefas, visualizações personalizadas, alertas | | Gestão Não Baseada no Sistema | Revisão semanal de um arquivo externo | Migração do fórum para um Dashboard | | Performance e Interface | Telas lentas, navegação confusa | Otimização e simplificação do Layout | O próprio diagnóstico leva duas semanas: dez conversas com usuários reais (não representantes de usuários), observação de uma hora do trabalho real de três funções e coleta de dados de uso real conforme descrito em [Métricas de Adoção do Salesforce](/pt/insights/salesforce-adoption-metrics). ## A Lei do Retorno: O Que o Usuário Recebe em 30 Segundos Este é o teste principal. Abra a tela principal de um usuário que está abandonando e pergunte: o que ele recebe aqui que não obteria sem o sistema? Se a resposta for "nada, ele só insere dados" — o abandono é completamente compreensível. Retornos que funcionam na prática: a lista de tarefas do dia ordenada por prioridade; histórico completo do cliente sem precisar procurar em e-mails; lembrete automático antes de uma reunião; um formulário de orçamento gerado com um clique. Cada um desses itens economiza tempo real e, portanto, gera uso sem necessidade de imposição. ## A Primeira Onda de Correções: 30 Dias Selecione entre cinco e oito correções, todas perceptíveis no dia a dia, todas implementáveis em um mês. Composição recomendada: 1. Remoção de 30%-50% dos campos no formulário principal, com evidências de que ninguém os consome. 2. No máximo dois campos obrigatórios em cada etapa do processo. 3. Uma visualização "Meu Trabalho Hoje" para cada função principal. 4. Correção de três problemas de qualidade de dados que os usuários citam como prova de que o sistema não é confiável. 5. Uma automação que elimina um trabalho manual repetitivo. 6. Otimização da tela mais lenta. O que não se encaixa nesta onda: novos recursos, módulos adicionais, novas integrações. A expansão durante uma crise de confiança agrava os danos. A direção correta nesta fase é a simplificação, conforme descrito em [Simplificação da UX no Salesforce](/pt/insights/salesforce-ux-simplification). ## Reconstruindo a Confiança A confiança não retorna com uma mensagem de e-mail. Ela retorna de três padrões recorrentes: correções entregues no prazo prometido, transparência sobre o que não será feito e crédito para quem levantou o problema. Um mecanismo simples que funciona: uma lista de solicitações abertas para toda a organização com status, entregas quinzenais e uma breve comunicação detalhando o que foi corrigido e por quem. Em seis semanas, isso muda a conversa de "o sistema não funciona" para "eu enviei uma solicitação". A rede humana que veicula essa mensagem é a rede de Champions, e sua construção é detalhada em [Rede de Champions no Salesforce](/pt/insights/salesforce-champions-network). ## O Ciclo de Gestão é a Ferramenta Mais Poderosa O fator mais influente na adoção é o que o gerente direto observa. Enquanto ele gerencia a equipe a partir de um arquivo externo, o sistema é opcional. No momento em que a revisão semanal do Pipeline ou dos Cases é conduzida a partir de um Dashboard em tempo real — a atualização se torna um interesse pessoal do representante. Esta é uma mudança gerencial que requer o apoio de um Sponsor e, portanto, faz parte do plano de gerenciamento de mudanças e não do plano de trabalho técnico. Consulte [Gerenciamento de Mudanças do Salesforce](/pt/insights/salesforce-change-management-plan). ## Quando Reduzir em Vez de Expandir Se o sistema contém módulos não utilizados, processos construídos para cenários teóricos e automações que ninguém entende — a medida correta é uma contração controlada. Desabilitar o que não está em uso reduz a carga cognitiva, encurta telas e diminui a manutenção. Muitas organizações descobrem que a melhoria mais significativa na adoção veio da exclusão, não da construção. ## Métricas para Recuperação Meça apenas quatro ao longo do trimestre: taxa de conclusão da ação central por função, tempo médio para completar o processo principal, taxa de uso de arquivos "sombra" (auditado manualmente) e uma métrica de qualidade de dados. Um aumento nas três primeiras sem melhoria na quarta significa que o sistema foi preenchido mais rapidamente, não melhor. ## Conclusão A recuperação da adoção é um projeto de remoção de atritos e retorno de valor, e não um projeto de convencimento. Diagnostique o custo que o usuário paga, entregue uma onda de correções perceptíveis em 30 dias, mova a gestão para dentro do sistema, e só então retorne ao treinamento e à expansão. ### Perguntas e respostas **Quanto tempo leva para recuperar a adoção do Salesforce após um lançamento fracassado?** O diagnóstico leva duas semanas, a primeira onda de correções cerca de 30 dias, e a estabilização mensurável ocorre em um trimestre. A recuperação da confiança da gestão leva mais tempo – geralmente dois trimestres com números consistentemente positivos. **Devemos anunciar um 'relançamento'?** Na maioria das vezes, não. Um anúncio repetido lembra os usuários do fracasso e eleva as expectativas. É preferível uma série de correções discretas que são percebidas no trabalho diário, seguida pela comunicação dos resultados. **O que fazer quando os gerentes continuam a trabalhar em planilhas do Excel paralelamente?** Remova o Excel como uma fonte legítima para discussões de gerenciamento. Enquanto a revisão do Pipeline for feita a partir de um arquivo, não haverá um incentivo real para atualizar o sistema. Esta é uma decisão de gestão, não técnica. **Substituir o sistema é melhor do que recuperá-lo?** Quase nunca. Em 80% dos casos, a causa do fracasso é o processo, os dados ou a interface – todos os problemas que seguirão para o próximo sistema. A substituição só se justifica quando a lacuna está na capacidade fundamental do produto. **Quem deve liderar a recuperação?** Um proprietário de processo de negócios sênior com autonomia para alterar processos, e não apenas um gerente de sistemas de informação. A maioria das correções necessárias são decisões de negócios: o que deixar de exigir, quem é responsável pelos dados e o que será medido. --- ## Reparar ou Reconstruir seu Salesforce? Um Guia Decisivo para Sistemas Existentes URL: https://hpi.pro/pt/insights/salesforce-rebuild-vs-refactor A decisão entre consertar, refatorar ou reconstruir é frequentemente tomada com base na intuição, o que explica por que o problema ressurge em apenas dois anos. Este guia apresenta quatro testes objetivos, explica por que a reconstrução quase sempre excede as estimativas e descreve uma abordagem prática para uma substituição gradual. ## A Resposta Curta As três opções não estão no mesmo contínuo. **Repair** trata o sintoma, **Refactor** modifica a implementação sem alterar o comportamento, e **Rebuild** altera o modelo subjacente. A decisão é determinada por uma pergunta: o problema reside na forma como as coisas foram implementadas ou no que foi definido desde o início? Se o modelo de dados estiver correto e a dor for devido a automações complicadas e permissões intrincadas, isso é um Refactor. Se o mesmo objeto for usado por três processos conflitantes e não for possível gerar relatórios sobre ele, isso é a raiz do problema, e então o Rebuild entra em pauta. ## Quatro Testes Decisivos | Teste | Aponta para Refactor | Aponta para Rebuild | | --- | --- | --- | | Modelo de Dados | Adequado, sofre com excesso de campos | Objetos que atendem a propósitos conflitantes | | Origem da Dor | Desempenho, duplicação de automações | Impossibilidade de relatar ou expandir | | Escopo dos Usuários Afetados | Parcial, pode ser isolado | Abrangente em todos os processos | | Custo do Reteste | Pode-se testar uma única área | Qualquer alteração requer regressão completa | Três linhas que apontam para a mesma direção são suficientes para a decisão. A divisão entre as linhas geralmente significa que o problema é mais local do que parece. ## Por Que o Rebuild É Mais Caro do Que o Estimado A estimativa usual considera apenas a reconstrução. Ela quase sempre ignora quatro itens: a migração de dados históricos com todas as exceções acumuladas, a reconstrução das integrações, cada uma acordada com um terceiro, um período de execução paralela em que ambos os sistemas convivem, e o treinamento completo para todos os usuários. Na prática, esses quatro itens geralmente representam mais da metade do custo. Uma organização que considera um Rebuild e não os precificou está comparando maçãs com meias laranjas. ## O Roteiro Prático: Substituição Gradual Mesmo quando a decisão é Rebuild, executá-lo como um projeto "parar e substituir" é o próprio risco. O caminho que funciona é a substituição área por área: 1. **Construa o novo modelo ao lado do antigo** - novos objetos, sem tocar no existente. 2. **Migre um processo completo** - com seus usuários, dados e relatórios. 3. **Desligue o equivalente antigo** - este é o passo que a maioria das organizações adia, e é o que torna o projeto duplicado. 4. **Repita** até que o antigo esteja vazio. O terceiro passo é o teste. Um sistema em que o antigo e o novo convivem em paralelo por um ano gerou custos e não reduziu débitos. ## O Que Precisa Mudar em Qualquer Caso Ambos os caminhos falham se o mecanismo de mudança permanecer o mesmo. Uma governança mínima – quem aprova uma mudança no modelo, qual teste é obrigatório antes da implantação e quem é o proprietário de cada área – é a condição que impede o retorno ao mesmo ponto. A priorização do débito em si é detalhada em [Priorização de Dívida Técnica Salesforce](/pt/insights/salesforce-technical-debt-prioritization), e os sinais de alerta em [8 Sinais de uma Atualização de Sistema Salesforce](/pt/insights/salesforce-system-upgrade-signs). ## Resumo A escolha não está entre "consertar" e "recomeçar", mas entre corrigir a implementação e corrigir a definição. Na maioria dos casos que parecem ser um Rebuild, um modelo de dados saudável está oculto, enterrado sob uma década de automações – e isso se limpa em ondas, não com uma varredura. ### Perguntas e respostas **Quando a reconstrução é realmente a escolha certa?** Quando o próprio modelo de dados está incorreto — por exemplo, um único objeto atendendo a três processos diferentes — e corrigi-lo exigiria, de qualquer forma, uma migração. Se a raiz do problema for apenas automações complexas, a refatoração é significativamente mais econômica. **Um novo Org resolve o problema?** Somente se a causa do caos foi a falta de governança. Sem regras de mudança, testes e uma clara propriedade, um novo Org voltará à mesma condição em dois anos – desta vez, com dois sistemas paralelos. **Quanto tempo leva uma refatoração séria?** Em um escopo médio, leva de três a seis meses em ondas — não como um único projeto. Cada onda deve proporcionar uma melhoria mensurável por si só, caso contrário, o financiamento pode ser interrompido. **O que fazer com o desenvolvimento contínuo durante o trabalho?** Apenas a área em tratamento é congelada, não o sistema inteiro. Um congelamento geral gera pressão de negócios que leva a desvios, e cada desvio adiciona nova dívida exatamente onde se está fazendo a limpeza. **Como convencer a diretoria a financiar uma limpeza que não adiciona novas funcionalidades?** Traduzindo a dívida técnica em custos operacionais mensuráveis: horas de suporte, falhas de integração, tempo prolongado para cada alteração. A dívida, quando apresentada como tempo e não como qualidade de código, geralmente obtém financiamento. --- ## Priorização da Dívida Técnica no Salesforce: O que corrigir primeiro e por quê URL: https://hpi.pro/pt/insights/salesforce-technical-debt-prioritization Uma lista de cem linhas de dívida técnica não é uma ferramenta de trabalho, mas sim uma fonte de frustração. Este guia apresenta uma pontuação de quatro dimensões que estabelece uma ordem clara, explica que tipo de dívida deve ser priorizado independentemente da pontuação e como transformar a dívida em uma linguagem que receba orçamento. ## A Resposta Concisa Dívida técnica não se mede pela qualidade do código, mas sim pelo custo que ela impõe a cada mudança futura. Portanto, a priorização não é sobre **"o que é mais feio"**, mas sim **"o que torna o próximo trabalho mais caro"**. A regra para priorizar rapidamente: um item que exige um teste de regressão abrangente para qualquer alteração em sua área—esse tem prioridade máxima. Ele duplica o custo de qualquer outra atividade no projeto. ## Pontuação em Quatro Dimensões | Dimensão | Pergunta | Peso | | --- | --- | --- | | Exposição de Negócios | O que acontece se falhar no pico de carga? | Alta | | Frequência | Quantas vezes por dia é acessado? | Alta | | Dependência | Quantas outras áreas são bloqueadas por ele? | Média | | Esforço | Quanto custa para corrigir em um ambiente controlado? | Inverso | A pontuação não é uma ciência exata. Seu verdadeiro valor reside em forçar uma discussão explícita entre quem conhece o risco técnico e quem conhece a dor de negócios — gerando uma ordem que pode ser defendida perante a gestão. ## Três Tipos de Dívida que Furam a Fila Independentemente da pontuação, três tipos de dívida têm prioridade: 1. **Dívida que Bloqueia Testes** – A ausência de um ambiente de Sandbox funcional ou de dados de teste adequados. Qualquer outra correção realizada sem isso é feita às cegas. 2. **Dívida em Permissões** – Um modelo de visibilidade que perdeu a lógica é uma exposição regulatória ativa, não um mero inconveniente. 3. **Dívida Centralizada em Uma Pessoa** – Quando apenas uma pessoa entende um componente, o risco não é técnico, mas organizacional. ## Como Apresentar Dívidas para Obter Orçamento A gerência não financia "limpeza de automações". Ela financia a redução de tempo e custo. A tradução se faz em três linhas para cada item: quantas horas de suporte ele consome por trimestre, quantos dias ele adiciona a cada mudança em sua área e qual a exposição se ele falhar. Quem apresenta "três solicitações de mudança por trimestre, cada uma estendida em duas semanas devido ao mesmo componente" obtém aprovação. Quem apresenta um diagrama de dependências — não. ## Cota Fixa, Não Promoção Pontual O padrão que falha: um grande projeto de limpeza a cada dois anos. O padrão que funciona: uma cota fixa de 15%-20% de cada ciclo dedicada à dívida, predefinida e inegociável a cada sprint. Junto à cota, é necessária pelo menos uma regra de prevenção — por exemplo, proibição de adicionar novas automações a um objeto que já possui várias, antes de consolidá-las. Sem prevenção, a taxa de criação de dívida supera a taxa de limpeza. A relação com a infraestrutura de desenvolvimento é detalhada em [Estratégia de Sandboxes e DevOps para Salesforce](/pt/insights/salesforce-sandbox-devops-strategy). ## Resumo Priorizar dívida técnica é um exercício de economia, não de estética: corrige-se o que encarece a próxima mudança, prioriza-se o que bloqueia testes e o que cria exposição, e estabelece-se uma cota para evitar recorrência. Uma lista de dez itens ranqueados vale mais do que cem itens mapeados. ### Perguntas e respostas **Quanto da capacidade atual deve ser alocado para a dívida?** Entre 15% e 20% de cada ciclo, como uma cobertura fixa. A alocação variável por pressão se anula dentro de dois trimestres, pois sempre há algo mais urgente. **Qual dívida nunca deve ser corrigida?** Dívida em uma área que será substituída ou descontinuada no próximo ano, e dívida que não tenha um custo operacional mensurável. A limpeza por si só compete pelos mesmos recursos. **Como medir se a priorização funcionou?** Por três métricas: tempo médio para implementar uma solicitação de mudança, número de falhas de produção reincidentes e número de áreas que exigem regressão completa em cada lançamento. A melhoria nesses índices é a prova. **O que fazer quando a dívida é criada mais rápido do que é eliminada?** Isso é um problema de governança, não de capacidade. Sem uma regra que proíba a adição de nova automação a um objeto antes de consolidar as existentes, qualquer limpeza é temporária. **A documentação ausente é considerada dívida técnica?** Sim, e com alto nível de risco quando o conhecimento está concentrado em uma única pessoa. Não aparece nos relatórios, mas é o que torna qualquer mudança dependente da disponibilidade de alguém específico. --- ## Otimização de Performance no Salesforce para Grandes Organizações: Diagnóstico, Planejamento e Medição URL: https://hpi.pro/pt/insights/salesforce-performance-optimization A lentidão no Salesforce raramente é um problema singular; geralmente, é o acúmulo de telas poluídas, consultas não seletivas e automações redundantes. Este guia apresenta um método de diagnóstico em camadas – navegador, tela, servidor, dados, integração – e métricas que comprovam a melhoria. ## A Resposta Curta O desempenho insatisfatório no Salesforce é um sintoma cumulativo: uma Record Page com 14 componentes, três automações executando no mesmo evento de Save, uma consulta que varre um milhão de registros e uma integração que extrai dados em horário de pico. A única maneira de aprimorar sem desperdiçar orçamento é medir por camadas, identificar a camada dominante e tratá-la — e então medir novamente. ## As Cinco Camadas e o Que Medir em Cada Uma | Camada | Sintoma Típico | Ferramenta de Medição | Tratamento Comum | | :--- | :--- | :--- | :--- | | Navegador e Rede | Lentidão apenas para alguns usuários | Lightning Usage App por usuário | Latência organizacional, versão do navegador, VPN | | Tela e Componentes | EPT alto em uma página de registro central | EPT por Página, Debug Mode | Redução de componentes, carregamento progressivo, Tabs | | Automação | Save lento, Timeout em atualização em massa | Debug Logs, Flow Interviews | Consolidação de Flows, transição para assíncrono | | Dados e Consultas | Relatórios falhando, List View travada | Query Plan, Apex Jobs | Filtragem seletiva, Index, arquivamento | | Integração | Picos de carga em horários fixos | Event Monitoring, API Usage | Bulk API, janelas de execução, Throttling | ## Lidando com Grandes Volumes de Dados Acima de aproximadamente um milhão de registros em um Objeto, as regras do jogo mudam. O Data Skew — por exemplo, 200 mil Accounts associadas ao mesmo Owner ou Parent — cria bloqueios de linha e retarda qualquer atualização em massa. A solução é a distribuição de propriedade, e não a adição de hardware, que de qualquer forma não está sob seu controle. Paralelamente, é aconselhável considerar o arquivamento: registros fechados de cinco anos atrás, que ninguém mais consulta, encarecem qualquer consulta que execute uma varredura. ## Telas: Menos É Mais Rápido A Record Page média em uma organização legada acumula componentes a uma taxa de dois a três por ano, porque cada stakeholder solicita "apenas mais um widget". Cada componente Lightning realiza suas próprias chamadas. Duas ações geram a maior parte do ganho: mover componentes secundários para Tabs separados que são carregados apenas sob clique, e aplicar o Component Visibility por Record Type ou perfil, de modo que o usuário veja apenas o que é relevante para ele. A combinação de ambos reduz o EPT em dezenas de percentagens sem alteração no código. ## A Ordem de Operações que Funciona Comece com uma semana de medição sem alterações, para estabelecer um Baseline confiável para cinco telas centrais e três processos chave. Em seguida, trate as telas — esta é a parte mais barata e rápida. Na terceira etapa, unifique as automações por Objeto, e somente na quarta etapa toque nas consultas e no modelo de dados. As integrações são tratadas em paralelo, se a medição indicou que são a causa. A lógica desta ordem é econômica: as primeiras camadas são baratas e reversíveis, as últimas são caras e exigem testes de regressão. Mais informações sobre o assunto estão disponíveis em [Salesforce Health Check](/pt/insights/salesforce-health-check-guide) e [Sinais para uma Atualização de Sistema](/pt/insights/salesforce-system-upgrade-signs). ## Riscos Comuns e Ações Preventivas O grande risco é a otimização sem Baseline: dez alterações são implementadas, os usuários ainda reclamam, e não há como saber o que realmente ajudou. A medição pré e pós-cada mudança significativa é uma condição, não um luxo. Um segundo risco é tratar o sintoma mais ruidoso. A tela sobre a qual mais se reclama não é necessariamente a mais lenta — às vezes, é simplesmente a que é aberta mais vezes ao dia. Um terceiro risco é modificar automações sem cobertura de testes: a unificação de Flows é a ação com o maior potencial para quebrar silenciosamente a lógica de negócios. ## Como Medir o Sucesso Quatro métricas são suficientes: EPT médio nas cinco telas principais, tempo de Save no processo de negócios primário, número de falhas de Timeout e Governor Limit por mês, e a porcentagem de consultas que demoram mais de cinco segundos. Uma quinta métrica — complementar e não técnica — é o número de reclamações de desempenho no Service Desk, que deve diminuir com a melhoria real. ### Perguntas e respostas **Por onde começar quando os usuários reclamam que 'o sistema está lento'?** Pela medição, não pela suposição. O Lightning Usage App mostra quais telas estão lentas e para quais usuários, e o EPT para cada Record Page indica o componente problemático. Uma reclamação geral sem medição quase sempre leva à correção do componente errado. **O que é uma consulta não seletiva e por que é um problema crítico?** É uma consulta cujo filtro não é suportado por um índice, forçando a varredura de uma tabela grande. Acima de um milhão de registros, ela falha por timeout ou retarda qualquer processo que dependa dela. A solução: filtrar por campos indexados, evitar NULL e LIKE abertos, e solicitar um Custom Index. **Quando uma Skinny Table é justificada?** Quando há um relatório ou List View central que puxa poucos campos de um Objeto com milhões de registros, e a filtragem já é otimizada. É uma solicitação ao Suporte Salesforce, e não uma configuração autônoma, que resolve a leitura – não a escrita ou automação pesada. **A substituição de Process Builder por Flow melhora a performance?** Na maioria dos casos, sim, mas não por causa da ferramenta em si, e sim pela consolidação. O real ganho vem da redução do número de automações executadas no mesmo Objeto e da movimentação de trabalho pesado para processamento assíncrono, não apenas pela transição. **Que nível de melhoria é razoável esperar?** Em um projeto focado de diagnóstico e tratamento, uma redução de 30% a 50% no tempo de carregamento das telas mais pesadas, dentro de seis a dez semanas, é uma meta realista. Melhorias maiores geralmente exigem a mudança do modelo de dados ou da arquitetura de integração. --- ## Implementação Salesforce na Organização: Guia Completo, da Análise ao Go Live URL: https://hpi.pro/pt/insights/salesforce-implementation-guide A maioria das implementações Salesforce não falha no desenvolvimento, mas sim entre as etapas: uma transição apressada do Discovery para a construção, migração sem ensaio geral e UAT sem um verdadeiro proprietário. Este guia detalha o percurso completo, etapa por etapa, entregas e validações. ## A Resposta Concisa A questão central na implementação do Salesforce em uma organização não é "qual módulo ativar primeiro", mas sim como construir um caminho onde cada etapa gera um resultado aprovável, e não apenas mais uma reunião. Este guia segue oito estações: Discovery, Solution Design, Construção Iterativa, Migração, UAT, Treinamento, Go Live e Hypercare. Em cada estação, há um produto final obrigatório, um aprovador e um risco principal que deve ser mitigado antes de prosseguir. A ideia central é uma sequência ininterrupta: não é possível construir sem um Solution Design aprovado, e não é possível entrar em operação sem um UAT assinado por alguém com autoridade de negócio. Quando uma etapa é pulada, o problema não desaparece – ele apenas é transferido para uma fase de correção mais cara. Informações adicionais sobre a decisão de substituir um sistema existente estão disponíveis em [Substituir CRM pelo Salesforce](/pt/insights/replace-crm-with-salesforce). ## Mapa Completo das Etapas | Etapa | Produto Final Obrigatório | Quem Aprova | Risco Principal | | --- | --- | --- | --- | | Discovery | Documento As-Is/To-Be, Baseline e Métricas de Sucesso | Patrocinador de Negócios e Proprietário do Processo | Definição de sucesso vaga que só é revelada no UAT | | Solution Design | Modelo de Dados, Permissões, ADR e Diagrama de Integrações | Arquiteto Salesforce e CIO | Solução construída em torno de uma solicitação pontual, e não de um processo | | Construção Iterativa | Vertical Slice funcional em cada Sprint, com Demonstração | Product Owner | Acúmulo de Backlog de "quase pronto" sem definição de conclusão | | Migração | Resultado de Rehearsal de Migração completo versus critérios de qualidade | Proprietário dos Dados por Objeto | Dados duplicados ou ausentes que são descobertos apenas após o carregamento em Produção | | UAT | Assinatura dos proprietários do processo para cenários ponta a ponta | Líderes de Equipes de Negócios | Teste superficial que cobre apenas o "Happy Path" | | Treinamento | Plano de Habilitação, Materiais de Treinamento e lista de Champions | Gerente de CRM | Usuários aprendem "na prática" e geram dados de baixa qualidade | | Go Live | Checklist Go/No-Go assinado e plano de Rollback | Gerência de Projeto | Entrada em produção sem um plano de contingência em caso de falha | | Hypercare | Registro diário de falhas e métrica de adoção versus Baseline | Gerente de CRM e equipe de implementação | Encerramento prematuro do projeto, antes que a adoção se estabilize | ## Discovery: Antes de Tocar Nas Ferramentas A fase de Discovery define tudo o que virá depois e, mesmo assim, é a etapa que mais organizações apressam para "começar a construir logo". O produto final exigido não é uma apresentação, mas um documento que inclui o processo As-Is documentado, a meta To-Be, e uma lista explícita do que não será incluído na primeira versão. Sem essa definição, qualquer nova solicitação que surgir em dois meses será percebida como uma parte "óbvia" do projeto. A ferramenta mais prática nesta fase é um Baseline mensurável: tempo de manuseio de um Lead, porcentagem de negócios fechados sem dupla digitação, taxa de campos vazios em um registro de cliente. Sem um número antes da mudança, é impossível provar a melhoria após o lançamento - apenas sentir que ela existe. Organizações que pulam esta fase voltam a ela de qualquer maneira, geralmente no meio da construção, e isso custa mais. Outras implicações de pular etapas precocemente são detalhadas em [Erros na Implementação do Salesforce](/pt/insights/crm-implementation-mistakes). ## Solution Design: Onde a Maioria das Decisões Caras Acontece Solution Design é a fase onde se escolhe entre várias alternativas de implementação e se documenta por que uma foi escolhida e não as outras. O modelo de dados, a estrutura de permissões (incluindo o compartilhamento entre funções e regiões) e o diagrama de integrações com sistemas como ERP, plataformas de pagamento ou marketing – tudo isso precisa estar escrito antes que o primeiro ambiente de desenvolvimento seja aberto. Um erro comum é permitir que a equipe de desenvolvimento "decida no decorrer do trabalho" como será o modelo de Compartilhamento, porque isso parece um detalhe técnico. Na prática, mudar um modelo de compartilhamento depois que já existem centenas de registros em produção é um projeto em si. Portanto, quando a decisão cruza vários departamentos ou afeta permissões sensíveis, é preciso garantir que as responsabilidades e funções em torno do projeto estejam claras – veja mais detalhes em [Equipe de Projeto Salesforce](/pt/insights/salesforce-project-team-roles). ### O que deve estar documentado no Solution Design - Modelo de objetos e campos centrais, incluindo o que não será construído na primeira versão - Mapa de permissões por função, incluindo exceções e casos de acesso temporário - Lista de integrações com a direção do fluxo de dados e frequência de sincronização - Pelo menos três decisões arquitetônicas com uma alternativa rejeitada e a razão para isso ## Construção Iterativa: Vertical Slice e Não Apenas uma Coleção de Telas Na fase de construção, a armadilha comum é o progresso "horizontal" – criar todas as telas de uma vez sem que nenhum processo funcione de ponta a ponta. A abordagem correta é construir um Vertical Slice em cada ciclo: um processo completo, com dados reais e permissões representativas, que pode ser demonstrado ao proprietário do processo para obter feedback imediato. Todo Sprint deve terminar com uma demonstração, não apenas com "código enviado". Quando não há uma Demo regular, acumula-se um inventário de itens "quase prontos" que se revelam incompletos apenas na fase de UAT, e é exatamente isso que encarece o projeto em seu último terço. ## Migração: A Parte Mais Subestimada A migração de dados é frequentemente o maior risco em um projeto, e geralmente recebe menos tempo no cronograma. É imperativo realizar um Rehearsal completo – carregar dados para um ambiente de teste em sua totalidade, incluindo volumes reais, e verificar o resultado em relação a critérios de qualidade predefinidos: duplicidades, campos obrigatórios ausentes, formato de datas e moedas, e compatibilidade entre sistemas. Uma tabela útil para gerenciar este risco: | Verificação de Qualidade | O que é verificado | Limite de Aceitação Recomendado | | --- | --- | --- | | Integridade de Campos Obrigatórios | Percentual de registros com campo crítico vazio | Abaixo de 2% | | Duplicidades | Clientes/Leads com o mesmo identificador de negócio | Abaixo de 1% após desduplicação | | Compatibilidade de Formato | Datas, moedas, códigos de país | 100% compatível com o padrão de destino | | Conectividade de Registros | Relações Parent-Child que não foram quebradas na transição | 100% das relações críticas | ## UAT: Teste com Propriedade Real, Não Assinatura Técnica Um UAT realizado corretamente envolve os proprietários do processo executando cenários de ponta a ponta por conta própria, e não a equipe do projeto demonstrando a eles. Recomenda-se selecionar 8 a 12 cenários que cubram não apenas o caminho feliz, mas também casos extremos: um cliente sem endereço de e-mail, um negócio cancelado após aprovação, um usuário com permissão parcial. A assinatura de um UAT deve ser explícita – nome, data e uma lista das lacunas que permanecem abertas para a próxima versão, e não apenas "aprovação verbal em reunião". ## Treinamento: Onde o Projeto Silenciosamente Atinge o Sucesso ou Falha Mesmo uma excelente solução técnica falha se os usuários não a adotam. Um bom plano de treinamento inclui material adaptado para cada função (não uma apresentação única para todos), demonstrações em um ambiente Sandbox com dados familiares e uma lista de Champions – usuários-chave de cada equipe que podem responder a perguntas cotidianas sem abrir um chamado de suporte. Organizações que investem em treinamento duas semanas antes do Go Live geralmente observam menos "falsos positivos" de falhas ("o sistema não funciona", quando na verdade é um erro de entrada). ## Go Live e Hypercare: A Entrada em Produção é o Começo, Não o Fim O Go Live exige uma Checklist assinada que inclua a verificação de permissões no ambiente de produção, a validação de integrações ativas e um plano de Rollback claro para o caso de uma falha bloqueante ser detectada. Após o lançamento, inicia-se o período de Hypercare – geralmente de duas a quatro semanas, durante as quais a equipe monitora diariamente logs de erros, taxa de uso real e reclamações de usuários, corrigindo com alta prioridade dentro de um dia útil. Encerrar o projeto antes que a adoção se estabilize é um erro comum: os dados das primeiras duas semanas quase sempre apresentam uma imagem pior do que a realidade será após a estabilização dos hábitos. ## O Que Realmente Acontece de Errado em Empresas Médias em Israel Na prática da HPI Pro com empresas de médio porte em Israel (entre 20 e 300 funcionários), a maioria das falhas não decorre de uma escolha errada de produto, mas sim de atalhos processuais: - **Gerência não disponível para aprovar o Escopo** – O projeto avança com base na interpretação do gerente de TI, e quando a gerência finalmente vê o resultado, solicita mudanças que retrocedem semanas. - **Dependência de um único desenvolvedor ou pequeno escritório sem backup de documentação** – Quando a pessoa sai, não há quem entenda as decisões tomadas no Solution Design. - **Migração de fontes não oficiais** – Planilhas Excel que cada vendedor gerencia separadamente, sem uma fonte de verdade acordada, o que transforma a fase de limpeza em um subprojeto. - **Compactação do UAT em uma semana antes do Go Live** – Quando o cronograma aperta, o UAT é a primeira etapa a ser reduzida, e é exatamente a etapa mais importante de se manter. - **Falta de treinamento adaptado ao idioma e à função** – Materiais de treinamento genéricos em inglês para uma equipe de vendas que trabalha em hebraico levam a um uso parcial e à contorno do sistema na prática. A maneira de reduzir esses riscos não é "trabalhar mais rápido", mas planejar a camada de DevOps do projeto – ambientes de teste separados, processo de Release definido e rastreamento de mudanças – desde o início. Mais detalhes sobre isso em [Salesforce DevOps Sandboxes](/pt/insights/salesforce-sandbox-devops-strategy). ## Checklist Antes de Mudar de Etapa - ☐ Há um produto final documentado para cada etapa, e não apenas um resumo de reunião. - ☐ O Baseline é medido antes do início do projeto. - ☐ O modelo de dados e as permissões são aprovados antes de iniciar o desenvolvimento. - ☐ Cada Sprint termina com uma demonstração de Vertical Slice. - ☐ Um Migration Rehearsal completo foi realizado com um limite de qualidade definido. - ☐ O UAT foi assinado pelos proprietários do processo com uma lista de lacunas abertas. - ☐ Existe um plano de treinamento adaptado à função e ao idioma. - ☐ Há um Checklist Go/No-Go e um plano de Rollback. - ☐ O período de Hypercare é definido em tempo e responsabilidade. ## Como Medir o Sucesso Real do Projeto | Área de Medição | O que é verificado | Frequência de Monitoramento Recomendada | | --- | --- | --- | | Adoção | Percentual de usuários ativos versus total de licenças | Semanal no primeiro mês | | Qualidade dos Dados | Campos obrigatórios ausentes, duplicidades | Antes do Go Live e uma vez por mês | | Desempenho do Processo | Tempo de manuseio de Lead/Negócio versus Baseline | Mensal nos primeiros três meses | | Falhas | Número de chamados de suporte e taxa de reabertura | Diário durante o período de Hypercare | Organizações que optam por um acompanhamento profissional ao longo de toda essa jornada, desde o Discovery até o encerramento do Hypercare, podem utilizar o [serviço de Implementação Salesforce](/pt/salesforce-implementation) para garantir que cada etapa receba o produto, a aprovação e o controle de risco adequados antes de prosseguir para a próxima fase. ## Recursos Profissionais - Salesforce Well-Architected — https://architect.salesforce.com/docs/architect/well-architected/guide/overview.html - HPI Pro – Implementação Salesforce — https://hpi.pro/salesforce-implementation - HPI Pro – Metodologia de Trabalho — https://hpi.pro/methodology ### Perguntas e respostas **Quanto tempo leva uma implementação completa do Salesforce em uma empresa de médio porte?** Para uma empresa com 30-80 usuários e processos básicos de vendas e serviço, o percurso completo do Discovery ao Go Live varia de 10 a 16 semanas. Projetos com integrações complexas a sistemas ERP ou de faturamento podem estender-se para 20-24 semanas, principalmente por conta da migração e testes. **Qual a diferença entre Solution Design e documentação de requisitos padrão?** O Solution Design inclui o modelo de dados, mapa de permissões, diagrama de integrações e decisões arquitetônicas com alternativas descartadas. A documentação de requisitos padrão descreve o que o usuário deseja; o Solution Design descreve como o sistema será construído na prática e qual o custo de cada escolha. **É possível pular a etapa de UAT quando o prazo está apertado?** É possível reduzir sua abrangência, mas não eliminá-la. Uma versão mínima de UAT envolve testar 5-8 cenários críticos de ponta a ponta com os proprietários reais do processo. Pular completamente o UAT quase sempre transfere as falhas para as primeiras semanas após o Go Live, quando o custo de correção é maior. **Quem é responsável pela qualidade dos dados na migração de Excel ou de um sistema antigo?** A responsabilidade profissional pelas regras de conversão e limpeza é da equipe de implementação, mas a responsabilidade pela exatidão do conteúdo de negócios permanece com o proprietário dos dados na organização. Por isso, recomenda-se nomear um Data Owner por objeto que aprove o resultado da migração antes que seja carregado no ambiente de produção. **O que realmente acontece durante o período de Hypercare?** Geralmente, são duas a quatro semanas em que a equipe de implementação está disponível para suporte próximo, monitora logs de erros e adoção diária, e corrige falhas de alta prioridade em até um dia útil. Ao final do período, a responsabilidade é formalmente transferida para a equipe de manutenção contínua ou suporte interno. --- ## Arquitetura Salesforce para Empresas: Como Planejar um Sistema Escalável URL: https://hpi.pro/pt/insights/crm-architecture-guide Uma organização que adiciona Custom Objects, Flows e integrações ponto a ponto sem uma arquitetura documentada acumula uma dívida técnica que só se revela ao tentar adicionar um novo negócio ou país. Este artigo disseca a arquitetura em seis camadas práticas. ## A Resposta Curta Uma boa arquitetura Salesforce não se mede pela quantidade de componentes construídos, mas sim pela capacidade da organização de adicionar um novo negócio, produto ou mercado sem desmantelar o que já funciona. O problema mais comum que observamos não é uma escolha tecnológica equivocada, mas sim a ausência de uma camada de decisões documentada: quem é o proprietário de cada objeto, por que o Flow foi escolhido em vez do Apex, e por que existem cinco integrações separadas em vez de uma única camada de Middleware. Este artigo divide a arquitetura em seis camadas que devem ser planejadas em conjunto, e não isoladamente: Modelo de Dados e Objetos, Compartilhamento e Permissões, Automação, Integrações, Estratégia de Org e DevOps com Escalabilidade. O contexto estendido sobre o tratamento de erros de integração pode ser encontrado em [Monitoramento de Erros de Integração Salesforce](/pt/insights/salesforce-integration-error-handling). ## Modelo de Dados e Objetos: A Base de Tudo Um erro comum em muitas organizações: criar um novo Custom Object para cada requisito de negócio, sem verificar se é possível usar um campo adicional em um objeto existente ou um Record Type. O resultado, após dois ou três anos, é uma Org com 80 a 120 objetos personalizados, alguns com significado duplicado, e sem documentação do motivo de cada criação. O princípio orientador antes de criar qualquer objeto é perguntar: quem é o proprietário do negócio, qual é a fonte da verdade (Salesforce ou sistema externo) e o que acontece quando um registro é excluído ou duplicado. Empresas que gerenciam um catálogo de produtos complexo, por exemplo, tendem a criar um Objeto separado para cada categoria em vez de usar Record Types em Product2 – o que gera uma sobrecarga de manutenção desnecessária a cada atualização. Tabela útil para verificar a maturidade do modelo de dados: | Componente | Pergunta de Verificação | Sinal de Alerta | | --- | --- | --- | | Objetos Personalizados | Existe um Objeto semelhante existente que pode ser estendido? | Dois objetos com campos essencialmente iguais | | Campos | O campo é usado para mais de um processo? | Mais de 800 campos em um objeto central | | Relacionamentos | Master-Detail ou Lookup foi escolhido intencionalmente? | Master-Detail escolhido como "padrão" | | External ID | Cada objeto sincronizado possui uma chave única? | Sincronização apenas por nome ou data | ## Compartilhamento e Permissões: A Camada que Quebra Silenciosamente Um modelo de permissões frouxo não é detectado imediatamente — ele é descoberto quando alguém vê um dado que não deveria ver, ou quando um relatório gerencial exibe menos linhas do que o esperado porque uma Sharing Rule bloqueia o acesso. A escolha entre Role Hierarchy, Organization-Wide Defaults, Sharing Rules e Permission Sets deve ser derivada da estrutura organizacional real, e não da estrutura hierárquica oficial no organograma. Um antipadrão comum: conceder "View All" ou "Modify All" no nível do perfil para "resolver" um problema de permissão sob pressão de tempo, sem revisitar e restringir posteriormente. Isso funciona no curto prazo e cria uma ampla exposição de dados no longo prazo — especialmente em setores regulamentados como finanças ou saúde. Permission Set Groups permitem construir permissões modulares que podem ser adicionadas e removidas sem tocar no perfil base, sendo uma forma mais segura de lidar com uma organização em crescimento. Criteria-Based Sharing Rules em objetos com milhões de registros exigem um teste de carga antes da produção — em alguns casos, uma regra de Compartilhamento aparentemente inofensiva causa um Recalculation que dura horas e paralisa processos noturnos. ## Automação: Flow versus Apex A questão "Flow ou Apex" não é uma questão de gosto, mas de complexidade, volume e ciclo de vida. O Flow é mais legível para uma equipe operacional, é construído e mantido rapidamente, e é adequado para lógicas de negócio que mudam. O Apex é necessário quando há processamento em massa (Bulk Processing) de milhares de registros em uma única transação, quando é preciso controle preciso da ordem de execução em relação a outros Triggers, ou quando é exigida testagem automatizada (Test Coverage) para fins regulatórios ou de Gerenciamento de Mudanças formal. Um antipadrão comum em organizações em crescimento: cadeias de Flow que chamam umas às outras (Flow que aciona Flow que aciona Flow), sem um mapa central que mostre a ordem de execução. Quando algo quebra, ninguém sabe qual Flow foi executado primeiro. Exemplo prático: uma organização com 14 Flows ativos em Opportunity, três deles com a mesma lógica de atualização de status, escritos em diferentes períodos por pessoas diferentes sem verificar o que já existia. Uma regra prática: se houver mais de 5 a 6 condições ramificadas em uma única lógica de negócio, ou se for necessária uma chamada externa dentro de um loop, o Apex é preferível. Fora isso, o Flow é preferível porque é acessível para manutenção mesmo quando o desenvolvedor original não está mais na empresa. ## Integrações: Do Ponto-a-Ponto a uma Camada Gerenciada Uma organização que começa com duas conexões externas (ERP e um sistema de pagamento, por exemplo) geralmente as constrói diretamente, ponto a ponto, o que é razoável nesta fase. O problema começa quando se adicionam uma terceira, quarta e quinta conexão — cada uma com sua própria lógica de Retry, tratamento de erros e mapeamento de campos, sem um padrão comum. Nesta fase, qualquer mudança no sistema fonte quebra uma ou mais conexões sem que ninguém saiba de antemão. A transição para uma camada de Middleware (MuleSoft, ou uma camada de integração personalizada) não precisa ser um projeto gigantesco — pode-se começar pela conexão mais frágil ou mais cara de manter e migrar gradualmente. Princípios a serem adotados em cada nova integração: Idempotência (uma chamada duplicada não cria um registro duplicado), External ID para identificação segura e um log que permita reconstruir exatamente o que aconteceu em cada chamada. Mais detalhes sobre padrões de integração podem ser encontrados em [Conectando Salesforce ao ERP](/pt/insights/salesforce-erp-integration) e [Padrões de Integração Salesforce](/pt/insights/salesforce-integration-patterns). ## Estratégia de Org: Single Org, Multi-Org ou Segmentação por Unidade de Negócio Esta é uma das decisões mais caras de mudar retrospectivamente. Uma Single Org com Segmentação por Unidade de Negócio (usando Record Types, Sharing e Permission Sets para separação lógica) é adequada para a maioria das organizações, pois mantém uma única fonte da verdade e métricas de relatórios unificadas. Uma Multi-Org é apropriada quando as unidades de negócio exigem modelos de permissão fundamentalmente conflitantes, quando há uma fusão ou aquisição que traz uma Org existente, ou quando a carga de permissões real afeta o desempenho. A transição entre os modelos depois que a organização já está estabelecida é um projeto pesado — fusão de dados, remapeamento de permissões e, às vezes, perda de histórico. Um detalhamento completo dos aspectos a serem considerados na decisão está em [Salesforce Multi Org](/pt/insights/salesforce-single-org-vs-multi-org). ## DevOps e Escalabilidade: Como Manter a Capacidade de Mudança Uma organização que desenvolve diretamente em Produção, sem Sandboxes organizados e sem ferramentas de CI/CD (como Copado, Gearset ou SFDX), rapidamente chega a um ponto em que qualquer mudança é arriscada. Um processo DevOps adequado inclui pelo menos um Sandbox para desenvolvimento, um Sandbox para testes, controle de versão para Metadata e um processo de Deployment automatizado com testes de regressão. Tabela de decisões arquitetônicas centrais e suas implicações a longo prazo: | Decisão | Vantagem Imediata | Implicação em 2-3 anos | | --- | --- | --- | | Custom Object para cada requisito | Solução rápida para necessidade pontual | Org com dezenas de objetos duplicados, difícil de manter | | Permissões "View All" temporárias | Resolve um problema em minutos | Exposição ampla de informações, difícil de rastrear e fechar | | Flow que chama Flow | Desenvolvimento rápido sem código | Cadeias difíceis de rastrear e testar | | Integração Point-to-Point adicional | Conexão rápida entre dois sistemas | Rede de conexões onde qualquer mudança quebra algo mais | | Desenvolvimento direto em Produção | Economiza tempo de configuração do processo | Alto risco para qualquer mudança, dificuldade de reversão | | Single Org sem separação lógica | Relatório unificado desde o primeiro dia | Dificuldade em adicionar uma unidade de negócio com necessidades diferentes | ## Cenário Organizacional de Exemplo Uma empresa de distribuição com três unidades de negócios operou por quatro anos em uma única Org, com cada unidade adicionando objetos, Flows e integrações conforme a necessidade imediata. Quando a gerência decidiu adicionar uma quarta unidade, descobriu-se que não havia um único documento explicando quem era o proprietário de cada objeto, e três integrações diferentes sincronizavam clientes com o sistema financeiro com lógicas conflitantes. A equipe de arquitetura realizou um mapeamento completo: identificou 23 objetos sem um proprietário claro, seis cadeias de Flow sobrepostas e duas integrações que criavam registros duplicados devido à falta de um External ID consistente. A solução não foi a reconstrução, mas sim a documentação gradual, a unificação da lógica de Compartilhamento sob Permission Set Groups e a migração de integrações críticas para uma única camada de Middleware. Em dois trimestres, o tempo para adicionar uma nova unidade de negócio diminuiu de vários meses para cerca de seis semanas. ## Antipatterns Comuns em Organizações em Crescimento - **Custom Object para cada solicitação** - Cria-se um novo objeto sem verificar a existência de um similar. - **Permissões amplas "temporárias"** - Concedidas sob pressão e nunca mais restritas. - **Flow-in-Flow sem mapeamento** - Cadeias de automação sem um diagrama de execução central. - **Point-to-Point sem Governança** - Cada nova conexão é construída separadamente, sem um padrão comum. - **Desenvolvimento em Produção** - Mudanças diretas sem Sandbox, testes ou Controle de Versão. - **Ausência de External ID** - Sincronização por nome ou e-mail que cria registros duplicados. ## Checklist para Avaliação da Maturidade da Arquitetura - ☐ Cada Custom Object possui um proprietário de negócio documentado. - ☐ O modelo de Compartilhamento foi testado sob cargas de dados realistas. - ☐ Existe um mapa central de todas as cadeias de Automação. - ☐ Cada integração possui External ID, Retry e log de erros. - ☐ Existe um processo Sandbox-to-Production organizado com testes de regressão. - ☐ A decisão entre Single Org e Multi-Org foi explicitamente tomada e documentada. - ☐ Os Governor Limits são verificados em relação à projeção de crescimento para três anos. Quando a arquitetura Salesforce exige orientação profissional e não apenas uma estrutura de trabalho autônoma, essa é a área de [Serviços de Arquitetura de CRM](/pt/crm-architecture). ## Fontes Profissionais - Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html - Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html - HPI Pro – Arquitetura de CRM — https://hpi.pro/crm-architecture - HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data ### Perguntas e respostas **Qual a diferença entre Flow e Apex na escolha da camada de automação?** Flow é adequado para lógica de negócios que muda frequentemente, acionamento por equipes operacionais e menos de 5-6 condições complexas. Apex é necessário para transações complexas, loops com chamadas externas, processamento em massa de milhares de registros, ou necessidade de testes automatizados (Test Classes) para conformidade regulatória. **Quando é o momento de migrar de uma Single Org para múltiplas organizações?** Quando diferentes unidades de negócio exigem modelos de permissão conflitantes, quando a carga de permissões impacta o desempenho, ou quando uma fusão/aquisição introduz uma Org separada. A migração é cara e complexa — é aconselhável verificar primeiro se a Segmentação de Unidades de Negócio ou Multi-Moeda resolvem o problema dentro de uma única Org. **Como construir um modelo de compartilhamento que não entre em colapso sob carga?** Primeiro, mapeie a estrutura da organização e os grupos de usuários, depois escolha entre Hierarquia de Funções, Regras de Compartilhamento e Conjuntos de Permissões, conforme a abrangência das exceções. Regras de Compartilhamento baseadas em Critérios que são executadas em milhões de registros exigem testes de desempenho antes da Produção, não depois. **O que fazer com integrações ponto a ponto antigas que se acumularam ao longo dos anos?** Mapeie todas as conexões existentes, identifique duplicações de lógica entre sistemas e construa um plano de transição gradual para uma camada de Middleware ou Arquitetura Orientada a Eventos. Não substitua tudo de uma vez – comece pela integração mais frágil ou mais cara de manter. **Como verificar se a arquitetura resistirá nos próximos três anos?** Verifique os Governor Limits em relação ao volume de crescimento esperado, o número de objetos personalizados, a profundidade das Cadeias de Automação e o número de integrações ativas. Uma organização com mais de 15 Triggers em um único objeto ou cadeias de Flow que se chamam mutuamente é um sinal de alerta precoce. --- ## Diagnóstico de CRM para Salesforce: Os Entregáveis Essenciais Antes de Iniciar a Implementação URL: https://hpi.pro/pt/insights/crm-discovery-guide Uma fase de descoberta que resulta apenas em uma apresentação elegante não é uma descoberta. Ao final da fase de diagnóstico de CRM, sete entregáveis cruciais devem estar prontos para que a construção, precificação e validação do projeto de Salesforce possam ser realizadas. Este guia detalha o conteúdo de cada entregável, critérios de maturidade e a duração esperada para sua elaboração. ## O Que Deve Estar na Mesa no Dia Seguinte à Fase de Análise e Desenho A fase de Análise e Desenho de CRM é avaliada pelos resultados que podem ser utilizados na prática, e não pela quantidade de reuniões. Se, ao final desta fase, o gestor de projeto ainda não consegue criar um plano de trabalho, o desenvolvedor ainda não sabe qual objeto contém o processo, e o gestor de dados ainda não sabe a origem do cliente, a fase de Análise e Desenho não foi concluída, mesmo que a apresentação tenha sido aprovada. Este documento define sete resultados essenciais. Para cada um, há um critério de maturidade: uma afirmação que pode ser respondida com "sim" ou "não". Se a resposta for "mais ou menos" para mais de dois, a fase de construção inicia-se com um risco que já pode ser precificado. A visão geral das etapas pós-análise e desenho encontra-se no [Guia de Implementação Salesforce](/pt/insights/salesforce-implementation-guide). ## Resultado 1: Mapa de Processos em Nível de Decisão Não se trata de um fluxograma de cada clique, mas sim de um mapeamento dos pontos de decisão: quem decide, com base em qual informação, o que acontece em cada ramificação e o que ocorre quando não há decisão. A maioria das falhas em projetos de CRM não reside no caminho principal, mas sim nas ramificações — um negócio que é congelado, um cliente que retorna após dois anos, uma solicitação aberta pelo cliente errado. Critério de Maturidade: É possível pegar um negócio real do último mês e rastreá-lo no mapa de ponta a ponta sem encontrar lacunas. ## Resultado 2: Glossário de Termos de Negócio Este é o resultado mais subestimado e cuja ausência é a mais custosa. "Cliente" significa algo diferente para finanças e vendas. "Projeto Ativo" significa algo diferente para operações e para a gestão executiva. Enquanto as definições não estiverem escritas, cada relatório gerará discussões. O glossário deve conter, para cada termo: uma definição em uma frase, a entidade em Salesforce que o representa, o campo que determina o status e o departamento responsável pela definição. ## Resultado 3: Modelo de Dados Central Decidido Na fase de Análise e Desenho, não se constrói um ERD (Diagrama de Entidade e Relacionamento) completo, mas sim se tomam decisões sobre as quatro questões mais caras para serem alteradas posteriormente: - Se a atividade de negócio reside em um Objeto Opportunity, em um objeto personalizado ou em uma combinação de ambos, e qual a relação entre eles. - Se a Entidade Account representa uma entidade jurídica, um local físico ou um grupo de compras — e como a hierarquia é tratada. - Qual é a chave única que identifica o cliente entre Salesforce e os sistemas base. - Quais dados históricos são importados para o sistema e quais permanecem na origem. Critério de Maturidade: É possível desenhar em um quadro os cinco objetos principais e seus relacionamentos sem consultar arquivos. ## Resultado 4: Modelo de Permissões e Compartilhamento O modelo de permissões é derivado da pergunta "quem não deve ver o quê", e não da pergunta "quem precisa ver o quê". Estas duas perguntas parecem idênticas, mas levam a arquiteturas opostas. Uma boa análise e desenho define as permissões padrão da organização para cada objeto principal, o mecanismo de expansão e os casos que exigem compartilhamento excepcional. | Pergunta | O que verificar na Análise e Desenho | Por que é caro mudar depois | | --- | --- | --- | | Padrão para o objeto | Privado, Leitura Pública ou Leitura/Escrita | Afeta todo o mecanismo de compartilhamento acima dele | | Estrutura hierárquica | Se a hierarquia de funções reflete gerenciamento ou geografia | A mudança exige recálculo do acesso em todos os registros | | Compartilhamento entre unidades | Equipes colaborativas, compartilhamento manual ou critério | Determina se é necessária lógica dedicada | | Dados sensíveis | Quais campos são restritos e para quem | A mudança posterior expõe informações que já foram visualizadas | ## Resultado 5: Mapa de Sistemas e Fontes da Verdade Para cada entidade central, deve haver uma única e declarada fonte da verdade, e uma direção de sincronização clara. Uma análise e desenho que deixa dois sistemas "atualizando um ao outro" cria conflitos que só serão descobertos na produção. O mapa também deve incluir a frequência e a tolerância ao atraso: um processo de vendas pode conviver com uma sincronização de cinco minutos, mas o controle de crédito geralmente não. ## Resultado 6: Critérios de Aceitação para Processos Chave Esta é a conexão entre a Análise e Desenho e os testes. Para cada processo chave, são necessários de três a cinco critérios de aceitação formulados como um resultado observável: "Após o fechamento de um negócio, um pedido é criado no sistema core em até cinco minutos, com o mesmo ID de cliente". Tal formulação é uma demanda, um roteiro de teste e uma definição de conclusão. Sem isso, a fase de UAT (User Acceptance Testing) torna-se uma série de comentários de design. ## Resultado 7: Métricas de Base Antes da Mudança É impossível provar melhoria sem medição prévia. Na fase de Análise e Desenho, selecionam-se de três a cinco métricas e as mede-se efetivamente no estado atual, mesmo que a medição seja manual e grosseira. A seleção das métricas e a forma de conectá-las ao benefício de negócio são detalhadas no [Guia de ROI e Métricas de Sucesso Salesforce](/pt/insights/salesforce-roi-kpis). ## Exemplo Ilustrativo: Rede de Clínicas Privadas O cenário a seguir é hipotético e serve apenas para fins ilustrativos. Uma rede de clínicas com oito unidades iniciou um projeto de CRM para centralizar as solicitações dos pacientes. Durante a fase de Análise e Desenho, descobriu-se que duas unidades definiam "solicitação recorrente" de forma diferente: uma contava cada ligação, enquanto a outra contava apenas solicitações sobre um novo tema. A diferença parecia semântica, mas determinava se o sistema precisaria de um único objeto Case com hierarquia ou de dois objetos separados, e influenciava todos os relatórios de carga de trabalho para a gerência. A equipe não resolveu a disputa no documento. Eles registraram uma decisão em aberto, definiram um proprietário em nível de Diretor de Operações e uma data-alvo antes do início da construção. A decisão foi tomada em duas semanas, e o modelo foi construído uma única vez. Se a decisão tivesse sido adiada, ela teria sido descoberta na fase de UAT — após telas e relatórios já terem sido construídos com base em uma premissa incorreta. ## Sinais de Alerta de uma Análise e Desenho Superficial - O documento descreve telas e campos, mas não descreve o que acontece quando um processo falha. - Nenhuma decisão documentada considerou alternativas. - Todas as demandas têm alta prioridade. - Não há um nome de pessoa associado a nenhum processo, apenas o nome de um departamento. - O número de campos solicitados em uma única tela excede vinte e cinco sem que ninguém tenha verificado quem os preenche. A relação entre uma análise e desenho superficial e os padrões de falha que aparecem posteriormente no projeto é detalhada no [Guia dos Erros Comuns](/pt/insights/crm-implementation-mistakes), e sua influência no cronograma é explicada no [Guia de Duração de Projeto Salesforce](/pt/insights/salesforce-project-timeline). ## Ao Substituir um Sistema Existente Quando o projeto substitui um CRM antigo, a fase de Análise e Desenho ganha uma tarefa adicional: decidir o que não será migrado. Um sistema antigo acumulou campos, automações e relatórios que ninguém mais usa, e a replicação cega deles importa a dívida técnica antiga para uma nova plataforma. A sequência de ações recomendada nesta transição está detalhada no [Guia de Substituição de CRM por Salesforce](/pt/insights/replace-crm-with-salesforce). ## Como Saber Que é Hora de Começar a Construir Revise os sete resultados e, para cada um, faça a pergunta de maturidade. Se seis dos sete responderem "sim", é possível iniciar a primeira onda gerenciando a sétima lacuna como um risco documentado. Se três ou mais responderem "mais ou menos", é preferível estender a fase de Análise e Desenho por duas semanas do que descobrir a lacuna após três meses de trabalho terem sido construídos sobre ela. A próxima etapa natural é a tradução dos resultados para um plano de ondas, com uma decisão explícita sobre o que entra na primeira onda e o que é conscientemente adiado. ### Perguntas e respostas **Qual a duração ideal de um diagnóstico de CRM antes de um projeto Salesforce?** Não há uma duração única, mas existe uma proporção razoável: a fase de diagnóstico geralmente corresponde a um décimo ou um quinto do tempo total do projeto. A duração depende principalmente do número de processos interdepartamentais e da quantidade de sistemas legados. Diagnósticos mais longos geralmente não sofrem de falta de tempo, mas sim da ausência de uma autoridade capaz de arbitrar conflitos de opiniões. **Qual a diferença entre diagnóstico de CRM e um documento de requisitos?** Um documento de requisitos descreve o que os usuários pediram. Um diagnóstico descreve o processo de negócio que será executado, o modelo de dados, as permissões, as integrações com outros sistemas e como seu funcionamento será validado. A mesma demanda pode ser implementada de cinco maneiras distintas no Salesforce; a função do diagnóstico é selecionar a melhor e justificar a escolha. **É possível realizar o diagnóstico com o mesmo fornecedor que fará a implementação?** Sim, e em muitos casos, é eficiente. O risco é que o diagnóstico possa se inclinar para o que é mais conveniente para o fornecedor construir. Esse risco pode ser mitigado garantindo que os entregáveis sejam fornecidos à organização em um formato não proprietário, que as decisões arquitetônicas sejam justificadas com alternativas consideradas, e que a precificação da fase de diagnóstico seja separada da precificação da implementação. **O que fazer quando os donos dos processos discordam sobre a definição de um processo?** Não encerre a disputa com texto ambíguo. Registre-a como uma decisão em aberto, atribuindo um responsável, uma data limite e a implicação no escopo. Em seguida, leve a questão a quem tem autoridade para decidir. Um diagnóstico que formula um consenso ilusório resultará em caros pedidos de mudança em etapas avançadas onde o código já foi construído. **É preciso diagnosticar todos os processos antes de começar a construção?** Não. É essencial diagnosticar profundamente os processos críticos para a primeira fase do projeto e mapear os restantes em um nível macro, para garantir que o modelo não seja impedido posteriormente. As únicas decisões que devem ser tomadas de antemão para o panorama completo são o modelo de dados central e o modelo de permissões, pois alterações posteriores nesses elementos são muito mais custosas do que alterações na interface. --- ## 10 Erros Comuns na Implementação de CRM e Salesforce e Como Evitá-los URL: https://hpi.pro/pt/insights/crm-implementation-mistakes A maioria das falhas em projetos de CRM não são problemas técnicos, mas sim decisões adiadas. Este material reúne dez erros recorrentes em projetos Salesforce, os sinais precoces para identificá-los a tempo e as ações preventivas que são de baixo custo se feitas no início e extremamente caras se realizadas após o Go Live. ## Como Ler Esta Lista As dez falhas a seguir não estão organizadas por frequência, mas sim pela ordem cronológica de sua ocorrência no ciclo de vida de um projeto. Para cada uma, apresentamos três elementos: o sinal precoce que pode ser identificado em tempo real, a ação preventiva e o estágio a partir do qual a correção se torna significativamente mais cara. A ideia é simples — a maioria dessas falhas custa muito pouco se abordada nas duas semanas certas. ## 1. Começar com uma Lista de Funcionalidades em Vez de um Processo **O Sinal:** O documento de requisitos é estruturado como uma tabela de capacidades desejadas, e nenhuma linha descreve um resultado de negócio. **O Que Acontece na Prática:** O projeto gera um sistema que atende à lista, mas não altera a forma de trabalho. Um ano depois, a gerência pergunta o que mudou, e não há uma resposta mensurável. **Prevenção:** Para cada requisito, associe o processo que ele atende e a métrica que ele deve impactar. Requisitos sem resposta para essas duas perguntas são movidos para uma lista de espera. O conjunto de entregáveis que evita esse padrão está detalhado no [Guia de Descoberta de CRM](/pt/insights/crm-discovery-guide). ## 2. Não Ter um Único Dono de Processo (Process Owner) **O Sinal:** Quatro pessoas do mesmo departamento comparecem às reuniões, e nenhuma delas está autorizada a dizer "assim será". **O Que Acontece na Prática:** Cada decisão é resolvida por um compromisso que tenta agradar a todos, resultando na construção de dois caminhos em vez de um. O sistema se torna duas vezes mais complexo do que o necessário. **Prevenção:** Para cada processo, atribua o nome de uma única pessoa. A divisão de papéis recomendada está detalhada no [Guia de Papéis da Equipe de Projetos Salesforce](/pt/insights/salesforce-project-team-roles). ## 3. Empurrar Decisões Arquitetônicas para o Final **O Sinal:** A equipe avança na construção de telas enquanto a pergunta "qual é a fonte de verdade para o cliente" ainda está em aberto. **O Que Acontece na Prática:** Quando a decisão finalmente é tomada, ela contradiz o que foi construído. Parte do trabalho é descartada, e a estimativa inicial do projeto já não é relevante. **Prevenção:** Identifique no início do projeto as três a cinco decisões mais caras de mudar — modelo de dados central, fonte de verdade, modelo de permissões — e estabeleça uma data de decisão para elas antes de iniciar a construção. ## 4. Importar a Dívida Técnica do Sistema Legado **O Sinal:** A especificação de migração contém todos os campos do sistema anterior, incluindo aqueles cujo nome termina em "_old_2". **O Que Acontece na Prática:** A nova plataforma nasce com duzentos campos que ninguém mantém, relatórios que dependem de dados não confiáveis e usuários que concluem que o novo sistema também não é sério. **Prevenção:** Cada campo a ser migrado deve ter um proprietário e um uso comprovado no último ano. O restante vai para um arquivo legível, não para o sistema ativo. ## 5. Medir o Progresso por Histórias Concluídas **O Sinal:** O relatório semanal mostra altas porcentagens de conclusão, mas ninguém conseguiu executar um processo completo de ponta a ponta. **O Que Acontece na Prática:** O projeto parece um sucesso no gráfico até a semana anterior ao *Go Live*, quando se descobre que todas as partes funcionam individualmente, mas ninguém testou a conexão entre elas. **Prevenção:** Defina um marco de "primeiro processo completo de ponta a ponta" o mais cedo possível, mesmo que cubra apenas um cenário. Até que isso seja alcançado, as porcentagens de conclusão não são informações relevantes. ## 6. Campos Obrigatórios como Substitutos para Disciplina de Dados **O Sinal:** A tela de criação de registro inclui doze campos obrigatórios, sendo que três deles ninguém sabe quem deveria conhecer seus valores. **O Que Acontece na Prática:** Os usuários selecionam o primeiro valor da lista para prosseguir. Os relatórios recebem dados completamente preenchidos, mas também completamente incorretos. **Prevenção:** A obrigatoriedade é imposta apenas a campos necessários para uma decisão no ponto em que são solicitados. Campos necessários em etapas posteriores do processo são tornados obrigatórios nessas etapas. ## 7. Construir Automação Antes que o Processo Seja Estável **O Sinal:** Existem três mecanismos de automação operando no mesmo objeto, e ninguém sabe a ordem de execução entre eles. **O Que Acontece na Prática:** Efeitos colaterais inesperados, *loops* de atualização e, principalmente, incapacidade de alterar um processo sem o medo de que algo se quebre. **Prevenção:** Execute um processo manual ou semi-manual por várias semanas antes de automatizá-lo. A automação fixa uma decisão — é importante que a decisão seja correta. ## 8. UAT Realizado por Quem Construiu **O Sinal:** Os roteiros de teste foram escritos pela mesma equipe que desenvolveu, e cobrem principalmente o caminho feliz. **O Que Acontece na Prática:** Os defeitos que chegam à produção são justamente os casos excepcionais — cancelamentos, estornos, cliente duplicado, usuário que saiu no meio de um processo. **Prevenção:** Os testes são realizados pelas pessoas que executam o processo, com dados semelhantes aos dados reais, e com responsabilidade definida para aprovar ou rejeitar. ## 9. Treinamento como Evento Único **O Sinal:** O plano de implementação inclui dois *workshops* na semana anterior ao *Go Live*, e nada depois disso. **O Que Acontece na Prática:** Os usuários aprendem telas, e não o processo, esquecem em duas semanas e recorrem a colegas ou a uma planilha Excel. A taxa de uso diminui gradualmente sem que ninguém perceba. **Prevenção:** Treinamento por função, o mais próximo possível do momento em que o funcionário realmente realizará a ação, com um ponto de suporte disponível nas primeiras semanas. ## 10. Falta de Proprietário Após o Go Live **O Sinal:** No plano do projeto, não há uma linha que descreva quem gerencia o sistema no terceiro mês. **O Que Acontece na Prática:** Solicitações de mudança se acumulam sem resposta, pequenos defeitos se transformam em trabalho alternativo e o sistema se torna obsoleto rapidamente. **Prevenção:** Defina a propriedade operacional, um mecanismo de recepção de solicitações e um ritmo de liberação regular *antes* do *Go Live*, e não depois. Em grandes organizações, isso geralmente é feito através de um modelo de governança estruturado, conforme descrito no [Guia de Implementação do Salesforce em Organizações Enterprise](/pt/insights/enterprise-salesforce-implementation). ## Custo da Correção por Estágio | Falha | Correção na Descoberta | Correção na Construção | Correção Após o Go Live | | --- | --- | --- | --- | | Modelo de dados incorreto | Alteração no diagrama | Reconstrução do objeto | Migração interna e retrabalho completo | | Ausência de Proprietário de Processo | Nomeação | Paralisações e decisões repetidas | Processo duplicado, mantido indefinidamente | | Dívida técnica do sistema legado | Filtragem da lista de campos | Limpeza antes do carregamento | Limpeza em sistema ativo | | Campos obrigatórios desnecessários | Decisão no planejamento da tela | Alteração na configuração | Limpeza de dados incorretos acumulados | | Ausência de Proprietário Operacional | Definição no plano | Recrutamento ou treinamento | Recuperação da confiança dos usuários | ## Exemplo Ilustrativo: Uma Companhia de Seguros de Médio Porte O cenário é hipotético e serve para ilustração. Uma companhia de seguros lançou o Salesforce para gerenciamento de agentes. Três meses depois, descobriu-se que a taxa de atualização dos registros dos agentes era baixa. A investigação não encontrou um único defeito técnico: foram encontradas três das falhas acima simultaneamente — campos obrigatórios desnecessários na tela de criação, ausência de um proprietário para o processo de recrutamento de agentes e treinamento realizado dois meses antes de os primeiros novos agentes entrarem no sistema. A correção não foi técnica. Seis campos obrigatórios foram removidos, um único proprietário de processo foi nomeado do departamento de operações, e o treinamento foi dividido em segmentos curtos enviados na semana em que cada grupo começou a trabalhar. A única mudança arquitetônica necessária foi adiar a obrigatoriedade de dois campos para uma fase posterior do processo. ## O Que Fazer Com Esta Lista Revise as dez falhas e marque para cada uma se o sinal precoce existe atualmente em seu projeto. Três ou mais sinais em um projeto que ainda não foi lançado são um motivo para uma breve pausa e correção, não para aceleração. Os mesmos três sinais em um sistema que já está no ar justificam um diagnóstico sistemático antes de adicionar novas funcionalidades sobre uma base instável. ### Perguntas e respostas **Qual erro na implementação Salesforce é o mais caro para corrigir?** Um erro no modelo de dados central. Alterar o objeto que contém o processo de negócios após o carregamento de dados e a construção de automações e relatórios exige migração interna, reescrita de lógica e reteste de permissões. Erros na interface do usuário, por outro lado, geralmente são corrigidos em dias. **O grande número de campos obrigatórios realmente prejudica a adoção?** Sim, e este é um dos mecanismos mais diretos. Cada campo obrigatório que não é necessário para uma decisão adiciona atrito a cada registro. O resultado conhecido são valores de preenchimento incorretos escolhidos para avançar na tela, que posteriormente contaminam exatamente os relatórios pelos quais o campo era exigido. É melhor tornar um campo obrigatório em uma fase posterior do processo, e não na fase de criação. **Quando geralmente se descobre que a implementação falhou?** Geralmente entre o segundo e o quarto mês após o Go Live, quando o suporte intensivo termina. Até então, os usuários contam com acompanhamento próximo e a gestão observa a atividade. O sinal real é uma queda contínua na atualização de registros, concomitantemente a um aumento no uso de arquivos Excel externos. **É possível corrigir um projeto Salesforce que já está no ar com deficiências?** Quase sempre, mas a ordem das operações é diferente de um projeto novo. Primeiro, estabilizamos o que está atrapalhando o trabalho diário, depois limpamos os dados, e só então voltamos a replanejar os processos. Tentar corrigir tudo simultaneamente enquanto o sistema está em uso geralmente prolonga a crise. **Quem é responsável por evitar esses erros — a organização ou o fornecedor?** A maioria deles é evitada apenas pela colaboração. Um fornecedor pode apontar um risco arquitetônico, mas não pode decidir quem é o proprietário do processo na organização, qual informação é considerada confiável ou quem está autorizado a abrir mão de um requisito. Projetos que falham quase sempre sofreram com a ausência de um agente organizacional com autoridade de decisão, e não com a ausência de conhecimento técnico. --- ## Serviços Salesforce: Como Escolher entre Análise, Implementação, Health Check e Suporte Contínuo URL: https://hpi.pro/pt/insights/salesforce-services-guide A maioria das organizações procura um fornecedor pedindo "implementação", mesmo quando o que realmente precisam é uma avaliação ou suporte. A escolha do tipo de serviço errado é a razão mais comum para projetos que resultam em algo que ninguém solicitou. Apresentamos um guia baseado em sintomas: o que solicitar em cada situação, qual será o resultado e quais são os sinais de alerta. ## O Problema Começa no Pedido, Não na Execução Quando uma organização procura um fornecedor Salesforce, o pedido inicial é quase sempre "uma proposta de implementação". Em muitos casos, este não é o pedido correto. Algumas organizações já possuem um sistema e o que falta é um diagnóstico; outras ainda não definiram o processo que desejam; e há aquelas cujo sistema funciona razoavelmente bem, mas lhes falta a manutenção contínua. Solicitar o tipo de serviço errado resulta em um projeto que entrega um produto irrelevante, e isso geralmente só é descoberto meses depois. Este guia mapeia os quatro tipos de serviço com base no sintoma que leva uma organização a buscar ajuda. ## Mapeamento Rápido por Sintoma | O que você diz | O que provavelmente é necessário | O principal produto final | | --- | --- | --- | | "Trabalhamos no Excel e precisamos organizar" | Análise e implementação em fases | Mapa de processos, modelo de dados, primeira fase em produção | | "Temos Salesforce, mas ninguém usa" | Health Check e plano de adoção | Relatório de descobertas priorizadas e ordem de correção | | "O sistema está lento e quebrado após anos" | Diagnóstico técnico e plano de dívida técnica | Mapeamento de dívidas, recomendação de refatoração ou reconstrução | | "O projeto está parado há seis meses" | Recuperação de projeto | Avaliação de status, decisão de continuação, plano de estabilização | | "Precisamos de alguém para fazer a manutenção contínua" | Suporte ou Managed Services | SLA, cadência de lançamentos, ponto de entrada para solicitações | | "O CEO quer saber se o Salesforce é adequado" | Consultoria breve, não um projeto | Parecer e recomendação de adequação | Esta tabela é suficiente para a maioria dos casos. O restante do artigo detalha exatamente o que solicitar em cada serviço. ## Serviço 1: Consultoria e Análise de Requisitos Quando solicitar: Quando o processo ainda não está claro, qual é a fonte da verdade e quais são os limites do projeto; ou quando há um conflito interno entre departamentos. O que deve estar no produto final: Um mapa de processos em nível de decisão, um modelo de dados principal, um modelo de permissões, um mapa de sistemas, critérios de aceitação e métricas base. Um produto que não inclua os primeiros cinco itens não é uma análise de requisitos, mas um resumo de reuniões. Escopo típico: Entre duas e oito semanas, dependendo do número de processos interdepartamentais. O que exatamente deve ser recebido e como identificar um bom consultor está detalhado no [Guia de Consultoria Salesforce](/pt/insights/salesforce-consulting-guide). ## Serviço 2: Implementação e Execução Quando solicitar: Quando a análise de requisitos foi concluída, os proprietários do processo são conhecidos e foi decidido o que entra na primeira fase. O que deve estar no contrato: Definição de fases, critérios de aceitação para cada fase, responsabilidade pela migração de dados, mecanismo de solicitação de mudança, período de garantia e plano de transferência de conhecimento. A ausência dos dois últimos é o fator mais comum para a dependência de longo prazo de um fornecedor. Sinal de alerta: Uma proposta que detalha o número de horas de desenvolvimento, mas não especifica o que é considerado "concluído". ## Serviço 3: Health Check e Diagnóstico Quando solicitar: Quando o sistema está em funcionamento, mas algo não está funcionando — baixa adoção, dados não confiáveis, desempenho ou incapacidade de fazer mudanças sem causar problemas. O que deve estar no produto final: Uma lista de descobertas com gravidade, impacto nos negócios, esforço de correção e ordem recomendada. Um relatório que lista cinquenta descobertas sem priorização não é útil; um relatório que diz "primeiro, corrija estes três e não mexa nos outros ainda" é um produto. Diferença importante: Um Health Check não é um projeto de correção. Ele visa permitir a decisão sobre o que corrigir e em que ordem. ## Serviço 4: Suporte, Manutenção e Managed Services Quando solicitar: Quando o sistema está em produção e não há uma equipe interna que possa assumir a manutenção contínua. O que deve ser definido: O que está incluído e o que não está. A distinção crítica é entre a correção de um bug, uma pequena alteração de configuração e o desenvolvimento de uma nova funcionalidade. Um contrato que agrupa os três em um "banco de horas" tende a explodir em um trimestre, porque o desenvolvimento de novas funcionalidades consome as horas destinadas ao suporte. Além disso: Tempos de resposta por gravidade, cadência regular de lançamentos e propriedade da documentação. ## Combinação Correta de Serviços A maioria das organizações não consome apenas um serviço, mas uma sequência. A sequência saudável se parece com isto: 1. Consultoria breve para decisão de adequação — dias, não semanas. 2. Análise de requisitos focada na primeira fase. 3. Implementação em fases. 4. Período de estabilização definido após a entrada em produção. 5. Suporte contínuo. 6. Health Check periódico, preferencialmente não realizado por quem construiu. O sexto ponto é o mais frequentemente ignorado, e é o mais barato. ## Exemplo Ilustrativo: Rede de Hotéis Boutique O cenário é hipotético e serve para ilustração. Uma rede com quatro hotéis procurou três fornecedores solicitando uma proposta para a implementação do Salesforce para gestão de eventos e solicitações de hóspedes. As duas primeiras propostas eram para uma implementação completa com escopo de muitos meses. O terceiro fornecedor fez uma única pergunta: quem define o que é um "evento" — o gerente de eventos de cada hotel ou a sede. A resposta foi que não havia uma definição compartilhada. Nesse caso, uma implementação completa teria criado quatro sistemas diferentes sob o mesmo nome. A rede solicitou, em vez disso, uma análise de requisitos breve, obteve uma definição acordada e um modelo de dados, e só então prosseguiu com a implementação — com um escopo menor do que o originalmente proposto. ## Sinais de Alerta ao Solicitar um Serviço - A proposta precifica horas, mas não define o produto final. - A mesma proposta inclui análise de requisitos e implementação em um único valor, sem um marco que permita a interrupção. - Não há período de garantia definido após a entrega. - Não há cláusula de transferência de conhecimento e documentação de propriedade da organização. - O fornecedor se recusa a fornecer um parecer arquitetônico antes da assinatura. As ferramentas para verificar o próprio fornecedor — e não apenas o serviço — são detalhadas no [Guia de Escolha de Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Do Pedido ao Documento Uma vez decidido qual serviço é necessário, o próximo passo é formulá-lo de forma que as propostas recebidas sejam comparáveis. A estrutura do documento de solicitação e a lista de perguntas a serem incluídas estão detalhadas no [Guia de RFP para Implementação Salesforce](/pt/insights/salesforce-rfp-guide), e as cláusulas que devem ser incluídas no próprio contrato estão detalhadas no [Guia de Contrato e SOW](/pt/insights/salesforce-sow-contract-clauses). ## Próximo Passo Antes de solicitar uma proposta, escreva em uma frase o sintoma — não a solução. "Não temos uma visão unificada do cliente entre vendas e serviços" leva a um pedido diferente de "Queremos Salesforce". Essa frase vale mais do que qualquer documento de requisitos que venha a ser escrito depois. ### Perguntas e respostas **Qual a diferença entre Análise e Discovery nas propostas de fornecedores Salesforce?** Na maioria dos fornecedores no Brasil, os termos são usados ​​de forma intercambiável. Por isso, é crucial analisar os resultados, e não apenas os títulos. Um Discovery profissional culmina em um modelo de dados essencial, um modelo de permissões, um mapa de sistemas e critérios de aceitação. Se a proposta promete "workshops de análise" sem detalhar um resultado mensurável, você está comprando horas, e não um documento estruturado. **É possível solicitar apenas um Health Check sem compromisso de continuidade?** Sim, e essa é a abordagem mais saudável. Um Health Check é um serviço independente cujo resultado é um relatório de descobertas priorizadas. Se um fornecedor condiciona a avaliação a um compromisso de implementação, um conflito de interesses surge: a mesma entidade diagnostica e vende a "cura". É preferível separar a avaliação da correção, pelo menos comercialmente. **Para uma organização pequena, é realmente necessário um serviço externo ou um Admin interno é suficiente?** Um Admin interno é suficiente para manutenção, pequenas alterações de configuração e suporte. No entanto, geralmente não é adequado para decisões que definem a arquitetura: modelo de dados fundamental, modelo de exposição ou demarcação entre sistemas. A regra prática é buscar suporte externo para decisões que seriam caras de mudar posteriormente, e manter o restante internamente. **O que são Managed Services para o ambiente Salesforce?** É um modelo em que um fornecedor externo é responsável pela manutenção contínua, processamento de solicitações de mudança, lançamentos periódicos e monitoramento, dentro de um escopo de horas acordado. É adequado para organizações que não possuem uma equipe interna dedicada, mas exige uma definição precisa do que está incluído: correção de falhas e pequenos desenvolvimentos têm custos completamente diferentes. **É possível contratar todos os serviços de um único fornecedor?** É possível e comum, mas é aconselhável separar, pelo menos, a fase de análise ou a auditoria periódica. A razão não é a desconfiança, mas sim um viés inerente: um fornecedor que implementou um sistema pode ter dificuldade em diagnosticar se uma decisão arquitetônica foi equivocada. Uma segunda opinião em pontos críticos de mudança é economicamente mais vantajosa do que o custo de uma correção tardia. --- ## Consultoria Salesforce: Quando contratar e o que esperar de resultados URL: https://hpi.pro/pt/insights/salesforce-consulting-guide Um consultor Salesforce é essencialmente necessário em pontos críticos onde um erro pode ser custoso – não para cada questão técnica. Este artigo define cinco gatilhos que justificam uma consultoria externa, diferencia um consultor, um arquiteto e um administrador, e detalha os entregáveis que, sem eles, você pagaria por reuniões em vez de decisões. ## Quando a Consultoria Externa Vale a Pena e Quando é um Desperdício Um consultor Salesforce não é necessário para responder a perguntas que podem ser respondidas com documentação ou pelo conhecimento de um administrador experiente. Ele é necessário em pontos onde a decisão é cara para ser alterada, transversal a departamentos, ou onde não há uma parte neutra na organização que possa tomar a decisão. Cinco gatilhos justificam a consultoria externa: 1. **Decisão de Plataforma** — Se o Salesforce é adequado, e em relação a quais alternativas. 2. **Decisão Arquitetural Difícil de Reverter** — Modelo de dados central, organização única versus múltipla, fonte da verdade. 3. **Conflito Interno entre Unidades** que não possui um decisor natural. 4. **Projeto Paralisado** onde é necessário um interveniente politicamente descomprometido para identificar o problema. 5. **Situação Pré-Compromisso Comercial Significativo** — Antes de assinar uma proposta de milhões, uma opinião independente é relativamente barata. O que não justifica uma consultoria: adição de campos, construção de relatórios, questões operacionais diárias. Estas são responsabilidades de um administrador, e a consultoria que se envolve nessas tarefas rapidamente se torna um reforço de pessoal caro. ## Três Papéis Frequentemente Confundidos | Papel | Pergunta que Responde | Horizonte | Quando Mal Contratado, Resulta em... | | --- | --- | --- | --- | | Consultor | O que fazer e em que ordem | Meses a Anos | Estratégia em vez de solução para o problema | | Arquiteto | Como implementar sem criar dívida técnica | Projeto e Sistema | Projeto detalhado para um problema não definido | | Administrador | Como operar e manter no dia-a-dia | Semanas | Solução pontual que fixa uma decisão maior | A falha comum é a terceira linha: uma decisão arquitetural que é efetivamente tomada por um administrador, porque surgiu como uma pequena solicitação. ## O Que é Essencial Obter de um Processo de Consultoria Um processo de consultoria que termina com uma apresentação de resumo é um processo inoperável. Os entregáveis que devem ser exigidos por escrito, antes da assinatura: - **Documento de Decisões** — Para cada decisão: a questão, as alternativas consideradas, a recomendação, a justificativa e a implicação se a decisão for diferente. - **Premissas e Dependências** — O que o consultor assumiu sem verificar, e o que acontecerá se a premissa estiver errada. - **Mapa de Riscos** focado na organização, não uma lista genérica. - **Recomendação de Curso de Ação** com dependências, não uma lista de desejos. - **O Que Não Fazer** — A recomendação negativa é geralmente a parte mais valiosa, e quase sempre está ausente. A última seção é um bom critério de qualidade: um consultor que consegue dizer "não construa isso agora" vende uma decisão, não horas. ## Como Avaliar um Consultor Antes de Contratar As perguntas a fazer não são sobre certificações, mas sobre a forma de pensar: - Descreva uma decisão arquitetural que você recomendou e da qual se arrependeu. O que aprendeu? - Em que caso você recomendaria não usar Salesforce? - Como você decide entre configuração e desenvolvimento? - O que você pede à organização para que a consultoria seja bem-sucedida, e o que acontece se você não conseguir isso? - Quem na sua equipe continua a manter o produto depois que você sai? Uma gama mais ampla de perguntas para avaliar um fornecedor está disponível no [Guia de Perguntas Antes de Escolher um Integrador Salesforce](/pt/insights/questions-before-choosing-salesforce-integrator). ## Conflito de Interesses — Nem Sempre Ruim, Sempre Exige Conhecimento Um fornecedor que consulta e depois implementa não é necessariamente problemático; às vezes, esta é a maneira mais eficiente, pois o conhecimento não se perde na transferência. O problema começa quando a recomendação afeta o escopo do trabalho da mesma parte e não há um mecanismo de equilíbrio. Três mecanismos simples de equilíbrio: - Precificação separada para a fase de consultoria, não condicionada à continuidade. - Direito da organização de abrir uma licitação após a fase de consultoria, com os entregáveis em sua posse. - Exigência de que cada recomendação seja apresentada com uma alternativa mais barata e a razão pela qual foi rejeitada. O terceiro é o mais eficaz e também o que gera as conversas mais úteis. ## Exemplo Ilustrativo: Empresa de Infraestrutura de Capital Aberto O cenário é hipotético e serve para ilustração. Uma empresa de infraestrutura considerou um grande projeto de CRM para gerenciar consultas públicas e de autoridades. Dois fornecedores propuseram uma arquitetura com uma organização Salesforce separada para cada um dos dois públicos, justificando com a segregação de informações regulatórias. A consultoria externa contratada examinou a própria exigência regulatória e descobriu que ela exigia segregação de acesso, não segregação de sistemas. A conclusão mudou completamente o quadro comercial: uma única organização com um modelo de exposição cuidadoso em vez de dois ambientes que exigiriam sincronização e manutenção duplicada. O entregável de maior valor no processo não foi uma recomendação sobre o que construir, mas a prova de que a premissa fundamental das duas propostas não havia sido verificada. ## Como Isso se Conecta à Decisão Comercial Uma boa opinião de consultoria muda o que você pede aos fornecedores, e, portanto, deve vir antes das propostas e não depois. A partir daí, a decisão passa para dois níveis: a escolha do modelo de precificação adequado ao nível de incerteza restante, conforme detalhado no [Guia de Precificação de Projeto Salesforce](/pt/insights/salesforce-project-pricing-models), e a comparação das propostas que serão recebidas, conforme detalhado no [Guia de Comparação de Propostas](/pt/insights/compare-salesforce-proposals). Os critérios para avaliar a empresa que realizará o trabalho efetivamente estão reunidos no [Guia de Escolha de Empresa de Implementação Salesforce](/pt/insights/choose-salesforce-implementation-company). ## Teste Rápido Antes de Contratar uma Consultoria Responda a três perguntas: Qual decisão você precisa tomar, quem na organização a aprovará, e o que acontecerá se você a tomar de forma errada. Se a resposta à terceira pergunta for "vamos corrigir depois de forma barata" — provavelmente você não precisa de um consultor. Se a resposta for "teremos que reconstruir" — este é o ponto exato onde a consultoria externa se paga. ### Perguntas e respostas **Qual a diferença entre um Consultor Salesforce e um Arquiteto Salesforce?** O consultor foca no 'o que' e na sequência correta das ações, incluindo considerações de negócios, organizacionais e comerciais. O arquiteto, por sua vez, aborda o 'como' implementar a plataforma de forma eficaz: modelo de dados, exposição, limites do sistema e integridade técnica. Em projetos menores, uma única pessoa pode assumir ambos os papéis, mas para decisões de grande impacto, a perspectiva dupla é preferível. **Qual a duração ideal de um processo de consultoria Salesforce?** A consultoria para uma decisão de adequação geralmente dura poucos dias. Uma consultoria que acompanha uma análise pode se estender por semanas. Se a consultoria se prolonga por meses sem resultados decisivos, ela tende a ser mais um reforço de equipe do que uma consultoria, e deve ser precificada e gerenciada como tal. **Um consultor externo pode colaborar com uma equipe interna de Salesforce?** Sim, e esse é frequentemente o modelo mais eficiente. A condição primordial é uma clara divisão de responsabilidades: o que o consultor decide, o que ele apenas recomenda e quem na organização aprova. Sem essa clareza, pode surgir tensão, com a equipe interna defendendo o que construiu e o consultor comunicando-se diretamente com a direção. **O que fazer quando o consultor recomenda uma solução à qual a equipe interna se opõe?** É fundamental exigir que a recomendação seja apresentada com as alternativas consideradas e os critérios de decisão, e não como uma conclusão final. A oposição da equipe interna geralmente se baseia em conhecimento contextual que o consultor pode não ter acesso. Se, após a apresentação das alternativas, ainda houver divergência, a decisão caberá ao responsável pelo risco, e não necessariamente a quem tem razão técnica. **Qual o custo de uma consultoria Salesforce no Brasil?** O preço varia consideravelmente entre os fornecedores e é determinado pelo volume de horas, nível de senioridade e pela responsabilidade que o consultor assume em relação ao resultado. O mais importante é comparar o custo total para se chegar a uma decisão, e não apenas a tarifa horária: uma consultoria com custo horário mais alto que entrega um documento de decisões em duas semanas pode ser mais econômica do que uma consultoria mais barata que se arrasta por dois meses. --- ## Prontidão para o Agentforce: Checklist Organizacional de Dados, Permissões e Processos URL: https://hpi.pro/pt/insights/agentforce-salesforce-ai-guide Antes de construir seu primeiro agente, é crucial responder a uma pergunta mais simples: sua organização está realmente pronta? Este guia apresenta uma avaliação de prontidão em cinco pilares – processo, dados, conhecimento, permissões e operações – com uma pontuação para cada pilar, um limite mínimo para pilotos e como abordar as lacunas identificadas. ## A Resposta Curta A avaliação de prontidão para o Agentforce leva poucas semanas; um piloto que falha custa meses e confiança interna. Por isso, vale a pena responder a cinco perguntas antecipadamente: existe um processo definido com um responsável, os dados nos quais o agente se baseará são confiáveis, existe uma base de conhecimento mantida, o modelo de permissões é claro e há quem opere o agente após o lançamento. A avaliação não é uma questão de sim ou não. Ela gera uma pontuação para cada eixo e um mapa de lacunas, permitindo uma decisão mais precisa: iniciar, reduzir o escopo ou adiar e resolver uma lacuna específica primeiro. A estrutura de decisão sobre a adequação do caso de uso aparece em [Agentforce para Empresas](/pt/insights/agentforce-for-enterprises). ## Os Cinco Eixos de Prontidão | Eixo | A Pergunta Crucial | Sinal de Fraqueza | Limite Mínimo para Piloto | |---|---|---|---| | Processo | O processo é definido e tem um responsável nomeado? | Cada equipe executa de forma diferente e não há documentação | Um processo documentado com um Proprietário e volume conhecido | | Dados | Os campos que o agente lerá são confiáveis? | Campos vazios ou preenchidos com texto livre | 90% de completude nos campos críticos para o processo | | Conhecimento | Existe uma fonte aprovada para as respostas? | Artigos antigos ou contraditórios | 20 artigos atualizados para os cenários comuns | | Permissões | É claro o que cada usuário pode ver e fazer? | Permissões amplas e não controladas | Mapeamento de Perfis e Conjuntos de Permissões para o processo | | Operação | Quem monitora, corrige e aprova mudanças? | Não há responsável após o lançamento | Proprietário operacional e rotina de revisão semanal | ## Eixo 1: O Processo A falha mais comum não é tecnológica. Organizações escolhem um processo sem um responsável, e então não há quem decida sobre as questões que surgem durante a construção: o que acontece em uma exceção, quando escalar, o que é considerada uma resposta correta. Sem decisão, a equipe técnica inventa regras e o negócio verifica de acordo com outra expectativa. Teste prático: solicitar a descrição do processo por escrito de quatro pessoas que o executam. Se forem recebidas quatro versões substancialmente diferentes, o processo não está maduro para a automação de um agente – ele está pronto para documentação e acordo prévios. Também é necessário volume. Um processo que ocorre dez vezes por mês não justificará o custo de construção e manutenção, mesmo que seja incômodo. Um bom candidato é um processo com volume significativo, alta repetitividade e variação na formulação da solicitação – exatamente onde as regras rígidas são quebradas. ## Eixo 2: Os Dados Não é necessária uma qualidade de dados perfeita em toda a Org. É exigida qualidade nos campos que o agente lerá ou atualizará no processo selecionado. O teste é restrito e mensurável: pega-se a lista de campos relevantes e mede-se a completude, consistência de valores e duplicidades nos registros relacionados. Três testes que fornecem uma resposta rápida: porcentagem de campos críticos preenchidos, número de registros duplicados no objeto principal e porcentagem de casos em que as informações necessárias vêm de um sistema externo e não do Salesforce. O terceiro teste é o que surpreende – ele revela uma dependência de integração não orçada. Texto livre é um sinal vermelho especial. Quando informações essenciais residem em um campo de notas, o agente precisará inferi-las, e é exatamente aí que surgem erros difíceis de detectar. A ordem recomendada para lidar com lacunas de dados é detalhada em [Métricas de Qualidade de Dados no Salesforce](/pt/insights/salesforce-data-quality-metrics). ## Eixo 3: O Conhecimento O conhecimento é avaliado não pela quantidade, mas pela cobertura e validade. Pega-se as vinte solicitações mais comuns e verifica-se para cada uma: se há um artigo aprovado, quando foi atualizado e quem é o proprietário. A cobertura de metade dos cenários com artigos atualizados é preferível à cobertura total com artigos antigos. Um sinal de fraqueza fácil de ignorar: artigos escritos apenas para o público interno e usados simultaneamente para respostas ao cliente. Eles contêm formulações, preços ou exceções que não devem ser expostos externamente, e a separação deve ser feita antes da conexão. ## Eixo 4: As Permissões O agente atua em nome de um usuário, e, portanto, o modelo de permissões existente se torna o modelo de segurança da IA. Se as permissões forem amplas e não controladas hoje, o agente aumentará a exposição, não a criará. O teste examina três coisas: quem pode ler os dados no processo, quais ações de escrita são necessárias e quem aprova uma ação sensível. Para cada ação que o agente realizará, é preciso definir se ela é reversível. Uma ação irreversível — crédito financeiro, fechamento de caso, envio de mensagem ao cliente — exige um ponto de aprovação humana na primeira etapa e, portanto, afeta o planejamento do processo e não apenas as configurações. O planejamento dos pontos de aprovação por risco é detalhado em [Human-in-the-Loop no Agentforce](/pt/insights/agentforce-human-in-the-loop). ## Eixo 5: A Operação Um agente não é um projeto com data de término. É um componente que exige monitoramento de traces, tratamento de falhas, atualização de conteúdo e controle de custos. Uma organização que não tiver quem faça isso – mesmo que em tempo parcial – verá uma diminuição gradual na qualidade em um trimestre. O mínimo: um proprietário operacional nomeado, uma rotina semanal de revisão de chamadas que falharam, um processo de mudança acordado para atualizar as instruções e um orçamento mensal monitorado. Se nenhum dos quatro existir, a lacuna neste eixo é maior do que parece no início. ## Traduzindo a Pontuação em Decisão | Situação | Significado | Ação Recomendada | |---|---|---| | Todos os eixos no limite ou acima | Prontidão total | Piloto em um processo com critérios de Go/No-Go | | Fraqueza apenas na operação | Pode ser compensada com acompanhamento | Piloto com acompanhamento externo e construção de capacidade interna em paralelo | | Fraqueza apenas no conhecimento | Lacuna de conteúdo específica | Quatro a seis semanas de treinamento de Conhecimento, e então piloto | | Fraqueza em dados ou permissões | Risco significativo | Não iniciar o agente; fechar a lacuna como um projeto separado | | Fraqueza em três ou mais eixos | A organização não está madura | Escolher um subprocesso mais restrito e reavaliar | ## Cenário: Organização Financeira Descobre que o Processo Incorreto Foi Escolhido Uma organização financeira solicitou um agente para lidar com solicitações de alteração de dados do cliente. Na avaliação de prontidão, verificou-se que o processo passava por dois sistemas externos, que toda alteração exigia aprovação regulatória e que o volume mensal era modesto. Os eixos de permissões e dados receberam pontuação baixa. Na mesma avaliação, surgiu outro processo que ninguém havia considerado: responder a perguntas de status sobre solicitações existentes. Ele se baseava em um único campo confiável no Salesforce, não incluía ação de gravação e seu volume era oito vezes maior. O piloto foi transferido para esse processo. O resultado prático da avaliação não foi "prontos ou não-prontos", mas a substituição do candidato. Essa é a principal contribuição de uma avaliação de prontidão – ela é barata o suficiente para ser executada em três candidatos e escolher aquele com as menores dependências. ## Checklist de Prontidão - ☐ Um único processo candidato com um proprietário nomeado foi selecionado - ☐ O volume mensal e a taxa de repetitividade foram medidos - ☐ A integridade dos campos críticos para o processo foi verificada - ☐ Duplicidades no objeto central foram verificadas - ☐ Dependências de sistemas externos foram identificadas - ☐ A cobertura de Conhecimento para as vinte solicitações mais comuns foi mapeada - ☐ Conteúdo interno foi separado do conteúdo permitido para o cliente - ☐ Permissões de leitura e gravação para o processo foram mapeadas - ☐ Ações reversíveis versus irreversíveis foram classificadas - ☐ Um proprietário operacional e uma rotina de revisão pós-lançamento foram definidos Quando um fator externo for necessário para realizar a avaliação e traduzi-la em um Roadmap, o [serviço Agentforce e IA](/pt/agentforce-ai) é o caminho prático a seguir. ### Perguntas e respostas **Quanto tempo leva uma avaliação de prontidão séria?** Entre duas e quatro semanas em uma organização de médio porte. A primeira semana dedica-se ao mapeamento do processo candidato e entrevistas, a segunda para amostragem de dados e conhecimento, e a terceira para verificação de permissões e formulação de lacunas. Mais de um mês geralmente significa que um escopo de avaliação muito amplo foi escolhido. **É possível iniciar um piloto com uma pontuação de prontidão média?** Sim, desde que a lacuna conhecida não esteja nos pilares de dados ou permissões. Uma fraqueza no pilar operacional pode ser compensada com suporte próximo nos primeiros meses, mas um repositório de conhecimento não mantido ou um modelo de permissões pouco claro derrubará o piloto, independentemente da qualidade da construção. **Quem deve liderar a avaliação de prontidão – TI ou o negócio?** O proprietário do processo de negócio lidera, pois é ele quem precisará justificar o resultado. TI e segurança da informação fornecem os pilares de dados e permissões. Uma avaliação liderada apenas por TI tende a examinar as capacidades da plataforma e não se o processo em si é adequado para automação. **O que fazer quando a avaliação revela que a organização não está pronta?** Transformar cada lacuna em um item do Roadmap com proprietário e data, e selecionar um processo candidato alternativo que exija menos dependências. Na maioria dos casos, há um sub-processo específico que atende aos limites, e ele se torna o piloto enquanto as grandes lacunas são resolvidas em paralelo. **O licenciamento do Agentforce deve ser adquirido antes da avaliação?** Não. A avaliação de prontidão lida com o processo, dados e permissões – todos os quais existem independentemente do licenciamento. A aquisição antes de saber qual caso de uso está maduro leva a licenças não utilizadas e à necessidade de demonstrar resultados muito rapidamente. --- ## Salesforce Health Check: O que avaliar, quando e o que esperar dos resultados URL: https://hpi.pro/pt/insights/salesforce-health-check-guide Um Health Check não é uma pesquisa de opinião sobre o sistema, mas um diagnóstico baseado em evidências: metadados, logs, dados de uso e observação de usuários reais. Este guia detalha os sete pilares de avaliação, a metodologia de classificação de criticidade e a estrutura do produto que permite decisões orçamentárias estratégicas. ## A Resposta Concisa Um Health Check é um diagnóstico baseado em evidências que dura de duas a seis semanas, culminando em três entregas: uma lista de descobertas classificadas por gravidade, um plano de "Ganhos Rápidos" (Quick Wins) para 30 dias e um Roteiro para investimentos de longo prazo. O que o torna valioso não é a amplitude da varredura, mas a evidência anexada a cada descoberta — um número, log ou gravação de tela — pois sem ela a discussão se torna uma disputa de opiniões. ## Os Sete Eixos de Avaliação | Eixo | O Que é Avaliado na Prática | Fonte da Evidência | | --- | --- | --- | | Processo e Adoção | Se o processo documentado é o processo executado | Histórico de Login, Uso de Campos, Observação de Usuários | | Modelo de Dados | Objetos desnecessários, campos sem uso, relacionamentos duplicados | Uso de Campos, Metadata API, Consultas de Amostragem | | Automações | Sobreposições entre Flows, Triggers e Process Builder antigo | Metadata, Debug Logs, Análise da Ordem de Execução | | Permissões e Segurança | Perfis inflados, regras de compartilhamento (Sharing Rules) conflitantes, acesso excessivo | Security Health Check, Atribuições de Permission Set | | Integrações | Limites de API, falhas recorrentes, tratamento de erros | Event Monitoring, Logs de Middleware | | Performance | Tempos de carregamento, consultas pesadas, Batches travados | Lightning Usage App, Apex Jobs | | Custo e Licenciamento | Licenças não utilizadas, Armazenamento, serviços duplicados | Relatório de Licenciamento, Fatura vs. Uso Real | ## Como Classificar a Gravidade Uma classificação arbitrária torna o relatório inútil. O método que funciona: cada descoberta recebe duas pontuações de 1 a 5 — Impacto (o que acontece com o negócio se não for resolvido) e Frequência (quantas vezes por mês ocorre). O produto dessas pontuações determina a prioridade, e não a percepção de quão "feio" é o código. Uma descoberta com pontuação igual ou superior a 20 é tratada imediatamente; 12–19 é planejada para o próximo trimestre; abaixo de 12 é registrada e não tratada, a menos que seja de baixo custo para corrigir durante outro trabalho. A separação mais importante no relatório é entre sintoma e causa raiz. "Usuários não preenchem o campo de motivo de perda" é um sintoma; a causa raiz pode ser que o campo não é obrigatório, que os valores não são relevantes para a área, ou que ninguém analisa o relatório baseado nele. Corrigir apenas o sintoma — tornando o campo obrigatório — produz dados ruins em vez de dados ausentes. ## O Que é Entregue no Final Uma entrega adequada inclui um documento de descobertas com evidências para cada item, uma matriz de gravidade, um plano de 30 dias onde cada item é executável sem uma mudança arquitetônica, e um Roteiro para um a dois trimestres com estimativas de esforço aproximadas. Além disso, é necessário um Registro de Decisões de três a cinco deliberações que a organização deve tomar — por exemplo, se deve unificar duas unidades de negócio em uma única Org — pois sem elas o Roteiro permanece imprevisível. Para mais detalhes sobre as decisões pós-diagnóstico, consulte [Reconstruir vs. Refatorar](/pt/insights/salesforce-rebuild-vs-refactor) e [Priorização de Débito Técnico](/pt/insights/salesforce-technical-debt-prioritization). ## Riscos Comuns e Ações Preventivas O primeiro risco é um relatório que é lido como uma lista de acusações. Se as descobertas são formuladas como críticas à equipe interna, a organização se defende e não corrige. A formulação correta foca no estado atual e nos custos futuros, não na responsabilidade histórica. O segundo risco é uma avaliação que termina sem um responsável. Cada descoberta deve ter o nome de uma pessoa e uma data, caso contrário o relatório se junta a uma pasta que ninguém abre. O terceiro risco é a amplitude excessiva: um diagnóstico que tenta cobrir sete eixos com profundidade total em duas semanas gera uma imagem superficial em todos eles. É preferível escolher três eixos para profundidade e marcar os restantes para a próxima rodada. ## Como Medir o Sucesso Um Health Check é bem-sucedido se, em 60 dias, pelo menos 70% dos itens do plano de 30 dias foram executados, se a administração aprovou orçamento para pelo menos um investimento de longo prazo, e se dois KPIs operacionais — por exemplo, a taxa de falhas de integração ou o tempo de carregamento de uma tela principal — melhoraram de forma mensurável em relação à linha de base estabelecida no início do diagnóstico. ## Próximo Passo Antes de solicitar uma avaliação, é aconselhável preparar três coisas: uma lista dos processos de negócio críticos, acesso de leitura a logs e metadados, e os nomes de três usuários reais cujo trabalho pode ser observado. Essas três ações encurtam o diagnóstico em cerca de uma semana e melhoram significativamente a qualidade das descobertas. ### Perguntas e respostas **Quanto tempo leva um Health Check?** Para uma organização de médio porte com uma única Org: Duas a três semanas, incluindo uma semana para coleta de evidências e observação, e uma semana para análise e redação. Uma Org com múltiplas unidades de negócio e dezenas de integrações exigirá de quatro a seis semanas. Além disso, não é mais um diagnóstico, mas um projeto. **Precisamos conceder acesso total de Administrador à parte externa?** Não. Para a maioria das verificações, 'Visualizar Configurações e Configuração', 'Visualizar Todos os Dados' (de forma limitada) e acesso de leitura aos logs são suficientes. Se houver dados sensíveis, trabalhamos em um Sandbox atualizado e complementamos na Produção apenas as métricas que não podem ser replicadas. **Qual a diferença entre um Health Check e a ferramenta nativa Security Health Check?** A ferramenta do Salesforce verifica as configurações de segurança em relação a uma linha de base e retorna uma pontuação. Um diagnóstico completo cobre também processos, modelo de dados, automações, integrações, adoção e custo — e a ferramenta nativa é apenas uma de suas entradas. **O que fazer com um achado que exige uma reescrita fundamental?** Não o inclua no plano de 'Quick Wins'. Marque-o como uma decisão de investimento separada com uma estimativa de esforço, risco de não agir e uma data-alvo para reavaliação, e priorize-o separadamente do tratamento dos achados urgentes. **Um Health Check se justifica quando o sistema está funcionando?** Sim, em duas situações: antes de uma grande decisão de investimento, para saber sobre o que se está construindo; e após dois a três anos de mudanças cumulativas, quando ninguém mais tem uma visão completa das automações e permissões. --- ## Trademark Disclosure Salesforce® and Agentforce® are trademarks of Salesforce, Inc. HPI Pro is an independent consultancy and does not present itself as an official Salesforce partner unless explicitly stated on the site.