👤 Para quem coordena aprovações ou revisões que dependem de rodadas de ajuste
🔐 Disponível para todos os planos
🎯 Para você garantir que cada retorno para ajuste fique rastreável, com histórico preservado e movimentação automática entre quem revisa e quem executa
Todo processo que passa por aprovação ou revisão tem um momento em que algo precisa voltar. Um documento que chegou incompleto, um pedido que veio com o valor errado, uma solicitação que precisa de um anexo que ninguém enviou. Quando isso acontece pela primeira vez, é comum resolver na conversa: um recado no chat, um e-mail pedindo o ajuste, e o card fica parado esperando. Na segunda e na terceira vez, essa mesma solução começa a cobrar seu preço, porque ninguém sabe mais quantas vezes aquele card já voltou nem o que foi pedido em cada rodada.
Ao terminar este artigo, você vai saber estruturar esse vai e vem como uma decisão consciente de arquitetura do seu processo: uma fase de ajuste dedicada, um registro de cada rodada e uma movimentação de retorno que acontece por automação, não por alguém lembrando de mover o card. O objetivo não é evitar que as coisas voltem, e sim fazer com que cada retorno deixe rastro.
📖 O que você vai entender aqui:
O vai e vem é uma decisão de arquitetura, não um recurso
Vale começar por um ponto que muda a forma de resolver isso: o fluxo de vai e vem não é um botão que você ativa no Pipefy. É uma forma de desenhar o processo. A diferença é importante, porque a tentação natural é fazer o card voltar arrastando manualmente para a fase anterior sempre que precisa de ajuste. Funciona nas primeiras vezes, e some com toda a informação sobre o que aconteceu ali.
Quando você trata o retorno como parte do desenho, três perguntas passam a guiar a construção: para onde o card volta, o que fica registrado sobre a rodada e como a movimentação acontece. Responder essas três perguntas de forma consistente é o que transforma um processo que "às vezes volta" em um processo que sabe exatamente quantas vezes voltou e por quê.
A pergunta que separa um vai e vem bem modelado de uma gambiarra é simples: se você tirasse a pessoa que hoje coordena os ajustes, o processo continuaria contando a própria história? Se a resposta é não, o histórico está na cabeça de alguém, e não no processo.
Quando criar uma fase de ajuste dedicada
A decisão mais importante do desenho é se o ajuste merece uma fase própria. A resposta quase sempre é sim, e por um motivo prático: quando o card simplesmente volta para a fase de origem, ele se mistura com os cards que estão entrando pela primeira vez. Quem trabalha naquela fase não distingue o que é novo do que é retrabalho, e a rodada de ajuste perde prioridade justamente quando ela costuma ser mais urgente.
Uma fase de ajuste dedicada resolve isso de duas formas. Ela separa visualmente o que voltou do que é novo, e dá a você um lugar específico para medir quanto tempo os ajustes levam. Na prática, é a diferença entre "esse card está na fase de análise" e "esse card voltou para ajuste pela segunda vez e está aqui há três dias".
Para nomear essa fase, siga o padrão de clareza do resto do processo: um nome que descreve o estado do card, não a ação de quem trabalha nele. "Aguardando ajuste" ou "Em ajuste do solicitante" comunica melhor do que "Corrigir", porque quem olha o quadro entende de imediato de quem o processo está esperando resposta.
Se você percebe que o ajuste envolve várias etapas, várias pessoas ou passa a mudar o escopo do que estava sendo aprovado, isso deixa de ser uma fase e vira sinal de que talvez precise de um pipe auxiliar dedicado ao ciclo de revisão. Esse é um tema para outro momento, mas vale reconhecer o limite: uma fase de ajuste resolve o retorno simples; múltiplas etapas de correção pedem uma estrutura maior.
Preservar o histórico de cada rodada
Aqui está o coração da rastreabilidade. Cada vez que um card volta para ajuste, alguma informação nova aparece: o que estava errado, o que foi pedido, quando voltou. Se essa informação vive só no campo que o solicitante vai reescrever, ela some no momento em que o ajuste é feito. A segunda rodada apaga a primeira.
A prática consolidada do time para resolver isso é manter um campo de texto longo dedicado ao histórico de ajustes. A cada retorno, o motivo daquela rodada é registrado ali, com data, antes que os campos de input sejam preenchidos de novo. O campo original continua sendo editado normalmente pelo solicitante; o campo de histórico só acumula. Ao fim do processo, esse campo conta a história completa: quantas vezes voltou, o que foi pedido em cada rodada e quando.
O critério de decisão aqui é sobre o que precisa sobreviver à próxima edição. Campos que o solicitante reescreve não servem como histórico, porque cada nova versão apaga a anterior. O histórico precisa de um lugar que só recebe, nunca substitui.
Automatizar a movimentação com botão, nunca manualmente
A última peça é como o card se move. E aqui há uma regra de modelagem que vale para qualquer movimentação crítica, não só para o vai e vem: aprovações e retornos de ajuste devem acontecer por automação ou por botão de ação, nunca por arrastar o card manualmente.
O motivo é consistência. Quando o retorno depende de alguém arrastar o card, cada pessoa faz de um jeito, e as ações que deveriam acompanhar o movimento (registrar o histórico, marcar visualmente que voltou, avisar o solicitante) dependem da memória de quem moveu. Quando o retorno acontece por uma automação disparada por botão, todas essas ações acontecem juntas, sempre, na mesma ordem. O revisor decide que o card precisa de ajuste, aciona o botão, e o processo cuida do resto.
No Pipefy, essa movimentação é montada como uma automação com o padrão de nomenclatura `[Fase gatilho] Cenário -> Ação`, por exemplo `[Análise] Reprovado para ajuste -> Move card`. O passo a passo de configuração dessa automação você encontra no Help Center; o que importa aqui é a decisão de desenho: o botão é o gatilho, e a automação carrega junto tudo o que precisa acontecer no retorno.
Saiba mais: consulte o Help Center para o passo a passo de criação de automações baseadas em ações do card
A etiqueta que sinaliza o retorno
Uma vez que o card volta por automação, vale dar a ele um sinal visual. Uma etiqueta de "Retorno de ajuste" atribuída automaticamente pela mesma automação que move o card faz com que qualquer pessoa que olhe o quadro reconheça de imediato que aquele card não é uma solicitação nova, e sim uma rodada de correção. O Help Center confirma que etiquetas podem ser inseridas em cards automaticamente por automação, sem depender de ninguém marcar manualmente.
Esse detalhe parece pequeno, mas é o que fecha o ciclo da rastreabilidade visual: o histórico conta a rodada por escrito, e a etiqueta conta pela cor.
O SLA da fase de ajuste
Fecha o desenho definir quanto tempo é razoável esperar por um ajuste. Uma boa prática é, junto ao cliente ou ao time, acordar um prazo máximo para a fase de ajuste, mesmo que seja uma expectativa alta no começo, que você refina conforme o processo roda. Sem esse prazo, um card que voltou para ajuste pode ficar esquecido indefinidamente, e o vai e vem que você desenhou para dar controle vira um buraco onde cards somem.
No Pipefy, esse acompanhamento de tempo por fase é configurado por meio do Alerta de Permanência, que monitora quanto tempo um card fica em uma etapa e dispara quando o limite é ultrapassado. O passo a passo fica no Help Center; a decisão de desenho é definir o número: qual é o maior tempo justo para um ajuste voltar antes de você precisar escalar.
Antes de avançar, confirme que você entende:
☐ Por que o retorno para ajuste é parte natural de uma aprovação e merece uma fase própria em vez de misturar com a fila de entrada
☐ Que o histórico de cada rodada precisa de um campo de texto longo dedicado, que só acumula e nunca é sobrescrito
☐ Que você consegue montar a movimentação de retorno por automação disparada por botão, carregando junto o registro do histórico e a etiqueta de sinalização
