Todo relatório de pipeline que analiso tem o mesmo ponto fraco. Os estágios estão desatualizados. Negócios ficam parados em "Proposta Enviada" dois dias depois que o contrato foi assinado porque um representante esqueceu de arrastar um cartão no quadro. É uma omissão pequena, mas ela torna sua previsão incorreta, seus números de velocidade pouco confiáveis e suas revisões de pipeline um jogo de adivinhação.

Existe uma solução simples. Em vez de depender de pessoas para atualizar os estágios dos negócios, você deixa o próprio documento acionar a mudança. Quando uma proposta é enviada, o negócio avança para "Proposta Enviada." Quando uma solicitação de assinatura é disparada, ele vai para "Contrato Enviado." Quando o documento é assinado, o negócio passa para "Fechado Ganho." Sem necessidade de memória.

Veja como configurar a progressão automática de estágios de negócios no HubSpot usando a propriedade Document Status do Portant e os workflows padrão do HubSpot. Se o seu pipeline parece estar sempre alguns dias atrás da realidade, provavelmente é por isso.

Por que as atualizações manuais de estágios falham

Os representantes estão ocupados. Eles estão em ligações, escrevendo e-mails, fazendo follow-up com compradores. Atualizar um estágio de negócio é uma tarefa de baixa prioridade que não agrega nenhum valor à venda em si. Por isso, ela é ignorada, postergada ou feita em lote no final da semana.

O impacto é maior do que a maioria dos líderes percebe. Se cinco representantes esquecerem de atualizar três negócios por semana, são quinze negócios parados no estágio errado a qualquer momento. Seu relatório de pipeline conta uma história para a liderança. A realidade conta outra.

As previsões dependem do estágio. Se o seu modelo de previsão pondera os negócios pela probabilidade do estágio, estágios desatualizados produzem números imprecisos. Um negócio que já foi fechado, mas ainda aparece como "Contrato Enviado," subestima sua receita fechada. Um negócio em que a proposta falhou, mas ainda aparece como "Proposta Enviada," superestima seu pipeline. Os dois cenários são problemáticos.

A solução não é mais disciplina ou mais um lembrete no Slack. Você nunca vai treinar pessoas para atualizar de forma confiável um campo no CRM toda vez que um evento externo acontece. A solução é eliminar a etapa manual por completo e deixar o próprio evento acionar a atualização.

O ciclo de vida do documento como sinal de pipeline

Quando você usa o Portant com o HubSpot, o Portant salva cada documento gerado como seu próprio registro (um Custom Object) no negócio. Esse registro possui uma propriedade chamada Document Status, que é atualizada automaticamente conforme o documento avança em seu ciclo de vida.

Esse é o sinal que seu pipeline precisa. Em vez de pedir aos representantes que monitorem a caixa de entrada e depois atualizem o HubSpot, a propriedade Document Status muda por conta própria quando algo real acontece. Um documento é enviado. Uma assinatura é solicitada. O documento é assinado. Algo dá errado. Cada uma dessas mudanças de status corresponde a um momento real no processo de vendas, o que significa que cada uma pode ser mapeada diretamente para um estágio do negócio.

Escrevi um artigo relacionado sobre como alinhar estágios de negócios com tipos de documentos que aborda o mapeamento conceitual entre estágios e documentos. Este artigo vai um passo além. Ele automatiza esse alinhamento para que o pipeline se atualize sozinho.

Valores de Document Status do Portant

O Document Object do Portant rastreia nove valores de status. Veja o que cada um significa e quando se aplica.

  • Pending: O Portant criou o registro do documento, mas a geração ainda não começou.
  • Draft: O Portant gerou o documento, mas ele ainda está em rascunho, não está finalizado.
  • Approved: Sua equipe revisou e aprovou o documento internamente. Isso se aplica se você usar os approval workflows.
  • Sent: O Portant entregou o documento ao destinatário.
  • Signature Requested: O Portant enviou uma solicitação de assinatura eletrônica ao(s) signatário(s).
  • Partially Signed: Pelo menos um signatário concluiu sua assinatura, mas outros ainda não assinaram.
  • Signed: Todos os signatários concluíram suas assinaturas.
  • Completed: O ciclo de vida do documento foi concluído, incluindo quaisquer etapas posteriores à assinatura.
  • Error: Algo deu errado durante a geração, o envio ou a assinatura.

Nem todo negócio passará pelos nove status. Uma cotação simples pode ir de Pending para Sent sem precisar de assinatura. Um contrato pode passar por Sent, Signature Requested, Partially Signed, Signed e Completed. Os workflows que você criar devem considerar os status que realmente importam no seu processo.

Para mais detalhes sobre como essas propriedades funcionam, consulte a documentação do Portant sobre como acionar workflows do HubSpot a partir de mudanças no status do documento.

Criando os workflows

A configuração usa a ferramenta padrão de workflows do HubSpot. Você criará workflows baseados em negócios que são acionados por mudanças na propriedade Document Status no Document Object do Portant associado.

Este é o mapeamento principal que recomendo para a maioria dos processos de vendas.

Workflow 1: Document Sent → Mover para "Proposta Enviada"

  1. Acesse Automation > Workflows no HubSpot.
  2. Crie um novo workflow baseado em negócios.
  3. Defina o gatilho de inscrição como: Associated Portant Document Object > Document Status is "Sent."
  4. Adicione uma ação: Set deal property > Deal Stage como "Proposta Enviada" (ou o estágio equivalente no seu processo).
  5. Salve e ative.

Quando o Portant entrega uma proposta ou cotação ao comprador, o Document Status muda para "Sent." Este workflow captura essa mudança e avança o negócio automaticamente.

Workflow 2: Signature Requested → Mover para "Contrato Enviado"

Mesma estrutura, gatilho diferente.

  1. Gatilho de inscrição: Document Status is "Signature Requested."
  2. Ação: Set deal stage como "Contrato Enviado."

Isso cobre o momento em que o processo de assinatura começa. O comprador recebeu o documento com uma solicitação de assinatura eletrônica, e o estágio do negócio deve refletir isso.

Workflow 3: Signed ou Completed → Mover para "Fechado Ganho"

  1. Gatilho de inscrição: Document Status is "Signed" OR "Completed."
  2. Ação: Set deal stage como "Fechado Ganho."

Você pode usar "Signed" ou "Completed" dependendo de como seu processo funciona. Se você precisa que todas as etapas pós-assinatura sejam concluídas antes de fechar o negócio, acione em "Completed." Se a assinatura final é o seu evento de fechamento, acione em "Signed."

Workflow 4: Error → Notificar o responsável pelo negócio

  1. Gatilho de inscrição: Document Status is "Error."
  2. Ação: Enviar uma notificação interna ao responsável pelo negócio com uma mensagem como: "Um documento em [Deal Name] apresentou um erro. Por favor, verifique o documento e reenvie se necessário."

Este é importante porque erros são invisíveis sem um alerta. Um representante pode não perceber que um contrato falhou na geração ou que uma solicitação de assinatura foi rejeitada. Uma notificação imediata evita que negócios fiquem parados silenciosamente.

Alternativa: um único workflow com ramificações

Se você preferir gerenciar menos workflows, pode criar um único workflow baseado em negócios com uma ramificação If/Then que verifica o valor de Document Status e direciona para a ação adequada. A lógica é idêntica, apenas a organização é diferente. Costumo começar com workflows separados porque são mais fáceis de depurar, e consolidar depois caso a equipe queira uma visão mais limpa.

Adicionando tags de negócios para visibilidade do pipeline

As tags de negócios são etiquetas coloridas que aparecem nos cartões de negócios na visualização de quadro do HubSpot. Elas oferecem aos representantes e gestores um indicador visual rápido ao escanear o pipeline sem precisar abrir cada negócio.

O Portant permite adicionar tags de negócios com base no Document Status, para que seu quadro de pipeline mostre de forma imediata em que ponto do ciclo de vida do documento cada negócio se encontra. Por exemplo:

  • Uma tag verde para negócios com status "Signed"
  • Uma tag amarela para negócios com status "Signature Requested"
  • Uma tag vermelha para negócios com status "Error"
  • Uma tag azul para negócios com status "Sent"

Isso é especialmente útil nas revisões de pipeline. Em vez de abrir cada negócio para verificar o progresso do documento, os gestores podem escanear o quadro e identificar imediatamente os negócios que precisam de atenção, seja uma assinatura travada ou um erro que passou despercebido.

Para instruções de configuração, consulte o guia do Portant sobre como adicionar tags de negócios usando status de documentos.

Casos extremos para planejar

Nenhuma automação funciona perfeitamente desde o primeiro dia. Aqui estão as situações que vejo travar equipes e como lidar com cada uma delas.

Vários documentos por negócio

Um único negócio pode ter um orçamento, uma proposta e um contrato, cada um com seu próprio Document Status. Se o orçamento estiver "Completed", mas o contrato estiver "Pending", qual status deve determinar o estágio do negócio?

Minha recomendação: use o status do documento mais recente como sinal principal. No registro de inscrição do seu workflow, você pode filtrar pelo template ou pelo nome do documento se usar convenções de nomenclatura consistentes. Isso exige alguns testes, mas acertar essa configuração evita que um orçamento concluído encerre o negócio prematuramente quando o contrato ainda nem foi enviado.

Propostas reenviadas

Se um representante reenvia uma proposta porque o comprador solicitou alterações, o Document Status percorrerá seus valores novamente. Seu workflow deve lidar com a reinscrição para que o estágio do negócio seja atualizado corretamente quando um novo status "Sent" aparecer em um documento diferente.

Esteja ciente de que isso pode fazer um negócio retroceder no pipeline. Se uma nova proposta for enviada depois que um contrato já estava em andamento, o negócio pode reverter para "Proposal Sent". Considere se seus workflows devem mover os estágios apenas para frente e nunca para trás. Para a maioria das equipes, recomendo uma lógica somente progressiva, com um workflow separado e deliberado para qualquer movimento de retrocesso.

Estados de erro

Um erro não significa que o negócio foi perdido. Significa que algo técnico deu errado, como uma falha na mesclagem de template ou um timeout do serviço de assinatura. O workflow de notificação do Workflow 4 é sua rede de segurança aqui. Certifique-se de que a notificação inclua contexto suficiente para o representante agir: o nome do negócio, o nome do documento e uma indicação para verificar o status em Portant.

Documentos parcialmente assinados

Para contratos com vários signatários, "Partially Signed" é um status intermediário útil. Talvez você não precise de um estágio de negócio separado para isso, mas uma tag de negócio como "Aguardando assinaturas" ajuda os gestores a acompanhar quais contratos estão em andamento em relação aos que estão parados aguardando um signatário específico.

O que isso faz pelos relatórios de pipeline

Quando os estágios de negócio são atualizados automaticamente com base em eventos reais de documentos, três coisas melhoram.

Precisão de previsão. Os estágios refletem o que realmente aconteceu, não o que um representante se lembrou de registrar. Se seu modelo de previsão usa probabilidades de estágio, essas probabilidades agora são baseadas na realidade, e não em uma estimativa do levantamento de dados da última sexta-feira.

Velocidade do pipeline. As métricas de tempo por estágio passam a ter significado. Você pode medir quanto tempo realmente leva de "Proposal Sent" para "Contract Sent", porque ambas as transições estão vinculadas a eventos de documentos, não a cliques manuais. Isso fornece dados reais sobre onde os negócios desaceleram.

Higiene do pipeline. Negócios desatualizados ficam mais fáceis de identificar. Se um negócio está em "Contract Sent" há duas semanas e o Document Status ainda mostra "Signature Requested", há algo de errado com o negócio, não com os dados. Os gestores podem concentrar as revisões de pipeline em coaching em vez de auditorias de entrada de dados.

Você configura isso uma vez e cada negócio que passa pelo pipeline recebe um estágio mais preciso sem que ninguém precise pensar nisso.

Primeiros passos

Se você já está usando Portant com HubSpot, a propriedade Document Status já está nos seus registros de documento. Comece com os quatro workflows principais que descrevi acima. Teste-os em alguns negócios antes de implementá-los para toda a equipe.

Se você quiser se aprofundar em como os estágios e os documentos devem se conectar conceitualmente, leia meu artigo anterior sobre como mapear estágios de negócio para tipos de documento.

E se você ainda não usa o Portant, a página de integração com HubSpot explica o que ele faz e como configurá-lo.

Perguntas frequentes

Isso funciona com qualquer pipeline de negócios no HubSpot?

Sim. Os workflows são acionados pela propriedade Document Status dos Portant Document Objects associados, que não está vinculada a um pipeline específico. Você pode definir mapeamentos de estágio diferentes para pipelines diferentes usando ramificações de workflow.

E se os meus estágios de negócio não corresponderem aos exemplos?

O mapeamento é totalmente flexível. Os exemplos que usei ("Proposal Sent", "Contract Sent", "Closed Won") são rótulos comuns, mas você deve mapear as mudanças de Document Status para os estágios que o seu pipeline realmente utiliza. O importante é que cada mudança de status corresponda a uma transição de estágio significativa para o seu processo.

Isso vai substituir as alterações manuais de estágio?

Depende de como você configura os workflows. Se um representante mover manualmente um negócio para "Closed Won" antes de o documento ser assinado, o workflow não irá revertê-lo a menos que você o configure especificamente para isso. Recomendo criar workflows que movam os estágios apenas para frente. Se você precisar de movimento de retrocesso, adicione-o como um workflow separado com salvaguardas extras e documentação clara para a equipe.

Posso usar isso com workflows de aprovação também?

Sim. Se sua equipe usa o workflow de aprovação do Portant, o Document Status é atualizado para "Approved" após a revisão interna. Você pode adicionar um workflow que move o negócio para um estágio como "Pending Send" ou "Ready for Buyer" quando isso acontece. Isso é útil para equipes que precisam da aprovação do gestor antes de qualquer proposta ser enviada a um cliente.