A regra que você quer escrever é simples de dizer em voz alta: «se o negócio voltou de Fatura enviada, avise o gerente de vendas». A regra que você realmente consegue configurar é outra. Uma regra de automação no Bitrix24 (Alaio) roda quando um item chega a uma etapa, e a única etapa que ela conhece é aquela em que está. De onde o negócio veio não está no documento, nem na lista de variáveis, nem nas configurações do gatilho: para a plataforma, uma mudança de etapa é um campo com valor novo, não um par «de → para».

O que uma regra de automação realmente sabe ao rodar

Vale separar três coisas que parecem uma. Um gatilho reage a um evento externo — um pagamento, uma chamada recebida, uma resposta no chat — e move o item. As regras ligadas a uma etapa rodam na chegada, de cima para baixo. E a plataforma grava uma linha no histórico de etapas.

Essa última parte é a útil, e não está na documentação: a linha do histórico é gravada de forma síncrona com o salvamento, antes de as regras rodarem. Ou seja, uma regra que dispara numa etapa já vê a linha da sua própria etapa: a linha mais recente é a etapa atual, e a de baixo é a anterior. Tudo o que vem a seguir se apoia nesse único fato.

Ler a etapa anterior sem campo personalizado

A gambiarra de sempre: uma regra em cada etapa que grava o próprio código num campo «etapa anterior». Funciona até alguém renomear uma etapa, inserir outra ou criar um segundo funil — aí os campos descolam da realidade e ninguém lembra qual regra preenche o quê. A outra gambiarra são aplicativos que desdobram o histórico em campos de serviço em segundo plano: o campo aparece com atraso, então numa condição ele não serve, porque a condição é verificada na hora.

O bloco Etapa anterior lê o histórico em tempo de execução, numa única requisição, e devolve o resultado direto para o processo: o código da etapa para as condições, o nome para um e-mail ou comentário, a semântica (em andamento / ganho / perdido), o ID do funil, o momento em que o item saiu daquela etapa e o tempo que passou lá em segundos. Um indicador separado, «encontrada», distingue «este item nunca se moveu» de um erro real, então o caminho normal não precisa de tratamento de erro. Nenhum campo extra aparece no cartão.

Os itens com etapas são negócios, leads e itens de processos inteligentes. Leads guardam a etapa num campo diferente dos negócios, e o bloco absorve essa diferença por conta própria. Contatos e empresas não têm etapas: não há o que devolver.

Como detectar um negócio voltando no funil

O retrocesso é o tipo de movimento mais caro: um negócio sai de Fatura enviada de volta para Negociação, e no relatório do funil isso parece trabalho normal. Três passos pegam o caso.

Coloque o bloco «Etapa anterior» na etapa para a qual se retrocede. Compare o resultado com uma condição se — então: o item veio de uma etapa que fica depois no funil, logo é um retrocesso. Várias verificações de uma vez — código da etapa anterior, valor, responsável — a Condição composta agrupa sem ramificações aninhadas. Depois, o kit de sempre: uma tarefa para o gestor, um comentário com o nome da etapa anterior e o tempo passado lá, uma marca num campo para o relatório.

O mesmo truque separa «o negócio chegou a Ganho pelo próprio caminho» de «alguém arrastou ele do meio do funil direto para Ganho». Só a etapa anterior diferencia os dois; pela etapa atual, ambos parecem iguais.

É possível proibir a mudança manual de etapa?

Os papéis de CRM conseguem limitar o trabalho com etapas específicas: as permissões de acesso definem quais etapas um papel vê e altera. O que os papéis não conseguem expressar é uma regra sobre a transição em si: «só para frente», «não mais de uma etapa por vez», «não para Ganho enquanto faltar o documento assinado». As permissões tratam a etapa como um estado, nunca como um par «de → para».

Essa regra é assunto de uma regra de automação. Na etapa de destino, verifique de onde o item veio e se os requisitos estão cumpridos; se a regra foi violada, Atualizar negócio por ID devolve o item para a etapa anterior e o responsável recebe uma notificação com o motivo. Não é um botão desabilitado, e sim um retorno em um segundo mais uma explicação — o que na prática funciona melhor, porque a pessoa aprende a regra em vez de bater num controle acinzentado. Para que os requisitos apareçam antes da tentativa, e não depois, coloque-os no cartão: o campo Checklist da etapa mostra em cada etapa a sua própria lista de ações obrigatórias e opcionais.

Medindo o tempo na etapa

O tempo na etapa é a distância entre duas linhas do histórico, e o bloco devolve isso pronto: os segundos que o item passou na etapa que acabou de deixar. Dali em diante é um número comum — compare numa condição («parado mais de três dias, escalar»), grave num campo e construa em cima uma métrica própria para ver onde a fila se acumula.

Duas ressalvas que vale conhecer de antemão. O bloco mede a última passagem pela etapa: se o item voltou duas vezes, cada par de transições é medido separadamente, e não sai um total de todas as passagens. E é tempo de calendário, não tempo útil: um negócio que chega na sexta à noite acumula honestamente três dias até a manhã de segunda, o que normalmente não é o que um KPI quer dizer.

Movendo entre funis

Mover um item para outro funil é registrado como uma única linha de histórico: funil novo e etapa nova juntos, sem um evento separado de «funil alterado». Para o bloco, isso é uma mudança de etapa normal: ele devolve a etapa anterior mais o ID do funil ao qual ela pertencia, então um salto entre funis se distingue do movimento dentro de um só exatamente por esse valor.

O outro lado: executar a mudança é mais exigente. O método antigo de atualização de negócio ignora em silêncio o campo do funil — sem erro, o negócio fica onde estava, e isso custa meio dia. «Atualizar negócio por ID» passa pelo método universal de CRM, então muda o funil junto com a etapa; os outros caminhos estão reunidos no guia sobre atualizar campos de um negócio. Se o processo roda sobre outro item, Encontrar negócio localiza o correto primeiro.

O que vem depois

Comece pela única etapa onde mais negócios se perdem: Etapa anterior, uma condição de retrocesso, uma tarefa para o gestor. Uma semana depois você tem os primeiros números — de onde se retrocede e quanto tempo os itens ficam parados — e é em volta deles que os funis e gatilhos devem ser refeitos. Para marcar a base existente numa passada, use o lançamento em massa.

Os blocos vizinhos vivem no catálogo de robôs: condições, atualização de entidades, ferramentas de data. E se o que você precisa está faltando, descreva a tarefa: a Roboteka constrói as atividades que faltam de graça e publica na biblioteca comum. «Etapa anterior» nasceu exatamente assim.