Como fazer o handoff de onboarding entre times no Salesforce sem cadastro perdido

Entra um cliente novo e o cadastro começa a correr solto: o comercial manda os dados por e-mail, o crédito responde num grupo de WhatsApp, a logística descobre o pedido quando já está atrasado. Duas semanas depois alguém pergunta "cadê o onboarding da conta X?" e ninguém sabe em que etapa travou nem de quem era a bola. Dá para orquestrar tudo isso dentro do Salesforce sem comprar nada e sem criar campo custom.

Resposta direta: modele cada time como uma fila e deixe a fila dona do registro ser a própria etapa. O comercial conclui sua parte e um Flow passa a posse para a fila do crédito, depois para a logística. A pergunta "em que fase está?" vira "qual fila é a dona agora?", com notificação e SLA no mesmo Flow, sem campo custom.

Por que o onboarding trava quando o processo não tem dono

O problema quase nunca é falta de gente competente. É que o cadastro de um cliente novo passa por três ou quatro mãos que trabalham em ferramentas diferentes. O comercial vive no funil de vendas, o crédito vive na planilha de análise, a logística vive no sistema de expedição. Entre uma mão e outra, a informação viaja por e-mail e mensagem, e cada handoff é um ponto onde a bola pode cair sem barulho.

O sintoma clássico é a pergunta sem resposta rápida. Um gestor quer saber por que o cliente que fechou há dez dias ainda não fez o primeiro pedido, e a única forma de descobrir é sair batendo na porta de cada time. O crédito acha que já devolveu para a logística, a logística jura que nunca recebeu, e o e-mail que provaria quem tem razão sumiu na caixa de entrada de alguém que está de férias. Ninguém mentiu: o processo só não tem um lugar único onde o estado dele mora.

A reação instintiva costuma ser cara demais para o tamanho do problema. Alguém sugere um objeto custom de "Onboarding" com dez campos, um campo de estágio, um pacote de gestão de processos do AppExchange com licença por usuário. Para um time de cinco pessoas fechando vinte contas por mês, isso é matar formiga com bazuca: seis meses depois o objeto custom está com metade dos campos vazios e a licença virou shelf-ware. O CRM já tem, de fábrica, a peça que resolve 80% disso: a fila.

A ideia central: a fila dona do registro é a etapa

No Salesforce, uma fila (queue) é um dono coletivo. Um registro cujo OwnerId aponta para uma fila não pertence a nenhuma pessoa: pertence ao grupo, e qualquer membro pode assumir. Filas nascem para distribuir Casos e Leads, mas nada obriga a usá-las só para isso. O truque deste modelo é enxergar a fila não como uma caixa de entrada, e sim como uma fase do processo.

Crie uma fila por time envolvido no onboarding e deixe o registro caminhar entre elas. Enquanto o dono for a fila "Onboarding - Comercial", o cadastro está na fase comercial. No instante em que o dono vira "Onboarding - Crédito", ele avançou. O estado do processo deixa de morar num campo que alguém precisa lembrar de atualizar e passa a morar no próprio OwnerId, que o Salesforce já mantém, já audita e já expõe em list view. É a diferença entre pedir para as pessoas registrarem o status e deixar o status ser um efeito colateral automático de fazer o trabalho.

Para o registro em si, use um objeto padrão que já suporte fila e não custe licença extra. O Caso é o candidato natural: aceita fila como dono, tem feed para o histórico da conversa, tem list view por dono e não exige nenhum campo custom para funcionar. Um Caso do tipo "Onboarding" por cliente novo, e pronto. Se o seu processo já nasce a partir da Oportunidade fechada, um Flow cria esse Caso automaticamente no Closed Won e já o entrega na primeira fila.

Passo a passo: montando o handoff entre comercial, crédito e logística

O modelo tem quatro peças, todas declarativas. Vou detalhar cada uma com o que ela faz e onde as pessoas erram ao montá-la.

1. As filas, uma por etapa

Em Setup, crie três filas sobre o objeto Caso: Onboarding - Comercial, Onboarding - Crédito e Onboarding - Logística. Coloque em cada uma os membros do time correspondente (por grupo público, para não ter que editar a fila toda vez que alguém entra). O erro comum aqui é esquecer de marcar o objeto Caso como suportado na fila: sem isso, o registro não pode ter a fila como dono e o Flow do próximo passo falha silenciosamente na atribuição.

2. A ação de "concluir minha etapa"

Cada time precisa de um botão que diga "terminei, passa para o próximo". Faça um Screen Flow curto, publicado como ação rápida no Caso, chamado "Passar para a próxima etapa". Ele lê a fila dona atual e, num elemento de decisão, define a próxima: comercial vai para crédito, crédito vai para logística, logística encerra o Caso. O Flow então atualiza o OwnerId para a fila seguinte e posta no feed quem concluiu e quando. A pessoa clica em um botão e o bastão troca de mãos com registro auditável.

// Decisão dentro do Screen Flow, em pseudocódigo do que cada ramo faz
SE Owner.Name = 'Onboarding - Comercial'
    Owner = Fila 'Onboarding - Crédito'
SENÃO SE Owner.Name = 'Onboarding - Crédito'
    Owner = Fila 'Onboarding - Logística'
SENÃO SE Owner.Name = 'Onboarding - Logística'
    Status = 'Fechado'   // fim do onboarding
Postar no Chatter: '{$User} concluiu a etapa em {!$Flow.CurrentDateTime}'

3. O aviso automático na troca de dono

Trocar o dono não adianta se o próximo time não percebe. Crie um Flow disparado por registro no Caso, na condição "OwnerId foi alterado". Ele dispara uma Custom Notification (aquele sino no topo do Salesforce, que também vira push no app) para os membros da nova fila, com o texto "Novo onboarding na sua fila: {nome do cliente}". Custom Notification é nativa, não gasta e-mail e chega em segundos. Se o seu time vive fora do Salesforce, a mesma lógica de aviso na hora certa aparece quando você dispara alertas em tempo real com Platform Events para um sistema externo, mas para o time interno a notificação nativa resolve.

4. O SLA por etapa, sem campo de data

Aqui está o pulo do gato que faz o modelo dispensar campo custom de verdade. Você quer escalar quando um cadastro fica parado numa fila por mais de 24h, mas não quer criar um campo "entrou na fila em" para calcular isso. Use o caminho agendado (scheduled path) do mesmo Flow de mudança de dono. Quando o OwnerId muda, o Flow agenda uma execução para 24 horas depois daquele instante. Nessa execução agendada, ele verifica: o dono ainda é a mesma fila? Se sim, o cadastro empacou, então notifique o gestor responsável. Se o dono já mudou, o registro andou e o ramo agendado simplesmente não faz nada.

O detalhe elegante é que o instante de entrada na fila fica gravado no próprio agendamento, não numa coluna. O Flow não precisa saber "há quanto tempo está aqui": ele já foi marcado para acordar no momento certo. Se quiser depurar por que uma escalada disparou ou deixou de disparar, o Flow Logging registra cada execução do caminho agendado e mostra qual ramo rodou, sem você ter que reproduzir o cenário no escuro.

O caso da Vetra: o que mudou na prática

Montei exatamente esse desenho na Vetra Distribuidora, a empresa fictícia que uso para demonstrar padrões de org (os números abaixo são desse ambiente de demonstração, não de um cliente). O onboarding de um cliente novo lá tem três paradas: o comercial confirma dados fiscais, o crédito define o limite, a logística cadastra os endereços de entrega e libera o primeiro pedido.

Antes, o processo vivia num grupo de WhatsApp e numa planilha compartilhada. Cronometrando dez cadastros de exemplo, a média do ciclo completo dava perto de 6 dias úteis, e três dos dez ficaram mais de dois dias parados numa etapa sem que ninguém percebesse, porque o aviso dependia de alguém lembrar de cutucar o próximo time. Não dava para responder "quantos onboardings estão parados agora?" sem abrir a planilha e conferir linha por linha.

Com o modelo de filas e Flow, cada time passou a ter uma list view "Meus onboardings", que nada mais é do que o Caso filtrado por Owner = minha fila. O SLA de 24h por etapa passou a escalar sozinho para o gestor. O ciclo médio dos mesmos dez cenários caiu para perto de 3,5 dias, não porque alguém trabalhou mais rápido, mas porque o tempo morto entre as mãos desapareceu: o próximo time era avisado no segundo em que a bola chegava, e o que empacava aparecia num relatório em vez de sumir. Zero campo custom, zero licença nova, três filas e dois Flows.

Filas e Flow, campo de estágio ou AppExchange: qual escolher

Ser honesto sobre os limites é o que separa um bom desenho de um dogma. O modelo de filas resolve muito bem um processo linear e curto, mas ele tem um custo escondido: como a etapa mora no OwnerId, você não ganha de graça o histórico de quanto tempo o registro passou em cada fase. Para report de tempo por etapa ao longo de meses, isso pesa. Veja onde cada opção brilha.

A conta de decisão é direta. Se o seu onboarding tem até cinco ou seis etapas lineares e o que dói é a bola cair no handoff, filas e Flow entregam o resultado hoje à tarde, de graça. Se você precisa reportar tempo médio por fase para negociar SLA com um fornecedor, adicione um objeto de log leve ou um campo de estágio com histórico ativado. Só parta para um pacote pago quando o processo tiver ramificações de verdade, múltiplos níveis de aprovação e volume que justifique a licença. Comprar a bazuca antes de a formiga virar um formigueiro é o erro que mais vejo em org de cliente.

Vale lembrar que a escolha entre resolver no clique e resolver no código segue a mesma lógica de qualquer automação: comece pelo declarativo e só suba de ferramenta quando ele não der conta. Se ficar na dúvida entre montar isso em Flow ou partir para uma classe, o raciocínio de quando usar Flow e quando usar Apex vale inteiro aqui. E como o modelo se apoia em disparar a ação certa no momento certo, ele é primo do padrão de follow-up pós-venda automatizado, que usa a mesma ideia de agendamento para não deixar uma tarefa vencer no esquecimento.

Erros que estragam o modelo

• Fila sem o objeto suportado: se você esquecer de habilitar o Caso na fila, o Flow tenta atribuir e falha calado. Sempre teste o handoff com um registro real antes de soltar para o time.
• Membro na fila em vez de grupo público: colocar pessoas direto na fila obriga a mexer na configuração a cada troca de time. Use um grupo público como membro e gerencie gente lá.
• Notificar sem contexto: uma Custom Notification que só diz "novo item na fila" faz o time abrir para descobrir o que é. Inclua o nome do cliente e a etapa no texto do aviso.
• Confiar no scheduled path e não testar o cancelamento: se o registro avança antes das 24h, o ramo agendado precisa checar o dono atual e desistir. Sem essa checagem, ele escala um cadastro que já andou e treina o gestor a ignorar o alerta.
• Empurrar tudo para filas quando o processo cresce: passou de seis etapas ou virou uma árvore de decisões, o OwnerId sozinho não conta mais a história. Aí é hora de um campo de estágio de verdade, e insistir na fila vira teimosia.

Perguntas frequentes

Dá para fazer onboarding de cliente no Salesforce sem campo custom?

Dá, para processos lineares e curtos. Como a fila dona do registro representa a etapa, o OwnerId já responde "em que fase está o cadastro". Isso dispensa o campo de status custom em times pequenos. Quando você precisa reportar tempo por fase ou tem muitas etapas, o campo volta a compensar.

Como avisar o próximo time na hora que a etapa muda de mãos?

Um Flow disparado por registro na mudança de OwnerId envia uma Custom Notification para os membros da nova fila e posta no feed do Caso. A troca de dono é o gatilho, então ninguém depende de mandar e-mail ou mensagem para o time seguinte saber que chegou trabalho.

Como colocar SLA por etapa sem um campo de data custom?

Use o caminho agendado do Flow. Ele captura o instante da entrada na fila e agenda uma verificação para 24h depois. Se o registro ainda for da mesma fila, o Flow escala para o gestor. O momento de entrada fica no agendamento, sem coluna nova no objeto.

Filas e Flow servem para qualquer processo interno, não só onboarding?

Servem para qualquer fluxo linear com handoff entre times: abertura de chamado que passa por triagem e atendimento, aprovação de cadastro de fornecedor, devolução que passa por comercial e fiscal. A regra é a mesma: poucas etapas, sequência clara, dor no repasse. Fugiu disso, reavalie a ferramenta.