👤 Para todos os usuários
🔐 Disponível para todos os planos
🎯 Para quem já estruturou as fases e quer garantir que estão bem nomeadas e ordenadas
Nomear fases parece uma decisão cosmética. Na prática, é uma das que mais afeta a operação. Nomes ambíguos geram dúvidas sobre onde colocar um card. Fases demais travam o fluxo. Ordenação sem critério dificulta relatórios e torna automações confusas de manter.
A virada que resolve a maior parte dos problemas é simples: o nome de uma fase deve descrever o estado do card naquele momento, não a ação que acontece nela. Essa distinção muda como o processo inteiro é pensado e comunicado.
📖 O que você vai aprender aqui:
O erro mais comum: fases que descrevem ações, não estados
Quando alguém cria um pipe pela primeira vez, a tendência natural é nomear as fases como tarefas: "Analisar", "Aprovar", "Enviar", "Finalizar". Parece lógico porque é assim que descrevemos o trabalho em reuniões.
O problema é que uma fase no kanban não representa o que alguém está fazendo. Representa onde o card está. E "onde o card está" é sempre um estado, não uma ação.
Quando a fase se chama "Aprovar orçamento", não fica claro se o card está esperando aprovação, sendo analisado ou já aprovado. Quando se chama "Aguardando aprovação", não há ambiguidade: o card está parado ali até que alguém tome uma decisão.
A tabela abaixo mostra a conversão para o processo de onboarding de colaboradores:
| Fases orientadas por ação (evitar) | Fases orientadas por estado (usar) |
| Analisar solicitação | Em análise |
| Aprovar orçamento | Aguardando aprovação |
| Enviar documentos | Documentação pendente |
| Configurar acessos | Acessos em configuração |
| Finalizar onboarding | Concluído |
Teste rápido: leia o nome da fase em voz alta e complete a frase "O card está...". Se completar naturalmente, o nome está orientado por estado. Se soar estranho, provavelmente é uma ação disfarçada de fase.
Critérios para nomear fases com consistência
Além da orientação por estado, três critérios ajudam a manter a nomenclatura consistente ao longo de todo o pipe:
Clareza sobre responsabilidade. O nome da fase deve deixar implícito quem age ou quem espera. "Aguardando aprovação do gestor" é mais informativo que "Aprovação" porque deixa claro que o próximo passo não é do operador, é do gestor. O time sabe sem abrir o card.
Consistência de tempo verbal. Misturar "Em análise" com "Documentos enviados" com "Aprovar" dentro do mesmo pipe cria ruído visual. Escolha um padrão e mantenha: ou gerúndio (Em análise, Em configuração), ou substantivo (Análise, Configuração), ou participio (Documentação recebida, Acessos configurados). O padrão importa mais do que qual padrão.
Unicidade. Cada fase deve ter um nome que não confunda com nenhuma outra do mesmo pipe. "Revisão" e "Revisão final" parecem distintas, mas geram dúvida operacional constante sobre onde colocar cada card. Se você sente necessidade de adicionar "final" ou "novo" para diferenciar, provavelmente são a mesma fase ou uma delas não precisa existir.
Nomes de fase aparecem em relatórios, filtros e automações. Uma fase renomeada depois que automações estão ativas exige revisão manual das regras que referenciam aquele nome. Decida o padrão de nomenclatura antes de criar automações.
Descrição de fase: onde SLA e responsabilidade ficam documentados
Cada fase tem um campo de descrição que a maioria dos times ignora. É um erro: a descrição de fase é o único lugar onde SLA, responsável e orientação operacional ficam registrados de forma persistente, visíveis para qualquer pessoa que abrir o pipe, inclusive quem entrar no time depois.
O padrão recomendado pelo time de especialistas Pipefy define três elementos para a descrição de cada fase:
| Elemento | O que registrar | Exemplo (fase: Documentação pendente) |
| SLA | Prazo esperado para essa etapa | SLA: 2 dias úteis |
| Responsável | Quem opera ou aprova nessa fase | Responsável: Analista de RH |
| Orientação breve | O que deve ser feito ou verificado | Solicitar ao colaborador o envio de RG, CPF e comprovante de residência pelo formulário. |
Uma fase bem descrita elimina a necessidade de documentação paralela. Quem abrir o pipe e passar o cursor sobre a fase vê imediatamente: qual o prazo esperado, quem é responsável e o que precisa ser feito antes de avançar o card.
Exemplo completo para a fase "Documentação em análise" do onboarding:
SLA: 1 dia útil.
Responsável: Analista de RH.
Verificar se todos os documentos foram enviados corretamente. Caso algum esteja faltando ou ilegível, mover o card para Ajuste pendente e notificar o colaborador.
Descrições de fase com SLA têm um efeito colateral positivo: forçam a equipe a definir expectativas reais de tempo para cada etapa antes de lançar o processo. Times que nunca definiram SLA usam esse momento como primeira conversa sobre o que é um prazo razoável.
Quantas fases um pipe deve ter
Não existe número ideal fixo, mas existe um critério claro: cada fase precisa representar um estado distinto que muda quem é responsável, o que está esperando ou qual informação precisa ser coletada.
O consenso de quem constrói processos profissionalmente no Pipefy é manter entre 10 e 15 fases. Acima de 10, já vale avaliar a divisão do processo. Acima de 15, a manutenção começa a ser problemática.
O sinal de que há fases demais: o time começa a pular fases, mover cards por dois ou três estágios de uma vez ou criar cards diretamente em fases do meio do processo.
O sinal de que há fases de menos: cards ficam parados por muito tempo em uma única fase sem que seja possível entender em qual sub-etapa estão ou quem é o responsável. Isso geralmente aparece como uma fase chamada "Em andamento" que acumula tudo.
Fases de arquivo e cancelamento têm papel específico: são destinos finais para cards que saíram do fluxo normal. Separe visualmente o que está em execução do que foi concluído, arquivado ou cancelado.
Ordenação lógica: da triagem à conclusão
A ordem das fases deve refletir a sequência real de decisões do processo, não uma aspiração sobre como ele deveria funcionar. Dois padrões funcionam bem na prática:
Da triagem para a execução para a conclusão. A maioria dos processos começa com uma entrada (solicitação recebida, candidatura chegou, pedido aberto), passa por etapas de análise ou execução e termina em um estado final (concluído, cancelado, arquivado). Esse fluxo da esquerda para a direita é o que o time deve conseguir ler sem explicação.
Responsabilidade muda de coluna para coluna. Quando o card avança de fase, quem age muda. Se duas fases consecutivas têm o mesmo responsável fazendo o mesmo tipo de trabalho, a ordenação pode estar fragmentando uma etapa que deveria ser contínua.
No onboarding de colaboradores, a ordem funcional seria:
- Solicitação recebida: entrada do processo, card criado pelo formulário
- Documentação pendente: aguardando envio pelo novo colaborador
- Documentação em análise: RH verificando o que foi enviado
- Equipamentos solicitados: TI acionado para preparar o setup
- Acessos em configuração: TI configurando sistemas e permissões
- Concluído: colaborador integrado e processo encerrado
Cada transição muda o responsável ou o estado de espera. Não há fase que poderia ser removida sem perder rastreabilidade.
Antes de publicar o pipe, confirme:
☐ Cada fase descreve o estado do card, não a ação que acontece nela
☐ O padrão de tempo verbal é consistente em todas as fases
☐ Nenhuma fase tem nome que poderia ser confundido com outra
☐ Cada fase tem descrição com SLA, responsável e orientação breve
☐ Fases com o mesmo responsável e sem automação distinta foram consolidadas
☐ A ordem da esquerda para a direita reflete a sequência real do processo
☐ Há uma fase de conclusão clara e separada das fases operacionais
