👤 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 email 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 desenho do ciclo de ajuste
Um ciclo de ajuste precisa de destino, motivo da devolução e caminho de retorno para a análise. A movimentação manual registra uma transição, mas esse movimento, sozinho, não garante o registro estruturado do motivo do ajuste e da resposta esperada.
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
Cada rodada acrescenta contexto: o que precisa mudar, quem pediu o ajuste e quando. Mantenha esse registro separado dos campos que receberão a resposta corrigida. Substituir uma resposta não deve substituir o registro do motivo da devolução.
Mantenha um campo Long Text dedicado ao histórico de ajustes. Acrescente motivo, data, hora e quem solicitou cada rodada antes de limpar ou substituir os campos de trabalho. Preserve os registros anteriores ao acrescentar uma nova rodada. Por exemplo: o comprovante de reembolso está ilegível, a pessoa revisora solicita outro arquivo e a análise seguinte registra se a substituição resolve a pendência.
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.
Movimentação controlada no retorno
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.
Defina as dependências entre registrar o motivo, avisar o solicitante, preparar os campos e mover o card. Um botão de ação ou uma automação pode apoiar a decisão de devolver a solicitação. A ordem das ações dependentes precisa ser planejada e testada; compartilhar um gatilho não garante, por si só, a ordem de execução.
Escolha o evento que representa a decisão da pessoa revisora e as regras necessárias para o retorno. Documente gatilho, condições e destino para que outra pessoa consiga entender o fluxo. Consulte as ações de automação documentadas no Help Center para aplicar esse desenho.
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 etiqueta de Retorno de ajuste ajuda a reconhecer as solicitações que aguardam correção na fila. Planeje sua atualização no fluxo de ajuste e defina quando deve ser removida ou mantida. Separe as etiquetas que descrevem uma fase daquelas que precisam acompanhar o card por todo o processo.
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.
Use o alerta de atraso da fase para acompanhar o tempo de permanência do card no ajuste. Esse controle é separado da data de vencimento do card. Combine o prazo de resposta, quem acompanha e o que acontece quando o limite é ultrapassado. Regras que calculam vencimento com calendário de trabalho têm outra finalidade e não equivalem ao alerta da fase. Consulte a documentação dos alertas.
Prepare a próxima rodada e teste o retorno
Limpe apenas as informações que precisam ser fornecidas novamente, depois de preservar o registro da rodada. Mantenha disponíveis os dados válidos da solicitação. Anexos contêm listas de arquivos: decida se a próxima rodada acrescenta um documento, remove um arquivo antigo ou substitui a lista. Em uma operação por API, ADD, REMOVE e REPLACE representam intenções diferentes. Consulte os operadores de atualização de campos.
Combine quando devoluções repetidas exigem escalonamento. Um contador é útil quando a equipe precisa desse indicador e consegue mantê lo de forma confiável. Se uma integração existente puder atualizá lo, avalie esse caminho; se forem necessárias várias tarefas de automação apenas para contar rodadas, compare o custo com o uso do histórico registrado.
Antes de liberar a alteração, execute duas rodadas consecutivas com uma solicitação de teste. Confira se os dois motivos permanecem com data e hora, se os campos corretos estão prontos para outra resposta, se a etiqueta representa a situação atual e se a solicitação retorna à pessoa revisora esperada. Confira também o alerta combinado para a fase.
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
☐ Você consegue definir e testar as dependências entre histórico, atualização de campos, etiquetas e movimentação.
Pronto para acompanhar solicitações que ficam no ajuste? Veja como planejar o escalonamento automático
