Mapeamento de stakeholder em projeto Revenue Cloud: por que isso decide o sucesso da entrega
A matriz de poder e interesse aplicada a implementações reais de Agentforce Revenue Management e CPQ
Projetos de Revenue Cloud travam com mais frequência por falha de mapeamento de stakeholder do que por problema técnico. O artigo detalha os quatro tipos de stakeholder, a grade poder x interesse e os três modos de comunicação aplicados ao dia a dia de projeto Salesforce.
Toda vez que um projeto de Revenue Cloud trava, a causa raiz raramente é técnica. É mapa de stakeholder mal feito. Já vi implementação de Agentforce Revenue Management com Pricing Procedure impecável, Product Catalog bem modelado, e o projeto quase morrer porque ninguém envolveu o time de billing operacional até a reta final de UAT. Resultado: duas semanas de retrabalho porque a regra de proration que "todo mundo sabia" nunca tinha sido validada com quem realmente fatura.
Stakeholder, na prática de projeto, é qualquer pessoa ou grupo que pode aprovar, bloquear, influenciar ou simplesmente sofrer o impacto do que você está entregando. Parece óbvio escrito assim, mas a maioria dos arquitetos e PMs trata isso como formalidade de kickoff, preenche um slide de RACI, e segue em frente sem revisitar.
Os quatro tipos que valem a pena diferenciar
Dá para organizar stakeholder em dois eixos que se cruzam:
- Interno x Externo: interno é quem está dentro da organização e participa da entrega (time de projeto, gerência, diretoria, dono de processo). Externo é quem está fora mas afeta ou é afetado (cliente, fornecedor, parceiro de integração, regulador).
- Primário x Secundário: primário sofre impacto direto e significativo (usuário final do sistema, time que vai operar o processo novo). Secundário tem interesse indireto (imprensa, associação de categoria, comunidade ao redor de uma obra de infraestrutura).
Essas categorias se misturam o tempo todo. Em uma migração de CPQ legado para Revenue Cloud, o time de operações comerciais é interno e primário (vai operar o novo Pricing Procedure todo dia), enquanto o fornecedor de um middleware de integração via MuleSoft é externo e pode ser primário ou secundário dependendo de quanto a integração muda.
A grade poder x interesse, aplicada a projeto Salesforce de verdade
A ferramenta mais prática aqui é a matriz de poder e interesse. Cruza quanto de autoridade o stakeholder tem com quanto de interesse ele demonstra no resultado:
- Alto poder, alto interesse: gerenciar de perto, consultar com frequência, trazer para decisões-chave. É o VP de vendas que vai aprovar a nova régua de aprovação em Flow Approval Process para descontos acima de X%.
- Alto poder, baixo interesse: manter satisfeito, com atualizações pontuais e acionamento quando a autoridade dele é necessária. Diretoria financeira que só quer saber se o billing vai fechar no prazo.
- Baixo poder, alto interesse: manter informado, com espaço para feedback. Time de suporte que vai lidar com os tickets gerados pelo novo processo.
- Baixo poder, baixo interesse: monitorar, sem sobrecarregar de informação. Áreas adjacentes que só precisam saber que algo mudou.
O erro clássico é tratar essa grade como hierarquia de importância. Não é. Um analista de operações com zero poder formal pode ser o único que sabe que aquele campo customizado alimenta um relatório que o conselho usa. Ignorar isso porque ele não está no quadrante certo é o tipo de decisão que explode em produção.
Comunicação por nível de participação
Dá para organizar a comunicação em três modos: informar, consultar, colaborar. Informar é update assíncrono, sem reunião, sem bloquear ninguém. Consultar é pedir insumo específico, com contexto suficiente e prazo claro, seja um líder de área revisando proposta de forma assíncrona ou um comitê que exige material formal. Colaborar é trabalho ombro a ombro, geralmente com canal dedicado, threads separando assunto, e reunião síncrona quando a discussão escrita começa a travar.
No dia a dia de um projeto Salesforce, isso se traduz em canal de Slack por workstream, canvas compartilhado com briefing e status, e Slack Connect quando o stakeholder está em outra organização, como o fornecedor de integração ou o parceiro de implementação.
Arquiteto de solução vive dizendo que requisito mal levantado é a maior causa de retrabalho, mas o requisito mal levantado quase sempre tem uma origem: stakeholder errado na sala, ou stakeholder certo ouvido tarde demais. Isso vale tanto para configurar uma Sharing Rule em Experience Cloud quanto para desenhar a régua de aprovação de desconto em Revenue Cloud. Mapear stakeholder não é exercício de gestão de projeto genérico, é insumo direto de arquitetura: define quem valida regra de negócio, quem aprova modelo de dados, quem vai operar o que você construiu.
Depois de alguns projetos de Revenue Cloud e Agentforce Revenue Management na bagagem, fico convencido de que a disciplina de mapear e revisitar stakeholder é tão arquitetura quanto desenhar Product Catalog ou Pricing Procedure. A plataforma você ajusta com Flow, com Apex, com configuração. Stakeholder mal mapeado vira dívida que nenhum refactor técnico resolve sozinho.
- No kickoff, monte a lista de stakeholder olhando para quem executa, quem aprova, quem fornece recurso ou expertise, quem usa o resultado e quem pode levantar objeção que muda escopo ou prazo.
- Classifique cada um na grade poder x interesse e defina o ritmo de comunicação antes de começar a construir, não depois que o problema aparece.
- Revisite essa lista em cada fase relevante do projeto (discovery, build, UAT, go-live). Stakeholder de baixo interesse na fase de levantamento pode virar crítico na fase de operação.
- Use canal dedicado no Slack por workstream, canvas para manter briefing e status acessíveis de forma assíncrona, e Slack Connect quando o stakeholder está fora da organização, como parceiro de integração ou fornecedor.
- Não confunda "baixo poder formal" com "pode ser ignorado". Quem opera o processo todo dia geralmente enxerga exceção de regra de negócio que ninguém no comitê vai ver.
- Cuidado com stakeholder que só aparece em UAT. Se o time de billing operacional, suporte ou compliance não foi ouvido antes, o retrabalho em cima de Pricing Procedure ou Flow Approval Process já construído custa caro.
- A grade poder x interesse é ferramenta de priorização de atenção, não de hierarquia de valor. Trate como mapa dinâmico, não como documento de kickoff engavetado.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.