# GRD — Troca de vendedor na distribuição de leads **Público:** pessoa responsável pela operação, com apoio de quem administra o n8n. **Objetivo:** encaminhar novos leads à pessoa correta, mantendo a carteira histórica até uma decisão separada. > O fluxo é de produção e tem várias rotas. Alterar só o nome no NocoDB ou um único nó do n8n não conclui a troca. Não exponha chaves da API ao gravar a tela nem faça substituições globais de números: um número pode ser parte de uma data ou de outro identificador. ## 1. Levantamento antes da mudança 1. Confirme nome completo e telefone de quem sai e de quem entra. Decida separadamente o destino dos clientes já atribuídos e a retirada do acesso ao CRM. 2. No iSales, abra **Usuários**, localize a pessoa nova e confirme nome, telefone, função e ID do usuário. No exemplo de Dione, o cadastro tinha ID **6636**. O ID de futuras pessoas será outro. 3. No Chatwoot, pesquise o número completo antes de criar outro contato. Confira identidade, nome, telefone e caixa de entrada. Anote o ID do contato e da conversa correta. No exemplo, contato **7**, conversa **2048**, conta **1** e caixa **8**. Não copie esses IDs para outra pessoa. 4. Peça à pessoa que envie uma mensagem à empresa para que a conversa possa ser respondida. Envie uma mensagem de teste, verifique o status e confirme com a pessoa que ela recebeu. 5. No n8n, identifique o que está ativo agora, exporte um backup seguro dos workflows afetados e registre as versões ativas. Backups podem conter credenciais e dados: guarde-os em local restrito. ## 2. Tabela de distribuição 1. No NocoDB, abra a base **Grd_solar** → **Distribuição vendedores**. 2. Identifique a linha efetivamente usada pelo fluxo para a vaga. Confirme o ID da linha e registre o nome e o contador anteriores antes de mexer. 3. O nome precisa corresponder exatamente ao nome consultado no n8n. O contador serve ao balanceamento e não representa necessariamente a carteira pessoal do vendedor. Decida com a operação como preservar ou iniciar essa contagem. 4. Planeje a troca coordenada com os workflows. Uma divergência temporária entre nome na tabela e nome no fluxo pode fazer uma rota falhar ou distribuir incorretamente. Não apague linhas históricas sem avaliar as referências. ## 3. Workflows a revisar Os nomes abaixo refletem a configuração observada em **10/11/2026**. Confirme novamente as versões e os fluxos ativos antes de executar uma alteração futura; a estrutura pode ter mudado. | Workflow | Nós a conferir | O que conferir | | --- | --- | --- | | **GRD SDR v3.3 CANDIDATO — receipt obrigatório** | `Code2`, `Code15`, `Code16` | Nome, telefone, conta, caixa, conversa e contato de quem recebe. Preserve os dados dos demais consultores. | | Mesmo workflow | `Consultor Switch`, `Consultor Switch1`, `Consultor Switch2` | A regra de comparação deve corresponder exatamente ao nome produzido pelo código e à rota correta. | | Mesmo workflow | `HTTP Request21`, `HTTP Request49` | Campo `vendedor_id` para a rota da pessoa substituída deve corresponder ao ID do CRM. Não altere outras rotas. | | **fup_grd** | `Code Consultor FUP1`, `Code Consultor FUP3`, `Code RR Post3` | Nome de exibição e nome da tabela, telefone, conversa e ID do vendedor no CRM. | | Mesmo workflow | `Consultor Switch FUP1`, `Consultor Switch FUP3`, `NocoDB FUP3 Qualificado`, `PG Qualifica Post3` | Condições e listas de nomes permitidos devem reconhecer a pessoa nova, sem mudar os demais. | | **repescagem_grd_check** | `Seleciona Consultor` | Mapeamentos de ID da linha de distribuição para ID do CRM, nome e conversa do Chatwoot. | | **GRD OPS — Handoff Stuck Monitor v1** | `Alert Tatiana inbox 4092` | Confira o destino real da mensagem. O nome do nó é histórico e pode não refletir o destinatário atual; não o renomeie sem revisar as referências. | Antes de salvar, confira cada ocorrência no contexto. IDs de conversa e de vendedor não são intercambiáveis. Não grave ou compartilhe URLs, parâmetros ou telas contendo tokens. ## 4. Aplicação e verificação 1. Programe a mudança com o responsável técnico e combine uma janela operacional: a atualização de tabela e de vários fluxos não é atômica. 2. Aplique somente as alterações revisadas, mantenha backup e verifique se a versão alterada é a versão ativa. Confirme que os demais consultores continuam configurados. 3. Verifique se a linha correta da tabela existe e se a contagem pode ser lida e atualizada. Testes locais de seleção não comprovam que o CRM e a notificação funcionem em conjunto. 4. Com a equipe, acompanhe um lead real autorizado: confira quem foi selecionado, o responsável no CRM, o registro de contagem, a mensagem na conversa certa e a confirmação de recebimento. Não envie testes a clientes sem autorização. 5. Se houver erro, registre o que aconteceu e acione o responsável técnico. Não restaure um backup antigo sem antes verificar se houve alterações posteriores de outras pessoas. ## 5. Acesso da pessoa que saiu Desativar o acesso e transferir a carteira são ações diferentes. No iSales observado, a lista tinha uma ação chamada **Excluir**, mas não foi comprovado se ela apenas desativa ou como afeta vínculos. Até confirmar com o fornecedor ou a administração, não use essa ação presumindo que seja reversível. No caso de Tatiana, a desativação não havia sido concluída nesta análise.