O responsável é o campo central de qualquer entidade do Bitrix24 (Alaio): é por ele que se calculam relatórios e KPI, é a ele que se amarram as permissões «meus/alheios», é ele quem recebe notificações e tarefas. Por isso a pergunta «como trocar o responsável» surge todo dia: o lead novo precisa ir para um gerente livre, os negócios de quem saiu da empresa — passar ao sucessor, a aprovação travada — subir ao supervisor. Vamos percorrer todos os níveis: troca manual, em massa e automática — e três robôs que fecham os cenários fora do alcance das ferramentas nativas. No fim, a pergunta inversa: como impedir a troca do responsável quando o Bitrix24 não tem uma permissão própria para isso.

Responsável ou executor: quem é quem

No CRM, lead, negócio, contato e empresa têm um único responsável — o campo «Responsável» do card. Nas tarefas há mais papéis: o criador, o executor, os coexecutores e os observadores. «Responsável» na tarefa é justamente o executor — quem faz o trabalho e em quem acendem os contadores; o criador apenas recebe o resultado. Se o processo precisa «trocar o responsável pela tarefa», o que muda é o executor. Mais sobre os papéis e campos das tarefas — no artigo sobre os robôs em tarefas.

Como trocar o responsável manualmente

No card: campo «Responsável» → escolher o funcionário. Na lista: marcar os registros necessários → ação em grupo «Alterar responsável» — assim se repassam dezenas de registros de uma vez; o filtro «Responsável = Silva» mais «selecionar tudo» cobre até centenas. Duas armadilhas. A primeira — permissões: troca o responsável qualquer pessoa cujo papel no CRM tenha a permissão «Edição» sobre o registro; não existe uma permissão própria para a troca — como bloqueá-la mesmo assim está explicado mais abaixo. A segunda — ao repassar o registro, o dono anterior pode perdê-lo de vista: as permissões «ler apenas os próprios» cortam o acesso no momento da troca, por isso o repasse da carteira de clientes se planeja junto com a configuração dos papéis.

Troca automática: o robô nativo e as condições

No designer de robôs existe a ação nativa «Alterar responsável» — ela define um funcionário específico ou um valor vindo de um campo. Em conjunto com as condições «se — então», surge o roteamento: o valor do negócio passa do limite — o responsável vira um gerente sênior; a fonte é «programa de parceiros» — os registros vão para o gerente de parcerias. O ponto fraco da ação nativa: ela só conhece o que está fixado na configuração — uma pessoa específica ou um campo. Quem está «livre», quem é «do departamento certo», quem é «o supervisor do responsável atual» — isso o designer não sabe sozinho, e é aí que entram os robôs da Roboteka.

Distribuição de leads e negócios entre gerentes

O clássico: os leads que chegam devem ser distribuídos pelo departamento de vendas de forma uniforme, e não cair sobre um único plantonista. O robô «Funcionário aleatório da lista ou do departamento» escolhe um funcionário ativo aleatório do departamento indicado — ou de uma lista explícita de IDs — e sabe excluir uma pessoa, por exemplo o responsável atual. Devolve ID, nome, e-mail e o indicador «encontrado» (Y/N); no passo seguinte, a ação nativa grava o ID no campo «Responsável». No longo prazo, a escolha aleatória dá uma carga uniforme sem planilhas de controle de fila. Se a distribuição precisa depender do departamento do autor ou do território — primeiro o robô «Obter o departamento do funcionário» identifica o departamento, depois uma condição ramifica a rota. A esteira completa de tratamento dos leads que chegam está no artigo sobre os leads.

Saída de um gerente: repassar tudo o que é relacionado

O cenário mais doloroso. A ação em grupo na lista repassa os negócios — mas não toca nos registros relacionados: a empresa fica com contatos do responsável antigo, os contatos — com os seus negócios. O robô «Alterar responsável nos relacionados» resolve exatamente isso: executado em uma empresa, reatribui todos os negócios dela ou todos os contatos; em um contato — os negócios ou as empresas dele; em um negócio — os contatos ou a empresa dele. Uma execução processa até 500 registros relacionados; o robô devolve a quantidade de atualizados e o indicador de sucesso. O processo de repasse da carteira se monta em dois passos: trocar o responsável da empresa com a ação nativa → com o robô, estender o novo responsável a todos os negócios e contatos daquela empresa. O mesmo truque funciona ao passar um cliente-chave para um novo gerente de contas — sem ninguém sair da empresa.

Escalonamento: não trocar, mas envolver o supervisor

Às vezes trocar o responsável é um erro: pela tarefa atrasada deve responder o mesmo gerente, mas o supervisor dele é obrigado a saber do atraso. O robô «Obter o supervisor do funcionário» devolve o supervisor direto pela estrutura de departamentos — ao processo resta criar uma tarefa para ele ou enviar uma notificação. O responsável não muda, mas surge o controle. Para o escalonamento funcionar, a estrutura da empresa deve estar preenchida honestamente — como configurá-la está no artigo sobre a estrutura da empresa.

Dá para impedir que os gerentes troquem o responsável?

Com as ferramentas nativas, só junto com todo o resto. Os papéis do CRM não têm uma permissão própria de «troca de responsável»: o campo «Responsável» é alterado por qualquer pessoa com a permissão «Edição» sobre o registro. Retirá-la significa que o gerente não edita mais o card: nem telefone, nem valor, nem comentários. O que o modelo de papéis realmente oferece:

  • Permissões por etapa. Para leads, negócios e processos inteligentes, as permissões são definidas separadamente para cada etapa: nas etapas finais e em «Aprovação» a edição pode ser fechada. O responsável fica bloqueado junto com os demais campos, o que nessas etapas costuma ser exatamente o desejado.
  • O nível «Próprios». Não é uma proibição, é um freio: ao passar um negócio para um colega, o gerente perde o acesso na hora, e não consegue pegar o negócio de outra pessoa porque simplesmente não o vê. Como os níveis de acesso dependem do responsável está no artigo sobre permissões de acesso e robôs.
  • Tarefas. Aqui a permissão existe: nos papéis de tarefas se ativam separadamente «Troca de executor» e «Delegação de tarefa». Mas os papéis de tarefas só são configuráveis nos planos Professional e Enterprise, e o supervisor sempre pode delegar tarefas aos subordinados, independentemente das configurações.

O modelo de papéis do CRM também não está em todos os planos. Se a «Edição» não pode ser retirada, mas o controle é necessário, o bloqueio é montado com um processo: a troca não é impedida, é revertida.

Como restaurar automaticamente o responsável anterior?

É preciso um campo personalizado de referência — por exemplo, «Responsável fixado» do tipo «Funcionário» — e um processo de negócios que inicie automaticamente a cada alteração. O esquema:

  1. Ao criar o negócio, o processo grava o responsável atual no campo de referência.
  2. A cada alteração do negócio, roda uma verificação. O robô «Obter o supervisor do funcionário» usa o ID do campo de referência e encontra o supervisor do responsável anterior.
  3. A «Condição composta» verifica três coisas em um passo: o responsável é diferente do campo de referência, «Modificado por» não é esse supervisor e não é o administrador do CRM. Lógica AND, o resultado é Y ou N.
  4. Y significa uma troca não autorizada: a ação nativa «Alterar responsável» devolve o valor do campo de referência, e o supervisor recebe uma notificação sobre quem tentou repassar o negócio.
  5. O responsável é diferente do campo de referência, mas a condição retornou N — a troca foi feita pelo supervisor ou pelo administrador. O processo grava o novo responsável no campo de referência e, a partir daí, é ele o responsável fixado.

A própria reversão dispara de novo o processo de alteração, mas nesse momento o responsável já coincide com o campo de referência, e a verificação termina sem ação — não há loop. Uma regra: processos que atribuem o responsável de forma legítima — distribuição de leads, repasse da base quando alguém sai — precisam gravar o novo responsável também no campo de referência, senão a verificação reverte esses também. Como a automação reage a alterações de campos está no artigo sobre gatilhos, e o que mais reatribuir quando um funcionário sai, no checklist de desligamento.

Perguntas frequentes

Dá para proibir os gerentes de trocar o responsável? Os papéis do CRM não têm uma permissão própria para isso: ou se retira a «Edição» por completo ou em etapas específicas, ou a troca é revertida por um processo, como descrito acima. O criador da tarefa muda? Nativamente não — recrie a tarefa por um processo ou troque o executor. O novo responsável é notificado? Sim, pela notificação padrão; uma adicional com contexto pode ser enviada pelo processo — como configurar está no artigo sobre as notificações dos processos de negócios. O que acontece com os processos ativos na troca de responsável? Eles continuam rodando; se a rota depende do responsável, releia o campo no momento do uso, e não no início do processo.

Conclusão

A troca manual fecha os casos pontuais; as ações em grupo, os repasses únicos; os robôs, o fluxo: distribuição uniforme dos novos contatos, repasse da base relacionada quando alguém sai, escalonamento pela estrutura e reversão de uma troca que ninguém autorizou. Os robôs «Funcionário aleatório», «Alterar responsável nos relacionados», «Obter o supervisor», «Obter o departamento do funcionário» e «Condição composta» estão no catálogo da Roboteka, instalados gratuitamente pelo Bitrix24 Market. Se não houver o cenário de que você precisa — descreva a tarefa e criamos o robô.