O vendedor novo entra na segunda-feira. O dono quer que ele veja a carteira dele, o histórico de compra dos clientes e as propostas em aberto — e não quer que ele veja a margem de nenhum produto, nem a carteira do colega da região vizinha, nem a tela de usuários.
Aí vem a pergunta: "qual perfil eu dou para ele?"
A pergunta parece uma só. São três. E a que mais dói — a da margem — não sai de perfil nenhum.
Três perguntas que a PME trata como uma
Quem diz "permissão" está misturando três coisas que se comportam de forma diferente:
- O que você pode fazer. Registrar conversa, editar conta, abrir painel gerencial. É verbo.
- Sobre quem você pode fazer. O vendedor registra conversas — só nos clientes dele. É recorte de gente, não de botão.
- O que aparece dentro de um registro que você já tem direito de abrir. Não é uma tela a menos: é uma coluna a menos, na tela que ele precisa usar.
Os três são independentes. Dois vendedores com a mesma função têm carteiras diferentes (eixo 2 muda, eixo 1 não). Gerente e dono veem a carteira inteira, mas talvez só um deva ver margem (eixo 3 muda, eixo 2 não). Por isso o organograma de perfis — "Vendedor", "Vendedor Sênior", "Gerente" — trava: tem uma dimensão, e o problema tem três.
Eixo 1: o que a pessoa pode fazer
O mais bem resolvido em qualquer sistema sério: existe uma lista de chaves — ver contas, gerenciar oportunidades, ver funil, ver financeiro, gerenciar usuários — e cada papel carrega um conjunto delas.
O erro não é técnico, é de desenho: PME cria perfil demais. "Vendedor interno", "Vendedor externo", "Vendedor externo que também cobra". Três meses depois ninguém sabe qual é qual, e toda dúvida vira copiar o perfil do fulano — que já estava errado. Perfil descreve cargo, não pessoa: se você precisa de um para uma pessoa só, o que você quer é ajuste nos outros dois eixos.
Eixo 2: sobre quem a pessoa pode fazer
Aqui mora a confusão mais cara da PME que tem ERP.
O ERP grava um vendedor em cada pedido, em cada nota. É tentador usar esse campo para decidir acesso: "quem vendeu, vê". Não funciona. O cliente foi atendido em 2019 pelo vendedor que saiu da empresa; a nota diz o nome dele até hoje; a conta é do João. Se o acesso seguir a transação, o João não vê o próprio cliente e um ex-funcionário aparece como dono. Vendedor da transação é fato histórico, responsável pela conta é decisão atual — só o segundo governa acesso.
O segundo ponto: filtro de tela não é permissão. O seletor de empresa ou vendedor no topo serve para o gerente olhar um pedaço de cada vez. O que ele nunca pode fazer é servir de porta: se o vendedor o troca para o nome do colega, a resposta correta é vazio. Filtro só estreita dentro do permitido. Se amplia, não é filtro — é falha de segurança com aparência de recurso.
Eixo 3: o que aparece dentro do registro
Este é o que faz o dono adiar o projeto inteiro. A conta 360 é o que dá valor ao vendedor: histórico, pedidos, propostas, o que o cliente compra e o que parou de comprar. Mas dois números moram no mesmo lugar e não podem sair: custo e margem.
A solução não é do mesmo tipo dos outros dois eixos. Não adianta um papel "Vendedor sem margem": o problema não é qual tela ele abre, é o que vem dentro da tela que ele precisa abrir. Isso é permissão de campo, e tem uma exigência que quase ninguém verifica na hora de comprar: quando o campo é negado, ele não pode ser enviado ao navegador. Esconder no front é maquiagem — o dado saiu do servidor e está a um F12 de distância. Ou o servidor não manda, ou você não tem controle: tem cortina.
O quarto eixo, que nem é controle de acesso
Tem um caso que os três eixos não cobrem, e é o mais comum na vida do vendedor externo. Ele tem direito de ver margem — precisa dela para negociar. Só que está na frente do comprador, com o notebook virado, mostrando o histórico de compra. E a margem está na mesma tela.
Isso não é permissão: o usuário está autorizado, e o risco é quem está do outro lado da mesa. Não há a quem negar — negar ao vendedor destruiria o trabalho dele. O que resolve é privacidade de exibição, o mesmo raciocínio do olho que esconde o saldo no app do banco. É controle contra plateia, não contra usuário, e confundir os dois leva a tirar acesso de quem precisa.
Erros comuns de acesso
- Usar o vendedor da transação do ERP para decidir quem vê o quê. Amarra acesso a um fato do passado que ninguém atualiza.
- Resolver tudo criando perfis. O campo sensível não cabe em perfil, e insistir gera dez papéis quase iguais.
- Confiar em esconder na tela. Se o número trafegou, vazou; só não estava pintado.
- Deixar o filtro de contexto ampliar escopo. É escalada de privilégio pela interface, sem aviso.
- Achar que permissão impede vazamento. Quem vê pode fotografar, exportar ou contar. Acesso limita a origem, nunca o destino — isso é contrato, não software.
Como isso se aplica no zCRM
A dor: o dono quer dar contexto comercial ao time sem entregar margem, carteira alheia e configuração junto — e trava o projeto por dois números.
Os três eixos existem separados. Função: um catálogo de chaves (crm.accounts.view, crm.opportunities.manage, crm.erp.financial.view, crm.users.manage, entre outras) guardado no papel, com cada rota da API atrás de um gate perm:<chave> — e um teste que varre as rotas e falha se alguma nasceu sem gate. Carteira: a visibilidade devolve "vê tudo" (admin, ou quem pode ver todos os vendedores do ERP) ou a lista de usuários cujos códigos de vendedor foram configurados para ele, mais ele mesmo; leituras e gravações passam pela mesma verificação de responsável. O seletor global só estreita dentro do permitido — pedir vendedor fora do escopo devolve vazio, e há teste garantindo isso. Campo: custo e margem ficam atrás de uma capacidade do usuário; negada, os campos não são calculados nem enviados.
Quem decide acesso é o responsável atual da conta, nunca o vendedor da transação. E o quarto eixo existe como o que é: um olho no topo da tela, só para quem já tem direito a custo, que esconde a família custo e margem inteira; o valor se revela por clique e some ao fechar o olho. No faturamento, com o olho fechado, o modo de métrica Margem nem aparece.
A decisão que muda: em vez de "libero o CRM ou não", o dono responde três perguntas separadas — e resolve cada uma sem estragar as outras.
Os limites, explícitos. Não existe trilha de auditoria de leitura: o zCRM registra uso por módulo, não "quem abriu a ficha deste cliente às 14h". Permissão de campo não é montável pelo cliente — existe o catálogo de chaves, os papéis e a capacidade de custo, não um construtor livre de perfis. A senha não é nossa: o login espelha o hash vindo do ERP e o reset se faz lá; não há SSO, MFA nem política de senha própria. E LGPD não é recurso de tela: controlar acesso ajuda, mas não é conformidade — não há anonimização nem retenção automática.
Próxima leitura
- Dashboard comercial: por que gráfico bonito não basta.
- Acompanhamento de uso do CRM: como saber se o time adotou de verdade.
- Como implantar CRM em 30 dias sem tentar resolver tudo de uma vez.