VelloFlow

Vellow Sistemas

O analista publica o fluxo.
A TI não entra.

O VelloFlow é um CRM com BPM: quem conhece a regra monta o formulário, desenha as etapas, escolhe os aprovadores e publica — sem programar e sem deploy. Cada pedido vira tarefa com dono, prazo e histórico, e o CRM enxerga o processo: o comercial vê o status do desconto na ficha do cliente, sem sair da tela.

0 solicitações sem dono — e o painel mostra esse número mesmo quando é zero
cada regra que protege a tarefa existe duas vezes: no sistema e no banco
194 verificações automáticas passando a cada mudança

Três coisas que um sistema de processo não pode errar

Não são recursos: são as decisões que dão forma ao resto. Um sistema que erra qualquer uma delas volta a exigir o e-mail ao lado — e o e-mail é onde o pedido de férias some.

O processo é dado, não código

Formulário e etapas são um JSON versionado, montado na tela. Se o fluxo fosse código, mudar uma alçada exigiria deploy — e o produto viraria “peça para a TI”, que é exatamente o que ele existe para acabar.

Nenhuma solicitação sem dono

Uma tarefa pendente por solicitação, garantido por índice único no banco — não por um if. Duas aprovações no mesmo instante passam por qualquer conferência de aplicação: entre a leitura e a gravação cabe a outra requisição. Nenhuma passa pelo índice.

Mudar o fluxo não reescreve o passado

A solicitação nasce presa a uma versão e morre nela. Sem isso, alguém apareceria tendo aprovado uma etapa que não existia quando pediu — e a auditoria de ponto, férias e desconto deixaria de valer no dia em que mais importa.

O que o sistema faz

Nove blocos que já estão no ar. Cada um existe porque resolve um problema que a empresa hoje resolve no e-mail, no grupo de WhatsApp ou na planilha do gestor.

Construtor de formulário

Texto, número, moeda, data, lista, CPF/CNPJ, pessoa, empresa e anexo. Campo obrigatório, ajuda e ordem. O que a etapa não edita continua visível — quem aprova precisa do contexto que decide.

Desenho do fluxo

Início, tarefa, aprovação, decisão e fim, com prazo por etapa. Cada etapa diz para quem vai: solicitante, gestor de quem abriu, papel, equipe ou a pessoa escolhida no formulário.

Alçada por valor

A decisão compara campo com valor — oito operadores, sem código escrito por usuário. Acima de dez mil vai para a diretoria; abaixo, para o gestor. A comparação é numérica, e não textual: "9000" > "10000" é verdade em texto, e seria o desconto fugindo da alçada.

Caixa de entrada

Atrasadas, vencem hoje, minhas, da minha equipe, do meu time e as que eu abri. Abre em atrasadas: uma caixa que abre em “tudo” é uma lista que ninguém termina de ler.

Filas de equipe

A tarefa endereçada à equipe aparece para todos e some quando alguém assume — e guarda quem assumiu. “A equipe RH aprovou” não responde a pergunta que a auditoria faz.

Prazo em horas úteis

Com expediente, dias úteis e feriados da empresa. Em horas corridas, uma tarefa de 4 h aberta às 17h de sexta venceria no sábado de madrugada — e na segunda o painel mostraria o time inteiro em atraso por um prazo que ninguém teve como cumprir.

Escalonamento

A tarefa que estoura o prazo sobe sozinha para o gestor de quem deveria agir, uma única vez, com a linha no histórico. O workflow cobra; não espera o RH lembrar.

CRM ligado ao processo

Empresas, contatos, funil configurável e atividades. A solicitação pode nascer ligada ao cliente — e aí ela aparece na ficha dele, com a etapa atual e o nome de quem precisa agir.

Painel e auditoria

Gargalo por etapa (não por processo), tempo médio, atrasadas e o número que quase ninguém mostra: solicitações vivas sem tarefa. Mais a trilha, que não aceita alteração nem exclusão.

O caminho de uma solicitação, do pedido ao fim

Cada passo grava quem fez, quando, com que comentário e com os dados do formulário naquele momento — imutável por trigger no banco. É o que responde “quem aprovou isso”.

  1. 1

    Aberta

    Do catálogo, com o formulário da versão publicada. O caminho aparece antes de enviar: quem sabe que o pedido vai para a diretoria escreve uma justificativa melhor.

  2. 2

    Distribuída

    O motor resolve o destino e grava na tarefa quem era o gestor naquele dia. Recalcular na leitura mudaria o dono de uma tarefa em andamento quando alguém trocasse de chefe.

  3. 3

    Na caixa de alguém

    Com prazo em horas úteis e lembrete antes do vencimento. Se vencer, sobe para o gestor — uma vez, e com a linha no histórico.

  4. 4

    Decidida

    Aprovar, recusar ou devolver. Recusa sem motivo é recusada pelo sistema: é o que faz a pessoa reabrir o mesmo pedido na semana seguinte.

  5. 5

    Devolvida, quando falta algo

    Volta para quem abriu, com o formulário inteiro liberado e o motivo escrito. É melhor que recusar por falta de informação — e o histórico mostra as duas voltas.

  6. 6

    Encerrada

    Concluída ou recusada, conforme o nó de fim que o fluxo alcançou. Com data de fechamento — sem ela, ela sairia da média de tempo sem avisar.

  7. 7

    Auditável para sempre

    A linha do tempo guarda a versão do fluxo usada e os dados do formulário em cada passo. Serve para LGPD, auditoria interna e fiscalização.

As regras que o sistema não deixa furar

Cada uma existe porque custa caro quando falha. As marcadas com banco não dependem do sistema: valem mesmo para quem abrir o banco por fora.

  1. Uma solicitação viva tem uma tarefa pendente, no máximo. banco
  2. Um processo tem uma versão publicada por vez. banco
  3. A definição de uma versão publicada não muda mais. banco
  4. Um fluxo inválido não publica: decisão sem saída padrão é erro.
  5. Nó que não aponta para lugar nenhum é erro, não aviso.
  6. Tarefa concluída não reabre — devolver cria uma tarefa nova. banco
  7. Tarefa pendente tem sempre um destino de verdade. banco
  8. Só age na tarefa quem é o destinatário dela.
  9. Aprovação por gestor sem gestor cadastrado recusa — não cai no solicitante.
  10. Recusa exige motivo, quando a conta assim quiser.
  11. A linha do tempo da solicitação não se altera nem se apaga. banco
  12. A trilha de auditoria também não. banco

O que já está pronto e o que vem depois

Dizer o que ainda não existe é parte da entrega. Recurso prometido e não entregue é o que faz o cliente parar de acreditar no que foi entregue.

Entrega 1 — no ar

Empresas, pessoas, equipes, hierarquia e permissões. CRM com empresas, contatos, funil configurável e atividades. Construtor de formulário e desenho do fluxo com início, tarefa, aprovação, decisão e fim. Publicação, versionamento e execução. Caixa de entrada com filas, prazos em horas úteis, escalonamento e linha do tempo. Quatro processos prontos. Painel, auditoria e API autenticada.

Fase 2

Canvas visual de arrastar e soltar. Etapas em paralelo com junção. Rotinas agendadas (“todo dia 1 roda X”) e gatilhos por evento do CRM. Anexos de verdade com armazenamento. Notificação por e-mail e WhatsApp com fila e reprocessamento. Delegação e substituto de férias.

Fase 3

Conectores HTTP com segredo protegido e webhooks de entrada. Subprocessos. Assinatura eletrônica. Portal público de solicitação. Construtor de painéis. Assistente que sugere fluxo e aponta gargalo.

Quer ver com dados de verdade?

O sistema já sobe com uma empresa de demonstração — sete pessoas com hierarquia, duas equipes, cinco clientes, um funil com seis oportunidades, os quatro processos publicados e cinco solicitações em andamento, uma delas com o prazo estourado. É o estado real de uma empresa numa terça-feira, não uma tela de exemplo.